Evolución arquitectónica de servicios basada en modelos CVL con cardinalidad

XXI JORNADAS DE INGENIERÍA DEL SOFTWARE Y BASES DE DATOS Jesús J. García Molina (Ed.) JESÚS J. GARCÍA MOLINA (ED.) XXI Jornadas de Ingeniería del Software y Bases de Datos AQUILAFUENTE, 219 Ediciones Universidad de Salamanca y de cada autor Motivo de cubierta: Diseñadora María Alonso Miguel 1.º edición: septiembre, 2016 ISBN: 978-84-9012-627-1 (PDF) Ediciones Universidad de Salamanca www.eusal.es [email protected] Realizado en España – Made in Spain Todos los derechos reservados. Ni la totalidad ni parte de este libro pueden reproducirse ni transmitirse sin permiso escrito de Ediciones Universidad de Salamanca Obra sometida a proceso de evaluación mediante sistema de revisión por pares a ciegas a tenor de las normas del congreso Usted es libre de: Compartir — copiar y redistribuir el material en cualquier medio o formato Ediciones Universidad de Salamanca no revocará mientras cumpla con los términos: Reconocimiento — Debe reconocer adecuadamente la autoría, proporcionar un enlace a la licencia e indicar si se han realizado cambios. Puede hacerlo de cualquier manera razonable, pero no de una manera que sugiera que tiene el apoyo del licenciador o lo recibe por el uso que hace. NoComercial — No puede utilizar el material para una finalidad comercial. SinObraDerivada — Si remezcla, transforma o crea a partir del material, no puede difundir el material modificado. Ediciones Universidad de Salamanca es miembro de la UNE Unión de Editoriales Españolas www.une.es Catalogación de editor en ONIX accesible en https://www.dilve.es/ Evolución arquitectónica de servicios basada en modelos CVL con cardinalidad José Miguel Horcas, Mónica Pinto, and Lidia Fuentes Universidad de Málaga, Andalucía Tech, Spain {horcas,pinto,lff}@lcc.uma.es, http://caosd.lcc.uma.es/ Resumen La computación en la nube se está convirtiendo en un me canismo predominante para desplegar fácilmente aplicaciones con requi sitos especiales, tales como el almacenamiento masivo compartido, o el equilibrado de carga. Esta funcionalidad se proporciona normalmente como servicios por las plataformas en la nube. Un desarrollador pue de mejorar tanto el despliegue de sus aplicaciones como la productividad siguiendo un enfoque multi-tenancy, donde diferentes variantes de la mis ma aplicación pueden adaptarse rápidamente a las necesidades de cada usuario (tenant). Sin embargo, gestionar la variabilidad inherente a las aplicaciones multi-tenant, con cientos de usuarios y miles de configura ciones arquitectónicas diferentes, puede llegar a ser una tarea intratable de abordar manualmente. En este artículo, se propone un enfoque de lí nea de producto software en el cual: (1) usamos modelos de variabilidad con cardinalidad para modelar cada tenant como una característica clo nable, (2) automatizamos el proceso de evolución de las arquitecturas de aplicaciones multi-tenant, y (3) demostramos que la implementación de los procesos de evolución es correcta y eficiente para un número elevado de tenants en un tiempo razonable. Keywords: Cardinalidad, Evolución, Línea de Producto Arquitectóni ca, Variabilidad, CVL 1. Introducción La computación en la nube se está convirtiendo en el principal mecanismo para desplegar fácilmente aplicaciones con requisitos especiales, tales como el almacenamiento masivo compartido, escalado automático, o el equilibrado de carga [2]. Los desarrolladores pueden integrar los servicios ofrecidos por las pla taformas en la nube (e.g., Microsoft Azure, Amazon Web Services) como parte de la arquitectura de sus aplicaciones, disminuyendo así el tiempo de desarrollo. Diferentes versiones de la misma aplicación pueden ser desarrolladas siguien do un enfoque multitenancy [12], donde cada variante de una aplicación puede ser personalizada según las necesidades de cada usuario (tenant). Sin embar go, gestionar la variabilidad inherente en las aplicaciones multi-tenant, donde es necesario mantener diferentes configuraciones de la arquitectura software para cada tenant, no es una tarea sencilla. Las Líneas de Producto Software (SPL, del inglés Software Product Line) [15] constituyen un enfoque ampliamente usado para especificar la variabilidad en general, y específicamente en arquitecturas orientadas a servicios [5]. Es aquí dónde las aplicaciones multi-tenant plantean © Ediciones Universidad de Salamanca XXI Jornadas de Ingeniería del Software y Bases de Datos, pp. 51-64 51 , josé miguel horcas mónica pinto , lidia fuentes evolución arquitectónica de servicios basada en modelos cvl con cardinalidad un nuevo reto: representar de forma explícita y gestionar la existencia de confi guraciones simultáneas de los mismos servicios, uno para cada tenant [7]. Además, se debe tener en cuenta la gestión de la evolución de este tipo de aplicaciones. Los proveedores de las plataformas en la nube están continuamente evolucionando y actualizando sus tecnologías con el fin de ser competitivos en el mercado. Por otra parte, la funcionalidad específica de la aplicación puede evo lucionar para tener en cuenta nuevas características solicitadas por los usuarios. En ambos casos, la arquitectura software de la aplicación en la nube debe ser adaptada para añadir nuevos componentes software o eliminar y reconfigurar los existentes. Sin embargo, gestionar la evolución de una aplicación multi-tenant con cientos de usuarios y miles de configuraciones posibles puede llegar a ser una tarea inabordable manualmente. Aunque existen SPLs en el contexto de las aplicaciones multi-tenant [5,9,14,19], la mayoría presenta dos principales limi taciones: (i) no tienen en cuenta la automatización de la evolución a nivel de la arquitectura software; y (ii) instancian la SPL de forma individual para cada tenant. Esto dificulta la realización de los cambios de forma automática y consis tente, y aumenta la complejidad de cambiar simultáneamente las configuraciones arquitectónicas existentes para cada tenant. Los principales objetivos de este artículo son: (1) identificar los cambios ne cesarios en las aplicaciones cuando los requisitos, tanto de la propia aplicación como de los servicios proporcionados por la plataforma en la nube, cambian; y (2) obtener de manera simultánea, para cada tenant, una arquitectura softwa re evolucionada que sea válida y consistente con la configuración actualmente desplegada en ese tenant. Para lograr estos objetivos se propone una línea de productos arquitectónica (PLA) [4] en la que: (i) modelamos la configuración de cada tenant como una característica clonable usando modelos de variabilidad con cardinalidad en CVL [10]; (ii) automatizamos el proceso de evolución de la arquitectura multi-tenant definiendo tres algoritmos que propagan automá ticamente los cambios necesarios en la configuración arquitectónica desplegada en cada tenant; y (iii) demostramos que los algoritmos son correctos y eficien tes para un número elevado de tenants. Ilustramos nuestra propuesta con una aplicación en el dominio del software médico. El artículo se organiza de la siguiente manera. La Sección 2 describe los retos principales de nuestra propuesta a través de un caso de estudio. La Sección 3 explica como modelar la variabilidad de las aplicaciones multi-tenant con CVL. La Sección 4 y 5 detallan nuestro proceso de evolución y los algoritmos propues tos. La Sección 6 evalúa nuestra propuesta. Finalmente, la Sección 7 discute el trabajo relacionado y la Sección 8 las conclusiones y el trabajo futuro. 2. Motivación y caso de estudio Nuestro caso de estudio es una aplicación para la gestión y administración de servicios médicos en hospitales. Con el fin de ahorrar en costes de implementa ción y mantenimiento, se decide desarrollar la aplicación usando una plataforma en la nube (e.g., Microsoft Azure) [18]. El objetivo es vender la aplicación médica a diferentes clientes (hospitales), por lo que para tener configuraciones diferentes para cada hospital, la aplicación seguirá un enfoque multi-tenant, considerando © Ediciones Universidad de Salamanca XXI Jornadas de Ingeniería del Software y Bases de Datos, pp. 51-64 52 , lidia fuentes evolución arquitectónica de servicios basada en modelos cvl con cardinalidad , josé miguel horcas mónica pinto «Azure» common:BlobStorage «Azure» common:GeoReplication «Azure» common:SQLDataBase Figura 1. Arquitectura software de una aplicación multi-tenant en Microsoft Azure. cada hospital como un tenant. Además, se plantea utilizar varios de los servicios proporcionados por la plataforma Azure, como la persistencia y la geo-replicación de datos. Por lo tanto, la aplicación multi-tenant tendrá un conjunto de servicios comunes disponibles desde la misma máquina virtual y compartidos por todos los usuarios, y también un conjunto de servicios específicos para cada usuario dispo nibles a través de máquinas virtuales específicas para cada usuario. La Figura 1 muestra una instancia de la arquitectura de la aplicación médica instanciada y configurada para tres usuarios: los hospitales de Málaga, Sevilla y Madrid. Primero, se proporciona un conjunto de servicios que son comunes para todos los tenants desde la misma máquina virtual (Máquina Virtual de Servicios Compunes). Algunos de ellos, estereotipados como «App», son específicos de la aplicación médica, como el sistema de citas (componente Appointment System) y el historial médico de los pacientes (Medical History). Otros, estereotipados como «Azure», son servicios ofrecidos por la plataforma de Microsoft, como el servicio de persistencia para almacenar los datos clínicos (SQL DataBase) y las citas de los pacientes (BlobStorage), o la posibilidad de crear múltiples copias de la información en diferentes centros de datos (GeoReplication). Segundo, ade más de estos servicios comunes, la aplicación proporciona para cada tenant un conjunto de servicios específicos configurados acorde a sus diferentes necesidades. Por ejemplo, el hospital de Málaga es el único que realiza cirugías vasculares, por lo que el componente VascularSurgery está incluido únicamente en este tenant. Análogamente, los componentes Nephrology y Neurology están instan ciados para el hospital de Málaga y de Madrid, pero no para el hospital de Sevilla. Finalmente, no sólo los componentes específicos de la aplicación varían entre los diferentes tenants, algunos servicios de la plataforma en la nube también pue © Ediciones Universidad de Salamanca XXI Jornadas de Ingeniería del Software y Bases de Datos, pp. 51-64 ... ... ... ... 53 , josé miguel horcas mónica pinto , lidia fuentes evolución arquitectónica de servicios basada en modelos cvl con cardinalidad den ser configurados por cada tenant. Por ejemplo, el método de autenticación es diferente para cada hospital: el hospital de Málaga usa un certificado digital para autenticar al personal médico en el sistema (componente DigCertAuthent) y nombre de usuario y contraseña para autenticar a los pacientes en el servicio de cita médica en línea (UserPassAuthent); mientras que el hospital de Sevi lla usa autenticación mediante el nombre de usuario y contraseña para todos indistintamente, y el hospital de Madrid usa certificado digital para todos. En las aplicaciones multi-tenant hay características (implementadas como componentes) que son requeridas por todos los tenants y otras que son variables y configurables. Esto significa que normalmente sólo un subconjunto de las ca racterísticas variables de la aplicación son desplegadas en cada tenant. Teniendo en cuenta que se deben generar y mantener cientos de configuraciones diferentes de la aplicación, lo que implica la gestión de miles de componentes, un reto im portante es proporcionar mecanismos para representar y gestionar directamente la variablidad de las aplicaciones multi-tenant. Pero una vez desplegadas, las aplicaciones multi-tenant tienen que ser adap tadas a mejoras tecnológicas y a cambios en las necesidades de los usuarios. Por ejemplo, nuevos métodos de autenticación (e.g., autenticación biométrica, autenticación usando redes sociales) o persistencia (e.g., fragmentación de base de datos, grupos de afinidad) aparecen con frecuencia. Si se quiere proporcionar estos nuevos servicios a los clientes, éstos se deben incorporar a los tenants que lo requieran. También se podría cambiar el proveedor de la plataforma en la nube y migrar la aplicación a una nueva (ej: Amazon Web Services). En este caso, la parte de la arquitectura de la aplicación que depende de los servicios de la plataforma tiene que adaptarse a los servicios que ofrece la nueva plataforma en la nube. Por último, durante la vida de la aplicación, los clientes pueden exigir nuevas funcionalidades (e.g., un nuevo módulo para la gestión de transplantes o cambios en los métodos de autenticación para identificar a los pacientes). Considerando los cambios que es necesario realizar en la arquitectura software de la aplicación multi-tenant, todas las situaciones mencionadas anteriormente se pueden representar con tres escenarios diferentes de evolución: (1) un nuevo componente necesita ser incorporado en la arquitectura software, ya sea propor cionado por la plataforma en la nube (Azure) o implementado por el desarrolla dor de la aplicación; (2) un componente existente necesita ser eliminado de la arquitectura software; y (3) un componente existente necesita ser reconfigurado con nuevos parámetros. Sin embargo, la evolución de una aplicación multi-tenant implica también tener que calcular y realizar estos cambios para miles de compo nentes que se ejecutan en cientos de tenants, convirtiendo el proceso de evolución en una tarea intratable de abordar manualmente. Por lo tanto, otros retos im portantes de la evolución en aplicaciones multi-tenant son el cálculo automático de los cambios que se deben realizar en cada tenant y la propagación automática de estos cambios para todos los tenant a nivel arquitectónico. Por otra parte, este proceso de evolución automático sólo será útil si es correcto y eficiente para un gran número de tenants, por lo que necesitamos demostrar la eficiencia y la corrección del proceso de evolución. © Ediciones Universidad de Salamanca XXI Jornadas de Ingeniería del Software y Bases de Datos, pp. 51-64 54 , lidia fuentes evolución arquitectónica de servicios basada en modelos cvl con cardinalidad , josé miguel horcas mónica pinto HospitalSoft TenantSpecific [1..*] CommonServices Application CloudPlatformServices ApplicationFunctionality CloudPlatform BlobStorage OperationLogs Availability 1..* Authentication 1..* Persistence 1..* 1..* Recovery Encryption Specialties OperationLogs AppointmentSystem FamilyMedicine MedicalHistory Radiology 1..* Paediatrics 1..* PartitioningScheme TimeDays: Integer 1..* Caching Geo-replication Surgery InfectiousDiseases InternalMedicine Allergy&Immunology Ophthalmology CacheSize: Integer SQLDatabase 1..* UserPassword SocialIdentity VMDatabase BlobStorage Cardiothoracic TableStorage SQLServer DigitalCertificate RelationalDB 1..* 1..* NonRelationalDB Cardiology Neurology Nephrology PrivateKey: String Vascular Sharding SQLServerVM 1..* MySQL 1..* MongoDB General Neurosurgery :ParametricSlotAssignment slotIdentifier = “privateKey” :ObjectSubstitution target = “Authentication” :ObjectExistence target = “Cardiology” :ObjectExistence target = “GeoReplication” :ObjectSubstitution target = “Persistence” :ObjectSubstitution target = “Persistence” Máquina Virtual específica para cada Tenant [1..*] Máquina Virtual de servicios comunes «App» «Azure» GeoReplication «Azure» Persistence «Azure» Caching -size : Integer «App» Neurology «App» Vascular Surgery «App» CardiologyIngectiousDiseases «App» MedicalHistory «Azure» «Azure» BlobStorage MongoDB «Azure» TableStorage «App» NeuroSurgery «App» «App» CardiothoracicSurgery «App» Operation HistoryLog «Azure» «Azure» Recovery Authentication -timeDays : Integer Appointment System «App» Radiology «App» Nephrology «Azure» SQLDataBase -virtualized : boolean «Azure» Sharding «App» Paediatrics «App» Ophthalmology «App» GeneralSurgery «Azure» MySQL «Azure» Encryption «Azure» DigCertAuthent. -privateKey : String «Azure» SQLServer «Azure» UserPassAuthent. «App» Allergy&Inmunology «Azure» SocialIdentityAuth. Leyenda Choice Clonable [1..*] 1 o más instancias Variable: Type especifica el valor de un tipo OCL Constraint restricciones 1..n grupo con multiplicidad característica característica OCL (entre 1 yn selecciones) obligatoria opcional decisión sí/no características evolucionadas ... enlaces a características referencias a la arquitectura Figura 2. Modelo de variabilidad en CVL y arquitectura software. 3. Gestión de la variabilidad con CVL En esta sección explicamos cómo nuestra propuesta usa CVL (Common Va riability Language) [10] para gestionar la variabilidad de la arquitectura software de todos los tenant en una aplicación basada en la nube. CVL es un lenguaje in dependiente del dominio para especificar y resolver la variabilidad en modelos ba sados en MOF.1 Concretamente, como muestra la Figura 2 para nuestro caso de estudio, modelamos explícitamente la variabilidad de las características que son específicas de cada tenant (i.e., sub-árbol TenantSpecific[1..*]) y la funciona lidad común que comparten todos los tenants (i.e., sub-árbol CommonServices). El modelo de variabilidad CVL está formado por dos partes. La primera es una parte abstracta que modela las características opcionales y obligatorias (VSpecs en CVL, de Variability Specifications) y las restricciones entre ellas (cross-tree constraints). Esta parte abstracta se define mediante un árbol como el mostrado en la parte superior de la Figura 2 y especifica la funcionalidad de la aplicación y los servicios ofrecidos por la plataforma en la nube. La segunda parte del modelo de variabilidad son los puntos de variación (variation points), que aparecen en la parte central de la Figura 2. Cada punto de variación está asociado a una característica del árbol y tiene una o más referencias a elementos de la arquitectura software. Estos puntos de variación representan modificaciones específicas a realizar en la arquitectura (i.e., transformaciones modelo a mode lo, M2M) cuando una característica ha sido seleccionada en una configuración concreta del modelo de variabilidad. Cuando hablamos de definir una configu ración del modelo de variabilidad nos referimos a seleccionar un conjunto 1 http://www.omg.org/mof/ © Ediciones Universidad de Salamanca XXI Jornadas de Ingeniería del Software y Bases de Datos, pp. 51-64 55 , josé miguel horcas mónica pinto , lidia fuentes evolución arquitectónica de servicios basada en modelos cvl con cardinalidad de características en el árbol que cumplan el conjunto de restricciones. Luego, el motor de ejecución de CVL es el encargado de ejecutar las transformaciones M2M asociadas a cada punto de variación según las características selecciona das. En CVL una configuración del modelo de variabilidad recibe el nombre de modelo de resolución (resolution model). Para dar soporte a diferentes configuraciones para cada tenant, nuestra pro puesta define la funcionalidad específica de los tenant bajo una característica clonable (TenantSpecific[1..*] en la Figura 2). La característica clonable tie ne una cardinalidad [1..*] que indica que esta característica puede ser instanciada una o más veces y todas sus sub-características pueden ser configuradas de forma diferente para cada instancia. En nuestro ejemplo, la cardinalidad representa el número de tenants, ycada instancia de TenantSpecific[1..*] define la confi guración para ese tenant específico (por ejemplo para el hospital de Sevilla). Seleccionando las características apropiadas bajo la característica clonable TenantSpecific[1..*], y ejecutando CVL, nuestra propuesta genera una con figuración de la arquitectura como la mostrada en la Figura 1, donde cada tenant está configurado de acuerdo a sus necesidades. 4. Gestión de la evolución con CVL Una vez que se ha generado y desplegado una configuración arquitectónica adaptada a los requisitos de cada tenant, la aplicación multi-tenant es susceptible de evolucionar debido a mejoras tecnológicas y/o a cambios en las necesidades de los clientes. Volviendo a nuestra aplicación médica, supongamos que Microsoft incorpora nuevas funcionalidades a su plataforma: un servicio de recuperación de datos, un método de autenticación basado en Facebook y un mecanismo de persistencia. Supongamos también que el proveedor de la aplicación médica quiere proporcionar estos nuevos servicios a sus tenants (i.e., a sus hospitales). El primer paso en el proceso de evolución es adaptar el modelo de varia bilidad con nuevas características (aparecen en color gris en la Figura 2), y la arquitectura de la aplicación con nuevos elementos arquitectónicos (la parte in ferior de la Figura 2 muestra la arquitectura ya evolucionada). Por ejemplo, las características Recovery, SocialIdentity, Caching, MongoDB y Sharding han sido incorporadas en el modelo de variabilidad con el fin de añadir el nuevo ser vicio de recuperación, el nuevo método de autenticación, y el nuevo mecanismo de persistencia (una nueva base de datos no relacional y un nuevo mecanismo de partición de base de datos). Así mismo, la arquitectura ha sido adaptada con los nuevos componentes Recovery, SocialIdentityAuth y MongoDB, entre otros. El segundo paso en el proceso de evolución es calcular de manera automática y consistente los cambios que son necesarios realizar en todos los tenants que es tán actualmente desplegados (Figura 1). El objetivo es que esas configuraciones ya desplegadas satisfagan el nuevo modelo de variabilidad y los nuevos requisi tos de la aplicación. Para automatizar esta tarea nuestra propuesta divide este segundo paso en dos partes: (i) modificar la configuración actual de todos los tenants, generando una nueva configuración evolucionada a partir del modelo de variabilidad previamente evolucionado (algoritmo Evolve Configuration); y (ii) © Ediciones Universidad de Salamanca XXI Jornadas de Ingeniería del Software y Bases de Datos, pp. 51-64 56 , josé miguel horcas mónica pinto , lidia fuentes evolución arquitectónica de servicios basada en modelos cvl con cardinalidad 7. Trabajo relacionado A pesar de existir multitud de trabajos centrados en modelar la variabilidad usando características clonables [7,8,17], sólo algunos de ellos tienen en cuenta el problema de la evolución de una familia de productos y los correspondientes cambios en los productos específicos [8,17]. La mayoría de los trabajos gestionan la variabilidad usando modelos de características clásicos (feature models) en una SPL [1,5,8], o arquitecturas de referencia [19]. Los modelos de característi cas tienen la ventaja de ser muy conocidos y hay muchas herramientas que le dan soporte (e.g., Hydra Tool presentado en [8]). Sin embargo, el principal incon veniente de los modelos de características clásicos es que requieren un proceso adicional para establecer las relaciones entre la variabilidad especificada a nivel abstracto (e.g., en el árbol) y los puntos de variación en la arquitectura software. En [8], un lenguaje independiente para modelar la variabilidad (VML, de Varia bility Modeling Language) [13] es usado para establecer la correspondencia entre las características del árbol y las acciones a realizar en la arquitectura software. VML depende del lenguaje usado para modelar la arquitectura, y por lo tanto, es necesario crear manualmente un fichero VML por cada modelo de caracterís ticas y por cada lenguaje de modelado de arquitectura. CVL, por el contrario, facilita la propagación de los cambios a la arquitectura definiendo puntos de variación como parte del modelo de variabilidad, que además soporta cualquier arquitectura definida en lenguajes basados en MOF. Otro punto a tener en cuenta es que la mayoría de las propuestas existen tes se centran en modelar la variabilidad de propiedades no funcionales de las aplicaciones multi-tenant, como por ejemplo el precio de los servicios, su dispo nibilidad o satisfacción de los usuarios [5,9,14], o se centran en analizar cómo las diferentes variaciones en los servicios afectan a los atributos de calidad de la arquitectura en términos no funcionales (e.g., rendimiento, eficiencia, etc.) [19]. Aunque ambos son aspectos de gran relevancia en el desarrollo de cualquier apli cación software, ninguna de las propuestas existentes aborda el modelado de la variabilidad de los componentes funcionales de la arquitectura (ej: la variabilidad de un componente de autenticación), como proponemos en este artículo. 8. Conclusiones y trabajo futuro En este artículo hemos presentado una propuesta que usa el lenguaje CVL y los modelos de variabilidad con cardinalidad para gestionar la variabilidad y evolución de un número elevado de tenants en el contexto de aplicaciones en la nube. Evolucionar miles de configuraciones en aplicaciones multi-tenant es una tarea intratable de realizar manualmente. Hemos definido tres algoritmos que automáticamente evolucionan una configuración previa de los tenants, calculan los cambios que se deben hacer en la arquitectura de la aplicación, y propagan dichos cambios a la arquitectura multi-tenant usando transformaciones modelo a modelo. Hemos formalizado los modelos CVL como un problema CSP para demostrar la corrección de los algoritmos y analizar la eficiencia de los algoritmos. Nuestro trabajo futuro incluye la reconfiguración dinámica de las arquitec turas multi-tenant ejecutando los modelos CVL en tiempo de ejecución. © Ediciones Universidad de Salamanca XXI Jornadas de Ingeniería del Software y Bases de Datos, pp. 51-64 63 , josé miguel horcas mónica pinto , lidia fuentes evolución arquitectónica de servicios basada en modelos cvl con cardinalidad Agradecimientos Trabajo financiado por los proyectos MAGIC P12-TIC1814 y HADAS TIN2015 64841-R. Referencias 1. Abu Matar, M., Mizouni, R., Alzahmi, S.: Towards software product lines based cloud architectures. In: IEEE IC2E. pp. 117–126 (2014) 2. Armbrust, M., Fox, A., Griffith, R., Joseph, A.D., Katz, R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A., Stoica, I., Zaharia, M.: A view of cloud computing. Com mun. ACM 53(4), 50–58 (2010), http://doi.acm.org/10.1145/1721654.1721672 3. Arora, S., Barak, B.: Computational Complexity: A Modern Approach. Cambridge University Press (2009) 4. Bosch, J.: Design and use of software architectures: adopting and evolving a product-line approach. Pearson Education (2000) 5. Cavalcante, E., Almeida, A., Batista, T., Cacho, N., Lopes, F., Delicato, F.C., Sena, T., Pires, P.F.: Exploiting software product lines to develop cloud computing applications. In: Software Product Line Conference. pp. 179–187. SPLC (2012) 6. CVL Submission Team: Common Variability Language (CVL), OMG revised sub mission. http://www.omgwiki.org/variability/ (2012) 7. Czarnecki, K., Helsen, S., Eisenecker, U.: Formalizing cardinality-based feature models and their specialization. SP: Improvement and Practice 10(1), 7–29 (2005) 8. Gamez, N., Fuentes, L.: Architectural evolution of famiware using cardinality-based feature models. Information and Software Technology 55(3), 563–580 (2013) 9. García-galán, J., Pasquale, L., Trinidad, P., Ruiz-Cortés, A.: User-centric adap tation analysis of multi-tenant services. ACM Trans. Auton. Adapt. Syst. 10(4), 24:1–24:26 (2016) 10. Haugen, O., Moller-Pedersen, B., Oldevik, J., Olsen, G., Svendsen, A.: Adding standardized variability to domain specific languages. In: SPLC (2008) 11. Jouault, F., Allilaire, F., Bézivin, J., Kurtev, I.: ATL: A model transformation tool. Sci. Comput. Program. 72(1–2), 31–39 (2008) 12. Krebs, R., Momm, C., Kounev, S.: Architectural concerns in multi-tenant saas applications. CLOSER 12, 426–431 (2012) 13. Loughran, N., Sánchez, P., Garcia, A., Fuentes, L.: Language support for managing variability in architectural models. In: Software Composition (2008) 14. Mietzner, R., Metzger, A., Leymann, F., Pohl, K.: Variability modeling to support customization and deployment of multi-tenant-aware software as a service appli cations. In: Principles of Engineering Service Oriented Systems. pp. 18–25 (2009) 15. Pohl, K., Böckle, G., Linden, F.J.v.d.: Software Product Line Engineering: Foun dations, Principles and Techniques. Springer-Verlag New York, Inc. (2005) 16. Tsang, E.: Foundations of constraint satisfaction, vol. 289 (1993) 17. White, J., Schmidt, D., Benavides, D., Trinidad, P., Ruiz-Cortes, A.: Automa ted diagnosis of product-line configuration errors in feature models. In: Software Product Line Conference. pp. 225–234 (2008) 18. Wilder, B.: Cloud Architecture Patterns: Using Microsoft Azure. O’Reilly (2012) 19. Yang, H., Zheng, S., Chu, W.C., Tsai, C.T.: Linking functions and quality attri butes for software evolution. In: APSEC. pp. 250–259 (2012) © Ediciones Universidad de Salamanca XXI Jornadas de Ingeniería del Software y Bases de Datos, pp. 51-64 64