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

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 mecanismo predominante para desplegar fácilmente aplicaciones con requisitos 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 puede mejorar tanto el despliegue de sus aplicaciones como la productividad siguiendo un enfoque multi-tenancy, donde diferentes variantes de la misma 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 configuraciones 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 clonable, (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ónica, 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 plataformas 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 siguiendo un enfoque multitenancy [12], donde cada variante de una aplicación puede ser personalizada según las necesidades de cada usuario (tenant). Sin embargo, 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 un nuevo reto: representar de forma explícita y gestionar la existencia de configuraciones 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 evolucionar 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 limitaciones: (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 consistente, 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 necesarios 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 software 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 eficientes 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 propuestos. 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 implementació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                                !            "            #$%&'()(* + ,'#$-. / 0123242 56780 9:;<=>? @ABACA DEFCGHIJKLJMHNJO #$ %&'( )( * + ,'#$-. / 012PQRP 56780 9:;<= >? @ASIFSDEFCGHI JKLJMHNJO 9: TT? U HV FBBHDGAISF WJMWIAXF XYLICHIZ «Azure» common:GeoReplication 9: TT? @ASIFSD[NCHXJF WL U EF U HAU HU 9:;<=>? @ABACA D \U HI] AUU KLJMH NJO «Azure» common:SQLDataBase 9:;<=> ? U HV FBBHD \U HI] AUU KLJMH NJO «Azure» common:BlobStorage 9: TT? XW @@W ND ^ HSF X AB _ F U JW I Z 9: TT? @ASIFSD ` HNHIAB YLICHIZ 9: TT? XW @@W NDK aaW FNJ@HNJ YZU JH@ ... ... ... ... 9: TT? @ASIFSDbHLIWY LICHIZ 9: TT? X W @@ WND ] AHSFAJIF XU 9: TT? @ABACADbHa MI W BW CZ 9: TT? @ASIFSDbHaMIWB W C Z 9: TT? X W @@ WNDcASF WBW C Z @ABACA DGAISF WBW C Z 9: TT? 9: TT? @ABACADbHLIWB W C Z 9:;<=>? @ASIFSDdN X IZaJF WN @ABACA Dea HIAJFW N _ FU JW IZfW C 9: TT ? 9: TT? @ASIFSDbH LIWBW CZ 9: TT? @ASIFSDea HIAJF WN _ F U JW IZfW C 9: TT ? U HV FBBHDeaHIAJFWN _ FU JW IZfW C 9: TT? @ABACA DgAUXLBAI YLICHIZ 9: TT? @ABACA D` HNHIAB YLICHIZ 9: TT? U HV FBBHD ` HNHIA B Y LICHI Z 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 disponibles 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, ademá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 yNeurology están instanciados 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- 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 Sevilla 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 caracterí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 importante 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 adaptadas 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 proporcionado por la plataforma en la nube (Azure) o implementado por el desarrollador 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 componentes 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 importantes de la evolución en aplicaciones multi-tenant son el cálculo automático de los cambios que se deben realizar en cada tenant yla 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. Máquina Virtual específica para cada Tenant [1..*] Máquina Virtual de servicios comunes «App» CardiothoracicSurgery «App» Allergy&Inmunology «App» IngectiousDiseases «Azure» SocialIdentityAuth. «Azure» UserPassAuthent. -virtualized : boolean «Azure» SQLDataBase «Azure» GeoReplication -privateKey : String DigCertAuthent. «Azure» «App» GeneralSurgery «App» Ophthalmology «Azure» Authentication -timeDays : Integer «Azure» Recovery «App» MedicalHistory «Azure» TableStorage «App» NeuroSurgery «Azure» Persistence «Azure» BlobStorage «App» Appointment System «Azure» SQLServer «App» Paediatrics «App» Nephrology «App» Operation HistoryLog «Azure» Encryption «App» Cardiology «App» Neurology «Azure» MongoDB «App» Radiology -size : Integer «Azure» Caching «Azure» Sharding «App» Vascular Surgery «Azure» MySQL BlobStorage HospitalSoft TenantSpecific [1..*] CommonServices ApplicationFunctionality SQLDatabase TableStorage Persistence 1..* SQLServerVM Sharding MySQL MongoDB PartitioningScheme SQLServer SocialIdentity UserPassword Authentication 1..* DigitalCertificate EncryptionRecovery CloudPlatformServices 1..* Surgery Specialties 1..* Cardiothoracic NeurosurgeryVascular InternalMedicine FamilyMedicine 1..* Cardiology Neurology Nephrology 1..* General 1..* Ophthalmology Paediatrics Radiology InfectiousDiseases MedicalHistoryOperationLogs AppointmentSystem Allergy&Immunology Application 1..* CloudPlatform 1..* Availability Geo-replicationCaching VMDatabase 1..* RelationalDB 1..* 1..* NonRelationalDB OperationLogs CacheSize: Integer TimeDays: Integer PrivateKey: String Choice Clonable [1..*] Variable: Type 1..n grupo con multiplicidad (entre 1 y n selecciones) OCL Constraint característica obligatoria característica opcional Leyenda 1 o más instancias decisión sí/no especifica el valor de un tipo restricciones OCL características evolucionadas hij klminopj qrst quvwtx vryivtx zt wjutq{ :ParametricSlotAssignment slotIdentifier = “privateKey” :ObjectSubstitution target = “Authentication” :ObjectExistence target = “Cardiology” BlobStorage :ObjectExistence target = “GeoReplication” :ObjectSubstitution target = “Persistence” :ObjectSubstitution target = “Persistence” ... Árbol de características (VSpecs) Puntos de variación Arquitectura Software Modelo de variabilidad 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 Variability 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 independiente del dominio para especificar y resolver la variabilidad en modelos basados en MOF.1Concretamente, 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 funcionalidad 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 modelo, M2M) cuando una característica ha sido seleccionada en una configuración concreta del modelo de variabilidad. Cuando hablamos de definir una configuración del modelo de variabilidad nos referimos a seleccionar un conjunto 1http://www.omg.org/mof/ 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 seleccionadas. 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 propuesta define la funcionalidad específica de los tenant bajo una característica clonable (TenantSpecific[1..*] en la Figura 2). La característica clonable tiene 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, y cada instancia de TenantSpecific[1..*] define la configuració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 configuració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 variabilidad 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 inferior de la Figura 2 muestra la arquitectura ya evolucionada). Por ejemplo, las características Recovery,SocialIdentity,Caching,MongoDB ySharding han sido incorporadas en el modelo de variabilidad con el fin de añadir el nuevo servicio 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 yMongoDB, 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 están actualmente desplegados (Figura 1). El objetivo es que esas configuraciones ya desplegadas satisfagan el nuevo modelo de variabilidad y los nuevos requisitos 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) Modelo de variabilidad evolucionado Configuración previa Nuevos requisitos Nueva configuración evolucionada Algoritmo Evolve Configuration |} ~                             } } ~                       } }    ~                } }                         ~             } ¡¢£ ¡¢¤ ¡¢¥ ...  ¡¢ £ ¡¢¤ ¡¢¥ ... X ~ ✔ ¡¢£ ¡¢¤ ¡¢¥ ... Figura 3. Algoritmo para evolucionar una configuración. calcular las diferencias entre la configuración evolucionada y la configuración actualmente desplegada (algoritmo Difference Configuration). Recordamos que por configuración nos referimos a una instancia concreta del árbol de características. El tercer paso es el más complicado en el proceso de evolución y consiste en propagar automáticamente los cambios previamente calculados a la arquitectura software actualmente desplegada. Para hacer esto, definimos un tercer algoritmo (Create Weaving Model) que genera un nuevo modelo en CVL que especifica cómo propagar a la arquitectura software las modificaciones definidas previamente a nivel de características (nos referimos a este modelo como modelo de composición). Este algoritmo es una de las principales contribuciones del artículo, debido a que las propuestas existentes que gestionan la evolución con SPLs (como en [1,8]) sólo abordan el problema de la evolución a nivel abstracto de características, y requieren modificar manualmente la arquitectura software para reflejar los cambios calculados — e.g., modificar el fichero de configuración de cada tenant, o definir manualmente un mapeo entre el modelo de configuración a nivel de características y la arquitectura evolucionada para cada tenant. Finalmente, CVL es ejecutado con el modelo de composición como entrada con el fin de obtener la arquitectura evolucionada con los cambios para cada tenant.2 4.1. Evolución del modelo de configuración El algoritmo para evolucionar la configuración de una aplicación multi-tenant (Evolve Configuration en la Figura 3) recibe como entrada el modelo de la configuración actualmente desplegada (que será evolucionado), el modelo de variabilidad evolucionado (actualizado previamente por el proveedor de la aplicación), y la lista de las nuevas características requeridas por los clientes; y genera el modelo de la configuración evolucionada. El modelo generado representa, a nivel del árbol de características, una nueva configuración válida de la aplicación multi-tenant con todas las configuraciones de los tenants evolucionados. La Figura 4 muestra una vista parcial del árbol de características donde, por limitación de espacio, se ha representado en el mismo árbol las tres entradas del algoritmo. El algoritmo genera un nuevo modelo donde, en primer lugar, se copian aquellas características que no cambian de la configuración previa (características en color blanco). A continuación, se añaden las nuevas características seleccionadas (marcadas con X), se omiten aquellas características que ya no son requeridas (marcadas con ×) y se añaden las características cuyos valores han cambiado (marcadas con ∼). Finalmente, se añaden aquellas características 2La formalización de los algoritmos y su definición completa está disponible en http://caosd.lcc.uma.es/papers/evolutionAlgorithms.pdf. Nuevos requisitos HospitalSoft MálagaTenant : TenantSpecific SocialIdentityUserPassword Authentication Recovery CloudPlatformServices TimeDays: Integer = 2 CommonServices ... SevilleTenant : TenantSpecific MadridTenant : TenantSpecific ... ... DigitalCertificate X✔ PrivateKey: String = “MALAGA2015” Característica no modificada UserPassword Authentication Recovery CloudPlatformServices TimeDays: Integer = 5 Authentication Recovery CloudPlatformServices TimeDays: Integer = 1 DigitalCertificate PrivateKey: String = “MADRID2015” Encryption ... ... Leyenda ~~ Características requeridas por las relaciones del árbol y restricciones OCL X Característica a eliminar de la configuración previa Característica a añadir en la nueva configuración ✔ ~ Cambio en la configuración de la característica Figura 4. Información gestionada por el algoritmo Evolve Configuration. Algoritmo Difference Configuration ¦§ ¨© ª«¬® ¯°± ²°³ ¯°±°¯¬ª±´ ³¬¯° ³ µ ¶ª · °« ¯° ¸¹ °© º ª« ²° «¶ª »° ¯º«® ¼¶ ±°¯½« ª»º²¶ ¯ º«°©° ¯º « ±ª³ ¾ ª ¯¬º ° ²° ¯º«® ¼¶ ±° ¯½« ¾ ±ª» ° ¿ ¦§¦§ ¨©ª«¬® ¯°± ¯°±°¯¬ª± ´³¬ ¯° ³ ³ª ²ª¯¯º «° ©°³ ÀÁ  ÃÂ Ä Å ¨ÆÇÁÈ § ¦§ ɧ ¨©ª«¬® ¯°± ¯°±°¯ ¬ª± ´³¬ ¯° ³ ª ²¸ « ° ©° ³ ÀÊ ÇÁ Âà ÂÄ Å ¨ Æ Ç ÁÈ § ¦§Ë§ ¨©ª«¬® ¯°± ¯°±°¯¬ª± ´³¬ ¯° ³ µ ¶ª ¯° ¸¹ °« ³¶ ¯º« ®¼¶ ±°¯ ½ «Ì»°²º ±ª³ À ÍÆ Î ¨Ï ¨ ÄÐÅ ¨ Æ Ç ÁÈ § Configuración previa Nueva configuración evolucionada Diferencias ÁÂÃÂ Ä Å ¨ÆÇÁ¿ f8,f9 Ê Ç Á Âà ÂÄ Å ¨ Æ Ç Á¿ f3 ÍÆ Î ¨Ï ¨ ÄÐÅ ¨ Æ Ç Á ¿ f7 f1 ÑÒÓÔÓÕ Ö ÑÒÓÔÓÕ × f5f2 f3 f4 ÑÒ ÓÔÓÕ Ø f7 f6 ... f1 ÑÒÓÔÓÕÖ ÑÒÓÔÓÕ× f5f2 f3 f4 ÑÒ ÓÔÓÕ Ø f7 f6 ... f8 f9 f10 Figura 5. Algoritmo para calcular la diferencia entre dos configuraciones. requeridas por las nuevas restricciones definidas en el modelo de variabilidad evolucionado (en gris). En nuestro ejemplo, para el tenant Málaga, la característica UserPassword es eliminada, mientras que SocialIdentity es añadida como nuevo requisito. Además, el parámetro PrivateKey del certificado digital es actualizado a un nuevo valor tanto para el tenant Málaga (“MALAGA2015”) como para el tenant Madrid (“MADRID2015”). También la característica Recovery y su parámetro TimeDays, que especifica el intervalo de copia de seguridad, son añadidos en todos los tenants debido a la nueva restricción (CloudPlatformServices implies Recovery) en el modelo de variabilidad evolucionado. Una vez que el modelo de resolución evolucionado ha sido generado, el siguiente algoritmo calcula la diferencia entre la nueva y la anterior configuración. 4.2. Cálculo de las diferencias entre configuraciones El algoritmo Difference Configuration recibe como entrada dos configuraciones (i.e., la configuración previa y la configuración nueva obtenida con el algoritmo Evolve Configuration) y calcula la diferencia entre ellas (Figura 5). Las diferencias están determinadas por: (1) las nuevas características seleccionadas en la nueva configuración que no estaban presentes en la anterior (SELECTIONS); (2) las características de la configuración anterior que han sido eliminadas en la nueva (UNSELECTIONS); y (3) las características que permanecen en la nueva configuración pero cambian sus valores con respecto a la anterior (MODIFICATIONS). 5. Propagación de los cambios a la arquitectura En esta sección definimos el tercer algoritmo de nuestro proceso de evolución, que genera un modelo arquitectónico en CVL para propagar los cambios a la arquitectura desplegada. En primer lugar, con el fin de definir el algoritmo de forma precisa, es necesario formalizar los diferentes modelos de CVL — es decir, el modelo de variabilidad y los modelos de resolución. La formalización de CVL se encuentra parcialmente publicada en [6], pero sólo formaliza la parte abstracta (es decir, el árbol de características) del modelo de variabilidad, y no los puntos de variación ni los modelos de resolución. Como parte de este trabajo, completamos la especificación definida en [6] para formalizar completamente los modelos de variabilidad y las configuraciones en CVL. 5.1. Formalización de los puntos de variación en CVL Los puntos de variación (VPs, de variation points) definen los elementos del modelo arquitectónico que son variables y pueden ser modificados. Estos también especifican cómo esos elementos variables se modifican mediante transformaciones de modelo (e.g., en ATL [11]). La semántica de estas transformaciones es específica de cada tipo de punto de variación. Por ejemplo, algunos puntos de variación soportados por CVL son la existencia o no de elementos en la arquitectura (ObjectExistence), la existencia de relaciones entre los elementos (LinkExistence), o la asignación de un valor a una variable (ParametricSlotAssignment), entre otros [6].Un tipo importante de punto de variación es Opaque Variation Point (OVP) que permite definir nuevos puntos de variación personalizados y, por lo tanto, nuevas transformaciones de modelo que no están predefinidas en CVL. Durante la ejecución de CVL, el motor CVL delega su control en un motor de transformaciones modelo a modelo (M2M) encargado de ejecutar las transformaciones definidas por los puntos de variación. Para representar los puntos de variación, definimos una tupla: variationP oints = (V P, type, ovptype, semantic, binding, MOF Refs), cuyos elementos son: V P .Conjunto finito, no vacío, de identificadores (nombres únicos) de los puntos de variación. type :V P →V P T ype.Función que dado un punto de variación devuelve su tipo de la taxonomía de puntos de variación disponible en CVL. ovpT ype :V P →OV P T ype.Función parcial que dado un OVP, devuelve el tipo de ese OVP. semantic :OV P T ype →SemanticSpec.Función que devuelve la semántica de un tipo de OVP. Esto incluye tanto la transformación de modelo a ejecutar por el motor M2M de CVL, como el lenguaje de transformación (e.g., ATL) usado por la transformación. binding :V P →V SP EC.Devuelve la característica del árbol asociada al punto de variación. refs :V P →P(MOF Ref).Función que devuelve las referencias a elementos de la arquitectura que están enlazadas con el punto de variación. A esos elementos se le aplicarán las transformaciones. 5.2. Formalización de los modelos de resolución en CVL Dado un modelo de variabilidad V, un modelo de resolución Rpara Ves una colección de características seleccionadas o resueltas (V SP ECres) del modelo de variabilidad V. Estas características pueden ser de tres tipos según el tipo de resolución que requieren: (1) CHOICEres, aquellas características que se deciden positivamente o negativamente indicando que estarán presentes o no en la configuración; (2) V ARIABLEres, aquellas características que requieren asignar un valor a una variable; y (3) CLASSIF IERres, aquellas características clonables que requieren especificar el número de instancias que se generarán. Cada selección/resolución en Rresuelve exactamente una característica de V. La formalización de un modelo de resolución Res idéntica a la formalización de V, incorporando además las siguientes definiciones: V SP ECres .Colección finita, de identificadores (nombres únicos) de las características (VSpecs) seleccionadas. El conjunto V SP ECres está particionado en CHOICEres ,V ARIABLEres, y CLASSIF IERres .CLASSIF IERres incluirá todas las instancias de la característica clonable TenantSpecific, con un prefijo diferente para cada instancia (e.g., MálagaTenant:TenantSpecific). El mismo prefijo es usado para los hijos de esa instancia (e.g., MálagaTenant:Authentication). resolved :V P SECres →V SP EC.Función que dada una característica seleccionada en el modelo de configuración (e.g., MálagaTenant:Authentication), devuelve la característica original del modelo de variabilidad (e.g., Authentication).