Generación de aplicaciones móviles conectadas con Mandarina Mobile

Texto completo

(1)Generación de Aplicaciones Móviles Conectadas con Mandarina Mobile. Carlos Andrés Toro Bolaños.

(2) UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN GRUPO DE CONSTRUCCIÓN DE SOFTWARE. Generación de Aplicaciones Móviles Conectadas con Mandarina Mobile. Carlos Andrés Toro Bolaños. Trabajo de grado para optar por el título de Maestría en Ingeniería de Sistemas y Computación de la Universidad de los Andes. Enero, 2013. Asesora: Dra. Rubby Casallas Jurado Interno: Dr. Darío Correal Jurado Externo: Dr. Carlos Parra.

(3) 2.

(4) Abstract Through the growth and penetration of diverse mobile platforms and devices with different capabilities, and the accelerated evolution of these technologies, arises a necessity to build fast and reliable applications that satisfies the market needs. Actually mobile application development has been characterized by the low productivity and incorrect use of visual design principles for every platform. In this paper we propose Mandarina Mobile a MD-SPL approach to generate cross-platform hybrid mobile applications, which take into account the platform and device where the application will be used. Mandarina Mobile presents the concept of mobile reference architecture as a PIM that will represent the functional requirements of the product and using model driven transformations techniques generate a PSM that will represent the final application. This paper presents our approach and how this helps us to improve development productivity and usability of the generated applications.. i.

(5) Índice general Abstract. i. Índice general. ii. Índice de Figuras. iv. Índice de Tablas. v. 1 Introducción 1.1 Contexto . . . . . . . . . . . 1.2 Descripción del Problema . . 1.3 Objetivos . . . . . . . . . . . 1.3.1 Objetivo General . . . 1.3.2 Objetivos Específicos . 1.4 Estrategia General . . . . . . 1.5 Contribución de la Tesis . . . 1.6 Organización del Documento. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 2 Contexto y Antecedentes 2.1 Ingeniería dirigida por modelos . . . . . 2.2 Ingeniería web dirigida por modelos . . 2.2.1 UWE . . . . . . . . . . . . . . . 2.2.2 OOHDM . . . . . . . . . . . . . 2.2.3 OOH4RIA . . . . . . . . . . . . . 2.3 Líneas de producto de software . . . . . 2.4 Líneas de producto de software dirigidas 2.5 Mandarina Mobile: Antecedentes . . . . 2.5.1 Genius . . . . . . . . . . . . . . . 2.5.2 JEMA . . . . . . . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . por modelos . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. 6 . 6 . 7 . 7 . 7 . 8 . 8 . 9 . 9 . 9 . 10. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . . .. . . . . . . .. . . . . . . .. 4 Aplicación de Mandarina Mobile en el caso de estudio 4.1 Variabilidad Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Especificación de los requerimientos funcionales y definición de la variabilidad para la SPL de Restaurantes . . . . . . . . . . . . . . 4.1.2 Configuración de un producto de software de la SPL de Restaurantes 4.1.3 Diagramas de interacción para la SPL de Restaurantes . . . . . . . 4.2 Variabilidad de Plataformas . . . . . . . . . . . . . . . . . . . . . . . . . . ii. 1 1 2 3 3 3 4 4 4. . . . . . . . .. 3 Mandarina Mobile: Visión general 3.1 Aplicaciones móviles conectadas . . . . . . 3.2 Caso de estudio . . . . . . . . . . . . . . . 3.3 Visión general de la solución . . . . . . . . 3.3.1 Variabilidad Funcional . . . . . . . 3.3.2 Variabilidad de Plataforma . . . . 3.3.3 Representación de la Arquitectura 3.3.4 Generación de la aplicación Móvil. . . . . . . . .. 13 13 14 15 15 17 18 20 21 21 21 23 24 25.

(6) Índice general 4.3. Representación de la Arquitectura . . . . . . . . . 4.3.1 Arquitectura estructura de Restaurantes . . 4.3.2 Arquitectura presentación de Restaurantes 4.3.3 Configuración Arquitectural . . . . . . . . .. iii . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 26 26 27 28. 5 Generación de las Aplicaciones Móviles Conectadas 5.1 Arquitectura de Referencia . . . . . . . . . . . . . . . 5.1.1 Vista Funcional . . . . . . . . . . . . . . . . . . 5.1.2 Patrón Estructural . . . . . . . . . . . . . . . . 5.1.3 Vista Desarrollo . . . . . . . . . . . . . . . . . 5.2 Aplicaciones Móviles Hibridas . . . . . . . . . . . . . . 5.3 Generación de las Aplicaciones . . . . . . . . . . . . . 5.3.1 Metamodelo de la arquitectura móvil . . . . . . 5.3.2 Metamodelos específicos de plataforma . . . . . 5.3.3 Generación del código . . . . . . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 30 30 30 30 32 33 34 35 37 40. 6 Comparación con otros trabajos 42 6.1 Mobl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.2 Canappi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7 Productividad en el Caso de Estudio. 44. 8 Conclusiones y Trabajo Futuro. 46. Bibliografía. 47.

(7) Índice de figuras 2.1 2.2. Representación de la solución dada en GENIUS. Tomada de [Mon12]. . . 11 Representación de la solución dada en JEMA. Tomada de [MMVS12]. . . 12. 3.1 3.2 3.3 3.4. Mandarina Mobile visión general. . . . . . . . . . . . . . . . . . . . . . Validación de Plataformas Móviles . . . . . . . . . . . . . . . . . . . . Modelo de Características y Catálogo de Patrones No Funcionales . . Patrones No Funcionales Vs Plataformas Compatibles Funcionalmente. . . . .. 16 18 19 20. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11. Entidades de negocio de la aplicación de restaurantes. . . . . . . . . . . . Casos de uso de la aplicación móvil para restaurantes . . . . . . . . . . . . Modelo de variabilidad para la SPL de restaurantes. . . . . . . . . . . . . Configuración de un aplicación móvil para restaurantes. . . . . . . . . . . Especificación del Diagrama de Interacción del patrón de caso de uso Detail. Diagrama de interacción para el caso de uso Crear Reserva . . . . . . . . Resultado de Validación Funcional de Plataformas Móviles . . . . . . . . . Arquitectura estructura de Restaurantes . . . . . . . . . . . . . . . . . . . Arquitectura presentación de Restaurantes . . . . . . . . . . . . . . . . . . Lenguaje para Configuración de Patrones no Funcionales . . . . . . . . . . Resultado Validación de Patrones no Funcionales en Dispositivos Móviles. 22 22 23 24 25 25 26 27 28 28 29. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11. Vista Funcional. . . . . . . . . . . . Patrón Estructural. . . . . . . . . . . Vista Desarrollo en UML. . . . . . . Pila de tecnologías. . . . . . . . . . . Aproximación de la generación. . . . MARC Metamodelo de estructura. . MARC Metamodelo de presentación. Metamodelo de JavaScript. . . . . . Metamodelo de PhoneGap. . . . . . Metamodelo de Backbone.js. . . . . Metamodelo de HTML5. . . . . . . .. 31 32 33 34 35 36 37 37 38 39 39. iv. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . . . . . . . . ..

(8) Índice de Tablas 3.1. Lista de versiones para la aplicación móvil para restaurantes . . . . . . . . 15. 4.1. Subsistemas de la SPL de restaurantes . . . . . . . . . . . . . . . . . . . . 23. 7.1. Tiempo requeridos para implementar rantes manualmente . . . . . . . . . Tiempo requeridos para implementar rantes usando Mandarina Mobile . .. 7.2. v. el producto . . . . . . . el producto . . . . . . .. 4 . 4 .. de la . . . de la . . .. SPL . . . SPL . . .. de restau. . . . . . . 44 de restau. . . . . . . 45.

(9) 1. Introducción 1.1 Contexto. El uso de los dispositivos móviles ha crecido a través de los años pasando por celulares básicos hasta los que hoy se destacan como los teléfonos inteligentes y las tabletas. Estos últimos se han caracterizado por tener capacidades de software y hardware cercanas a las que hace un tiempo solo un computador de escritorio podía brindar lo que ha incrementado la oferta y demanda de dispositivos y aplicaciones. Un estudio de Gartner del año 2012 muestra que las ventas de teléfonos inteligentes a nivel mundial en el año 2011 fue de 472 millones de unidades, 58 % mayor que en 2010 [GP12]. Ello deja ver el amplio potencial del mercado que también se ve reflejado en la importancia que tiene un dispositivo móvil en la vida de una persona. El trabajo, la familia, los amigos, la interacción con el mundo, se ven mediados por los artefactos tecnológicos a tal punto de ser una herramienta indispensable para el diario vivir. Es por ello que organizaciones de diferentes industrias como bancos, retail, entretenimiento, servicios financieros o manufacturas ven grandes oportunidades para mejorar e innovar en la operación de sus negocios. Competitividad, reducción de costos, incrementar la productividad y ventas son las motivaciones principales que empujan a estar organizaciones a tener aplicaciones móviles dentro de sus portafolios [XCu12]. Las empresas encuentran en las aplicaciones una gran oportunidad para manejar las ventas, mercadeo, inventarios, personal, apoyo logístico, entre muchos otros procesos. La principal ventaja de estas funciones es que la información está en tiempo real para todos los usuarios lo que evita inconvenientes de comunicación, los costos disminuyen, mejora la productividad y las decisiones son tomadas en menos tiempo. Un estudio del 2011 muestra que el 65 % de las empresas en Estados Unidos y Reino Unido habían planeado desarrollar cinco o más aplicaciones, mientras el 21 % esperan desarrollar 20 o más [XCu12]. De la misma manera, pueden mejorar su relación con los clientes a través servicios innovadores que les permita conocerlos mejor, tener un canal directo de retroalimentación y mejorar la satisfacción que se tiene frente al producto y la compañía. Sin embargo, el camino de entrada al desarrollo de aplicaciones es retador por los hechos del mercado donde resalta la fragmentación de dispositivos y su evolución acelerada, donde año tras año salen con mejores características y nuevas tecnologías que dejan a las aplicaciones desarrolladas como obsoletas. Asimismo, existe una gran cantidad de fabricantes, Apple, HTC, Motorola, Nokia, LG, Samsung, Sony que construyen una amplia gama de dispositivos, caracterizados por tener diferentes capacidades y características. Los existen de diferentes tipos y tamaños, con teclado o pantalla táctil, con sistema de geo posicionamiento o sin él, con acceso a 1.

(10) Introducción. 2. redes de baja o alta velocidad, infinidad de variaciones que son difíciles de enumerar y que también hacen difícil la personalización de las aplicaciones para cada una de estos variantes. Como un factor adicional que complejiza aún más la situación del desarrollo de aplicaciones móviles, se encuentra el hecho que estos dispositivos están soportados por múltiples plataformas, Android, Blackberry, iOS o Windows Phone, las cuales tienen grandes divergencias entre sí por la forma de construir las aplicaciones, los distintos estándares, las apariencias visuales, entre otras. Actualmente existen varios modelos de aplicación que se pueden desarrollar para estos dispositivos: Nativas, Web o Hibridas. Las aplicaciones nativas son aquellas desarrolladas usando el lenguaje nativo de la plataforma y se caracterizan por tener un alto rendimiento, sin embargo su desarrollo es completamente diferente entre otras plataformas. Por otra parte, las aplicaciones móviles basadas en web se desarrollan utilizando tecnologías web, y son ejecutadas por el denominador común entre las plataformas, un navegador, sin embargo no tienen el acceso a la mayor parte de las funcionalidades nativas del dispositivo. Por último, las aplicaciones híbridas se desarrollan utilizando tecnologías web y también los lenguajes nativos, tienen los beneficios de las aplicaciones nativas para acceder a todas las funcionalidades de la plataforma, pero el rendimiento es más bajo que el de una nativa. La elección entre estos diferentes modelos de aplicaciones consiste en tomar en cuenta los pros y los contras de cada uno y dependerá de las necesidades de la empresa, como en cualquier proyecto de software. [CL11] Con el fin de crear aplicaciones para este gran abanico de opciones y retos, la industria ha optado por hacer desarrollos independientes para cada plataforma a través de aplicaciones nativas o desarrollos multiplataforma usando diferentes frameworks y herramientas que prometen cambiar el panorama fragmentado de plataformas y dispositivos a través del uso de una base de código única en el que se pueden generar las aplicaciones correspondientes para cada plataforma. [Chr11] El mercado de estas herramientas de desarrollo multiplataforma se ha expandido rápidamente en los últimos años, de acuerdo al estudio realizado por Vision Mobile en 2012 [Mob12]. Estas herramientas, tienen una gran diversidad en la forma de cómo las aplicaciones se desarrollan. Algunos se concentran en generar aplicaciones nativas y otros en aplicaciones híbridas, utilizan diferentes lenguajes, como Java, C, C++ y Tecnologías Web, además permiten interactuar con las capacidades nativas de los dispositivos. Dentro de esta gama de herramientas de desarrollo multiplataforma hay otro jugador conocido como Mobile Enterprise Application Platform (MEAP) especializado no sólo en el desarrollo de aplicaciones móviles, sino también en su integración con aplicaciones empresariales existentes y gestionar el ciclo de vida de las mismas, incluyendo las pruebas, despliegue y gestión.. 1.2 Descripción del Problema En esta sección del documento se analizan los problemas identificados que suelen tener las aproximaciones relacionadas con nuestro trabajo, específicamente en el proceso de la generación de aplicaciones móviles multiplataforma que es la gran contribución de esta tesis al proyecto Mandarina Mobile. Problema 1: Productividad en el desarrollo Los diferentes métodos para la construcción de aplicaciones móviles (desarrollos independientes o uso de herramientas multiplataforma), en nuestro conocimiento -excluyendo a los MEAPs- utilizan estrategias dirigidas por código como el artefacto principal, por lo que, en el momento en que se requieren hacer múltiples aplicaciones dentro de un mismo dominio de negocio, el desarrollador tiene que realizar varias tareas repetitivas, tratar con muchas tecnologías, herramientas y procesos que resultan en una baja productividad y en tiempos de salida al mercado que no están a la altura con la acelerada evolución tecnológica que existe en el contexto de las aplicaciones móviles..

(11) Introducción. 3. Problema 2: Usabilidad Cada plataforma del gran abanico existente ha establecido principios visuales para las interfaces graficas de las aplicaciones que corren en ellas, dada la gran acogida por parte de los desarrolladores de aplicaciones de estos principios visuales estos se han establecido como estándares de usabilidad en la forma en que se presentan las funcionalidades a los usuarios para que estos puedan trabajar sin problema con las nuevas aplicaciones. Un gran ejemplo de esto es la interfaz metro que guía las aplicaciones para Windows Phone la cual es muy diferente a las directrices impuestas en Android o iOS. Sin embargo, gran parte de los enfoques de generación de aplicaciones multiplataforma no tienen en cuenta las características específicas de los dispositivos para la generación de las interfaces de usuario por lo que utilizan la misma interfaz para todas las plataformas sin tener en cuenta los principios visuales establecidos en cada una de estas. Esto tiene como consecuencia que el usuario final, dependiendo del tipo de dispositivo que tenga, no dispondrá de la mejor experiencia de usuario en la aplicación final. Problema 3: Extensibilidad de las aplicaciones generadas Dentro de las posibilidades de herramientas multiplataforma algunas se enfocan en la generación de código a través del uso de lenguajes de dominio específico o lenguajes comunes de programación, que abstraen conceptos específicos de las plataformas para poder generar las correspondientes aplicaciones. Sin embargo, lograr abstraer todos los conceptos específicos de tantas plataformas y sus grandes variaciones es una tarea bastante complicada, por lo que estas aproximaciones generalmente no las soportan. Es por ello que si se quiere explotar características específicas de cada plataforma, las aplicaciones deberían poderse extender manualmente sin ninguna complicación. Sin embargo, dentro de nuestro conocimiento estas estrategias no están enfocadas a la manipulación manual del código generado, de hecho algunas no permiten tener acceso a este, por lo que explotar este tipo de características en las aplicaciones generadas es algo complicado.. 1.3 Objetivos 1.3.1.. Objetivo General. Proponer una solución que permita la generación automática de aplicaciones móviles para múltiples plataformas a través de líneas de producto de software orientada por modelos haciendo énfasis en la etapa de derivación y generación del producto, integrando y reutilizando ideas de proyectos del grupo de construcción de software de la Universidad de los Andes.. 1.3.2.. Objetivos Específicos. Especificar una arquitectura de referencia para la línea de producto de software que nos permita representar las variabilidades funcionales y no funcionales de cada producto y poder derivar cada aplicación mediante el uso de modelos y transformaciones que hacen parte de los activos de la línea para incrementar los niveles de productividad en aplicaciones móviles multiplataforma dentro de un mismo dominio. Desarrollar una serie de activos que generen las interfaces graficas teniendo en cuenta los principios de visualización de la plataforma y dispositivo donde se va a usar la aplicación, con lo cual, se pueda tener mejores niveles de usabilidad en las aplicaciones generadas. Implementar una serie de activos que generen el código de la aplicación conforme a la arquitectura de referencia especificada para la línea, y que tenga una estructura.

(12) Introducción. 4. adecuada y siguiendo las mejores prácticas de desarrollo para facilitar la extensión manual de las aplicaciones. Validar el enfoque presentando un caso de estudio donde se desarrolle una línea de productos de software en el dominio de restaurantes, que permita ver el potencial de la aproximación y las diferentes aplicaciones móviles conectadas que pueden ser generadas automáticamente.. 1.4 Estrategia General Mandarina Mobile es una aproximación basada en líneas de producto de software dirigidas por modelos que busca incrementar la productividad en el desarrollo de aplicaciones móviles multiplataforma. Nuestra estrategia partió de la construcción de un ejemplo concreto que pretendía explotar características especiales de los dispositivos móviles como el uso de GPS, mensajería de texto, contactos, etc. Para esto se diseñaron casos de uso en un dominio específico de aplicaciones para restaurantes, los cuales fueron implementados a través de aplicaciones nativas de prueba para las plataformas Android, Windows Phone y BlackBerry y también aplicaciones hibridas para Android y Windows Phone. El desarrollo de estas aplicaciones de prueba fue la base para diseñar, plantear y construir nuestra aproximación global. La estrategia general se basa en construir una línea de producto de software (SPL) en un contexto específico: las aplicaciones móviles conectadas que se caracterizan por estar conectadas con un servidor remoto que soporta la mayoría de requerimientos funcionales y el uso de algunas características concretas de los móviles como el GPS, la cámara, los contactos, etc. El objetivo principal de esta SPL es derivar varias aplicaciones móviles donde se puedan configurar sus variaciones funcionales y no funcionales, y las plataformas y dispositivos donde las aplicaciones van a ser usadas. Esta serie de productos deben estar dentro de un mismo dominio de negocio y deben ser representados como activos de la SPL usando diagramas de entidades y casos de uso asociados a patrones de casos de uso.. 1.5 Contribución de la Tesis Mandarina Mobile es un proyecto desarrollado en conjunto con el grupo de construcción de software de la Universidad de los Andes, la estrategia global está dividida en varias fases que son contribuciones de varias personas. Particularmente la fase de variabilidad funcional es trabajada por Leonardo Ibarra, la fase de variabilidad de plataformas y configuración de patrones no funcionales es trabajada por Román Albarracín y las principales contribuciones de este trabajo están en la generación de aplicaciones móviles que hace parte de la derivación de un producto concreto. Estas contribuciones son: (1) la implementación de aplicaciones móviles hibridas de referencia que permitieron guiar el desarrollo de la aproximación , (2) la conceptualización de una arquitectura de referencia para la SPL en el contexto de las aplicaciones móviles conectadas, (3) la definición de un metamodelo de arquitectura que representa la aplicación usando un modelo independiente de la plataforma (PIM), (4) la conceptualización de modelos específicos de plataforma (PSM) que representan los frameworks y tecnologías usadas en la aplicación concreta, (5) el empleo de una cadena de transformación para la generación automática de código a través de un modelo específico de plataforma (PSM) que se obtiene a partir del modelo de arquitectura (PIM), y (6) el desarrollo de un caso de estudio que permite ver la validez de la aproximación global.. 1.6 Organización del Documento Este documento se encuentra organizado de la siguiente manera: El capítulo 2 presenta el contexto que enmarca la estrategia global del proyecto y los antecedentes del.

(13) Introducción. 5. mismo. En el capítulo 3 presentamos la estrategia global de Mandarina Mobile. En el capítulo 4 se muestra la aplicación de la estrategia global al caso de estudio, por lo tanto el capítulo 3 y 4 son capítulos escritos en conjunto con los otros miembros del proyecto. El capítulo 5 explica las contribuciones de esta tesis incluyendo en detalle cómo fue la implementación de la misma. En el capítulo 6 nos comparamos con dos iniciativas que están relacionadas con la generación de aplicaciones móviles. En el capítulo 7 se muestran los incrementos de productividad con el uso de nuestra solución por lo que también es un capítulo en conjunto. Finalmente en el capítulo 8 se concluye la tesis y se presenta el trabajo futuro..

(14) 2. Contexto y Antecedentes. En este capítulo se presentan los conceptos principales de las temáticas que son la base de la tesis: ingeniería dirigida por modelos, ingeniería web dirigida por modelos y líneas de producto de software. Estas temáticas serán explicadas brevemente para dar un contexto sobre nuestra estrategia general. De la misma manera los trabajos previos desarrollados en el grupo de Construcción de Software de la Universidad que son los antecedentes de nuestra aproximación.. 2.1 Ingeniería dirigida por modelos La Ingeniería dirigida por modelos (MDE) es un enfoque que propone el uso de modelos como ciudadanos de primera clase que permitan la separación de preocupaciones en el desarrollo de software por medio de varios niveles de abstracción. En MDE se busca hacer la ingeniería de software usando modelos asociados al dominio del problema y no sobre artefactos de software que están ligados a tecnologías particulares. [Béz06] Pero para entender MDE se debe entender la base que está compuesta por cuatro niveles de abstracción siendo el primero el más abstracto: M3 meta-metamodelo el cual sirve para definir los conceptos de los metamodelos y se especifica usando elementos de otros meta-metamodelos; M2 metamodelo, es un modelo abstracto que permite definir los conceptos de los modelos y se especifica usando elementos definidos en metametamodelos; M1 modelo, sirve para especificar diferentes aspectos de una versión simplificada de un sistema y su entorno; M0 son las instancias particulares de un modelo. La relación existente entre estos modelos de diferentes niveles de abstracción se conoce como la conformidad, de esta manera los modelos del nivel más bajo son conformes a su nivel superior. Es decir, un modelo es conforme a su metamodelo. El otro gran artefacto dentro de MDE son las transformaciones que producen modelos de salida dado otros modelos de entrada, a partir de ciertas reglas que los permiten traducir, estos modelos deben ser conformes a metamodelos incluidos en la transformación. Existen transformaciones de modelo a modelo (m2m) y modelo a texto (m2t). En m2m la salida de las transformaciones es otro modelo donde generalmente se baja el nivel de abstracción de la representación del sistema, y las m2t generan código valido de cierta plataforma escogida. La arquitectura dirigida por modelos (MDA) es una iniciativa de la (OMG) basada en los principios de MDE, su principal objetivo es separar la lógica de la aplicación y representación del problema de la plataforma tecnológica donde iba a ser ejecutada. De esa manera definieron tres tipos de modelos diferenciados por el nivel de abstracción: CIM modelo independiente del contexto es donde se puede expresar los requerimientos 6.

(15) Contexto y Antecedentes. 7. del negocio y es comúnmente usado para la representación del problema; PIM modelo independiente de la plataforma es donde se puede expresar abstractamente la solución del problema donde se pueden incluir elementos del diseño del sistema; PSM modelo dependiente de la plataforma describe la plataforma donde la solución va a ser desplegada y se incluye la solución del problema. Las aplicaciones pueden ser generadas automáticamente usando transformaciones m2m y m2t, inicialmente llevan modelos conformes CIM a modelos conformes PIM y modelos conformes PSM bajando el nivel de abstracción de la representación del sistema y finalmente con transformaciones a texto generan el código de la aplicación. [DFPS09]. 2.2 Ingeniería web dirigida por modelos El desarrollo dirigido por modelos se puede aplicar a varios dominios pero, particularmente, ha sido motivo de investigación en el dominio de las aplicaciones web como es descrito en [KMM+ 08] al cual han denominado ingeniería web dirigida por modelos (MDWE). Este tema ha sido de gran interés por la constante y natural evolución de las plataformas para este tipo de aplicaciones. Actualmente existen varias estrategias relacionadas con MDWE, las cuales capturan las distintas preocupaciones de las aplicaciones web como el contenido, la visualización y la navegación usando diferentes técnicas. Particularmente se estudiaron las aproximaciones de UWE, OOHDM y OOH4RIA.. 2.2.1.. UWE. UWE es una metodología de modelado web definida como una extensión de UML a través del uso de perfiles para representar elementos propios de sus modelos en diagramas convencionales de UML. La estrategia de ellos está basada en la separación de preocupaciones para la generación de las aplicaciones web de una manera incremental. Las preocupaciones las definen haciendo el uso de varios modelos PIM describiendo el contenido, la navegación, el proceso de negocio y la presentación de la aplicación. [KKK07] Primero está el modelo de contenido donde se definen a través de un diagrama de clases de UML la estructura del dominio del negocio con todas las entidades que el sistema manejará; segundo, el modelo de navegación que a través de otro diagrama de clases anotado se representa los caminos de navegación de la funcionalidad del sistema; tercero, un modelo de proceso donde se representan los aspectos dinámicos de la aplicación web como transacciones y flujos complejos de actividades a través del uso de un diagrama de actividades UML y cuarto, un modelo de presentación que contiene la estructura de elementos visuales que componen la interfaz de usuario a través del uso de un diagrama de clases de UML.. 2.2.2.. OOHDM. OOHDM es un enfoque también fundamentado en la separación de preocupaciones que permite mejorar la navegación, mantenimiento y evolución de las aplicaciones web. Estas aplicaciones son construidas en un proceso de cinco pasos que soportan un proceso incremental, cada paso se enfoca en una preocupación de diseño y un modelo apropiado es construido. [RS08] El primer paso del proceso es el análisis de requerimientos, el cual se define a partir de la definición de casos de uso con sus parámetros correspondientes a través de diagramas de interacción de usuario un metamodelo definido por ellos para este fin; el segundo paso lo denominan diseño conceptual donde se representa la semántica y estructura del dominio de la aplicación a través de un perfil del diagrama de clases de UML; el tercer paso el diseño de la navegación donde se definen objetos de navegación como nodos y vínculos que están ligados a conceptos del dominio y son creados para cada usuario del sistema ya que tienen comportamientos distintos; el cuarto paso es el diseño de la interfaz.

(16) Contexto y Antecedentes. 8. que está compuesto por la especificación de elementos visuales que contienen información y el manejo de los eventos disparados por los usuarios o el sistema, estos elementos se ligan con los navegacionales especificando la comunicación entre estos; el último paso lo denominan el de implementación donde se pueden especificar arquitecturas elaboradas que vinculan elementos de la interfaz, con los de la navegación y contienen la gran imagen de la aplicación a generar. Finalmente con el modelo del último paso a través de una herramienta denominada HyperDE se genera la aplicación basada en la plataforma Ruby on Rails por medio de transformaciones m2m y m2t.. 2.2.3.. OOH4RIA. OOH4RIA es una estrategia basada en el paradigma de ingeniería dirigida por modelos (MDE) que propone un proceso que contiene una serie de modelos y transformaciones para la generación de aplicaciones de internet enriquecidas (RIA) en una tecnología particular: GWT, esta estrategia es similar a la aproximación presentada por OOHDM. [MGPD08] El proceso inicia con la definición de un modelo del dominio y un modelo de navegación que sirven de entrada para una cadena de transformación que genera la aplicación final. Hay un punto intermedio en la cadena donde son representados las preocupaciones estructurales y de comportamiento de la aplicación en dos metamodelos diferentes: el metamodelo de presentación y el de orquestación. Esos modelos son específicos de la plataforma GWT, representan la estructura de la interfaz de usuario y el comportamiento de las funcionalidades para que finalmente a través de transformaciones modelo a texto generen la aplicación final.. 2.3 Líneas de producto de software Las líneas de producto de software (SPL) es una metodología para el desarrollo de software, basado en el mismo principio de las líneas de producto donde cada producto es una aplicación que comparte una serie de características comunes que satisfacen necesidades particulares de un dominio o segmento de mercado y son desarrollados a partir de activos comunes de una manera prestablecida [CN01]. Por lo tanto, una SPL permite ensamblar o generar aplicaciones que comparten elementos comunes y conforme a una configuración pueden tener comportamientos distintos. Este paradigma ha sido definido de varias maneras en distintas investigaciones, que han definido metodologías específicas para el desarrollo de SPL, por lo que no existe una receta específica sino la interpretación y uso de varias aproximaciones. Teniendo como base el trabajo de Pohl [PBvdL05] se definen dos procesos muy importantes que son la columna vertebral de las líneas de producto de software: La ingeniería del dominio y la ingeniería de la aplicación. La ingeniería del dominio es el proceso donde se definen los activos que permitirán construir los productos concretos. Los principales activos que se desarrollan en este proceso son: (1) el análisis del dominio o segmento de mercado donde se establece qué funcionalidades son comunes, cuáles son opcionales, y cuáles son alternativas para la familia de productos; (2) una arquitectura de referencia para la línea desarrollada a partir del análisis del dominio, donde se establecen qué componentes de la arquitectura son comunes, opcionales y variables; y (3) componentes desarrollados que satisfacen la arquitectura de referencia. La ingeniería de aplicación es el proceso donde se deriva o genera un producto. El proceso inicia con la configuración de los activos a partir de las definiciones de lo común y variable que permite satisfacer las necesidades del producto concreto. A partir de estas configuraciones el producto final es ensamblado haciendo uso de los activos desarrollados en la ingeniería del dominio y el producto final es entregado. Las grandes motivaciones que mueven la industria para el uso de líneas de productos de software son incrementos de productividad, reducción de costos, reducción de tiempos en la salida al mercado, incremento de la calidad del software. Todas estas motivaciones.

(17) Contexto y Antecedentes. 9. o beneficios son válidos en escenarios donde el dominio de la línea de producto permita especificar gran cantidad de productos que correspondan a la realidad del negocio.. 2.4 Líneas de producto de software dirigidas por modelos Las líneas de producto de software dirigidas por modelos (MD-SPL) combinan la capacidad de abstracción de la ingeniería dirigida por modelos y la capacidad de generación de una familia de productos de software con variaciones y similitudes. MDE ayuda a representar gran variedad de artefactos de la SPL más abstractamente y también una aproximación para la generación automática de productos a través de cadenas de transformación. [CAK+ 05] Gran parte de los activos definidos en el proceso de ingeniería del dominio en una SPL como la arquitectura de referencia y los componentes son usados de manera estrictamente documental o se encuentran desarrollados para una plataforma específica. El aumento en el nivel de abstracción que provee MDE, permite representar el dominio del problema como un artefacto de primera clase (CIM) al que a través de transformaciones sucesivas se obtiene un modelo independiente de plataforma (PIM) que puede ser la arquitectura de referencia de la línea y a partir de este artefacto continuar con transformaciones que generen modelos dependientes de plataforma y finalmente el producto final. Por lo tanto, la incorporación del enfoque MDE dentro de una SPL puede facilitar la derivación de productos a través de la representación del problema y no de la solución. Mezclar estas dos metodologías puede traer lo mejor de los dos mundos como la independencia tecnológica y un proceso bien definido para la creación de múltiples aplicaciones dentro de un mismo dominio.. 2.5 Mandarina Mobile: Antecedentes Dentro de las líneas de investigación del grupo de construcción de software de la Universidad de los Andes se han desarrollado una serie de proyectos que han sido la base para la construcción de nuestra aproximación. Genius [Mon12] y Jema [MMVS12] son dos de los proyectos más recientes los cuales a su vez fueron desarrollados a partir del trabajo de otros proyectos. En esta sección explicaremos brevemente la aproximación general de cada uno de estos.. 2.5.1.. Genius. Genius: Use Case Pattern-Based Approach to Web User Interface Generation for Enterprise Applications [Mon12], fue desarrollado bajo un enfoque MDWE (Model-Driven Web Engineering) para aplicaciones web transaccionales. En términos generales este proyecto presenta una propuesta para representar el problema independientemente de la solución, expresando su estructura y requerimientos funcionales. En la representación del problema usa patrones para tomar ventaja de los problemas comunes encontrados en el dominio tecnológico seleccionado y así implementar la solución conocida para dichos patrones, esto le permite maximizar la cantidad de código generado de los componentes web de las aplicaciones web transaccionales, separando la descripción del problema de la tecnología o la solución planteada. Para lograr su objetivo esta aproximación se enfoca en dos objetivos esenciales: (1) proveer un artefacto donde un experto en el dominio de negocio pueda describir el problema usando sólo términos del negocio, y (2) crear un mecanismo que permita factorizar la implementación, comportamiento y estructura común de los requerimientos funcionales comunes y automatizar la generación de las soluciones conocidas..

(18) Contexto y Antecedentes. 10. Representación del problema Para la representación del problema GENIUS usa dos artefactos: (1) un Modelo de la Aplicación Empresarial que contiene la estructura del dominio del negocio, es decir, las entidades que hacen parte del dominio y (2) un Modelo Extendido de Casos de Uso que representan los requerimientos funcionales de la aplicación. Estos artefactos son representados por un Lenguaje de Dominio Específico creado para tal fin. Representación de la solución En la representación de la solución se usa un concepto muy conocido en la Ingeniería de software, los patrones. Un patrón es una solución reutilizable sobre problemas que ocurren comúnmente en un contexto dado [GHJV95]. Tomando como referencia la definición anterior se puede decir que en un dominio tecnológico específico podemos identificar interacciones del usuario y el sistema que son comunes y que pueden ser representadas para automatizar la generación de código. Por ejemplo, si se desea consultar la información de una entidad del negocio, la interacción del usuario requiriendo los datos de la entidad, el sistema consultándola de un repositorio y por último mostrando los datos de la entidad al usuario, siempre es la misma. Una vez identificada la interacción necesaria para resolver la necesidad del usuario se puede construir una MTC que contenga la información y una serie de transformaciones necesarias para generar la solución del patrón. La representación de las interacciones del usuario del sistema, es decir, el funcionamiento del patrón, se describen mediante los Interaction Specification Diagram Model (IDSpec).Para lograr su objetivo esta aproximación se enfoca en dos objetivos esenciales: (1) proveer un artefacto donde un experto en el dominio de negocio pueda describir el problema usando sólo términos del negocio, y (2) crear un mecanismo que permita factorizar la implementación, comportamiento y estructura común de los requerimientos funcionales comunes y automatizar la generación de las soluciones conocidas. Cadena de Transformación de GENIUS En la Figura 2.1 se observa cómo se logran los dos objetivos propuestos por GENIUS, del lado izquierdo se encuentra la representación del problema usando los dos artefactos antes mencionados. Tomando como base la representación del problema se aplican las transformaciones detalladas por cada patrón a través del IDSpec. Al final se combinan las soluciones de los diferentes patrones para generar un Diagrama de Interacción (ID) que será la fuente para crear un modelo de Entidades de la Aplicación Empresarial (EA) que permite la creación de la capa de la lógica del negocio y los Modelos de Forms y Nav que son el insumo para la generación del código web o capa de presentación.. 2.5.2.. JEMA. A Model-Based Framework for Developing Management Information Systems Software Product Lines[MMVS12]. Es una solución que está centrada en los principales procesos de las líneas de productos de software: la ingeniería de dominio y la ingeniería de aplicación. La intención es apoyar las actividades específicas que se realizan durante estos procesos con el fin de favorecer una reducción de los costos asociados a la configuración del producto de software en la línea de productos. En el proceso de ingeniería de dominio, los activos son diseñados e implementados de acuerdo a las necesidades de un dominio específico. Esta fase es responsable de la definición de los componentes reutilizables que forman la base para una configuración específica del producto. Define e implementa las construcciones incluyendo requisitos, arquitectura, componentes, pruebas, entre otros, que pueden ser obligatorios u opcionales, en función del interés común y la variabilidad del dominio específico. En el proceso de ingeniería de aplicación, los productos se derivan de la selección y el montaje de los activos de software de la línea de producto. Esta fase es responsable de lograr la mayor reutilización de los activos del dominio durante la definición y desarrollo.

(19) Contexto y Antecedentes. 11. Figura 2.1 Representación de la solución dada en GENIUS. Tomada de [Mon12].. de aplicaciones sobre la línea de producto. Se benefician de los aspectos comunes y variables del conjunto de activos con el fin de satisfacer las necesidades individuales de cada cliente. Para satisfacer el objetivo final de reducir los costos de configuración de productos en una línea de producto de software, este framework mantiene en su nivel más abstracto un esquema de tres etapas de configuración: Variabilidad funcional, la cual se enfoca en la configuración de los aspectos de dominio para lograr la configuración automática de cada producto basado en los requisitos que se especifican; la variabilidad arquitectónica, permite administrar la estructura arquitectónica ofrecida por el Framework para realizar configuraciones por cliente con el fin de responder a las necesidades particulares; y la Variabilidad de Plataforma, permite la realización del producto una vez que la arquitectura ha sido configurada. Las tres etapas mencionadas anteriormente se materializan gracias a la cadena de transformación JEMA. Su tarea principal es llevar los modelos expresados en términos de conceptos del dominio como entrada, y ejecutar una secuencia de transformaciones de modelos que agregan conocimiento funcional, arquitectónico y de la plataforma, así como los detalles de implementación en cada paso. Finalmente, utilizando los modelos consolidados, JEMA produce un artefacto que representa la solución en términos de una tecnología específica. Los componentes básicos de esta cadena de transformación no sólo incluyen metamodelos, modelos y transformaciones, también lenguajes de dominio específicos (DSL). Permiten a los actores de la línea de producto expresar las decisiones durante los procesos de SPL sin tener un conocimiento completo de la estructura subyacente. En el proceso de ingeniería de dominio, estos lenguajes se utilizan para especificar los conceptos abstractos que representan los activos y su respectiva similitud y variabilidad. Asimismo, durante el proceso de ingeniería de aplicaciones, el DSL se utiliza para especificar un producto en función de los requisitos que debe cumplir para configurar su arquitectura. Los modelos, las transformaciones y los DSLs, como componentes de la MTC JEMA, establecen las bases para la realización de la variabilidad funcional, arquitectónico y la plataforma. La Figura 2.2 muestra el esquema de la cadena de transformación. En la etapa de variabilidad funcional, los activos de la SPL se definen y clasifican (obligatorio, opcional) dependiendo de las necesidades del dominio específico. Cuando un producto tiene que ser configurado, el arquitecto de la aplicación selecciona los activos que serán ensamblados para satisfacer las necesidades particulares de un cliente individual. Como resultado, los activos seleccionados se toman como entrada para la siguiente etapa, como el artefacto funcional. La primera actividad es una manifestación de la Ingeniería de Requisitos del Dominio sub-proceso, mientras que la segunda y la.

(20) Contexto y Antecedentes. 12. Figura 2.2 Representación de la solución dada en JEMA. Tomada de [MMVS12].. tercera corresponde a la Ingeniería de Aplicación Requisitos. Después, durante la etapa de variabilidad arquitectónica, una arquitectura base multicapa se especifica automáticamente mediante la incorporación de los aspectos funcionales del producto deseado. Esta Arquitectura es ampliada en dos puntos de vista: Funcional y Desarrollo, en un intento de abordar las preocupaciones arquitectónicas de forma separada. Como otro aspecto central de esta etapa, JEMA proporciona un mecanismo para configurar la arquitectura base y enriquecerla con decisiones que particularizan el comportamiento y la estructura que va a ser exhibida por el producto final. Esta configuración se realiza a través de la selección de patrones arquitectónicos apoyados por el framework. Por último, en la etapa de variabilidad de plataforma es donde el producto final es generado reflejando las decisiones funcionales y arquitectónicas. Se inicia mediante la transformación de los puntos de vista en la plataforma relacionados con el aprovechamiento de la separación preocupación de que fue concebido previamente. En este punto, la configuración del producto se utiliza para enriquecer este modelo de la plataforma mediante la adición y modificación de los conceptos de la misma plataforma que representan las decisiones arquitectónicas basadas en patrones. El modelo resultante se procesa entonces con el fin de generar los archivos de origen necesarios en código y descriptores que constituyen la solución final. Una característica importante de esta propuesta es que sus tres etapas se pueden combinar de dos maneras interrelacionadas para generar los productos finales. La primero permite que los productos derivados se generen automáticamente después de realizar una configuración funcional. La segunda añade una configuración opcional de arquitectura de la etapa anterior. En este sentido, uno se basa únicamente en una configuración funcional y la segunda añade a la primera la posibilidad de configurar ciertos aspectos arquitectónicos y de proporcionar un producto enriquecido. Ambos generan el código fuente que representa el comportamiento esperado..

(21) 3. Mandarina Mobile: Visión general Mandarina Mobile es un proyecto del grupo de Construcción de Software de la Universidad de los Andes y las principales contribuciones hacen parte del trabajo de tesis de varias personas, es por ello que para explicar la estrategia general se tiene en cuenta los trabajos individuales de todos los miembros del proyecto, por lo tanto esta es una sección compartida. Primero se va presentar el contexto de las aplicaciones móviles que van a ser generadas, segundo se presenta el caso de estudio que muestra un escenario donde nuestra aproximación es válida y finalmente se muestra la aproximación global del proyecto.. 3.1 Aplicaciones móviles conectadas Existe un amplio espectro de diferentes tipos de aplicaciones móviles enfocadas en distintas necesidades de los usuarios, por ejemplo juegos, multimedia, productividad, comunicaciones, entre otras. Esa es la principal razón del por qué en nuestra aproximación definimos el contexto de las aplicaciones móviles que vamos a generar. Hoy en día se les han dado muchos nombres a aplicaciones con objetivos similares a las que queremos definir en Mandarina Mobile. Aplicaciones móviles empresariales, aplicaciones móviles en línea, aplicaciones de hipermedia móvil, aplicaciones móviles dirigidas por datos, son algunas de las etiquetas que intentan caracterizar a las aplicaciones móviles que requieren de una conexión de red a una fuente de datos remota con el fin de satisfacer los requerimientos funcionales de estos. Sin embargo, para tener claro cuál es el tipo de aplicaciones que se van a generar en este proyecto, nosotros lo caracterizamos con el nombre de: Aplicaciones Móviles Conectadas. Este tipo de aplicaciones se caracterizan por estar soportadas por un servidor de back-end, requieren una conexión de red constante y usan funciones específicas de los teléfonos celulares como el GPS, multimedia, información de contactos, calendario, etc. Las funcionalidades soportadas son crear, leer, actualizar, borrar (CRUD) y listar entidades de negocio, las cuales son presentadas al usuario en el dispositivo pero la persistencia se realiza en el servidor. A pesar de las restricciones impuestas en término de funcionalidades a este tipo de aplicaciones, nuestra estrategia de composición de casos de uso, permiten la creación de una amplia gama de productos concretos con gran variabilidad funcional y que se ajusta a las realidades del teléfono.. 13.

(22) Mandarina Mobile: Visión general. 14. 3.2 Caso de estudio Con el fin de evaluar nuestro enfoque hemos desarrollado el siguiente caso de estudio en torno a un dominio de negocio específico para mostrar un escenario en donde la estrategia de Mandarina Mobile beneficia la productividad de los desarrolladores de aplicaciones móviles conectadas. Todos los ejemplos e ilustraciones presentados en este documento están basados en este caso de estudio. Una empresa de desarrollo de software de aplicaciones para restaurantes desea responder a las necesidades crecientes de sus clientes, quienes quieren tener aplicaciones móviles dentro de su portafolio de servicios para poder ofrecer funcionalidades innovadoras para mejorar el funcionamiento de su negocio. La compañía de software no quiere hacer desarrollos independientes para su gran lista de clientes y reducir la capacidad de atender los nuevos, por eso se toma la decisión de utilizar Mandarina Mobile. Nuestro enfoque les da la oportunidad de generar aplicaciones para cada uno de sus clientes, en donde deben realizar una inversión inicial en el modelado del dominio de los restaurantes, lo que les permite tener altos niveles de productividad, teniendo en cuenta que no tienen ninguna experiencia en el desarrollo de aplicaciones móviles. Realizando un análisis del dominio de las aplicaciones móviles para los restaurantes de han identificado los siguientes requerimientos: (1) Consulta de la ubicación de las sucursales de un restaurante usando como referencia la localización actual del cliente. (2) Mostrar información de las sucursales como datos de ubicación, teléfono, horario. (3) Consultar el menú ofrecido por el restaurante. (4) Reserva de mesas por parte de los clientes. (5) Uso de características propias del celular como inclusión de la reserva en el calendario del dispositivo o envío de mensajes SMS con los datos de una reserva. Para satisfacer los requerimientos anteriormente mencionados se identificó que el alcance de la SPL debe contener los siguientes casos de uso: Consultar sucursal cercana: Permite realizar una búsqueda de las sucursales del restaurante que se encuentran en un radio específico de la ubicación del cliente. Consultar menú: Permite realizar una consulta de la información de los platos que se encuentran en el menú. Reservar mesa: Permite realizar una reserva en una sucursal para una fecha y hora específica. Actualizar Reserva: Permite modificar los datos de fecha y hora de una reserva. Eliminar Reserva: Permite eliminar una reserva. Consultar Reserva: Muestra los datos de una reserva. Incluir evento al calendario: Crea un evento en el calendario del dispositivo móvil con los datos de la reserva. Enviar reserva por SMS: Envía los datos de una reserva a través de un mensaje SMS. De acuerdo a los casos de uso identificados para este dominio en particular, se puede realizar una segmentación de clientes para quienes se ofrece un producto diferente de la aplicación. Es así como podemos crear 4 productos de la siguiente forma: El producto 1 está dirigido a los restaurantes cuyo interés particular es que sus clientes los puedan ubicar fácilmente y obtener información de contacto o llegada a cualquiera de sus sucursales. Un Producto 2 además de servicios de ubicación puede presentar a los clientes del restaurante la consulta de los platos ofrecidos por el restaurante con información detallada de ingredientes y precios. Por otra parte, un Producto 3 puede ser usado por los restaurantes interesados en permitir a sus clientes no solo ubicar las sucursales si no.

(23) Mandarina Mobile: Visión general. 15. también poder realizar reservas a través de su dispositivo móvil. Y con el fin de aprovechar las características de los dispositivos móviles se puede crear un Producto 4 con la capacidad de interactuar con el calendario o el envío de mensajes SMS. Cada uno de estos productos puede ser construido con la combinación de los casos de uso anteriormente mencionados. Por ejemplo el Producto 3 estaría compuesto por los casos de uso Consultar sucursal cercana, Reservar Mesa, Consultar Reserva, Actualizar Reserva y Eliminar Reserva. Con estos casos de uso un cliente del restaurante está en la posibilidad de buscar una sucursal de acuerdo a su posición y realizar reservas o modificarlas de acuerdo a su preferencia. Los casos de uso que componen cada uno de los productos mencionados se presentan en la Tabla 3.1. Tabla 3.1 Lista de versiones para la aplicación móvil para restaurantes. Casos de Uso Consultar sucursal cercana Consultar menú Reservar mesa Consultar Reserva Actualizar Reserva Eliminar Reserva Incluir evento al calendario Enviar reserva por SMS. Producto 1 X. Producto 2 X X. Producto 3 X X X X X. Producto 4 X X X X X X X X. 3.3 Visión general de la solución La estrategia general de Mandarina Mobile presentada en la Figura 3.1, se basa en el desarrollo de una línea de productos de software basada en modelos para la generación de aplicaciones móviles conectadas en dominios específicos del negocio. Este marco se descompone en cuatro grandes actividades: 1) variabilidad funcional, 2) variabilidad de plataformas, 3) representación arquitectural y 4) generación móvil. La primera actividad es la contribución principal de Leonardo Ibarra, la segunda actividad es una contribución de Román Albarracin así como la configuración de patrones no funcionales que enriquecen la arquitectura en la tercera actividad y finalmente mis contribuciones se centran en la actividad de representación arquitectural y generación móvil.. 3.3.1.. Variabilidad Funcional. Esta actividad está dividida en tres fases: (1) la especificación de los casos de uso y definición de la variabilidad de la SPL, (2) la configuración de los productos de la SPL y (3) la generación de los diagramas de interacción de los casos de uso. Especificación de los requerimientos funcionales y definición de la variabilidad En la fase (1) de la Figura 3.1 el arquitecto del dominio debe especificar los subsistemas que hacen parte de los activos de la SPL y por cada subsistema debe definir los casos de uso y entidades que están agrupados de acuerdo a su afinidad funcional. Adicionalmente el Arquitecto del dominio debe definir la variabilidad de la SPL usando como activos los casos de uso y subsistemas. A continuación se describen estas actividades: 1. Especificación de entidades. La especificación de las entidades del negocio es el primer paso en la descripción del problema en cualquier dominio. Cada entidad de negocio debe ser especificada a través de: (a) un nombre que la identifique, (b) los.

(24) Mandarina Mobile: Visión general. 16. Figura 3.1 Mandarina Mobile visión general.. atributos que la describen identificando por cada uno el nombre y el tipo de dato y (c) las relaciones con otras entidades de negocio. 2. Especificación de casos de uso. Basados en la propuesta presentada en GENIUS [Mon12] los casos de uso son especificados usando Patrones. Estos patrones tienen asociada la solución ya conocida a los requerimientos más comunes en la construcción de sistemas de información. Sin embargo, una de las limitaciones a las que nos enfrentamos con el uso de patrones para la especificación de casos de uso es que solo se pueden utilizar patrones que existan previamente en el catálogo y que contenga asociadas las actividades propias de su solución. Por lo tanto si en el catálogo solo se han definido patrones simples como los del CRUD no es posible especificar casos de uso más complejos, lo que imposibilita el modelamiento del 100 % de la aplicación de software. Con el fin de mitigar el impacto causado por esta limitación se plantea como estrategia la composición de casos de uso, es decir, poder crear un nuevo caso de uso a partir de la unión de varios ya descritos y de esta forma se pueden especificar casos de uso más complejos. La composición se realiza por medio de la relación include descrita en la especificación Superstructure de UML[Omg11]. El objetivo de la relación include es adicionar el comportamiento de un caso de uso en otro. Generalmente es usada para factorizar acciones que se pueden repetir en diferentes casos de uso. La ejecución del caso de uso incluido no es opcional, esto quiere decir que para que se ejecute correctamente el caso de uso base el caso de uso incluido se debe ejecutar también. 3. Especificación de subsistemas. Los Subsistemas fueron propuestos por JEMA [MMVS12] con el fin de agrupar Entidades del negocio y Casos de Uso en una unidad funcional de acuerdo a la relación que estos tienen entre sí. La unión de dos o más subsistemas ayuda a definir los productos que pueden ser derivados de la SPL. Cada subsistema cuenta con la solución a un conjunto de requerimientos funcionales que son resueltos por los casos de uso y entidades que contiene. 4. Definición de Variabilidad. En esta actividad el Arquitecto del Dominio debe definir la variabilidad de la SPL especificando por cada activo si es o no obligatorio..

(25) Mandarina Mobile: Visión general. 17. Un subsistema o caso de uso debe ser especificado como obligatorio si resuelve un requerimiento funcional vital para todas las aplicaciones derivadas de la SPL. Mientras que los subsistemas o casos de uso especificados como opcionales pueden estar o no presentes en las aplicaciones de la SPL. Configuración de los productos de la SPL La fase (2) de la Figura 3.1 hace parte de la Ingeniería de la Aplicación de las SPLs cuyo objetivo principal es construir las aplicaciones reutilizando los artefactos construidos en la Ingeniería del dominio y explotando la variabilidad de la SPL [PBvdL05]. Precisamente el mayor provecho que se puede obtener de la variabilidad definida en la SPL es creando diferentes aplicaciones que son identificadas de acuerdo a las necesidades de cada cliente. Una vez identificada esta necesidad se configura la aplicación de software específica seleccionando los subsistemas y casos de uso clasificados como opcionales. Con esta selección de subsistemas y casos de uso se crea un modelo de configuración de la aplicación específica, de tal forma que sirva como insumo más adelante a una MTC cuyo objetivo es la generación del código de la aplicación. Diagrama de interacción de los casos de uso En la fase (3) de la Figura 3.1 reside el mayor valor que aporta el uso de patrones a la especificación de los casos de uso. Cada patrón tiene asociadas un conjunto de actividades ya conocidas que son ejecutadas para que el usuario obtenga el valor del negocio deseado. Estas actividades fueron descritas en la propuesta de GENIUS [Mon12] y MTC-EA [CAC08] como un diagrama de interacción el cual es representado a través de una máquina de estados en los que cada nodo hace referencia a una interfaz de usuario o a un servicio prestado ya sea por un back-end que ejecuta la lógica del negocio como manipulación de entidades, o por la plataforma que presta servicios especiales como los de los dispositivos móviles. Para obtener este diagrama de Interacción se deben ejecutar las siguientes actividades: 1. Generar el diagrama de interacción para cada caso de uso. Cada patrón de caso de uso tiene asociado una secuencia de estados a través de los cuales debe atravesar la aplicación para conseguir el valor deseado por el usuario. Usando esta secuencia de estados predefinida llamada Especificación del diagrama de interacción [Mon12] se genera el modelo de interacción para cada caso de uso que fue seleccionado para hacer parte de un producto específico. Para la representación de la especificación del diagrama de secuencia de un patrón como el diagrama de secuencia propiamente dicho de un caso de uso se usa el Metamodelo de UML. 2. Combinar los diagramas de interacción de los patrones de caso de uso empleados en la relación include entre dos casos de uso. Al finalizar la actividad anterior por cada caso de uso se tiene un diagrama de interacción creado a partir del patrón de caso de uso y su correspondiente Especificación del diagrama de Caso de uso. Por consiguiente, cuando existen relaciones de inclusión entre dos casos de uso, tanto el caso de uso base como el caso de uso incluido tendrán su propio diagrama de interacción por separado. Sin embargo, la relación include de los casos de uso establece que el comportamiento del caso de uso incluido debe ser adicionado al comportamiento del caso de uso base [Omg11], por lo tanto es necesario realizar una combinación de los diagrama de interacción de los dos casos de uso. Al finalizar se tendrán en un solo diagrama de interacción todos los estados necesarios para ejecutar el caso de uso base.. 3.3.2.. Variabilidad de Plataforma. La segunda actividad es la variabilidad de la plataforma. En esta fase (4) hay una ontología de plataformas, parte del proceso de ingeniería de dominio, que almacena el conocimiento de múltiples dispositivos e indica el software y hardware de estos, en otras.

(26) Mandarina Mobile: Visión general. 18. Figura 3.2 Validación de Plataformas Móviles. palabras, tiene la información de los teléfonos celulares que utilizan nuestras plataformas compatibles: Android y Windows Phone. (5) Dada la configuración funcional de la segunda etapa realizada en los pasos anteriormente descritos y, específicamente, con la información de los casos de uso que tienen asociados los patrones que emplean características del dispositivo móvil, se realiza una validación al cruzar esta información con el conocimiento de la ontología (6) que determina qué plataformas y dispositivos son válidos para la configuración funcional especificada. La información de las plataformas y dispositivos que son compatibles con la configuración funcional será utilizada en múltiples puntos durante el enfoque. En la Figura 3.2 se representa el proceso de validación descrito para la actividad de variabilidad de plataforma. En el último paso de esta fase (7) se genera el lado del servidor de las aplicaciones móviles conectadas a través de JEMA, usando las funcionalidades configuradas en el paso (2) a manera de entrada. Esta plataforma expone los servicios del backend a través de un API RESTful que nuestra aplicación móvil podrá consumir. Esta actividad se produce inmediatamente después del final de la etapa de validación de plataforma (6).. 3.3.3.. Representación de la Arquitectura. La tercera actividad consiste en la representación de la arquitectura. Esta fase (8) comienza con el modelo base de arquitectura del producto el cual es generado a partir de transformaciones modelo a modelo con la información obtenida del tercer paso de la aproximación a partir de los modelos de interacción de cada caso de uso. Este modelo es la representación de la arquitectura y no posee ninguna información sobre las plataformas y tecnologías por eso es denominado como un modelo independiente de la plataforma (PIM). La principal función de este modelo de arquitectura es tener un artefacto que permita representar la aplicación como un todo teniendo en cuenta las distintas preocupaciones para este tipo de aplicaciones como lo son la presentación, la estructura y el comportamiento. Por esa razón se cuenta con dos metamodelos denominados de estructura y presentación, los cuales tienen la responsabilidad de atacar esas preocupaciones. Metamodelo de Estructura El primer metamodelo aplica una variación del patrón estructural de diseño MVC a cada caso de uso y entidad de negocio que fueron modelados para el producto, donde se asocian los servicios que representan el comportamiento con los patrones funcionales base que soportamos: crear, leer, actualizar, borrar y listar. Dentro de este modelo estructural de la arquitectura tenemos subsistemas, los cuales.

(27) Mandarina Mobile: Visión general. 19. Figura 3.3 Modelo de Características y Catálogo de Patrones No Funcionales. están compuestos por modelos, vistas y controladores para cada función listar o CRUD que se necesite para satisfacer un caso de uso, adicionalmente tenemos elementos como delegados que hacen de intermediarios entre un subsistema y el backend; y por último, enrutadores que se encargan de la navegación de los requerimientos funcionales que abarca un subsistema. Metamodelo de presentación Por otra parte, tenemos el segundo metamodelo de presentación el cual está vinculado con el de estructura por medio de las vistas representadas en este. Dependiendo de qué función va a satisfacer la vista (CRUD), siempre se van a tener los mismos tipos de elementos gráficos que podrán cumplir con los requerimientos. Pero la cantidad de elementos y el comportamiento de los mismos están ligados a la configuración funcional que se realice para el producto concreto. Configuración arquitectural Complementaria a la tercera actividad correspondiente a la representación de la arquitectura, se procede a realizar la configuración de ésta por medio de la selección de patrones no funcionales de un catálogo de patrones existentes, Figura 3.3, estos patrones fueron diseñados para afectar de forma transversal la arquitectura de los productos y son aplicados para enriquecerse sin afectar la funcionalidad del producto configurado. Un patrón no funcional es un patrón de diseño que si se aplica puede afectar a algunos atributos de calidad de la arquitectura, por lo que es responsabilidad del arquitecto que configura el producto, saber qué repercusiones puede tener la elección o no de alguno de estos. Durante este proceso, la información obtenida de la identificación de plataformas en la actividad de variabilidad de plataformas en el paso (6) seis de Mandarina Mobile, es utilizada debido a que algunos patrones no funcionales tienen requisitos de carácter específico de los dispositivos como almacenamiento, CPU, o RAM. De esta manera, en el momento de hacer la configuración de cuáles patrones no funcionales son elegidos, por medio del uso de un lenguaje de dominio específico, se realiza una depuración de la información obtenida en el proceso de validación de plataformas obtenida en el paso (6) seis, dejando de esta forma sólo los dispositivos que cumplen con los requisitos específicos, como se muestra en la Figura 3.4. El último paso de esta actividad (10) es el resultado de aplicar la configuración de los patrones no funcionales para el modelo de arquitectura base, que se mantiene con los elementos adicionales insertados por cada patrón seleccionado, para con estos continuar la actividad de generación de la aplicación..

(28) Mandarina Mobile: Visión general. 20. Figura 3.4 Patrones No Funcionales Vs Plataformas Compatibles Funcionalmente. 3.3.4.. Generación de la aplicación Móvil. La cuarta y actividad final es denominada la generación móvil. En esta fase (11) se generan modelos conformes a metamodelos de tecnologías específicas teniendo en cuenta el modelo de arquitectura enriquecido del paso (10) y la información de las plataformas y dispositivos soportados del paso (6). Estos modelos bajan el nivel de abstracción del producto y se encuentran cerca de los detalles de implementación de las aplicaciones móviles conectadas, por ello los modelos son conformes a tecnologías HTML5, JavaScript y PhoneGap que representan la aplicación como un todo. Particularmente el modelo JavaScript generado está basado en el framework Backbone.js que facilita la estructuración de la aplicación de acuerdo a la arquitectura definida, el de HTML5 simplemente es una representación de las vistas necesarias y el de PhoneGap nos dice que capacidades nativas deben ser usadas y en qué punto. Finalmente el último paso (12) es la generación del código a partir de los modelos de plataforma usando transformaciones modelo a texto que a través del uso de distintas plantillas generan la aplicación completamente satisfaciendo las configuraciones funcionales, no funcionales y de dispositivos realizados para la derivación del producto. En este capítulo se presentó la visión global de Mandarina Mobile teniendo en cuenta las contribuciones de todos los miembros del grupo, en el siguiente capítulo se mostrará la aplicación del caso de estudio en todas las fases de la aproximación y en el capítulo 5 se presentará en detalle cómo fue construida la derivación de las aplicaciones móviles que es mi contribución principal. Si se desea tener más detalles sobre las otras fases de la aproximación global se debe remitir a los documentos de cada miembro del grupo..