Modelo exploratorio del transporte de carga en México

Texto completo

(1)ll? -Z ti.

(2) INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS CIUDAD DE MÉXICO. ,. TECNOLOGICO DE MONTERREY®. PRoModel y EMF on Rails: Facilitando y agilizando el desarrollo de prototipos de aplicaciones web con y sin incertidumbre por. Ing. Rosa Atzimba López Landa. Tesis Presentada al Programa de Graduados de la Escuela de Diseño, Ingeniería y Arquitectura como requisito parcial para obtener el grado académico de Doctor en Ciencias Computacionales. Supervisada por • Dra. Juana Julieta Noguez Monroy . '·. México, 2013. ~. DE MONTEP.REY.

(3) ,.. INSTITUTO TECNOLOGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS CIUDAD DE MÉXICO Escuela de Diseño, Ingeniería y Arquitectura Programa de Graduados. Los miembros del comité de tesis recomendamos que la presente tesis de:. Rosa Atzimba López Landa sea aceptada como requisito parcial para obtener el grado académico de:. Doctor en Ciencias Computacionales. Comité de Tesis:. V('. ,'. 70. /. j¡f. ~/ ·- hL¿.uJ~. F. (9ra. 1. J'ulieta Noguez Monroy. Asesora de la tesis. Sinodal. Sinodal. _.----:?'. .. ~~,e. 1. ... ~r~~· Malina Espinosa Director del programa. México, D.F. a 16 de abril de 2013.

(4) INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS CIUDAD DE MÉXICO. PRoModel y EMF on Rails: Facilitando y agilizando el desarrollo de prototipos de aplicaciones web con y sin incertidumbre por. Rosa A tzimba López Landa Ingeniera en Sistemas Computacionales. Tesis Presentada al Programa de Graduados de la Escuela de Diseño, Ingeniería y Arquitectura como requisito parcial para obtener el grado académico de Doctor en Ciencias Computacionales. Distrito Federal, México Abril de 2013.

(5) A mi mamá y hermano..

(6) Resumen. En la actualidad muchos individuos y organizaciones se dedican al desarrollo de sistemas computacionales a la medida. La implementación de estos sistemas siempre involucra la definición y desarrollo de entidades que permiten administrar información. Aunque estas entidades varían entre los diferentes dominios y a pesar de que su funcionamiento es equivalente, su elaboración incrementa notablemente los tiempos y costos de desarrollo de los sistemas, por lo que el esfuerzo requerido es muy grande, y demanda del conocimiento técnico en bases de datos y lenguajes de programación. En este contexto, el desarrollo rápido de aplicaciones es una metodología que mejora la productividad del desarrollo de software al agilizar la construcción de nuevos sistemas a partir de componentes existentes. La reutilización de componentes de software elimina la necesidad de invertir tiempo y esfuerzo en el desarrollo de artefactos que se pueden generar de forma automática, lo que también reduce los costos de desarrollo. Del mismo modo, la ingeniería dirigida por modelos ayuda a aumentar la capacidad de mantenimiento general de los sistemas y promueve una mejor gestión de los cambios tecnológicos que estos deben atravesar. La importancia de contar con una metodología de desarrollo rápido de aplicaciones en conjunto con técnicas dirigidas por modelos que brinde las pautas para el desarrollo de sistemas recae en la idea de que se pueden disminuir el esfuerzo, tiempo y costos de desarrollo y mantenimiento de los mismos, permitiendo que se reutilicen sus estructuras y componentes; y promoviendo mayores niveles de productividad. Así es posible liberar a los desarrolladores de tareas repetitivas, y se favorece la generación de código esqueleto a partir de comandos de nivel superior; lo que elimina la necesidad de dominar lenguajes y herramientas de programación.. R. A. López Landa. IX.

(7) RESUMEN Por otra parte, muchos dominios tienen asociado cierto grado de incertidumbre. La incertidumbre surge cuando se tienen modelos incompletos o aproximados para la representación del conocimiento. Las redes bayesianas son herramientas que permiten modelar con éxito la deficiencia de la información. Los modelos relacionales probabilistas son estructuras que permiten que se combinen modelos de datos relacionales con redes bayesianas. No obstante, aunque estos modelos han sido propuestos en un marco teórico, hasta el momento no hay herramientas de software que faciliten su construcción. Dado lo anterior, en este trabajo de investigación se propone el diseño de dos metodologías que agilicen y faciliten el desarrollo de sistemas con incertidumbre y de generadores para familias de aplicaciones web. Para la definición de las metodologías se contempló la generación automática de código a partir de modelos del dominio. Estas metodologías han sido sustentadas a través del desarrollo de dos herramientas para el desarrollo de aplicaciones web: (1) PRoModel, que facilita y agiliza el desarrollo de sistemas con incertidumbre a partir de modelos relacionales probabilistas; y (2) EMF on Rails, que facilita el diseño de generadores de aplicaciones y automatiza la elaboración. de familias de aplicaciones web a partir de modelos de dominio específico. De esta forma se agiliza el desarrollo de componentes de software al combinar herramientas para el desarrollo rápido de aplicaciones con técnicas de desarrollo dirigidas por modelos, y se facilita la creación de prototipos funcionales de aplicaciones web con y sin incertidumbre.. Palabras clave: Arquitectura orientada a servicios; Desarrollo dirigido por modelos; Desarrollo rápido de aplicaciones; Incertidumbre; Modelos relacionales probabilistas; Redes bayesianas.. X. Tesis doctoral.

(8) "Menos del 10 % del código tiene que ver directamente con el propósito del sistema; el resto tiene que ver con la entrada y salida, validación de datos, mantenimiento de estructuras de datos y otras labores domésticas." ~. R. A. López Landa. MaryShaw. XI.

(9) IIX.

(10) ,. Indice Resumen. IX. Índice Índice de figuras. XIII XVII. Índice de tablas. XIX. Agradecimientos. XXI. Apoyo recibido. XXIII. Abreviaciones. XXV. l. Introducción l. l. Antecedentes 1.2. Motivación . . . . . . . 1.3. Propuesta de solución 1.4. Objetivos . . . . . . . . 1.5. Hipótesis . . . . . . . . 1.6. Estructura del documento. I. Marco teórico y estado del arte. 2. Desarrollo dirigido por modelos 2.1. Introducción . . . . . . . . 2.2. Fundamentos . . . . . . . . 2.3. Arquitecturas de software . 2.3.1. Arquitectura orientada a servicios 2.4. Arquitectura dirigida por modelos 2.4.1. Jerarquía de meta-modelos 2.4.2. Modelos . . . . . . . . . . . 2.4.3. Transformaciones . . . . . . 2.4.4. Lenguajes de transformación 2.4.5. Principios generales . . . . 2.5. Desarrollo rápido de aplicaciones . . 2.6. Trabajo relacionado . . . . . . . . . . 2.6.1. Un enfoque para el desarrollo de aplicaciones utilizando MOA 2.6.2. Un enfoque MOA basado en BPM para el desarrollo de aplicaciones R. A. López Landa. 1. 1 2 4 5 5 6. 7 9. 9 10 11 12 13 14 16 17 18 19 19 21 21 22 XIII.

(11) ÍNDICE. 2.6.3. Un enfoque para el desarrollo de aplicaciones con MOA y WebML 2.6.4. Análisis . . . . . . . . . . . . . . . . . . 2.7. Resumen . . . . . . . . . . . . . . . . . . . . . . 2.7.1. Áreas de oportunidad en investigación 3. Redes bayesianas 3.1. Introducción 3.2. Incertidumbre 3.3. Redes bayesianas 3.3.1. Definición 3.3.2. Independencia condicional 3.3.3. Propagación e inferencia . . 3.4. Redes bayesianas dinámicas . . . . 3.5. Modelos relacionales probabilistas 3.5.1. Definición . . . . . . 3.5.2. Modelo relacional .. 3.5.3. Modelo probabilista 3.6. Aplicaciones . . . . 3.7. Trabajo relacionado 3.7.1. BayesiaLab 3.7.2. Elvira . . . . 3.7.3. OpenMarkov 3.7.4. Discusión .. 3.8. Resumen . . . . . . . 3.8.1. Áreas de oportunidad en investigación. II. 24 24 25 26 27 27 28 29 30 31 33 33 34 34 35 36 37 38 39 40 41 42 43 43. Metodologías Pnn2Web y Ecore2Web. 45. 4. PRoModel 4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Descripción de la metodología 4.3. Arquitectura . . . . . . . . . . . . . . . . 4.3.1. Componentes de la arquitectura 4.3.2. Capas de la arquitectura . . . . . 4.4. PRMs dirigidos por modelos 4.4.1. Meta-modelos Ecore . . 4.4.2. Transformaciones ATL . 4.5. Interfaz gráfica de usuario 4.5.1. Aplicación web 4.5.2. Editor gráfico 4.6. PgmBus . . . . . . 4.7. Archivo XML . . . . 4.8. Control de acceso . . 4.9. Automatización de pruebas de unitarias y de integración 4.10. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 47 47 48 49 50 51 53 54 57 58 58 60 62 63 64 66 67. 5. EMF on Rails 5.1. Introducción. 69 69. XIV. Tesis doctoral.

(12) ÍNDICE. 5.2. Descripción de la metodología 5.3. Arquitectura . . . . . . . . . . . . . . . . 5.3.1. Componentes de la arquitectura 5.3.2. Capas de la arquitectura . . . . . 5.4. Generador de familias de aplicaciones web 5.4.1. Anotaciones (Perfil UML) 5.4.2. Meta-modelo del add-on . . . . . . . 5.4.3. Transformaciones ATL . . . . . . . . 5.5. EOR: Lenguaje de dominio específico para definir add-ons . 5.6. Plug-in de Eclipse . . . . . . . . 5.7. Web2Xmi . . . . . . . . . . . . . 5.7.1. Generador web de EMF 5.7.2. Editor web de EMF . 5.8. Resumen . . . . . . . . . . . . .. 111. Evaluación y resultados. 70 71 72. 74 75 76 78. 79 80 81 83 83 85 90. 91 93 93 94 94. 6. Caso de estudio 1: Evaluación de PRoModel 6.1. Introducción . . . . . . . . . . 6.2. Sistemas tutores inteligentes . 6.2.1. Componentes 6.3. SiEntrenO . . . . . . . . . . . 6.3.1. Modelo físico . . . . . 6.3.2. Modelo del estudiante 6.4. Obtención del sistema tutor inteligente con PRoModel 6.4.1. Resultados . . . . . . . . . . 6.5. Pruebas de usabilidad y de estrés . 6.5.1. Prueba de usabilidad . . . . 6.5.2. Prueba de estrés . . . . . . . 6.6. Métricas para la calidad del software . 6.7. Resumen . . . . . . . . . . . . . . . . .. 101 104 104 104 107 108 110. 7. Caso de estudio 2: Evaluación de EMF on Rails 7.1. Introducción . . . . 7.2. Evaluación en línea . . . . . . . . 7.3. TecEval . . . . . . . . . . . . . . . 7.3.1. Modelo entidad-relación . 7.3.2. Arquitectura . . . . . . . . 7.4. Obtención del problemario dinámico con EMF on Rails 7.4.1. Desarrollo de los comandos para la bitácora 7.4.2. Desarrollo del sistema TecEval . 7.4.3. Resultados . . . . . . . . . . . . 7.5. Métricas para la calidad del software . 7.6. Resumen. 111 111 112 113 114 116 117 118 120 124 125 125. 8. Resultados 8.1. Introducción . . . . . . . . . . . . . . 8.2. Estimación en proyectos de software. 129 129 130. R. A López Landa. 96. 97 99. XV.

(13) ÍNDICE. 8.3. 8.4. 8.5.. 8.6.. 8.2.1. Estimación del tamaño del sistema . . . 130 131 8.2.2. Estimación de la duración del proyecto 8.2.3. Estimación del esfuerzo requerido 132 Información del experimento . . . . . . . 133 Conceptos de probabilidad 135 Pruebas de hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 138 8.5.1. Ejecución de la prueba de hipótesis 1 139 8.5.2. Ejecución de la prueba de hipótesis 2 8.5.3. Análisis de resultados . . . . . . . . . 141 8.5.4. Comprobación de resultados 141 Resumen . . . . . . . . . . 143. 9. Conclusiones y trabajo futuro 9.1. Conclusiones . . . . . . . 9.2. Aportaciones realizadas 9.3. Trabajo futuro . . . . . .. Publicaciones derivadas de la investigación Referencias. IV. Anexos. Anexo A. Fundamentos de las redes bayesianas Anexo B. Propagación e inferencia en redes bayesianas Anexo C. Factores y métricas para la calidad del software Anexo D. Vistas de la arquitectura. 145 145 147 149. XXVII XXIX. XXXIX XLI XLV XLVII. LI. Anexo E. Vista de casos de uso y de procesos de PRoModel. LIII. Anexo F. Vista de casos de uso y de procesos de EMF on Rails. XCI. Anexo G. Vista lógica de la arquitectura. cm. Vita. XVI. CXVII. Tesis doctoral.

(14) .,. Indice de figuras 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7.. Procesos de desarrollo de software. . . . . . . Ejemplo de modelos y meta-modelos. . . . . Meta-modelos y transformaciones en MOA. . Arquitectura del estándar QVT de la OMG. Traducido de [OMG05]. Desarrollo de una aplicación web con Spring Roo. . . . . . . . . . . . . Artefactos generados por Spring Roo para cada entidad del dominio. Proceso de desarrollo de MOA. Tornada de [SVGFJA08] .. 14 15 17 18 20 20 23. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7.. Ejemplos de redes bayesianas. . . . . . . . . . . . . . . . Red bayesiana con tablas de dependencia condicional. . Tipos de conexiones de las redes bayesianas. Red bayesiana dinámica. . . . . Modelo relacional probabilista. . . . . . . . . Modelo relacional de un PRM. . . . . . . . . Modelo probabilista de un PRM con N tablas de probabilidad condicional para el nodo A. . . . . . . Interfaz gráfica de BayesiaLab. . Interfaz gráfica de Elvira. . . . . Interfaz gráfica de OpenMarkov. Componentes para los algoritmos de inferencia de la arquitectura de OpenMarkov. Tornada de [AC09] .. 29 30 32 33 35 36. 3.8. 3.9. 3.10. 3.11.. Metodología Prm2Web. . . . . . . Componentes de PRoModel. . . . Modelo de capas de la arquitectura de PRoModel. . Proceso de transformación de los PRMs. . . . . . . Meta-modelo para la representación de PRMs. . . Meta-modelo para la representación de modelos relacionales. Meta-modelo para la representación de redes bayesianas. . . . Fragmento de las reglas de transformación para las entidades. Aplicación web de PRoModel. . . . . . . . . . . . . . . . . . . . Patrón MVC utilizado para la definición de la capa de presentación. . Editor gráfico de PRoModel. . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de clases del componente: PgmBus. . . . . . . . . . . . . . . Archivo XML para la definición de PRMs basado en el meta-modelo de la figura 4.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.14. Aviso de seguridad que intercepta las llamadas para la ejecución de los servicios ... 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9. 4.10. 4.11. 4.12. 4.13.. R. A. López Landa. 37 39 40 41 42 48 50 52 54 55 55 56 57 59 59 61 62 64 65 XVII.

(15) ÍNDICE DE FIGURAS. 4.15. Tag de seguridad que muestra los objetos de la GUI. 4.16. Prueba de integración . . 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. 5.9. 5.10. 5.11. 5.12. 5.13. 5.14. 5.15. 5.16.. 65 66. Metodología Ecore2Web. Componentes de EMF 011 Rails. Modelo de capas de la arquitectura de EMF 011 Rails. . Proceso para el desarrollo de aplicaciones web de un dominio específico. Meta-modelo Ecore anotado visto desde Eclipse. . . . . . . . . . . . . . . Meta-modelo para los add-ons de Spri11g Roo. . . . . . . . . . . . . . . . . Fragmento del query de ATL para generar el script de comandos de Spri11g Roo. . . . . . . . . . . . . . . . Gramática del DSL de EMF 011 Rails. . . . . . . . . . . . . . . . . . Plug-in de EMF on Rails. . . . . . . . . . . . . . . . . . . . . . . . . Metodología Ecore2Web adaptada para el desarrollo de Web2Xmi. Instancia del add-on del generador web de EMF descrito con el lenguaje EOR. Anotaciones del editor web de EMF. Modelo simplificado Ecore. . . . . . . . . . . . Modelo simplificado Ecore anotado. . . . . . . Aplicación Web2Xmi generada por Spring Roo. Editor de árbol de Eclipse. . . . . . . . . . . . .. 70 73 74 75 77 78 79 80 82 83 84 85 86 86 88 89. 6.1. Arquitectura clásica de un ITS propuesta por Wenger (1987). Traducido de [DH05]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Sistema simplificado de una planta termodinámica de ciclo combinado. Tornado de [BR12]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. Modelo de dominio del sistema tutor inteligente. Tornado de [BR12] 6.4. Red bayesiana del sistema SiEntrenO. . . . . . . . . . . . . . . . . . . 6.5. Modelo relacional probabilista del sistema tutor inteligente para el entrenamiento de operadores del sector eléctrico. . . . . 6.6. Desarrollo del ITS a través de la metodología Prm2Web. 6.7. GUis del sistema tutor inteligente. . . . . 6.8. PRM generado en la sesión demostrativa. 6.9. Resultados de la prueba de usabilidad. . .. 101 102 103 105 106. 7.1. 7.2. 7.3. 7.4. 7.5. 7.6. 7.7. 7.8. 7.9.. 114 115 116 117 118 119 121 122 123. Ejemplo de una pregunta dinámica para un alumno. Tornado de [JR13]. Modelo entidad-relación del problernario dinámico. Tornado de [JR13]. . Arquitectura de TecEval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Desarrollo del problernario dinámico a través de la rnetología Ecore2 Web. Entidades que forman parte de la bitácora de eventos. . . . . . . . . . . . Modelo del add-on de la bitácora de eventos definido con el lenguaje EOR. Meta-modelo Ecore del problemario dinámico. Slzell de Spri11g Roo. . . . . . . . . GUis del problemario dinámico. . . . . . . . .. 8.1. Gráficas de caja y de extensión del tiempo y esfuerzo requeridos y estimados para el desarrollo de los prototipos funcionales de aplicaciones web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2. Tabla de la distribución t de stude11t. Tomado de [WMMY07). . . . . . . . 8.3. Resultados de la prueba de hipótesis 1 obtenidos mediante el lenguaje R. 8.4. Resultados de la prueba de hipótesis 2 obtenidos mediante el lenguaje R. XVIII. 95 97 99 100. 135 137 142 142. Tesis doctoral.

(16) ,. Indice de tablas 2.1. Capas de la arquitectura dirigida por modelos. . . . . . . . . . . . . . . . 16 2.2. Resultados de la prueba de concepto del enfoque propuesto en [MdSB08]. 22 2.3. Cuadro comparativo de las arquitecturas que combinan los enfoques MOA y SOA para el desarrollo de sistemas. . . . . . . . . . . . . . . . . . 25 3.1. Herramientas de software para el diseño de modelos gráficos probabilistas. 38 3.2. Cuadro comparativo de las herramientas de software para el diseño de redes bayesianas. . . . . . . . . . . . . . . . 42 4.1. Perfiles y privilegios del sistema PRoModel.. 65. 5.1. Anotaciones rooStructure . . . . . . . . . 5.2. Anotaciones rooCommand . . . . . . . . . 5.3. Valores por defecto para las anotaciones. 76 76 77. 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 6.8. 6.9.. Variables de restricción del sistema SiEntrenO. Tornada de [BR12] Variables de exploración del sistema SiEntrenO. Tomada de [BR12] Variables dinámicas del sistema SiEntrenO. Tornada de [BR12] . . . Variable meta del sistema SiEntrenO. Tornada de [BR12] . . . . . . . Rangos de potencia meta para el circuito de la turbina de vapor. Tomada de [BR12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encuesta de usabilidad. Encuesta de rendimiento. . . . . . . . . . Resultados de la prueba de rendimiento. . Métricas de calidad de PRoModel.. 7.1. Encuesta de usabilidad. . . . . . 7.2. Métricas de calidad de EMF on Rails. 8.1. Factores de conversión para obtener los puntos de función con base en los componentes de software. . . . . . . . . . . . . . . . . . . . . . . . . . 8.2. Estadísticos para el cálculo de la estimación del proyecto. Tomada de [HillO]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3. Tiempo de desarrollo de los prototipos generados con PRoModel y EMF on Rails. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4. Tiempo de desarrollo estimado para los proyectos: Web2Xmi, SiEntrenO, ITS y TecEval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5. Esfuerzo estimado para el desarrollo de los prototipos a través de PRoModel y EMF 011 Rai/s. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6. Esfuerzo estimado para los proyectos: Web2Xmi, SiEntrenO, ITS y TecEval. R. A. López Landa. 98 98 98 98 100 106 108 108 109 124 126. 130 132 133 133 134 134 XIX.

(17) ÍNDICE DE TABLAS. XX. Tesis doctoral.

(18) Agradecimientos Me gustaría expresar mi agradecimiento a todos los que me han apoyado en la realización de este trabajo de investigación. En este sentido, le agradezco al Consejo Nacional de Ciencia y Tecnología (CONACyT) y al Tec de Monterrey, Campus Ciudad de México, por haberme otorgado el apoyo económico para realizar mis estudios de posgrado. De la misma forma quisiera manifestar mi agradecimiento a la Dra. Julieta Noguez por apoyarme y creer en mí. Aprecio mucho su dedicación y paciencia, y le agradezco todas las oportunidades que me brindó para colaborar con diversos investigadores. De igual forma, quisiera hacer extensa mi gratitud al Dr. Martín Malina por todo su apoyo y guía. Gracias por haberme otorgado la oportunidad de estudiar un doctorado. Su respaldo y confianza en mi trabajo es invaluable. Al Dr. Rafael Lozano, le agradezco el haberme dado las bases tecnológicas para la concepción y elaboración de las herramientas presentadas en este trabajo de investigación. A la Dra. Violeta Chirino, la Dra. Lourdes Muñoz, el Dr. Luis Neri, el Dr. Gerardo Aguilar, el Dr. Víctor Robledo y el Dr. Moisés Alencastre, miembros de la cátedra de. e-learning del Tec de Monterrey, les agradezco el apoyo durante la revisión y evaluación de las herramientas desarrolladas. A mis compañeros: Gilberto, lván, Eusebio, Gerardo y Luis; les agradezco sus consejos y toda la ayuda que me brindaron. Al M. en C. C. Marcos Berna!, gracias por haberme ayudado con en el desarrollo de la interfaz gráfica de PRoModel. Al M. en C. C. Juan Carlos Castrejón, le agradezco el apoyo en la elaboración y publicación de Model2Roo. De la misma forma quisiera agradecer a todos los que participaron en el desarrollo de los sistemas SiEntrenO y. TecEval, en especial al M. en C. C. Daniel Blancas, al M. en C. C. Jesse Jacobs y al lng. Jesús Jaquez. Aprecio mucho la ayuda que me brindaron. R. A. López Landa. XXI.

(19) AGRADECIMIENTOS. A los miembros del proyecto DyNaMo les agradezco la oportunidad que me dieron para colaborar con ustedes. En especial, me gustaría expresarle mi gratitud al Dr. Javier Diez, al Dr. Manuel Luque y al Dr. Manuel Arias por su apoyo y hospitalidad durante las sesiones de trabajo que tuvimos en la Universidad Nacional de Educación a Distancia (UNED), en España. De igual forma quisiera agradecer al Dr. Juan de Lara, a la Dra. Esther Guerra y al Grupo de Herramientas Interactivas Avanzadas (CHIA) por su ayuda para la concepción de EMF on Rails, y por su hospitalidad durante mi estancia de investigación en la Universidad Autónoma de Madrid (UAM). En lo personal, quisiera agradecer a mis amigos Lili, Anita y Jesús por el apoyo incondicional que me brindaron y por impulsarme a seguir adelante. A Eva, Vladislav, Miguel, Luis, Roberto y Daniel; muchas gracias por toda su ayuda en España y por estar ahí cuando más lo necesitaba. A Lupita, Sonia, Vicky, Jéróme, Gabriel, Jorge, Femando. y Juan; gracias por hacer del doctorado una de las mejores experiencias de mi vida. Así mismo me gustaría agradecer a mi familia por ser el pilar fundamental de todo lo que soy. Ustedes han sido testigos de mis sueños, triunfos, fracasos, alegrías y tristezas. Gracias por todo su amor, confianza, comprensión y paciencia. A mi padre Clementet, gracias por ser un ejemplo a seguir y por fortalecer mi corazón. A mi madre María Elena y a mi hermano Alejandro, que siempre me ayudaron y creyeron en mí, gracias por su gran apoyo, pero sobre todo por darme la oportunidad de seguir construyendo mi camino. Sabiendo que jamás existirá una forma de agradecerles todo lo que me han dado, deseo compartir con ustedes este logro, de muchos otros, que nos quedan por vivir juntos.. XXII. Tesis doctoral.

(20) Apoyo recibido. Este trabajo contó con el apoyo económico del Consejo Nacional de Ciencia y Tecnología (CONACyT), convocatorias no. 290564 y 290618; así como del Tec de Monterrey, Campus Ciudad de México. De igual forma, parte de esta investigación se realizó bajo el marco de trabajo del proyecto DyNaMo 1 : "Modelos gráficos probabilistas dinámicos y sus aplicaciones", no. 95185, subvencionado por el CONACyT y la Unión Europea a través del Fondo de Cooperación Internacional en Ciencia y Tecnología (FONCICyT).. 1. http://www.dynamopro.org/. R. A. López Landa. XXIII.

(21) APOYO RECIBIDO. XXIV. Tesis doctoral.

(22) Abreviaciones. ATL. Lenguaje de transformaciones Atlas. BN. Red bayesiana. CIM. Modelo computacionalmente independiente. CPT. Tabla de probabilidad condicional. DAO. Objeto de acceso a datos. DSL. Lenguaje de dominio específico. EMF. Marco de trabajo para modelado de Eclipse. ER. Modelo entidad-relación. FP. Punto de función. ITS. Sistema tutor inteligente. MOA. Arquitectura dirigida por modelos. MDE. Ingeniería dirigida por modelos. PGM. Modelo gráfico probabilista. PIM. Modelo independiente de la plataforma. PRM. Modelo relacional probabilista. PSM. Modelo específico de la plataforma. RAD. Desarrollo rápido de aplicaciones. SOA. Arquitectura orientada a servicios. R. A. López Landa. XXV.

(23) ABREVIACIONES. XXVI. Tesis doctoral.

(24) Capítulo 1. Introducción. 1.1.. Antecedentes. El desarrollo de aplicaciones web ha sido una de las industrias que ha evolucionado más rápidamente en el área de ingeniería de software [Jaz07]. Esta evolución se ha asociado con un aumento de la complejidad en el conjunto de requisitos funcionales y no funcionales que estos sistemas deben cumplir. Del mismo modo, las aplicaciones web se han hecho populares recientemente porque, a diferencia de los sistemas autónomos, éstas se distribuyen y son accesibles a un gran número de usuarios. Estructuralmente, las aplicaciones web se basan en una arquitectura cliente-servidor, donde los clientes hacen peticiones a uno o más proveedores de servicios y recursos. No obstante, el desarrollo constante de nuevos lenguajes de programación, herramientas, marcos de trabajo y metodologías para el desarrollo de sistemas representan problemas adicionales que los desarrolladores de software deben abordar. En este contexto, el desarrollo rápido de aplicaciones [Man97] (RAD - por sus siglas en inglés) es una metodología que mejora la productividad del desarrollo de software al permitir la construcción de nuevos sistemas a partir de componentes R. A. López Landa. 1.

(25) 1.2. MOTIVACIÓN existentes [Pou93]. La reutilización de componentes de software elimina la necesidad de invertir tiempo y esfuerzo en el desarrollo de artefactos que se pueden generar de forma automática, lo que también reduce los costos de desarrollo. Actualmente existen diversos marcos de trabajo que aceleran la implementación de artefactos de código ya que utilizan lenguajes de dominio específico. Así, marcos de trabajo como Spring. Roo1, Ruby on Rails 2, Django3 y Grails 4 promueven mayores niveles de productividad, liberando a los desarrolladores de tareas repetitivas, y favoreciendo la generación de código esqueleto a partir de comandos de nivel superior. Del mismo modo, la ingeniería dirigida por modelos [SVB+06] (MDE - por sus siglas en inglés) ayuda a mejorar el mantenimiento de las aplicaciones web, ya que promueve una mejor gestión de los cambios tecnológicos durante las fases de desarrollo. MDE se enfoca en el desarrollo de modelos abstractos y no en detalles de implementación. De esta forma se elimina la falta de cumplimiento entre los documentos de diseño y los artefactos de código. Esto aumenta la capacidad de mantenimiento general de los sistemas y promueve una mejor gestión de los cambios tecnológicos que éstos deben atravesar [SVB+06]. Asimismo, el desarrollo de modelos específicos para cada dominio promueve mayores niveles de productividad, permitiendo que los desarrolladores no se involucren con los componentes de bajo nivel de los sistemas. La importancia de contar con una metodología de desarrollo rápido de aplicaciones en conjunto con técnicas dirigidas por modelos que brinde las pautas para el desarrollo de sistemas incide en la idea de que se pueden disminuir los tiempos y costos de desarrollo y mantenimiento de los mismos, permitiendo que se reutilicen sus estructuras y componentes, y eliminando la necesidad de dominar lenguajes y herramientas de programación.. 1.2.. Motivación. En la actualidad muchos individuos y organizaciones se dedican a la construcción de aplicaciones a la medida que garantizan cubrir las necesidades de los clientes. Con base en mi experiencia profesional en el desarrollo de diversos sistemas, he percibido que 1. http://www.springsource.org/spring -roo http://rubyonrails.org 3 htlps://www.djangoproject.com ~http://grails.org 2. 2. Tesis doctoral.

(26) CAPÍTULO 1. INTRODUCCIÓN. la implementación de estas aplicaciones siempre involucra la definición y elaboración de entidades (o catálogos) que permiten administrar los datos mediante operaciones comunes5 . A pesar de que la forma en la que se administran las entidades es la misma, su elaboración incrementa notablemente los tiempos y costos de desarrollo, por lo que el esfuerzo requerido para su implementación es muy grande y demanda que el usuario posea conocimientos técnicos en bases de datos y lenguajes de programación. Del mismo modo, en la actualidad se desarrollan múltiples aplicaciones que poseen las mismas características estructurales. A pesar de que los principios arquitectónicos y de diseño son los mismos, cada una de estas aplicaciones se desarrolla de forma independiente. Familias de aplicaciones médicas o educativas que permiten llevar el registro y control de los pacientes y estudiantes, son desarrolladas autónomamente, sin reutilizar componentes de software. Lo que incrementa el esfuerzo, tiempo y costos de desarrollo. Asimismo, diversos sistemas requieren administrar la incertidumbre de la información en el dominio. La incertidumbre surge cuando se tienen modelos incompletos o aproximados para la representación del conocimiento. Los sistemas que consideran información incierta requieren tomar decisiones y deducir información de interés. Sistemas de reconocimiento de imágenes y voz, así como simulaciones del comportamiento humano y eventos climáticos necesitan manejar y reducir la incertidumbre de la información que procesan. La incertidumbre se puede tratar de diferentes formas. No obstante, diversos sistemas con incertidumbre tienen limitaciones importantes, principalmente porque en la mayoría no se utilizan técnicas de ingeniería de software que establezcan las bases para su diseño y construcción. Esto ha generado que los sistemas no puedan ser fácilmente extendidos o mantenidos, sobre todo porque la mayoría de ellos son aplicaciones independientes que no interactúan con bases de datos u otros sistemas. Un problema adicional es la dificultad de representar en una misma aplicación, la información relacional y la incertidumbre del dominio, lo que genera que no se puedan identificar dependencias o patrones que no son evidentes. Lo anterior representa un reto que asumí mediante la implementación de dos metodologías que automatizan la constmcción de aplicaciones web con y sin incertidumbre. Particularmente, con base en dichas metodologías, desarrollé dos herramientas basadas 5 Las operaciones comunes para la administración de datos involucran el alta, baja, edición y lectura de los mismos.. R. A. López Landa. 3.

(27) 1.3. PROPUESTA DE SOLUCIÓN. en una arquitectura dividida en capas, orientada a servicios y dirigida por modelos que reducen el tiempo, esfuerzo y costo de desarrollo de aplicaciones web. De esta forma los usuarios sin conocimiento técnico profundo en bases de datos, lenguajes de programación y modelos probabilistas tienen la posibilidad de crear sus propias aplicaciones con y sin incertidumbre.. 1.3.. Propuesta de solución. A partir de lo anterior, en este trabajo de investigación se propuso el diseño de dos metodologías que agilizan y facilitan el desarrollo de sistemas con incertidumbre y de generadores familias de aplicaciones web. Para la definición de las metodologías propuestas se tomó en cuenta que existen usuarios con pocos conocimientos y habilidades técnicas que deben participar en el desarrollo de sistemas, por lo que se contempló la generación automática de código a partir de modelos de diseño. Las metodologías propuestas son:. Prm2Web que facilita y agiliza el desarrollo de sistemas con incertidumbre, permi-. tiendo que usuarios sin conocimientos técnicos profundos puedan desarrollar aplicaciones web a partir de modelos que representan la incertidumbre. Para validar esta metodología se desarrolló una herramienta web, denominada PRoModel, que permite generar artefactos de código a partir de modelos para tratar. la incertidumbre. Ecore2Web que automatiza la generación de familias de aplicaciones web a partir. de modelos de dominio específico, permitiendo que se reutilicen componentes de software. Para validar esta metodología se desarrolló EMF on Rails, una herramienta que permite generar familias de aplicaciones web a partir de metamodelos asociados a un dominio específico.. De esta forma se pretende agilizar el desarrollo de componentes de software al combinar herramientas para el desarrollo rápido de aplicaciones con técnicas de desarrollo dirigidas por modelos. A continuación se enumeran los principales objetivos de este trabajo de investigación.. 4. Tesis doctoral.

(28) CAPÍTULO 1. INTRODUCCIÓN. 1.4.. Objetivos. El principal objetivo de este trabajo es el de diseñar metodologías que faciliten la construcción de prototipos funcionales 6 de aplicaciones web con incertidumbre, así como de familias de aplicaciones web asociadas a un mismo dominio. La realización de esta propuesta integró elementos tecnológicos que satisfacen los siguientes objetivos específicos:. • Diseñar y desarrollar dos metodologías que agilicen el desarrollo de aplicaciones web con y sin incertidumbre, mediante el uso de herramientas RAD y técnicas de desarrollo dirigidas por modelos. • Diseñar e implementar una arquitectura dividida en capas, orientada a servicios y dirigida por modelos, que permita disminuir la dependencia de los componentes; facilitando así el reuso y mantenimiento de los sistemas generados mediante las metodologías propuestas. • Desarrollar una herramienta web para el diseño de modelos con incertidumbre a partir de modelos que permitan representar la información relacional y la incertidumbre del dominio. • Desarrollar una herramienta para la generación de familias de aplicaciones web a partir de modelos de dominio específicos.. 1.5.. Hipótesis. A través de las metodologías propuestas en este trabajo de investigación se plantean las siguientes hipótesis: Hipótesis l.. Es posible elaborar herramientas que ayuden a disminuir el tiempo. y esfuerzo requerido para el desarrollo de aplicaciones web utilizando herramientas. RAD y técnicas de desarrollo dirigidas por modelos. Hipótesis 2.. Es posible generar prototipos funcionales de aplicaciones web a partir. de modelos relacionales probabilistas y meta-modelos Ecore. 6. Prototipos que están listos para ser instalados en un servidor de aplicaciones web para que los usuarios puedan hacer uso del sistema.. R. A. López Landa. 5.

(29) 1.6. ESTRUCTURA DEL DOCUMENTO. 1.6.. Estructura del documento. En el capítulo 2 se presentan los fundamentos de la ingeniería dirigida por modelos y las arquitecturas de software que se utilizaron en el presente trabajo de investigación. El capítulo 3 introduce los conceptos básicos de incertidumbre y los modelos bayesianos que han servido para la definición de la metodología propuesta. De igual forma, en ese capítulo se presentan algunas herramientas para el diseño de modelos con incertidumbre disponibles en la actualidad. El capítulo 4 describe la metodología y arquitectura propuesta para el ambiente enfocado al desarrollo de sistemas con incertidumbre. Particularmente se describen los componentes, las características y modelos que se han diseñado para la definición de PRoModel. Del mismo modo, el capítulo 5 describe la metodología y arquitectura empleada por EMF 011 Rails para el desarrollo del generador de familias de aplicaciones web con base en modelos de dominio específicos. En el capítulo 6 se presenta el desarrollo de un sistema tutor inteligente para validar la funcionalidad de PRoModel. De la misma forma, el capítulo 7 describe el desarrollo de un problemario dinámico para validar la generación de aplicaciones web a través de EMF 011 Rails. En el capítulo 8 se presentan los resultados de las pruebas de hipótesis que permiten demostrar el ahorro de tiempo y esfuerzo que brindan las metodologías y herramientas desarrolladas en este trabajo de investigación. El capítulo 9 presenta las conclusiones de este documento, junto con el trabajo futuro que se puede derivar del mismo. Posteriormente, se enlistan las publicaciones derivadas de este trabajo de investigación. Finalmente, en los anexos se presentan los fundamentos teóricos y los detalles de los elementos técnicos del diseño y la implementación que no han sido incluidos en los capítulos correspondientes.. 6. Tesis doctoral.

(30) Parte I. Marco teórico y estado del arte. R. A. López Landa. 7.

(31) Capítulo 2. Desarrollo dirigido por modelos. 2.1.. Introducción. Como se mencionó en el capítulo anterior, diversos sistemas desarrollados en la actualidad carecen en su elaboración de los fundamentos básicos de los procesos de ingeniería de software. Por este motivo existe la necesidad de apoyar a los usuarios que no poseen los conocimientos y habilidades técnicas en la construcción de aplicaciones web. En este sentido, para proveer una solución a este problema, es de gran importancia contar con una metodología de desarrollo rápido de aplicaciones en conjunto con técnicas de desarrollo dirigidas por modelos que brinden las pautas para la elaboración de aplicaciones web. El principal objetivo es el de disminuir el tiempo, esfuerzo y costos de desarrollo y mantenimiento de los sistemas, permitiendo que se reutilicen sus estructuras y componentes, y disminuyendo la necesidad de dominar lenguajes y herramientas de programación. En este capítulo se describen las características, ventajas y principios generales de las arquitecturas de software y técnicas de ingeniería dirigida por modelos. Del mismo. R. A. López Landa. 9.

(32) 2.2. FUNDAMENTOS modo se realiza un análisis de los procesos de transformación de algunas herramientas que poseen características similares a las propuestas en este trabajo de investigación.. 2.2.. Fundamentos. El desarrollo de software ha sido una de las industrias que más ha evolucionado en los últimos años. No obstante, y a pesar del uso de normas y metodologías de ingeniería de software, muchos proyectos exceden los costos y tiempos de desarrollo. Aunado a esto, los desarrolladores y administradores constantemente se enfrentan a la complejidad derivada de la aparición de nuevos lenguajes de programación, herramientas de desarrollo y marcos de trabajo para la construcción de aplicaciones. Inclusive se debe considerar que muchos sistemas de software son desarrollados por individuos que no poseen los conocimientos y habilidades técnicas necesarias para el desarrollo de sistemas. Por este motivo, en la actualidad aún se desarrollan sistemas que poseen muchas limitantes, principalmente porque no pueden ser fácilmente extendidos o mantenidos, por lo que se vuelven obsoletos con el tiempo y las nuevas necesidades de los usuarios Uaz07]. La administración de la complejidad del software y la adecuada selección de herramientas de desarrollo es vital para la construcción de sistemas. Las aplicaciones web han llegado a ser muy populares recientemente debido a que se distribuyen y dan acceso a un gran número de usuarios. Estructuralmente, las aplicaciones web se basan en una arquitectura cliente-servidor, donde cada cliente realiza peticiones a uno o más proveedores de recursos. En la actualidad, las aplicaciones web han evolucionado considerablemente [Jaz07). Esta evolución se ha asociado con un aumento en la complejidad en los requerimientos funcionales y no funcionales que se espera que estos sistemas cumplan. Adicionalmente, los rápidos cambios y los resultados evidentes de la globalización han forzado a las aplicaciones web a adoptar nuevas tecnologías, metodologías y estándares que ofrecen la flexibilidad ante los cambios que la industria demanda [EA08]. Del mismo modo se debe considerar que los procesos deficientes pueden llevar a problemas de productividad y mantenimiento [BCK03]. En este sentido, la arquitectura dirigida por modelos, que se basa en abstracciones de modelos en lugar de los detalles de implementación, mejora significativamente el mantenimiento general de 10. Tesis doctoral.

(33) CAPÍTULO 2. DESARROLLO DIRIGIDO POR MODELOS. los sistemas de software y promueve una mejor gestión de los cambios tecnológicos que se puedan generar. En este mismo contexto, el desarrollo rápido de aplicaciones es una metodología que mejora la productividad del desarrollo de software al permitir la construcción de nuevos sistemas a partir de componentes existentes [Pou93]. La reutilización de componentes de software elimina la necesidad de invertir tiempo y esfuerzo en el desarrollo de artefactos que se pueden generar de forma automática, lo que también reduce los costos de desarrollo. En este sentido, actualmente existen diversos marcos de trabajo que aceleran la elaboración de artefactos de código, mediante el uso de lenguajes de dominio específico (DSLs - por sus siglas en inglés). Así, estos marcos de trabajo promueven mayores niveles de productividad, liberando a los desarrolladores de tareas repetitivas, y favoreciendo la generación de código esqueleto a partir de comandos de nivel superior. Contar con una metodología de desarrollo rápido de aplicaciones en conjunto con técnicas dirigidas por modelos que brinden las pautas para el desarrollo de sistemas se basa en la idea de que se pueden disminuir los tiempos y costos de desarrollo y mantenimiento de los mismos, permitiendo que se reutilicen sus estructuras y componentes. A continuación se describen los fundamentos teóricos de las arquitecturas de software y técnicas dirigidas por modelos empleados en este trabajo de investigación.. 2.3.. Arquitecturas de software. En la literatura actual existen numerosas definiciones para el término de arquitectura de software. Sin embargo, y a pesar de que no se tiene un consenso, diversos autores [GS93, IEEOO, BCK03, KOS06] coinciden en que el objetivo principal de esta disciplina es el de capturar y describir la estructura y comportamiento de alto nivel de un sistema de software, lo que permite olvidarse de los detalles y enfocarse en un modelo abstracto del mismo. De esta forma, una arquitectura de software es un modelo abstracto que permite desarrollar sistemas complejos, logrando que se reduzca el tiempo y costo de desarrollo, y cuyo principal objetivo es el de verificar la calidad y facilitar la evolución y reuso de los componentes y subsistemas [MRRR02]. Así, este modelo abstracto actúa como un puente entre las necesidades de los usuarios y el código del sistema de software [GarOO]. R. A. López Landa. 11.

(34) 2.3. ARQUITECTURAS DE SOFTWARE De la misma forma se debe considerar que los sistemas de software evolucionan y crecen continuamente, por lo que la arquitectura de software debe ser lo suficientemente flexible para evolucionar y crecer simultáneamente con éstos. Así, y dependiendo del nivel de abstracción del modelo desarrollado, se puede tener una arquitectura conceptual (lógica o ideal), que es la que existe en la documentación técnica; y una arquitectura concreta (física o implementada), que es la que se puede derivar del código fuente [DP09]. Las arquitecturas de software han demostrado ser un modelo maduro y estable, que evoluciona y se adapta a nuevas tecnologías, metodologías y marcos de trabajo. Esto se debe a que las arquitecturas de software se diseñan con base en las necesidades y preocupaciones de todos los usuarios del sistema, dado que cada uno de ellos tiene un enfoque particular de la solución. Por este motivo, la arquitectura de software se debe presentar a través de diferentes vistas que permitan que cada usuario pueda observar todo el sistema a través de la perspectiva de su interés [Kru95].. 2.3.1.. Arquitectura orientada a servicios. La arquitectura orientada a servicios [Er!OS] (SOA - por sus siglas en inglés), brinda las mejores prácticas y procesos que facilitan el reuso de componentes. Una de las características de esta arquitectura es que permite separar las diferentes necesidades de un sistema de software en pequeñas partes que pueden ser tratadas de forma individual. Es decir, la lógica necesaria para hacer frente a un problema grande se puede desarrollar si se descompone el problema en una colección de pequeñas partes relacionadas entre sí [Er!OS, KZ08]. Lo que distingue a la arquitectura orientada a servicios de otros enfoques similares es la forma en la que SOA realiza dicha separación. Esto debido a que cada una de las partes individuales puede ser distribuida de forma independiente. Como ejemplo de la analogía orientada a servicios se puede pensar en una ciudad, formada por empresas, instituciones e individuos [Er!OS]. Cada uno de los componentes de la ciudad provee un servicio (médico, seguridad, entretenimiento, etc.) que es utilizado por diversos consumidores. Al permitir la especialización de cada una de las partes que forman a la ciudad se obtiene un ambiente en el que es fácil distribuir y consumir los productos y servicios.. 12. Tesis doctoral.

(35) CAPÍTULO 2. DESARROLLO DIRIGIDO POR MODELOS. De esta forma, SOA se caracteriza por abordar la alta flexibilidad y baja complejidad que requieren las aplicaciones en la actualidad. Además, SOA es uno de los estilos arquitectónicos más utilizados para el desarrollo de las aplicaciones web [KAJ09]. La principal ventaja de SOA es que permite la creación de sistemas escalables que interactúan con otros sistemas, propios y de terceros [BBCCOS, Erl05]. Los servicios pueden ser publicados a través de plataformas que permitas estandarizar y dar forma a cada componente. SOA utiliza un bu.s de servicios para consumir y exponer todos o parte de sus servicios, con la finalidad de que los consumidores puedan hacer uso de ellos. Esto permite evitar la cohesión entre los sistemas, lo que facilita el mantenimiento y los cambios en cualquiera de los componentes de software.. 2.4.. Arquitectura dirigida por modelos. La arquitectura dirigida por modelos [KWB03] (MOA - por sus siglas en inglés) es una iniciativa de la OMG [OMG13] que pretende elevar el nivel de abstracción en la forma en la que se desarrollan los sistemas de software [KZOS]. MOA surgió a partir de la problemática en la inconsistencia entre los artefactos de diseño y de implementación que enfrentan muchos sistemas de software en la actualidad. El origen de este problema radica en la forma en que el proceso de desarrollo de software tradicional es llevado a cabo [KWB03]. En la figura 2.1 se puede observar la forma en la que difiere el proceso de desarrollo de software tradicional del dirigido por modelos. Particularmente, en la figura 2.l(a) se muestra el proceso tradicional, que se compone por seis etapas generales que van desde el análisis de los requerimientos del sistema hasta la liberación de una aplicación. Como se puede ver gráficamente, en las primeras etapas se realiza el análisis y diseño de los sistemas, lo que implica trabajar con documentos y modelos que representen, con un alto nivel de abstracción, las características y funciones del sistema. En las últimas etapas del proceso de desarrollo de software se trabaja sobre artefactos de código que, idealmente, son una representación de los artefactos de diseño iniciales. En teoría, cuando se debe realizar algún cambio al sistema, todos los documentos y artefactos relacionados deben actualizarse. Sin embargo, los desarrolladores de software tienden a considerar las etapas de programación más importantes que sus contrapartes de diseño, y, como consecuencia, los cambios son únicamente aplicados a los artefactos R. A. López Landa. 13.

(36) 2.4. ARQUITECTURA DIRIGIDA POR MODELOS. (en teo..-(a). - ----, L---l 9-<~l;o!IJ.---' (en. p..-,íctica) 1. 1 1 1 1 1 1 1 1 1 1. _____ L. (a) Proceso tradicional para el desarrollo de software. Traducido de [KWB03].. (b) Proceso de desarrollo dirigido por modelos.. Figura 2.1: Procesos de desarrollo de software. de código [KWB03]. Esto deriva en una falta de conformidad entre los documentos del diseño y los artefactos de implementación, lo que puede causar un deterioro general en la calidad del sistema de software [BCK03]. Por otro lado, el proceso de desarrollo dirigido por modelos (ver figura 2.l(b)) trata de reducir dicha inconsistencia en los artefactos mediante la generación automática de componentes de software a partir de modelos. Así los desarrolladores se deben de ocupar de los artefactos de análisis y diseño para desarrollar sistemas de software. De esta forma se promueve una mejor gestión de los cambios tecnológicos en los sistemas, ya que se elimina la falta de acoplamiento entre los artefactos de diseño y código.. 2.4.1.. Jerarquía de meta-modelos. La base de la iniciativa de MOA radica en la capacidad de manipular y especificar modelos basados en meta-datos 1 . La OMG provee una forma de representar los metadatos a través de la especificación MOF [OMG13]. De esta forma, mediante el uso I. Los meta-datos son datos altamente estructurados que proporcionan información sobre el contexto de los datos y sus características [How12]. También se denominan datos de los datos. 14. Tesis doctoral.

(37) CAPÍTULO 2. DESARROLLO DIRIGIDO POR MODELOS. ld lnt nomtw. en., g.,,..-c, lnt t.ch.• N.. omiento, d,a te. id~ lnt ~Stri"9. g• ta,to- 1r, t ltd'J• ~dm1• nto ¡ava util O.te. ~. .¡::.,~7:;i•:». getld{) int. .. • •. ~~. nombti!. c:hal(2!i1 J. Q~O. 1nt. te chaNadm1ff!to oat.r,me. gttNomt!,teC) S\t'ing g•tG.ntfQ() in t ~tFt-(:h.a.>hom ,e nto() Java 1..ttl Cat•. •Pl'et~/~h Mtld(tnt) YOt C ~-tStnr-.g> Y01 d • Mt0fll.,0(1nt) VCNd • ...tFKhaNaa!l'heMO(j•v• 1,;til Date} vOtd. ·. publl( d d ". prh•t , prlv.au pr-lv•t • Pf'IY.th. •,c.t~u {. c. H•1•. tnt Id; Str l 11¡ ne.e,~. IM pn«ro; , ..... , . u! f l .CMt• ftt(h.U.Cl•len t o.. u•l•. 1>.l,ClfKH. 1 10. - . . - 1(. /Oltll. { ut' (l'i,$1. C.lNUO. ,u.,,,., JIA(?ftllN r o. p,..bll< ltll ¡•ttd(l( ""'""' Id;. <-~,; .. l•t. l •t IMUt t .... Pt: _1>1,( ll MH o,r l _,- Ir~ chnt•.-...S ( tO). );. l. pcibll( vold Hti d ( lfl1 ......V•) )(. ld · _..v, I¡ !J,11< Strl1'¡ ¡eV~•(){ r'1't- "10Clr•;. l. pW,lh YOld HtHooltln{Strln.¡ --.i,l )( ~. ..· ~--v,l;. l. put,11( lt1t gtot~"fl"O( ){. ~t11rn ¡t,nef'O;. l. publh 'Hid $~tGenero( ht ne.,,V.&I )( l'\\'VV.il ;. ,.~ ..º ... l. publl < j,1v, . utll . O.¡¡te &•?F.c h.,uclai..-.to(I(. ,.,.t•rn f•cl'l.~<1•1f"tlto;. l. putl ll < ..old Ut~ecl'1.1H.1cl•hnto(j1V,1,vt l l h tUU .ac bllltt1'1tO .. MWV.1 1 ;. o,u. ,..........,1 )(. . 1. Figura 2.2: Ejemplo de modelos y meta-modelos. de una implementación de MOF, como el Lenguaje Unificado de Modelado [BRJOS] (UML- por sus siglas en inglés) o Ecore [SBPM09], se pueden desarrollar meta-modelos que pueden transformarse en otro tipo de modelos más particulares. Así, mediante MOF, se puede especificar la estructura de los diagramas de clases de UML. En la figura 2.2 se muestra un ejemplo donde se puede observar gráficamente que con los diagramas de clases se puede realizar el diseño de una aplicación para un consultorio médico, en el que una de las clases deberá representar a un paciente. Posteriormente, al especificar la plataforma sobre la cual se construirá la aplicación médica (por ejemplo: Java y SQL), el diagrama de clases podrá ser transformado en uno o más modelos que representen las particularidades de la plataforma. Finalmente se podrán generar los artefactos de código a partir de estos modelos. R. A. López Landa. 15.

(38) 2.4. ARQUITECTURA DIRIGIDA POR MODELOS Tabla 2.1: Capas de la arquitectura dirigida por modelos.. Nombre M3 M2 Ml MO. Capa Meta-meta-modelo Meta-modelo Modelo Instancias. Ejemplo MOF Diagrama de clases (UML) Paciente Clemente López, Elena Landa. La OMG especifica cuatro capas para la definición de las arquitecturas dirigidas por modelos [LSPM02]. Estas capas permiten especificar la funcionalidad del sistema, independientemente de su implementación. Corno se puede observar en la tabla 2.1, cada capa representa una instancia de la capa superior. Por ejemplo, un diagrama UML, definido en la capa M2, representa una instancia de MOF, definido en la capa M3. Del mismo modo, un modelo particular del diagrama de clases (como un paciente, del ejemplo anterior) representa una instancia de la capa M2. Finalmente, cada individuo que se registre en el sistema representa una instancia de la clase paciente, definida en la capa Ml.. 2.4.2.. Modelos. Un modelo se puede definir corno un conjunto de elementos que describen un sistema y su entorno [OMG13]. Un buen modelo incluye aquellos elementos que tienen una gran influencia y omite a los elementos que no son relevantes a un propósito en particular [BRJOS]. Tradicionalmente, los modelos han servido corno medio de comunicación entre clientes, analistas y desarrolladores [HG07]. No obstante, el uso de modelos es controversia!. Los partidarios de los procesos de desarrollo ágil [Bec99, RJOO] señalan que los modelos son ambiguos, forzando a los programadores a tornar decisiones que no se han documentado correctamente [HG07]. No obstante, MOA considera que los modelos son los principales insumos que permiten generar artefactos de código, fieles a las especificaciones abstractas. Incluso, MOA afirma que los modelos facilitan el reuso y mantenimiento de los sistemas, ya que los artefactos generados son consistentes en todo momento. De esta forma MOA define tres tipos de modelos que permiten especificar la funcionalidad del sistema desde diferentes puntos de vista [KWB03]:. 16. Tesis doctoral.

(39) CAPÍTULO 2. DESARROLLO DIRIGIDO POR MODELOS. Modelos computacionalmente independientes (CIM - por sus siglas en inglés). Son modelos independientes de cualquier plataforma tecnológica, que permiten describir los procesos de negocio. Algunas partes de los CIMs pueden ser soportadas por sistemas de software. Modelos independientes de la plataforma (PIM - por sus siglas en inglés). Son modelos con un alto nivel de abstracción, que, corno su nombre lo indica, son independientes de cualquier implementación tecnológica. El objetivo de los PIMs es el de describir al negocio. Modelos específicos de la plataforma (PSM - por sus siglas en inglés). Estos modelos permiten especificar los detalles técnicos de la implementación. Cada PIM puede generar uno o más PSMs (como en el ejemplo de la figura 2.2).. 2.4.3.. Transformaciones. Uno de los principales beneficios de MOA es el de proveer mecanismos de portabilidad que permitan separar el dominio de la aplicación de una plataforma tecnológica en particular. Esto fa vorece el reuso e incrementa la calidad de los productos generados. Para poder generar los PSMs a partir de los PIMs, y los artefactos de código a partir de los PSMs, es necesario definir procesos de transformación (ver figura 2.3). Aunque estas transformaciones se han realizado tradicionalmente de forma manual, MOA propone el uso de herramientas que automaticen este proceso.. •. ~ 1. -. l 1an"fon n~1~1l,11. p ivl. • =•. -. I r.11hf,xm~1.:1on. -Códi go. Figura 2.3: Meta-modelos y transformaciones en MOA. Las transformaciones permiten obtener uno o varios modelos destino a partir de uno o varios modelos origen. Los modelos destino son representaciones del sistema desde distintos puntos de vista o niveles de abstracción. La OMG define el estándar QVT [OMGOS] (Q11en;Niew(fra11sformations) para las transformaciones de los modelos. Dichas transformaciones se realizan a través de lenguajes de transformación, los cuales se componen de reglas de transformación. Cada regla posee una parte izquierda, que accede al modelo fuente, y una parte derecha que genera el modelo destino [CH03]. R. A. López Landa. 17.

(40) 2.4. ARQUITECTURA DIRIGIDA POR MODELOS. 2.4.4.. Lenguajes de transformación. Los lenguajes de transformación permiten automatizar el proceso de generación de artefactos de diseño y de código. Estos lenguajes se pueden clasificar en [CH03, HG07]:. Declarativos o racionales. Definen reglas de transformación con vínculos entre patrones del lenguaje fuente y del lenguaje destino. Las reglas son correspondencias bidireccionales que facilitan la doble transformación. Imperativos u operacionales. Definen la forma en la que se obtiene un programa destino a partir de un programa fuente. Las transformaciones son unidireccionales. Híbridos. Combinan las características de los lenguajes declarativos e imperativos.. El estándar QVT de la OMG posee una naturaleza híbrida (ver figura 2.4) [OMGOS, HG07]. La parte declarativa se compone de: (1) un lenguaje con un alto nivel de abstracción que permite expresar relaciones; y (2) un lenguaje base que es semánticamente equivalente, pero menos abstracto. QVT realiza la traducción automática del lenguaje de relaciones al lenguaje base. La parte imperativa se compone de un lenguaje operativo de conversiones, y permite la invocación de transformaciones externas elaboradas con otros lenguajes a través de una interfaz de caja negra. El lenguaje de transformación Atlas [JABK08] (ATL - por sus siglas en inglés) también es un lenguaje híbrido que proporciona los mecanismos de transformación automática que permiten producir modelos específicos a partir de modelos independientes. Parte. imperativa. Figura 2.4: Arquitectura del estándar QVT de la OMG. Traducido de [OMGOS]. 18. Tesis doctoral.

(41) CAPÍTULO 2. DESARROLLO DIRIGIDO POR MODELOS ATL se desarrolló con base en el estándar QVT y provee dos unidades principales de operación: módulos y queries. Los módulos proveen un conjunto de reglas de transformación entre un modelo de entrada y uno de salida; mientras que los queries permiten generar cadenas y archivos de texto a partir de uno o más modelos de entrada.. 2.4.5.. Principios generales. MOA se fundamenta en los siguientes principios generales [KZ08]:. • Los modelos expresados a través de una notación bien definida son la piedra angular para la definición de los sistemas. Así, MOF y UML proveen las bases para la definición de PIMs y PSMs. • La construcción de los sistemas se puede organizar alrededor de un conjunto de modelos y mediante la imposición de una serie de transformaciones entre ellos. • La descripción formal de modelos a partir de un conjunto de meta-datos facilita las transformaciones entre los modelos.. 2.5.. Desarrollo rápido de aplicaciones. En el ámbito de la construcción de software, el desarrollo rápido de aplicaciones es una metodología que mejora la productividad, permitiendo que se construyan nuevos sistemas a partir de componentes de software existentes [Pou93]. En la actualidad existen diversos marcos de trabajo que automatizan el desarrollo de componentes de software.. Spring Roo 2 [RP12, R0013] es una herramienta de productividad de Java para la construcción de aplicaciones empresariales. Este proyecto provee un núcleo en el que un conjunto de comandos especiales pueden generar aplicaciones web de alta calidad. La importancia de este proyecto recae en su habilidad para facilitar el desarrollo de aplicaciones web en minutos, garantizando que dichas aplicaciones se encuentren sustentadas en un conjunto de patrones arquitectónicos y mejores prácticas de desarrollo. 2. http://www.springsource.org/spring-roo. R. A. López Landa. 19.

(42) 2.5. DESARROLLO RÁPIDO DE APLICACIONES. _____. ,~-----.... _. .........,,-.aa1-,a;.--~. ::::::::::·::::~ -..... ....,..._..,, ....,~. ==~=~. Desarrollador. ... .._.,..... __..._.,. _......_•-...:>-~-.11,·1,li!E. ~. Comandos especiales. o Línea de c8mandos de Spring Roo. Aplicación web. Base de ·datos Figura 2.5: Desarrollo de una aplicación web con Spring Roo. El objetivo de Spring Roo es el de mejorar la productividad del desarrollador de código sin comprometer la integridad o la flexibilidad de la solución propuesta [R0013). La figura 2.5 muestra el enfoque de Spring Roo para el desarrollo de aplicaciones web. Como se puede observar, esta herramienta requiere que los desarrolladores introduzcan los comandos especiales que darán forma a la aplicación web (1). Posteriormente estos comandos son interpretados por el shell de Spring Roo (2) para producir una aplicación web de Java (3) con su base de datos (4). Una ventaja de Spring Roo es su flexibilidad, ya que si existen requerimientos especiales, como resguardar el acceso a la aplicación web, los desarrolladores pueden usar add-ons.. Spring Roo se basa en una arquitectura modular que brinda soporte para la instalación de add-ons de terceros. Cada add-on incorpora un conjunto de comandos y funciones al núcleo de Spring Roo, lo que permite que se construyan diferentes tipos de aplicaciones.. c.;,;'"'] ~ ~. ;_J. .. }. - .,. .,;;...., ...1 .,;. icJPEt .. n.a. me. E.Strmg. -" age: §Int _. --~ Figura 2.6: Artefactos generados por Spring Roo para cada entidad del dominio.. 20. Tesis doctoral.

(43) CAPÍTULO 2. DESARROLLO DIRIGIDO POR MODELOS. De esta forma los desarrolladores pueden extender las capacidades de este marco de trabajo [R0013]. Por otro lado, Spring Roo genera 10 artefactos de código por cada entidad del dominio. Como se puede ver en la figura 2.6, esta herramienta genera dos interfaces gráficas para cada entidad, una para la consulta de los datos (1) y otra para la edición de los mismos (2). De la misma forma, Spring Roo genera 8 clases que contienen la implementación de los objetos de acceso a datos y controladores para la gestión de los datos de cada entidad. Finalmente, se debe considerar que, aunque Spring Roo produce interfaces gráficas estándar para todas las aplicaciones, estas pueden ser adaptadas o reemplazadas para generar la presentación adecuada a la aplicación deseada.. 2.6.. Trabajo relacionado. A continuación se presenta una selección de trabajos relacionados sobre transformaciones de modelos que facilitan la generación de sistemas. El principal objetivo de estos sistemas es el de reducir el tiempo y esfuerzo de desarrollo de las aplicaciones.. 2.6.1.. Un enfoque para el desarrollo de aplicaciones utilizando MOA. Marzullo et al. [MdSBOS] presentan un enfoque para el desarrollo de aplicaciones utilizando MOA y SOA que tiene el objetivo de crear un ambiente de desarrollo que permita reutilizar modelos del dominio en diferentes proyectos. Para poder lograr esto, los autores definieron la siguiente metodología [MdSBOS]:. Modelar el dominio del negocio. En esta fase se identifican los servicios requeridos por el dominio. El objetivo es el de crear una estructura que pueda hacer frente a las necesidades de cualquier proyecto en dominios similares. Crear un archivo XMI. En esta fase, se genera un modelo UML (representado a través de un archivo XMI) que contiene los servicios y elementos del dominio. Almacenar los servicios del dominio y los modelos de los componentes. En esta fase se almacenan, en bases de datos, los modelos creados por los arquitectos de software. Un requisito fundamental de este enfoque es que cada proyecto debe R. A. López Landa. 21.

(44) 2.6. TRABAJO RELACIONADO. tener su propia base de datos, pero debe de poder exponer la funcionalidad a través de servicios web. Exponer y compartir los modelos del dominio. En esta fase se deben de publicar los modelos a través de servicios web. Cada proyecto debe tener su propio servicio web que permita a otros sistemas acceder a la información del dominio y a los componentes del proyecto. Automatizar la generación de código. En esta fase se utilizan los modelos del dominio para generar artefactos de código. Para lograr esto, se deben de incorporar las reglas de negocio específicas del dominio en el producto final.. En la tabla 2.2 se presentan los resultados preliminares de la evaluación de la metodología desarrollada en [MdSB08]. Como se puede observar, los resultados demuestran que la arquitectura orientada a servicios y dirigida por modelos puede reducir significativamente los tiempos de desarrollo de los proyectos de software; lo que también se traduce en un ahorro significativo en los costos del mismo. Tabla 2.2: Resultados de la prueba de concepto del enfoque propuesto en [MdSB08]. Servicio Tiempo de desarrollo (estimado) Tiempo de desarrollo (real) % de reducción en el tiempo de desarrollo. Control de acceso 2 meses 1.5 meses 25%. No obstante, a pesar de los resultados de ahorro de tiempo para el desarrollo de sistemas de software, los usuarios aún requieren de conocimientos y habilidades técnicas profundas. Esto debido a que se requiere de un arquitecto de software que genere el servicio web para exponer los componentes e información de la aplicación generada. De esta forma, en este enfoque se limita la construcción de aplicaciones a usuarios con conocimientos y habilidades técnicas en el desarrollo de sistemas.. 2.6.2.. Un enfoque MDA basado en BPM para el desarrollo de aplicaciones. La administración de procesos de negocio (BPM - por sus siglas en inglés) ayuda a definir los servicios de negocio mediante modelos CIMs [SVGFJA08]. De esta forma, Sánchez et al. [SVGFJA08] proponen una arquitectura dirigida por modelos y orientada a servicios que, mediante la administración de los procesos de negocio, facilita la definición de las fases iniciales de los procesos de software. 22. Tesis doctoral.

(45) CAPÍTULO 2. DESARROLLO DIRIGIDO POR MODELOS. En este enfoque los autores proponen una metodología para la definición de modelos y servicios a partir de los procesos de negocio. Los pasos de la metodología propuesta. son [SVGFJA08]:. l. El proceso de desarrollo de software inicia con la definición de modelos CIMs. asociados a los procesos de negocio. Estos modelos deben de ser procesados y transformados en modelos PIM. 2. Los modelos CIM se basan en la descripción de los procesos de negocio. De esta forma, los CIMs pueden ser diseñados y administrados por los usuarios finales. Así, BPM mejora la comunicación entre los usuarios y los desarrolladores de software. 3. Los servicios permiten ligar los procesos de negocio con los componentes de software, lo que facilita que los requerimientos iniciales sean transformados en artefactos de código fáciles de rastrear. Stepll.3. Step 11.2 Businna process mod•ling •nd specitication (CIM Lenl). Software analysís relaled lo lhe business procH!I (PIM level). Execute CIM to PIM trans fonnaúon. .!. ldentify key. aulomallon and. elem@nls in the tx..s1nt1ss pnx:ess. inlegration le~els. ,l.. ,l.. Define ~ftware requwemenls relaled lo business process. .J, Model and specify the business. pro~. •~. S1ml,lal10t1 and analysis of lhe busmess p,oces.s. .!.. Software anafysis and services identificalion. *. Review CIM model and 1ls relabonst11p wilhPIM. Rev1ew .11'1d validale PIM PIM oo1 ,_,,,,.,,..,. [Busmess p,ocess ~.Ji,ddt~J. Figura 2.7: Proceso de desarrollo de MOA. Tomada de [SVGFJAOB) En la figura 2.7 se presenta un ejemplo del flujo de trabajo definido anteriormente. En este ejemplo se puede observar que se requiere de la definición de los procesos de negocio para poder diseñar los modelos de los cuales se deberán extraer los servicios. De esta forma se puede apreciar que, aunque la definición de los procesos de negocio puede ser generada por los usuarios finales, se requiere de la participación de usuarios R. A. López Landa. 23.

(46) 2.6. TRABAJO RELACIONADO. con conocimientos y habilidades técnicas para la definición de los requerimientos de software y para la validación de los modelos PIM generados. Además, en este enfoque no se generan los artefactos de código para la elaboración automática de sistemas de software.. 2.6.3.. Un enfoque para el desarrollo de aplicaciones con MDA y WebML. Zhuang y Du [ZD09] presentan un enfoque para el desarrollo de aplicaciones web de comercio electrónico con base en el lenguaje de dominio específico WebML 3 . Así, los autores proponen una metodología en la que los desarrolladores deben generar: (1) un modelo de datos, representado por un diagrama entidad-relación; (2) un modelo de hipertexto, que permite especificar el flujo de navegación de la interfaz gráfica del usuario; y (3) un modelo de presentación que especifica la forma en la que se van a invocar las operaciones predefinidas. Una vez generados estos modelos, los desarrolladores podrán obtener, automáticamente, la base de datos y los artefactos de código que dan forma a la aplicación web, y que pueden ser instalados en un servidor de aplicaciones. Así, esta metodología permite generar aplicaciones web a partir de un lenguaje de dominio específico. Una ventaja de este enfoque es que permite especificar la navegación entre las páginas de la aplicación web. No obstante, se debe tomar en cuenta que el desarrollo del modelo requiere de la intervención de usuarios con conocimientos del DSL. De la misma forma, este enfoque requiere que se genere más de un modelo para el desarrollo de las aplicaciones web.. 2.6.4.. Análisis. A pesar de que los enfoques presentados aprovechan las ventajas de las arquitecturas orientadas a servicios y dirigidas por modelos, ninguno permite que usuarios con pocos conocimientos y habilidades técnicas puedan elaborar prototipos funcionales de sistemas de software. Además, aunque el enfoque para el desarrollo de aplicaciones con MOA y WebML es muy similar al que se propone en este trabajo de investigación, ya que permite la generación de prototipos funcionales a partir de modelos, se debe 3. 24. http://www.webml.org/. Tesis doctoral.