CFRA Cloud - una línea de producto para aplicaciones tipo concurso sobre Cloud Computing

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIER´IA

Departamento de Sistemas y Computaci ´on

Grupo de construcci ´on de software

CFRA Cloud: Una l´ınea de producto para

aplicaciones tipo concurso sobre Cloud Computing

Oscar Guillermo Mellizo Angulo

Tesis elaborada en cumplimiento parcial de los requisitos para el grado de Maestr´ıa en Ingenier´ıa de Sistemas y Computaci ´on

en la Universidad de los Andes

Mayo, 2014

Asesoras:

Rubby Casallas Gutierrez. Ph.D., Universidad de Los Andes, Colombia. Kelly Garces Pernett. Ph.D., Universidad de los Andes, Colombia.

Tabla de contenidos

1 Introducci´on 7

2 Planteamiento problema 9

2.1 Motivaci´on . . . 9

2.2 Problema . . . 10

2.3 Objetivo general . . . 11

2.4 Objetivos espec´ıficos . . . 11

2.5 Alcance de la propuesta . . . 11

3 Marco te´orico 12 3.1 Cloud Computing . . . 12

3.1.1 Modelo IaaS . . . 12

3.1.2 Modelo PaaS . . . 12

3.1.3 Modelo SaaS . . . 13

3.1.4 Ventajas de Cloud Computing . . . 13

3.1.5 Desventajas de Cloud Computing . . . 13

3.2 Estilo arquitectural CQRS . . . 14

3.3 Model Driven Engineering - MDE . . . 14

3.4 Model-Driven Architecture - MDA . . . 16

3.5 Modelo de rasgos o Feature model . . . 17

3.6 Heroku . . . 18

4 Estado del arte 19 4.1 Grupo D - Generadores MDE en la nube para la nube . . . 20

4.1.1 MODACLOUDS: A Model-Driven Approach for the De-sign and Execution of Applications on Multiple Clouds . . 20

4.2 Grupo B - Generadores MDE para la nube . . . 20

4.2.1 Developing migratable multicloud applications based on MDE and adaptation techniques . . . 20

4.2.2 Model-driven Generative Framework for Automated OMG DDS Performance Testing in the Cloud . . . 21

4.3 Grupo C - Generadores MDE en la nube . . . 21

4.3.1 Transitioning to the cloud. a model-driven analysis and automated deployment capability for cloud services . . . . 21

4.4 Grupo A - Generadores MDE . . . 22

4.4.1 A Model-Driven Development Approach for Service-Oriented Integration Scenarios . . . 22

4.4.2 Model Driven Development of a Service Oriented Archi-tecture (SOA) Using Colored Petri Nets . . . 22

5 CFRA Cloud 25

5.1 Configuraci´on . . . 25

5.1.1 Requerimientos no funcionales . . . 26

5.1.2 Requerimientos funcionales . . . 26

5.1.3 Atributos de entidad de negocio . . . 27

5.1.4 Propiedades configuraci´on . . . 28

5.1.5 Variabilidad de la arquitectura . . . 28

5.2 Generaci´on . . . 32

5.3 Despliegue . . . 38

5.4 Pruebas . . . 39

6 Costos aplicaciones para concurso 43 6.1 Costos de la plataforma Cloud Computing . . . 43

6.1.1 Tipos de Dyno . . . 44

6.1.2 Bases de datos . . . 44

6.1.3 Ejemplos de seleccion de features . . . 45

6.2 Costos de construcci´on y despliegue . . . 50

7 Validaci´on 53 7.1 Caso de estudio . . . 53

7.1.1 Requerimientos no funcionales . . . 54

7.1.2 Requerimientos funcionales . . . 54

7.1.3 Escenario . . . 57

7.2 Aplicaci´on estrategia . . . 58

7.2.1 Configuraci´on . . . 58

7.2.2 Generaci´on . . . 60

7.2.3 Despliegue . . . 61

7.2.4 Pruebas . . . 63

7.3 Costos y tiempos . . . 64

7.4 Discusi´on . . . 67

List of Figures

3.1 Diagrama explicativo de la arquitectura CQRS. . . 14

3.2 Diagrama del MDE [Oldevik]. . . 15

3.3 Diagrama Y de MDA. . . 17

4.1 Grupos de articulo del estado del arte. . . 20

5.1 Estrategia de soluci´on . . . 25

5.2 Diagrama features - Requerimientos no funcionales . . . 26

5.3 Diagrama features - Requerimientos funcionales . . . 27

5.4 Metamodelo atributos concursante . . . 27

5.5 Metamodelo propiedades configuraci´on . . . 28

5.6 Diagrama de features seleccionado ejemplo 1 . . . 29

5.7 Diagrama de componentes arquitectura ejemplo 1 . . . 29

5.8 Diagrama de despliegue arquitectura ejemplo 1 . . . 30

5.9 Diagrama de features seleccionado ejemplo 2 . . . 30

5.10 Diagrama de componentes arquitectura ejemplo 2 . . . 31

5.11 Diagrama de despliegue arquitectura ejemplo 2 . . . 32

5.12 Cadena de transformaci´on . . . 33

5.13 Metamodelo arquitectura b´asica . . . 35

5.14 Metamodelo arquitectura detallada . . . 36

5.15 Interface Deploy.jar . . . 38

5.16 Interface Apache JMeter - Plan de pruebas . . . 40

5.17 Interface Apache JMeter - Men´u ”Archivo” opci´on ”Abrir” . . . 40

5.18 Interface Apache JMeter - Seleccion archivo Contest.jmx . . . 41

5.19 Archivo Contest.jmx abierto . . . 41

5.20 Valores por defecto para prueba . . . 42

6.1 Diagrama de features - Requerimientos no funcionales. . . 43

6.2 Diagrama de features seleccionado ejemplo 1 . . . 46

6.3 Diagrama de features seleccionado ejemplo 2 . . . 46

6.4 Diagrama de features seleccionado ejemplo 3 . . . 47

6.5 Diagrama de features seleccionado ejemplo 4 . . . 47

6.6 Diagrama de features seleccionado ejemplo 5 . . . 48

6.7 Diagrama de features seleccionado ejemplo 6 . . . 48

6.8 Diagrama de features seleccionado ejemplo 7 . . . 49

6.9 Diagrama de features seleccionado ejemplo 8 . . . 49

6.10 Diagrama de features seleccionado ejemplo 9 . . . 50

7.1 Diagrama de features seleccionado - Requerimientos funcionales . 58 7.2 Diagrama de features seleccionado - Requerimientos no funcionales 59 7.3 Modelo atributos concursante . . . 59

7.5 Modelo arquitectura b´asica . . . 61

7.6 Modelo arquitectura detallada . . . 62

7.7 Interface Deploy.jar . . . 63

7.8 Mensaje de confirmaci´on . . . 63

7.9 Pantalla inicial concurso . . . 64

7.10 Botones compartir redes sociales . . . 65

7.11 Pantalla de inscripci´on al concurso . . . 66

7.12 Resumen prueba . . . 66

1

Introducci´

on

Actualmente est´an surgiendo un tipo de aplicaciones Web con un tiempo de vida corto, en las cuales existe la posibilidad de interactuar directamente con el cliente durante un evento, un lanzamiento de un producto o un posicionamiento de marca, entre otros; dichas aplicaciones presentan el formato de un concurso donde los clientes se inscriben, siguen algunas instrucciones y pueden ganar pre-mios; dadas las caracter´ısticas de estas aplicaciones, se requiere que se puedan crear y publicar f´acilmente, as´ı mismo deben permitir un gran n´umero de usuar-ios concurrentes, como tambi´en deben ser capaces de soportar una demanda inesperada en cualquier momento [Forrester].

Las empresas que no son de tecnolog´ıa habitualmente tienen un ´area de sis-temas que se encarga de la administraci´on de las aplicaciones que pertenecen a la compa˜n´ıa. Los t´ecnicos o ingenieros que trabajan en esas ´areas son expertos en los sistemas que pertenecen a la empresa, pero cuando se requiere la creaci´on de una nueva aplicaci´on es frecuente que los mismos no est´en en capacidad de hacerlo, ya que no poseen la experiencia, ni el conocimiento suficiente; como resultado, surge la necesidad de contratar a un proveedor que realice el an´alisis, dise˜no e implementaci´on de la aplicaci´on, incurriendo en altos costos para las empresas, a´un cuando las mismas posean un ´area de sistemas.

Por otro lado, existe la posibilidad de usar los servicios disponibles en inter-net que permiten la creaci´on de todo tipo concursos, algunos son muy b´asicos, otros muy elaborados [SocialTools] [CoolTabs] [EasyPromos] [Halalati] [Trisocial] [OneKontest], pero los de mejor calidad y presentaci´on est´an acoplados a redes sociales, la mayor´ıa colocan publicidad en las pantalla del concurso y los costos mensuales pueden llegar a ser bastante elevados, adem´as se desconocen temas cruciales como la escalabilidad y el desempe˜no.

Con el fin de suplir esa necesidad de aplicaciones tipo concurso, que sean de bajo costo, con alto desempe˜no, escalabilidad y de f´acil uso, se propone aqu´ı una aproximaci´on llamada CFRA Cloud, la cual es una l´ınea de producto con un enfoque basado en modelos (Model Driven Engineering - MDE). CFRA Cloud permite la construcci´on r´apida y f´acil de aplicaciones para concurso en Cloud Computing sobre una plataforma PaaS (Platform as a Service) [Nist], de tal manera que temas como la gesti´on de dispositivos de almacenamiento, sistemas

operativos, componentes de red, firewalls o enrutadores son transparentes para el creador de la aplicaci´on. CFRA Cloud adem´as permite variar la arquitectura de las aplicaciones concurso seg´un los requerimientos no funcionales, y a trav´es de las tecnolog´ıas MDE genera el c´odigo fuente, archivos de configuraci´on, ayudante de despliegue y archivos de pruebas de carga. La aplicaci´on concurso generada es un SaaS (Software as a Services)[Nist], ya que es un software propiedad de un proveedor de servicios, y no requiere de administraci´on de infraestructura ni de la plataforma de desarrollo.

Adicionalmente, nosotros proponemos una aproximaci´on para calcular los costos de las aplicaciones generadas (incluye construcci´on y despliegue) y los costos en los que se incurre por el uso de la plataforma Cloud Computing.

La l´ınea de producto fue probada en un caso de estudio, en donde el objetivo es generar aplicaciones tipo concurso para una empresa de comestibles que busca fidelizar a sus clientes. Como resultado de la validaci´on, obtuvimos el costo de la aplicaci´on generada. CFRA Cloud redujo un 95% el costo de la aplicaci´on y disminuyo de 8 d´ıas o m´as la implementaci´on, a menos de una hora, generando el 100% de la aplicaci´on con una arquitectura acorde a las necesidades del concurso. Adem´as las aplicaciones generadas tienen una arquitectura que les permite ser altamente escalables tanto verticalmente como horizontalmente, y el desempe˜no es bastante bueno por lo que tienen una latencia promedio de 302 milisegundos para una prueba de registro de 1000 concursantes que duro un poco m´as de un minuto.

La metodolog´ıa utilizada en este trabajo est´a estrechamente ligada al orden en el cual se presentan los cap´ıtulos del documento e involucr´o las siguientes etapas:

• Planteamiento del problema: Se indica claramente el problema que se quiere resolver.

• Marco Te´orico: Se explica cada uno de los artefactos que se involucran en la soluci´on del problema.

• Estado del Arte: Otros proyectos o aproximaciones que est´an relacionadas con los componentes o artefactos relacionados en la soluci´on del problema. • Costos aplicaciones para concursos: Se detalla la manera en que se cobra el desarrollo y despliegue de aplicaciones para concursos hechas a mano y con MDE

• CFRA Cloud: Detalle de la l´ınea de producto.

• Validaci´on: Se eval´ua la l´ınea de producto a partir de un escenario. • Conclusiones y trabajos futuros: Se concluye el trabajo y se proponen

2

Planteamiento problema

La necesidad comercial de hacer publicidad y mantener los productos y servicios en auge, ha producido un crecimiento en la demanda de sitios web y aplicaciones, las cuales pueden ser de larga o corta duraci´on, entre las cuales, se encuentran particularmente las de tipo concurso, cuyo esquema est´a dado por la inscripci´on, el cumplimiento de instrucciones y la adquisici´on de premios en un lapso de tiempo determinado; siendo los mismos generalmente de corta duraci´on, ya que est´an enmarcados en un evento especial para la industria que lo propone. Este tipo de aplicaciones, generalmente requiere la contrataci´on de una empresa es-pecializada en el desarrollo de la misma (proveedor), generando un coste extra en tiempo y en dinero para el cliente. Surge as´ı la idea de crear un servicio que facilite la creaci´on de dichas aplicaciones sin necesidad de recurrir a ex-pertos, es decir, que la misma pueda ser generada por quienes se encargan del mantenimiento de los dominios inform´aticos del cliente, dichas personas poseen conocimientos t´ecnicos, aun cuando no son expertos en el desarrollo de aplica-ciones.

Con el surgimiento de Cloud Computing, cuyas ventajas y beneficios ser´an explicados posteriormente, se hace posible el desarrollo de un servicio cuyo ob-jetivo es el de brindar una herramienta para crear aplicaciones tipo concurso de manera r´apida y f´acil sobre la nube; generando as´ı una soluci´on a la demanda de este tipo de elementos inform´aticos.

2.1 Motivaci´

on

Cloud Computing se ha convertido en una tecnolog´ıa que posee componentes y facilidades muy atractivas desde diversos aspectos para todo tipo de clientes, tales como:

• Econ´omico: Produce un cambio significativo debido al modelo de pago bajo demanda [Gartner]

• Velocidad de desarrollo: Ofrece un conjunto de servicios que reduce el tiempo utilizado para el desarrollo. Si una persona o empresa necesita

re-alizar un desarrollo completo de una aplicaci´on necesitar´ıa un presupuesto y meses de trabajo, mientras que a trav´es de los servicios Cloud Computing, necesitar´ıa pocos d´ıas [Nist]

• Niveles de servicio: Esta tecnolog´ıa propone tres niveles de servicios IaaS, PaaS y SaaS. Particularmente para PaaS, se proyecta un crecimiento sus-tancial en la demanda en el transcurso de los pr´oximos a˜nos, as´ı como la participaci´on de una gran cantidad de proveedores, de acuerdo al pron´ostico de Forrester [Forrester2] como se observa en la figura.

Algunas de las preocupaciones que tienen las personas y empresas son las de la identificaci´on objetiva de servicios ofrecidos por los proveedores PaaS, as´ı como el entendimiento de las posibles arquitecturas a construir y el conocimiento del tiempo estimado para el dise˜no, desarrollo y despliegue de una aplicaci´on en Cloud Computing. Al respecto de este nivel de servicio y esta tecnolog´ıa, se dice: ”Los usuarios y proveedores de TI en las empresas de soluciones de software que a´un no est´an comprometidos con PaaS deben comenzar la construcci´on de conocimientos en PaaS o enfrentarse a duros retos de los competidores en los pr´oximos a˜nos” Gartner[Gartner].

Existen herramientas y APIs que facilitan el desarrollo de aplicaciones sobre Cloud Computing, pero se necesita un conocimiento robusto t´ecnico que permita el uso efectivo de las mismas.

2.2 Problema

El desarrollo y despliegue de aplicaciones sobre Cloud Computing puede pare-cer muy complejo para personas o empresas que desconocen las herramientas, arquitecturas, tecnolog´ıas y beneficios de Cloud Computing. La creaci´on de una aplicaci´on parte de los requerimientos funcionales y no funcionales que ser´an la base para el dise˜no de la arquitectura, la cual debe variar con respecto a los cam-bios del negocio o entes externos, tales como demandas inesperadas, camcam-bios en herramientas, soporte de contenido, entre otros.

Las empresas que no son de tecnolog´ıa habitualmente tienen un ´area de sis-temas que se encarga de la administraci´on de las aplicaciones que pertenecen a la compa˜n´ıa. Los t´ecnicos o ingenieros que trabajan en esas ´areas son expertos en los sistemas que pertenecen a la empresa, pero cuando se requiere de la creaci´on de una nueva aplicaci´on los mismos no est´an en capacidad de generarla, ya que no poseen la experiencia, ni el conocimiento suficientes; creando as´ı la necesidad de contratar a un proveedor que realice el an´alisis, dise˜no e implementaci´on de la aplicaci´on, generando altos costos para las empresas, aun cuando las mismas posean un ´area de sistemas.

Muchas empresas realizan campa˜nas publicitarias para atraer clientes po-tenciales de sus productos, algunas de estas est´an conformadas por concursos cuyos premios buscan que la gente se motive y se cree fidelizaci´on del producto o marca. Existen herramientas en internet que facilitan la creaci´on y adminis-traci´on de concursos, pero la manipulaci´on e implementaci´on de los mismos a trav´es de dichas tecnolog´ıas generan altos costos adicionales a la empresa y en algunos casos quedan limitados, ya que los recursos contratados pueden no ser lo suficientemente robustos y no soportar la demanda esperada, o por el contrario pueden sobrar recursos, creando as´ı gastos innecesarios para la empresa.

Las aplicaciones concursos de fidelizaci´on de clientes para empresas solo re-quieren estar en uso por un tiempo determinado y luego se desechar´an. Dentro de las empresas se da por hecho de que para la creaci´on de un concurso se deben utilizar herramientas que generan costos adicionales, lo que lleva a la pregunta: ¿Es posible que una persona con algunos conocimientos en tecnolog´ıa, pueda construir una aplicaci´on de concurso que funcione sobre una plataforma Cloud Computing usando una herramienta sencilla, y siguiendo algunas instrucciones?

2.3 Objetivo general

Proponer una aproximaci´on que permita la construcci´on f´acil y r´apida de apli-caciones para concursos en una plataforma PaaS para empresas que no son de tecnolog´ıa.

2.4 Objetivos espec´ıficos

1. Definir las variantes de arquitectura necesarias para la construcci´on de aplicaciones para concursos.

2. Dise˜nar una estrategia que permita la creaci´on de aplicaciones concurso sobre Cloud Computing.

3. Validar la aproximaci´on utilizando un escenario de concurso teniendo en cuenta escalabilidad y desempe˜no.

4. Disminuir los tiempos y costos de la creaci´on y despliegue de una aplicaci´on concurso.

2.5 Alcance de la propuesta

Se propone una herramienta que permite la creaci´on de aplicaciones para la generaci´on de concursos, la cual permitir´ıa que personas con conocimiento en tecnolog´ıa que no sean expertas en el desarrollo de dichas aplicaciones, puedan crearlas y desplegarlas en una plataforma Cloud Computing a partir de deter-minadas instrucciones, as´ı mismo la administrar´ıan y publicar´ıan de manera sencilla.

3

Marco te´

orico

3.1 Cloud Computing

Cloud Computing es un nuevo paradigma que nos permite adquirir tecnolog´ıa de Informaci´on bajo un esquema por demanda (On-Demand). En este tipo de computaci´on todo lo que se encuentra en el Datacenter de una compa˜n´ıa es ofre-cido como un servicio, adem´as, permite ofrecer de manera conveniente recursos y servicios con alta disponibilidad tanto en una red privada como una p´ublica, de esta manera, los usuarios acceden a un cat´alogo amplio de servicios, el cual responde a las necesidades del negocio de forma flexible, que le permite tambi´en adaptarse a las demandas en el tiempo [Chappell]. Su principal caracter´ıstica es la utilizaci´on de recursos que est´an compartidos, de esta manera los usuarios disponen de los servicios independientemente de donde se encuentren ubicados.

3.1.1 Modelo IaaS

El modelo de entrega de servicios de infraestructura hace referencia a recursos de almacenamiento, procesamiento y memoria, dicha infraestructura se despliega bajo demanda, permitiendo a los usuarios el despliegue de aplicaciones sobre un sistema operativo principal. En este modelo de servicio, el usuario final no ad-ministra, ni controla la infraestructura base de Cloud Computing, pero puede controlar dispositivos de almacenamiento, sistemas operativos, aplicaciones de-splegadas y opcionalmente controlar componentes de red, tales como un firewall o un enrutador. [Henrik]

3.1.2 Modelo PaaS

Este modelo consiste en la entrega de una plataforma de ejecuci´on de servicios que permiten el despliegue y ejecuci´on de aplicaciones creadas bajo las condi-ciones y herramientas de un proveedor Cloud Computing, entre las cuales se encuentran los lenguajes de programaci´on, middlewares, frameworks y APIs de acceso a los servicios de almacenamiento, c´omputo y conectividad. Igualmente,

en el modelo PaaS se oculta al usuario final todos los detalles de la infraestruc-tura, sistemas operativos, servidores, redes de telecomunicaciones, entre otros.

3.1.3 Modelo SaaS

Este modelo consiste en la entrega de software a trav´es de Internet, donde la aplicaci´on es propiedad de un proveedor de servicios. Las necesidades de las empresas son soportadas dentro de una misma aplicaci´on. Este modelo de ser-vicio se caracteriza por entregar a las empresas o los usuarios un software listo para usar sin que se preocupen por la responsabilidad de administrar tanto la infraestructura, como la plataforma de desarrollo. [Henrik]

3.1.4 Ventajas de Cloud Computing

Una vez relacionados y expuestos los niveles de servicios de Cloud Computing, se exponen las ventajas y desventajas generadas de utilizar esta herramienta:

• Reducci´on de costos: No hay necesidad de adquirir hardware y software, lo que reduce costos operativos en infraestructura, mantenimiento y energ´ıa. Usar la nube es m´as econ´omico que la suma de la instalaci´on y manten-imiento de un servidor propio o contratar los servicios de un proveedor. • Flexibilidad: El servicio de nube se paga de acuerdo a la demanda. Si, por

ejemplo, una empresa los d´ıas treinta incrementa el movimiento de su ´area contable y financiera por pagos a empleados y proveedores, puede decidir que requiere mayor capacidad de proceso o de almacenamiento de datos, y pagar´a por una mayor demanda, pero s´olo el d´ıa 30.

• Movilidad: Los datos de una empresa al quedar alojados en la nube pueden ser consultados por los empleados desde cualquier lugar. Esta caracter´ıstica est´a significando un crecimiento del teletrabajo con todos sus efectos de tipo econ´omico, social e incluso, inmobiliario.

• Focalizaci´on: Cloud Computing permite a las compa˜n´ıas centrarse en su core business, negocio principal. En vez de hacer una alta inversi´on tec-nol´ogica en sistemas, una empresa podr´ıa invertir en su infraestructura industrial o f´ısica o en capital humano para proseguir sus planes de ex-pansi´on

• Ecolog´ıa: Usar la nube en una empresa reduce la huella de carbono de una empresa al ahorrar recursos y componentes que pasan de estar almacenados en componentes f´ısicos a ser virtuales. Se ahorra tambi´en en consumo de energ´ıa con sus beneficios al medio ambiente.

3.1.5 Desventajas de Cloud Computing

• Seguridad: Los datos pueden extraviarse en agujeros de seguridad o ser robados por hackers, por lo que se debe ser muy cuidadoso con el manejo de la informaci´on.

• Privacidad: Datos confidenciales y sensibles como planes de mercadeo, lanzamientos de productos, informaci´on personal de empleados, datos fi-nancieros pueden quedar en manos de terceros si no se tienen las medidas preventivas.

• Conectividad: La velocidad de acceso a la informaci´on y la disponibilidad de las aplicaciones dependen de la velocidad de la conexi´on a internet. Sin acceso a Internet no hay Cloud Computing y este servicio puede dejar de funcionar en cualquier momento por diversos factores.

3.2 Estilo arquitectural CQRS

CQRS es un estilo arquitectural dise˜nado para aplicaciones distribuidas y donde m´as del 90% de las operaciones son de consulta y el restante 10% son inserciones, modificaciones y eliminaciones.

Existen dos pilares que son la base fundamental de CQRS, la colaboraci´on y la obsolescencia. La Colaboraci´on se refiere a circunstancias bajo las cuales m´ultiples actores usar´an o modificar´an los mismos datos (teniendo o no la in-tenci´on de colaborar entre ellos). A menudo hay reglas que indican los usuarios puede realizar determinadas modificaciones, cu´ales de ellas podr´ıan ser acept-ables y en qu´e casos. Los actores pueden usuarios normales (personas) o au-tom´aticos (otro software). La Obsolescencia se refiere al hecho de que en un entorno colaborativo, una vez que los datos han sido mostrados al usuario, los mismos pueden ser o haber sido modificados por otro actor, en otras palabras la informaci´on puede ser potencialmente obsoleta. Cualquier sistema que haga uso de una cach´e est´a sirviendo datos obsoletos a menudo, esto debido a la eficiencia, lo que significa que no se puede confiar completamente en las decisiones de los usuarios, ya que podr´ıan estar tomadas en base a informaci´on desactualizada. El hecho de que la informaci´on sea obsoleta no es completamente obvio. Las arquitecturas de capas est´andar no tratan expl´ıcitamente con ninguno de estos problemas (colaboraci´on y obsolencia). Mientras que compartirlo todo en una misma base de datos podr´ıa ser un paso en la direcci´on correcta para tratar la colaboraci´on, la obsolescencia es normalmente m´as acusado en esas arquitecturas por el uso de cach´es cuya intenci´on es mejorar el rendimiento.

Figure 3.1 Diagrama explicativo de la arquitectura CQRS.

3.3 Model Driven Engineering - MDE

Un modelo representa una versi´on simplificada de un sistema complejo, es de-cir, es una abstracci´on de la realidad, puesto que no representa cada aspecto

y dimensi´on del mismo; la construcci´on de un modelo puede tener diferentes objetivos, tales como el analizar, corregir y/o simular una funcionalidad, entre otros; sin embargo, el objetivo principal es el de representar un conjunto par-ticular de caracter´ısticas del sistema con un inter´es espec´ıfico [Bezivin]. Por lo tanto, pueden haber diferentes modelos que representan un sistema, pero cada uno se centra en un conjunto diferente de propiedades. Junto con el concepto de modelo est´a el metamodelo, el cual se define como la especificaci´on abstracta del lenguaje de modelado. Se podr´ıa decir que un metamodelo es un idioma: contiene la definici´on y descripci´on de cada ”palabra” (concepto) y la manera c´omo se pueden o no ”articular” entre ellas (relaciones estructurales) para que las ”sentencias ”(modelos) sean v´alidas. De acuerdo con esta definici´on, hay una relaci´on entre un modelo y un metamodelo, la cual es de conformidad. Se dice que un modelo es conforme a un metamodelo, si el modelo s´olo utiliza los conceptos definidos por el metamodelo y cumple con las relaciones estructurales y restricciones establecidas por este ´ultimo. Estos conceptos son la base que

Figure 3.2 Diagrama del MDE [Oldevik].

definen el paradigma MDE, que busca reducir la brecha conceptual existente en-tre la abstracci´on concebida para plantear el problema y la descripci´on utilizada de los dominios de aplicaci´on de la soluci´on. MDE propone utilizar modelos como ciudadanos de primera clase, en otras palabras, propone el desarrollo de herramientas y marcos capaces de construir modelos de manipulaci´on y elabo-raci´on. Al hacerlo, se estar´ıa ayudando a los desarrolladores con las tareas com-plejas de implementaci´on causadas por el conjunto de subsistemas y tecnolog´ıas

empleadas para construir un sistema [Bezivin]. Un artefacto clave adicional en el mundo MDE son las transformaciones, que son una de las primeras contribu-ciones de MDE para convertir los modelos en ciudadanos de primera clase. Las transformaciones son herramientas que procesan los modelos y los transforman en diferentes artefactos que se componen de reglas de transformaci´on definidas en t´erminos de los dominios involucrados (por lo general metamodelos) [Rumpe]. Cada regla de transformaci´on define un conjunto de elementos de entrada, un conjunto de elementos de salida, y un conjunto de operaciones, este ´ultimo se puede realizar en el primero con el fin de producir el segundo. Las transforma-ciones se clasifican por la naturaleza de los dominios implicados. Los tipos m´as comunes son el modelo a modelo y el modelo a texto. Las transformaciones de modelo a modelo se encargan de transformar un modelo conforme a un metamod-elo fuente espec´ıfico a otro conforme a un metamodmetamod-elo destino espec´ıfico. Las transformaciones modelo a texto se encargan generar texto a partir de un mod-elo, estas se utilizan para generar c´odigo fuente y/o archivos de configuraci´on. Actualmente MDE trabaja en tres diferentes frentes:

1. El lenguaje de modelado, el cual trata de responder las siguientes pregun-tas ¿C´omo se puede utilizar la abstracci´on como un ciudadano de primera clase? ¿Qu´e caracter´ısticas del lenguaje de modelado necesitan ser formal-izadas? Y ¿C´omo esas caracter´ısticas pueden ser formalizadas?

2. La separaci´on de las preocupaciones se ocupa de las consecuencias de la utilizaci´on de los diferentes modelos que representan el mismo sistema.

3. El manejo y gesti´on de modelado de artefactosabarca todas las herramien-tas, marcos y entornos, cuya finalidad sea la de almacenar, analizar, vali-dar, transformar, hacer seguimiento de la evoluci´on y las versiones de los modelos [Muller].

3.4 Model-Driven Architecture - MDA

La MDA es una de las principales iniciativas que forman MDE, fue propuesta por el Object Management Group (OMG) y su objetivo es proporcionar un marco preciso y eficiente que contribuya a la producci´on de sistemas de software [Montes]. MDA especifica tres puntos de vista en un sistema:

1. El punto de vista independiente de c´omputo, el cual se enfoca en el contexto y los requisitos del sistema, sin considerar su estructura o procesamiento, es decir, se centra en el entorno en el que el sistema funcionar´a y en sus caracter´ısticas requeridas (CIM).

2. El punto de vista independiente de plataforma, se enfoca en las capacidades operacionales del sistema fuera del contexto de una plataforma espec´ıfica, mostrando s´olo aquellas partes de la especificaci´on completa que pueden ser abstra´ıdas de la plataforma. Vale la pena mencionar que en el contexto de MDA, una plataforma se define como el ”conjunto de subsistemas y tecnolog´ıas que proporcionan un conjunto de funcionalidades a trav´es de interfaces espec´ıficas y patrones de uso”. El punto de vista independiente de la plataforma se centra en los aspectos del sistema que no van a variar de una plataforma a otra (PIM).

3. El punto de vista espec´ıfico de plataforma ofrece una vista del sistema ofreciendo detalles espec´ıficos, expresados en un modelo de descripci´on de la plataforma (PDM), se integra con los elementos de la PIM. Este punto de vista de un sistema se describe por un modelo espec´ıfico de la plataforma (PSM). La separaci´on de aspectos independientes y espec´ıficos de la plataforma se considera la clave para proporcionar un soporte efectivo en la generaci´on de una aplicaci´on en una plataforma espec´ıfica o en otra.

Figure 3.3 Diagrama Y de MDA.

3.5 Modelo de rasgos o Feature model

Entre los aportes para expresar variabilidad se encuentra FODA [Foda]. Este m´etodo fue introducido en 1990 por la Universidad Carnigie Mellon (CMU) y el SEI, su metodolog´ıa est´a relacionada con el an´alisis de requerimientos y el dise˜no de alto nivel. El principal aporte de FODA es el modelo de feature. Un feature es una propiedad del sistema relevante para alg´un stakeholder (usuarios finales, expertos del dominio, desarrolladores), este puede referirse a un requerimiento, a un componente de la arquitectura o a una pieza de c´odigo. Un modelo de feature puede ser usado para

1. Capturar los resultados del an´alisis de dominio.

2. Manejar lo com´un y lo variable entre productos de una SPL

3. Facilitar el dimensionamiento de la SPL

4. Proveer una base para configurar autom´aticamente los productos concretos.

Durante el an´alisis, los features son categorizados como obligatorios, op-cionales o alternativos. los features obligatorios determinan lo com´un entre los productos de la l´ınea y los features opcionales y alternativos determinan el grado de variabilidad de la misma. Features obligatorios o comunes son los features que deben ser prove´ıdos por cada miembro de la SPL. Features opcionales son aquellos prove´ıdos por solo algunos miembros de la SPL. Features alternativos exclusivos: dos o m´as features son alternativos exclusivos, cuando uno y solo uno de ellos puede ser prove´ıdo por un miembro de SPL.

3.6 Heroku

CRFA Cloud genera aplicaciones que pueden ser desplegadas sobre Heroku, una PaaS que ofrece el desarrollo de aplicaciones y servicios Web en la nube, esta provee herramientas de desarrollo, capacidad de procesamiento escalable y gesti´on en la nube. Heroku se desarroll´o inicialmente para Ruby on Rails y ahora es compatible con otros lenguajes de desarrollo.

Heroku ofrece un conjunto de herramientas de desarrollo y servicios espec´ıficos de la aplicaci´on, posee una ´unica plataforma para desarrollar, probar, implemen-tar y administrar el proceso de desarrollo de aplicaciones de extremo a extremo. En adici´on, posee varios componentes que trabajan juntos para proporcionar una plataforma completa de desarrollo en la nube. Por ejemplo provee una API que permite el despliegue de c´odigo de la aplicaci´on, la gesti´on de versiones, as´ı como otras actividades de gesti´on de la operaci´on de colaboraci´on y gesti´on de control de acceso y escalabilidad [Heroku].

Heroku tambi´en viene con varios servicios que permiten a los desarrolladores integrar soluciones de terceros dentro de la arquitectura del programa, incluyendo la base de datos, la monitorizaci´on, el correo electr´onico y la facturaci´on, entre otros, conocidos estos servicios como add-on.

4

Estado del arte

En este cap´ıtulo se definieron agrupaciones de art´ıculos y herramientas rela-cionadas con MDE, Cloud Computing y aplicaciones de concursos en general. En la investigaci´on se encontr´o gran cantidad de proyectos MDE, algunos de ellos para la generaci´on autom´atica de aplicaciones web, otros que generan apli-caciones para la nube, de los cuales algunos pocos son apliapli-caciones que son ofrecidas como servicios en la nube. Las aplicaciones para concurso no se encon-traron relacionadas con ninguno de los anteriores temas, pero se hallaron muchas aplicaciones que permiten creaci´on de aplicaciones para concurso.

[Bruneliere] propone diferenciar los generadores MDE as´ı:

MDE para la nube

Las t´ecnicas de MDE pueden facilitar y semi automatizar el desarrollo de nuevas aplicaciones SaaS. Dados los modelos del sistema de negocio independientes de la plataforma, se realizan transformaciones modelo a modelo y modelo a texto de manera que se obtiene c´odigo fuente de las aplicaciones.

MDE en la nube: Modeling as a Service (MaaS)

Cloud computing puede dar muchos beneficios a MDE, este articulo propone MaaS como iniciativa para desplegar servicios en Internet que por demanda ejecuten modelos para la generacion de aplicaciones de software.

Ambos grupos pertenecen a un grupo m´as grande que son los generadores MDE, la combinaci´on de ambos son generadores MDE en la nube para generaci´on de servicios en la nube, pero nuestro objetivo es la generaci´on de aplicaciones para concursos. Por estas razones se decidi´o clasificar estos proyectos y herramientas en 5 grupos:

A) Generadores MDE.

B) Generadores MDE para la nube.

D) Generadores MDE en la nube para la nube.

E) Aplicaciones concurso.

Figure 4.1 Grupos de articulo del estado del arte.

4.1 Grupo D - Generadores MDE en la nube para la nube

4.1.1 MODACLOUDS: A Model-Driven Approach for the De-sign and Execution of Applications on Multiple Clouds

Este art´ıculo [Ardagna] hablan sobre la computaci´on en nube, la cual se est´a convirtiendo en una tendencia importante en la industria de las TIC. Si bien la mayor parte de la atenci´on de la comunidad de investigaci´on se centra en considerar la perspectiva de los proveedores de la nube, ofreciendo mecanismos para apoyar la escala de los recursos, la interoperabilidad y la federaci´on entre las nubes.

Argumentan que MDE puede ser ´util en el contexto de Cloud Computing, ya que permite a los desarrolladores dise˜nar sistemas de software en la nube y a partir de t´ecnicas de transformaci´on se puede validar el modelo creando instancias espec´ıficas para diferentes nubes, aprobando la que m´as se ajusta a las necesidades del cliente. El enfoque MODACLOUDS (Enfoque Dirigido por Modelos para el dise˜no y ejecuci´on de aplicaciones en m´ultiples nubes) se basa en estos principios, y tiene como objetivo apoyar a los desarrolladores y operadores del sistema en la explotaci´on de m´ultiples nubes por el mismo sistema y en la migraci´on de gran parte de sus sistemas de nube en nube, seg´un sea necesario. MODACLOUDS ofrece un dise˜no conducido por atributos de calidad, el desar-rollo y el m´etodo de funcionamiento, cuenta con un sistema de que apoya la toma de decisiones permitiendo analizar los riesgos en la selecci´on de los proveedores de la nube.

4.2 Grupo B - Generadores MDE para la nube

4.2.1 Developing migratable multicloud applications based on MDE and adaptation techniques

El desarrollo de software para la nube por lo general implica el uso de las her-ramientas y bibliotecas suministradas por proveedores de la nube para cada una

de sus plataformas. Este fuerte emparejamiento del software para plataformas espec´ıficas y la interoperabilidad con servicios de nube externos, es lo que se conoce como el encadenamiento con proveedores. En estas circunstancias, las multicloud se vuelven dif´ıciles de construir y mantener, ya que requieren equipos multidisciplinarios con experiencia en m´ultiples plataformas, y la modernizaci´on de algunos componentes entorpece la implementaci´on en la nube. El marco MULTICLAPP descrito en este art´ıculo [Guillen] aborda estas cuestiones me-diante la presentaci´on de un proceso de desarrollo de tres etapas que permite a las aplicaciones multicloud desarrollar sin ser acoplado a cualquier proveedor de concreto. MDE y t´ecnicas de adaptaci´on se utilizan en todas las etapas de desarrollo de software con el fin de abstraer el software de servicios en especifica-ciones de cada proveedor. Como resultado de esto, las aplicaespecifica-ciones multicloud o sus subcomponentes pueden ser reasignados a diferentes plataformas en la nube sin tener que someterse a un proceso de reconstrucci´on parcial o completa.

4.2.2 Model-driven Generative Framework for Automated OMG DDS Performance Testing in the Cloud

El Object Management Group’s (OMG) Data Distribution Service (DDS) pro-porciona muchas pol´ıticas configurables que determinan la calidad de extremo a extremo de servicio (QoS) de aplicaciones. Es un reto predecir el rendimiento del sistema en t´erminos de latencias, el rendimiento, y el uso de recursos debido a diversas combinaciones de configuraciones de QoS influyen en la QoS de las aplicaciones de diferentes maneras. Para superar este problema, los m´etodos formales en tiempo de dise˜no se han aplicado con ´exito desigual, pero la falta de suficiente precisi´on en la predicci´on, el soporte de herramientas, y la comprensi´on del formalismo ha impedido una mayor adopci´on de las t´ecnicas formales. Un en-foque prometedor para hacer frente a este reto es emular el comportamiento del sistema y recopilar datos sobre los par´ametros de calidad de servicio de inter´es por la experimentaci´on. Para hacer realidad este enfoque, que se prefiere frente a los m´etodos formales, debido a sus limitaciones en la calidad de servicio que predicen con exactitud, se ha desarrollado un marco de pruebas de rendimiento autom´atico basado en modelos con capacidades generativas para reducir los es-fuerzos manuales en la generaci´on de un gran n´umero de configuraciones de QoS pertinentes que pueden ser implementado y probado en una plataforma en la nube. Este art´ıculo [Kuroda] describe los esfuerzos iniciales en el desarrollo y el uso de esta tecnolog´ıa.

4.3 Grupo C - Generadores MDE en la nube

4.3.1 Transitioning to the cloud. a model-driven analysis and automated deployment capability for cloud services

Como la nube se est´a volviendo cada vez m´as popular y atractivo, de aplica-ciones y los proveedores de servicios, por lo tanto los usuarios se enfrentan cada vez a m´as preguntas sobre si trasladarse a la nube pueda ser ben´efico para su negocio, y c´omo debe ser realizado el despliegue en la nube de su aplicaci´on. T´ecnicas de an´alisis, tales como simulaciones, son prometedoras en el an´alisis de los beneficios de trasladarse a la nube, y mientras que los mecanismos gener-ativos pueden automatizar la implementaci´on de aplicaciones en la nube. Este

art´ıculo [Caglar] describe c´omo la ingenier´ıa dirigida por modelos (MDE) soporta ambos capacidades deseadas, proporcionando capacidades intuitivas y automa-tizadas para conducir simulaciones de infraestructuras de nube y servicios de aplicaci´on para analizar los beneficios de mover las aplicaciones a la nube, y la automatizaci´on del despliegue de estas aplicaciones en la nube.

4.4 Grupo A - Generadores MDE

4.4.1 A Model-Driven Development Approach for Service-Oriented Integration Scenarios

[Hoyer] El establecimiento de procesos apoyados por IT en las organizaciones requiere la integraci´on de aplicaciones heredadas distribuidas existentes. Por lo tanto, los servicios Web se pueden generar como envoltorios para integrar de forma flexible las aplicaciones heredadas distribuida ya existentes mediante una interfaz estandarizada. Los enfoques existentes se centran principalmente en las cuestiones t´ecnicas de la integraci´on mediante servicios web y no son compatibles con el desarrollador durante la descripci´on de un proceso de integraci´on. As´ı, en este art´ıculo presentamos un enfoque de desarrollo que apoya el desarrollador en la descripci´on de un proceso de integraci´on y, finalmente, permite una trans-formaci´on basada en modelos del proceso de integraci´on definido antes en las interfaces de servicios web y las definiciones de esquema XML. Nuestro enfoque se ejemplifica con un escenario en el Instituto de Tecnolog´ıa de Karlsruhe (KIT) que implementa un proceso de visualizar el progreso del estudio de un estudiante.

4.4.2 Model Driven Development of a Service Oriented Archi-tecture (SOA) Using Colored Petri Nets

La Arquitectura Orientada a Servicios (SOA) ha logrado una amplia aceptaci´on en una variedad de sistemas de la empresa, debido a su inherente flexibilidad y la interoperabilidad, la mejora en la mayor tradici´on y enfoque menos soportable ” compartimentos estancos”. El alto grado de concurrencia y tanto las comunica-ciones s´ıncronas y as´ıncronas inherentes a SOA hace que sea un buen candidato para un modelo de desarrollo impulsado basado Petri Nets (MDD). Este tipo de enfoque, con sus implicaciones de verificaci´on y validaci´on subyacentes, se vuelve m´as crucial en aplicaciones de misi´on cr´ıtica, tales como los que tienen incidencia en la defensa. Este art´ıculo [Gehlot] informa sobre experiencias con el uso de Redes de Petri de colores(CPN) para el desarrollo dirigido por modelos y evaluaci´on de la calidad de un arquitectura orientada a servicios de software orientada defensa. Identificaron caracter´ısticas de CPN que han resultado en la facilidad de adopci´on como una herramienta de modelado en el entorno actual. Los resultados preliminares se proporcionan apoyo en el uso de las RPC como base para el modelo impulsado por el desarrollo de software, y la verificaci´on y validaci´on para garantizar la calidad altamente concurrente y de misi´on cr´ıtica SOAs.

4.5 Grupo E - Aplicaciones concurso

Las siguientes son herramientas que permite la creaci´on de concursos en Inter-net, fueron seleccionadas entre muchas ya que cumplen con los requisitos que

cumplir´an las aplicaciones generadas por la aproximaci´on de este trabajo. En la tabla 4.1 podemos ver que todas las aplicaciones que permiten crear concurso est´an acopladas a redes sociales, la mayor´ıa colocan publicidad en la pantalla del concurso y los costos est´an entre 99 y 409 d´olares mensuales.

Aplicaci´ on Costo Usuarios Redes So ciales Publicidad Can tidad de concursos So cial to ols [So cialT o ols] 199 d´ olares/mes M´ aximo 500.000 Acoplado No Ilimitados Co ol tabs [Co olT abs] 274 d´ olares/mes Ilimitados Acoplado Si Ilimitados Easy promos [EasyPromos] 250 d´ olares/mes M´ aximo 100.000 Acoplado No Ilimitados Halalati [Halalati] 409 d´ olares/mes Ilimitados Acoplado Si Ilimitados T riso cial [T riso cial] 135 d´ olares/mes Ilimitados Acoplado Si Ilimitados One Kon te st [OneKon test] 99 d´ olares/mes M´ aximo 1.000 Acoplado Si Ilimitados T able 4.1 Costos aplicaciones pa ra crea r concursos

5

CFRA Cloud

CFRA Cloud nace dada la necesidad de llevar la tecnolog´ıa a todo tipo de empresas, la cuales necesitan crear aplicaciones y no cuentan con un amplio conocimiento en herramientas de dise˜no, desarrollo y despliegue de aplicaciones, mucho menos en arquitectura. CFRA Cloud es una l´ınea de producto, que tiene como artefactos iniciales cuatro modelos, requerimientos funcionales, requerim-ientos no funcionales, modelo de la entidad concursante y modelo de datos de configuraciones arquitecturales y generales, a partir de ellas, es capaz de construir una aplicaci´on concurso a la medida de las necesidades de la compa˜n´ıa.

CFRA Cloud es una aproximaci´on que permite la generaci´on del c´odigo fuente de aplicaciones para concursos, las cuales son desplegadas en una plataforma Cloud Computing como Heroku, y solo requiere de conocimientos en herramien-tas como IDE Eclipse y un Navegador Web, adem´as, la arquitectura var´ıa con respecto a los requerimientos no funcionales del concurso.

Este cap´ıtulo est´a dividido en 4 partes que en conjunto son la estrategia de la aproximaci´on CFRA Cloud detallada a continuaci´on.

Figure 5.1 Estrategia de soluci´on

Se defini´o la estrategia de la imagen 5.1 que divide la l´ınea de producto en cuatro secciones.

5.1 Configuraci´

on

La configuraci´on de la l´ınea de producto requiere de 4 artefactos de entrada, re-querimientos funcionales, rere-querimientos no funcionales, atributos de entidad de negocio y atributos de configuraci´on, los cuales son descritos a continuaci´on, y al

final se explica la variabilidad de la arquitectura que depende de la configuraci´on de los artefactos.

5.1.1 Requerimientos no funcionales

Los requerimientos no funcionales son definidos utilizando un modelo de features conforme al formato SXFM [Sxfm] de los componentes de la arquitectura que in-fluyen directamente con el funcionamiento de la aplicaci´on, en esta aproximaci´on se defini´o la escalabilidad y el desempe˜no como requerimientos funcionales clave. La escalabilidad esta precisada a partir del estilo arquitectural en el cual se de-sarrollan los servicios de la aplicaci´on, y en los tipos de Dyno que es la unidad m´ınima de procesamiento de la plataforma Cloud Computing que estamos uti-lizando. En cuanto al desempe˜no lo definimos por medio de la base de datos.

Figure 5.2 Diagrama features - Requerimientos no funcionales

Dentro de la escalabilidad el estilo arquitectural es Rest ya que necesitamos la aplicaci´on maneje objetos sin estado para el caso en que escale a m´as de un Dyno y se da˜ne la integridad de los datos. En cuanto los tipos de Dyno se permite variabilidad al seleccionar 3 tipos, 1X, 2X y PX, la diferencia en cada uno es el tama˜no de memoria, capacidad de computo y cantidad de memoria compartida para el procesamiento.

El desempe˜no solo tiene un punto de variabilidad que es la base de datos, per-mite seleccionar una sola o las dos y adem´as admite la cantidad de combinaciones de los tipos de bases de datos de la tablas 5.4 y 5.5.

5.1.2 Requerimientos funcionales

Los requerimientos funcionales son definidos utilizando un modelo de features conforme al formato SXFM [Sxfm] de los men´us, m´odulos o caracter´ısticas princi-pales de las aplicaciones de concurso. En esta aproximaci´on tenemos tres grandes divisiones, la inscripci´on del concursante, compartir el concurso en redes sociales y el tipo de concurso.

La inscripci´on del concursante no tiene punto de variabilidad, este contiene la funcionalidad de inscripci´on y los t´erminos y condiciones. Compartir en redes sociales no es obligatorio, pero si se selecciona es requerido marcar al menos una de las redes (Facebook, Twitter o Google +). El tipo de concurso tiene dos opciones, Sorteo (Se termina el tiempo y aleatoriamente se elige al ganador) o Votaci´on (Gana el que tenga mayor n´umero de votos), si seleccionamos el segundo

Figure 5.3 Diagrama features - Requerimientos funcionales

debemos seleccionar si es un concurso de videos, textos o im´agenes, en caso de ser un concurso de im´agenes este requiere que el elemento por el cual se votara se al-macenen en un servidor externo (S3 Amazon) lo cual cambia autom´aticamente la arquitectura, si selecciona alguno de los dem´as requiere almacenamiento interno y se maneja persistencia en base de datos para el elemento de votaci´on.

5.1.3 Atributos de entidad de negocio

Se defini´o un peque˜no metamodelo que permite crear atributos a una concur-sante, la tarea es asegurar que el Concursante tenga al menos un atributo que sera solicitado al momento de la inscripci´on.

Figure 5.4 Metamodelo atributos concursante

Este metamodelo esta definido con tres clases, Concursante, Atributo y TipoDato.

• Concursante Es la clase ra´ız, de la cual se desprenden los atributos. • AtributoEs cada uno de los atributos que tiene el concursante.

• TipoDato Enumeraci´on que contiene los datos Num´erico y Cadena para darle un tipo de dato a los atributos.

5.1.4 Propiedades configuraci´on

Se defini´o un metamodelo que contiene las propiedades necesarias para person-alizar la aplicaci´on utilizando la cuenta de la plataforma Cloud Computing, S3 de Amazon para las im´agenes y algunas caracter´ısticas de las aplicaciones.

Figure 5.5 Metamodelo propiedades configuraci´on

Este metamodelo se definio con tres clases, Configuraci´on, Propiedad y TipoPropiedad.

• Configuraci´onEs la clase ra´ız, de la cual se desprenden todas las propiedades. • PropiedadEs cada uno de los propiedades que se desean personalizar con

los datos del cliente.

• TipoPropiedadEnumeraci´on que contiene todos los nombres de las propiedades que deseamos personalizar.

5.1.5 Variabilidad de la arquitectura

Seg´un la configuraci´on seleccionada y explicada en la secci´on anterior, la arqui-tectura resultante cambia de manera que supla las necesidades del concurso. La variabilidad de la arquitectura se explica a partir de las vistas principales de arquitectura. A continuaci´on damos dos ejemplos donde se detallan las vistas en funci´on de los feature seleccionados.

Ejemplo 1

En la imagen anterior se han seleccionado el feature del Dyno 1X de 512 MB lo que indica que ser´a utilizado el que no tiene costo y tambi´en esta seleccionado el feature SQL indicando que se utilizara base de datos relacional.

A continuaci´on el diagrama de componentes que muestra las relaciones entre componentes de la aplicaci´on, teniendo en cuenta los features seleccionados.

• WebappContiene las pantallas y estilos de la aplicacion.

• Paquete ControllerContiene las clases que reciben las peticiones de la pantalla y se comunica con la capa de servicios utilizando objetos DTO.

Figure 5.6 Diagrama de features seleccionado ejemplo 1

Figure 5.7 Diagrama de componentes arquitectura ejemplo 1

• Paquete ServicesContiene las clases que tienen la l´ogica de negocio y se comunican con la capa de persistencia utilizando los objetos entidades.

• Paquete RepositoryContiene las clases que tienen todos los servicios de la base de datos relacional.

• Archivo procfileArchivo que indica como debe ser desplegada la aplica-cion en la plataforma Cloud Computing

A continuacion el diagrama de despliegue de la aplicacion concurso en una plataforma Cloud Computing, teniendo en cuenta los feature seleccionados.

Figure 5.8 Diagrama de despliegue arquitectura ejemplo 1

En el anterior diagrama vemos que la aplicacion funciona integrandose a algunos servicios de Amazon S3 y base de datos.

Ejemplo 2

En este ejemplo se explica la variabilidad de la arquitectura se se seleccionan ambas base de datos en buscar de replicar la informacion convirtiendose en una arquitectura mixta llamada CQRS.

Figure 5.9 Diagrama de features seleccionado ejemplo 2

Se han seleccionado el feature del Dyno 1X de 512 MB lo que indica que ser´a utilizado el que no tiene costo y tambi´en, est´an seleccionado los feature SQL y

No SQL indicando que se utilizara base de datos relacional y no relacional, de manera que cambia la arquitectura utilizando ahora dos estilos arquitecturales tres capas y CQRS. Ahora se necesita agregar a la aplicaci´on algunos paquetes para gestionar las operaciones con la base de datos no sql.

Figure 5.10 Diagrama de componentes arquitectura ejemplo 2

• WebappContiene las pantallas y estilos de la aplicacion.

• Paquete ControllerContiene las clases que reciben las peticiones de la pantalla y se comunica con la capa de servicios utilizando objetos DTO. • Paquete Servicios Contiene las clases que tienen la l´ogica del negocio y

se comunica con la capa de persistencia utilizando los objetos entidades. • Paquete RepositoryContiene las clases que tienen todos los servicios de

la base de datos relacional.

• Paquete Query ServicesContiene las clases encargadas de gestionar las operaciones sobre la base de datos No SQL.

En el anterior diagrama se adiciono un componente que fue el paquete Query Services el cual gestiona las operaciones con la base de datos no sql.

En el siguiente diagrama de despliegue observamos que se adiciono la base de datos no sql.

Figure 5.11 Diagrama de despliegue arquitectura ejemplo 2

5.2 Generaci´

on

Para la generaci´on de la aplicaciones se defini´o con una cadena de transformaci´on imagen 5.12, la cual recibe cuatro artefactos de entrada explicados en la secci´on Configuraci´on.

La cadena de transformaci´on est´a elaborada utilizando un plugin del IDE Eclipse denominado MTC Flow [MtcFlow]. En esta herramienta se dise˜no la cadena de transformaci´on de la l´ınea de producto, la cual est´a compuesta por artefactos de entrada que son modelos conformes a metamodelos previamente definidos, estos se pasan por una transformaci´on hacia un modelo de arquitec-tura b´asica que es conforme a un metamodelo de arquitectura general de una aplicaci´on Cloud Computing, este modelo expresa los componentes de arquitec-tura requeridos seg´un la configuraci´on de los artefactos de entrada. La segunda transformaci´on es del modelo de arquitectura b´asica a un modelos de arquitec-tura detallada, el cual permite la definici´on de paquetes, clases y relaciones que se encuentran en la aplicaci´on. Adem´as existen otras transformaciones para los temas de archivos de configuraci´on y despliegue.

A continuaci´on se explica cada una de las cajas de la cadena de transfor-maci´on.

• MM Atributos ConcursanteMetamodelo definido para indicar los atrib-utos que se desean tenga el concursante al momento de la inscripci´on al

Figure 5.12 Cadena de transformaci´on

concurso.

• MM Formato SXFM Metamodelo del formato SXFM [Sxfm] el cual sirve para definir modelos de variabilidad.

• MM Configuraci´onMetamodelo definido para indicar valores para atrib-utos de configuraci´on requeridos en aplicaciones Cloud Computng y datos de usuario en general.

• M Atributos ConcursanteModelo conforme al metamodelo de atributos de concursantes el cual contiene los atributos que son parte del concursante y que le ser´an solicitados al momento de inscribirse al concurso.

• M Requerimientos FuncionalesModelo de requerimientos funcionales, el cual es conforme al metamodelo del formato SXFM que permite definir modelos de variabilidad

• M Requerimientos No FuncionalesModelo de requerimientos no fun-cionales, el cual es conforme al metamodelo del formato SXFM que permite definir modelos de variabilidad

• M Configuraci´on Modelo conforme al metamodelo de configuraci´on el cual contiene valores de atributos de configuraci´on de aplicaciones Cloud

Computing y datos del usuario en general.

• MM Arquitectura B´asica Metamodelo de arquitectura b´asica, el cual contiene los elementos m´ınimos requeridos para una aplicaci´on concurso.

• Transformaci´on Requerimientos a Arquitectura B´asica Transfor-maci´on M2M encargada de generar la arquitectura b´asica requerida para soportar la aplicaci´on concurso.

• M Arquitectura B´asicaModelo generado a partir de la primera transfor-maci´on de arquitectura. Este modelos contiene los componentes m´ınimos requeridos para una arquitectura de una aplicaci´on de concurso.

• Transformaci´on Arquitectura B´asica a Configuraci´onTransformaci´on M2T que a partir de la arquitectura b´asica se pueden definir varios de los archivos de configuraci´on requeridos para el despliegue o funcionamiento de las aplicaciones.

• Archivos Configuraci´on Los archivos generados son persistence.xml, procfile y applicationContext.xml.

• Transformaci´on Arquitectura B´asica a pom.xmlTransformaci´on M2T que se encarga de saber cu´ales son las librer´ıas requeridas para la apli-caci´on concurso. Este genera el archivo pom.xml requerido cuando se uti-liza Maven.

• Pom.xml Este es el archivo pom.xml resultado de la transformaci´on que tiene como entrada el modelo de arquitectura b´asica.

• MM Arquitectura DetalladaMetamodelo que permite la definici´on de los paquetes, clases, patrones y referencias que existen en una aplicaci´on concurso.

• Transformaci´on Arquitectura B´asica a Arquitectura Detallada Se-gunda transformaci´on M2M de arquitectura. En esta transformaci´on se definen los paquetes, clases, patrones y referencias que los relacionan. • M Arquitectura DetalladaResultado de la segunda transformaci´on de

arquitectura, este modelo tiene definidas los atributos del concursante, cada una de las capas de arquitectura y las clases que en ellas se requieren.

• Transformaci´on Arquitectura Detallada a C´odigo Java Transfor-maci´on M2T que genenra c´odigo java a partir de la arquitectura detallada.

• Transformaci´on Arquitectura Detallada a JSPTransformaci´on M2T que genera las pantallas necesarias dentro del concurso a partir de la ar-quitectura detallada.

• C´odigo JavaC´odigo Java con patrones de desarrollo, con una estructura arquitect´onica fiel al estilo arquitectural tres capas y en el caso de tener dos bases de datos (relacional y no relacional) una arquitectura mixta CQRS.

• JSPs Pantallas JSP resultado con una estructura definida y que utilizan los servicios generados en c´odigo Java.

Figure 5.13 Metamodelo arquitectura b´asica

El siguiente metamodelo permite la definicion de la aquitectura basica re-querida por una aplicacion concurso.

• SystemRa´ız del metamodelo, de ella se generan la dem´as clases implicadas en la definici´on de la arquitectura.

• WebClase que define el componente web de la aplicaci´on, la cual posee car-acter´ısticas como capacidad del Dyno requeridas, el titulo y la descripci´on del concurso.

• RelationalDatabaseClase que indica que se utilizara una base de datos relacional.

• NoRelationalDatabase Clase que indica que se utilizara una base de datos no relacional, al colocar esta clase junto a RelationalDatabase au-tom´aticamente se sabe que se espera tenga una arquitectura mixta.

• StorageFileComponent Clase utilizada ´unicamente cuando se generara un concurso de im´agenes, la cual generara que se generen las clases nece-sarias para almacenar las im´agenes del concurso en un lugar externo.

• Component Clase abstracta de la cual cada una de las clases de arqui-tectura heredan. Contiene una variable booleana indicando si esta activa o no.

• Memory Enumeraci´on que contiene los tres tipos de memoria de los Dynos.

El siguiente metamodelo define la arquitectura detallada requerida para la creaci´on de una aplicaci´on concurso. Estan presentes los componentes de ar-quitectura como las bases de datos, las pantallas JSP, los paquetes y las clases Java.

Figure 5.14 Metamodelo arquitectura detallada

• ApplicationRa´ız del metamodelo, de ella se generan las clases, Web, Re-lationalDatabase y NoReRe-lationalDatabase, que son clases las mas generales en la definici´on de la arquitectura.

• WebClase que define el componente web de la aplicaci´on, la cual posee car-acter´ısticas como capacidad del Dyno requeridas, el titulo y la descripci´on del concurso.

• RelationalDatabaseClase que indica que se utilizara una base de datos relacional.

• NoRelationalDatabase Clase que indica que se utilizara una base de datos no relacional, al colocar esta clase junto a RelationalDatabase au-tom´aticamente se sabe que se espera tenga una arquitectura mixta. • Component Clase abstracta de la cual cada una de las clases de

arqui-tectura heredan. Contiene una variable booleana indicando si esta activa o no.

• WebApp Clase que se genera a partir de la clase Web y contiene todas las pantallas y archivos de configuraci´on de la aplicaci´on.

• Java Clase que se genera a partir de la clase Web y contiene todas las clases Java organizadas en paquetes seg´un su uso.

• ResourceClase que indica una carpeta donde generalmente se almacenan archivos de configuraci´on.

• FolderClase que personifica cualquier carpeta que contiene elementos de arquitectura.

• SrcClase abstracta de la cual heredan las tres grandes carpetas Resource, WebApp y Java. Solo puede existir una de cada una en la arquitectura.

• File Clase que representa a los archivos de configuraci´on y despliegue re-queridos por las aplicaciones web en general y la plataforma Cloud Com-puting.

• Attribute Clase que representa un atributo del concursante el cual ser´a solicitado en conjunto en la inscripci´on al concurso.

• PackageDeclaration Clase que representa un paquete en lenguaje Java. • ClassDeclarationClase que representa una clase en lenguaje Java. • MethodClase que representa un m´etodo de una clase en lenguaje Java.

• TypeDeclarationClase que representa cualquier tipo de dato definido en lenguaje Java.

• NamedElement Clase de la cual todos los elementos que representan algo en lenguaje Java heredan y de esta manera son obligados a tener un nombre.

• ModifierClase que representa los modificadores de la clases y m´etodos en lenguaje Java.

• DataType Clase que define los tipos de datos posible que pueden tener los datos del concursante.

• Memory Enumeraci´on que contiene los tres tipos de memoria de los Dynos.

Luego de la ejecuci´on del l´ınea de producto, esta nos genero un proyecto que puede ser abierto por IDE Eclipse, pero debe tener instalado y configurado el plugin de plataforma Heroku. Pero como el objetivo no es instalar y configurar un ambiente de pruebas o producci´on, sino publicar la aplicaci´on generada en la plataforma Cloud Computing Heroku, se adicionaron dos artefactos, un pro-grama Java standalone que facilita el despliegue de la aplicaci´on de inmediato sobre la plataforma Cloud Computing y un archivo de JMeter que facilita la prueba de desempe˜no de la aplicaci´on. Estos artefactos ser´an explicados en las siguientes secciones.

5.3 Despliegue

Una vez generada la aplicaci´on, abrimos la carpeta del proyecto y esta muestra la estructura de un proyecto web eclipse para el pluguin de Heroku y adicionalmente un archivo Deploy.jar.

Deploy.jar es un programa standalone hecho en Java el cual facilita la tarea de desplegar la aplicaci´on en la plataforma Cloud Computing Heroku. A contin-uaci´on se explicaran los requerimientos del uso de Deploy.jar para el despliegue de la aplicaci´on en la plataforma Cloud Computing y por ´ultimo se mostraran unas pantallas que muestran el funcionamiento de Deploy.jar.

Requerimientos de despliegue

Los requerimientos para que el despliegue con la aplicaci´on standalone funcione correctamente son los siguientes:

• Cuenta HerokuTener una cuenta en la p´agina de Heroku. www.heroku.com • Heroku ToolbeltTener instalado el Heroku Toolbelt en la maquina desde

donde se utilizara Deploy.jar. https://devcenter.heroku.com/articles/quickstart • Java Virtual Machine Tener instalada la maquina virtual de java en la

maquina donde se utilizara Deploy.jar.

http://www.oracle.com/technetwork/es/java/javasebusiness/downloads/index.html • GitTener instalado Git en la maquina donde se utilizara Deploy.jar.

http://git-scm.com/downloads

Aplicaci´on Deploy.jar

Deploy.jar es una aplicaci´on standalone que facilita el despliegue del concurso en la plataforma Cloud Computing Heroku. Su funcionamiento es explicado a continuaci´on.

Figure 5.15 Interface Deploy.jar

• Git PathEn este campo se debe colocar el path de instalaci´on de Git del equipo donde se esta ejecutando Deploy.jar.

• Heroku Account En este campo se coloca el usuario de la cuenta de Heroku.

• Hwroku Account Password En este campo se coloca la clave de la cuenta de Heroku.

• Principal Context ImageEn este campo se coloca el path de la imagen principal del concurso.

5.4 Pruebas

Una vez generada la aplicaci´on, abrimos la carpeta del proyecto y esta muestra la estructura de un proyecto web eclipse para el pluguin de Heroku y adicionalmente un archivo contest.jmx.

El archivo Context.jmx tiene la extension del programa JMeter, el cual fa-cilita la tarea de prueba de carga para la aplicaci´on concurso en la plataforma Cloud Computing. A continuaci´on se explicara los requerimientos y c´omo re-alizar la prueba con JMeter.

Requerimientos uso JMeter

• JMeterDescargar JMeter. http://jmeter.apache.org/index.html

• Java Virtual Machine Tener instalada la maquina virtual de java en la maquina donde se realizara la prueba con JMeter.

http://www.oracle.com/technetwork/es/java/javasebusiness/downloads/index.html

Prueba

Ejecutar JMeter dando doble clic en jmeter.bat que se encuentra en la carpeta bin de la carpeta que contenga JMeter. Imagen 5.16.

Abrimos el men´u ”Archivo” y damos clic en la opci´on ”Abrir”. Imagen 5.17.

Buscar el archivo Context.jxm dentro de la carpeta donde se genero la apli-caci´on. Imagen 5.18.

El archivo abierto JMeter debe verse como muestra la siguiente imagen. Ini-cialmente tiene el t´ıtulo ”Prueba Concurso en Cloud Computing” y esta enviara creara 10 peticiones por segundo a la aplicaci´on. Imagen 5.19.

Si seleccionamos en el arbol de la izquierda ”Valores por Defecto para Petici´on HTTP” mostrara la siguiente interface. Imagen 5.20.

En la Imagen 6.20 vemos en el nombre de servidor ”concursotesis.herokuapp.com/ contest/inscrip” que es el url para la inscripci´on al concurso, y m´as abajo en la secci´on par´ametros se ven los que se enviaran en cada solicitud http.

Figure 5.16 Interface Apache JMeter - Plan de pruebas

Figure 5.18 Interface Apache JMeter - Seleccion archivo Contest.jmx

6

Costos aplicaciones para concurso

En la construcci´on y despliegue de aplicaciones, los costos en tiempo y dinero son factores muy importantes que determinan si se elige una opci´on u otra. Este cap´ıtulo explica los costos que se generan en la creaci´on, desarrollo y despliegue de la aplicaciones para concurso y por el uso de la plataforma Cloud Computing. Los costos en la plataforma Cloud Computing se calculan a partir de los componentes o caracter´ısticas utilizadas en la arquitectura de la aplicaci´on.

Los costos en construcci´on y despliegue se calculan a partir de la complejidad, tiempos de desarrollo, despliegue y experiencia de la persona o grupo de personas que construyan la aplicaci´on.

6.1 Costos de la plataforma Cloud Computing

Los requerimientos no funcionales est´an ligados estrechamente con los costos que se generaran en la plataforma Cloud Computing. En esta l´ınea de producto se seleccionan los requerimientos no funcionales a partir de un diagrama de features (Figura 7.1).

Figure 6.1 Diagrama de features - Requerimientos no funcionales.

Cloud Computing cambian. Como estamos utilizando la plataforma Cloud Com-puting Heroku, manejamos el t´ermino Dyno para indicar la unidad m´ınima de procesamiento. Se seleccionan los features de los extremos del diagrama, Arqui-tecturaRest es un feature fijo, solo se permite seleccionar un tipo de Dyno y las base de datos.

6.1.1 Tipos de Dyno

En cuanto los tipos de Dyno existen tres opciones, 1X, 2X y PX, pero pode-mos tener un solo Dyno o varios de diferentes tipos, la tabla 6.1 muestra las caracteristicas de hardware de cada uno de los tipos de Dyno.

Tipo Memoria Cuota CPU Precio Hora

1X 512 MB 1X 0.05 D´olares

2X 1 G 2X 0.1 D´olares

PX 6 G 100% (1) 0.8 D´olares

Table 6.1 Caracter´ısticas de los tipos de Dyno

(1) El tama˜no dyno PX tiene 8 n´ucleos y es altamente aislado.

La tabla 6.2 muestra los costos que tienen los diferentes Dynos si se utiliza uno solo.

Tipo Precio Mes

1X 0 D´olares 2X 34.5 D´olares PX 538 D´olares

Table 6.2 Precios utilizando un solo Dyno

La tabla 6.3 muestra los costos que genera la plataforma Cloud Computing si una aplicacion utiliza dos Dynos o mas.

Tipo Precio Mes dos Dynos Tercer Dyno en adelante

1X 34.5 D´olares 36 D´olares mas

2X 106.5 D´olares 72 D´olares mas

PX 1114.5 D´olares 576 D´olares mas

Table 6.3 Precios con mas de un Dyno

6.1.2 Bases de datos

Podemos seleccionar dos clases de bases de datos, relacional (SQL) y no relacional (No SQL), cada una tiene varios tipos con caracter´ısticas y precios diferentes. La tabla 6.4 muestra los tipos de bases de datos relacionales, sus caracteristicas y precios.

Tipo Limite de Filas Memoria Alta Disponibilidad Precio Mes

Hobby Dev 10.000 0 Bytes No Gratis

Hobby Basic 10.000.000 0 Bytes No 9 D´olares

Standard Yanari Ilimitadas 410 MB No 50 D´olares

Premium Yanari Ilimitadas 410 MB Si 200 D´olares

Standard Tengu Ilimitadas 1.7 G No 200 D´olares

Premium Tengu Ilimitadas 1.7 G Si 350 D´olares

Standard Ika Ilimitadas 7.5 G No 750 D´olares

Premium Ika Ilimitadas 7.5 G Si 1200 D´olares

Standard Baku Ilimitadas 34 G No 2000 D´olares

Premium Baku Ilimitadas 34 G Si 3500 D´olares

Standard Mecha Ilimitadas 68 G No 3500 D´olares

Premium Mecha Ilimitadas 68 G Si 6000 D´olares

Table 6.4 Tipos de Base de Datos Relacional

La tabla 6.5 muestra los tipos de bases de datos no relacionales, sus carac-teristicas y precios.

Tipo Memoria Precio Mes

MongoHQ Sandbox 512 MB Gratis

MongoHQ Small 2 G 15 D´olares

4 GB SSD 4 G 100 D´olares

12 GB SSD 12 G 250 D´olares

25 GB SSD 25 G 500 D´olares

50 GB SSD 50 G 900 D´olares

75 GB SSD 75 G 1350 D´olares

150 GB SSD 150 G 2700 D´olares

Table 6.5 Tipos de Base de Datos No Relacional

6.1.3 Ejemplos de seleccion de features

A continuaci´on se dan algunos ejemplos de selecci´on en el diagrama de features y el costo generado en la plataforma Cloud Computing.

Ejemplo 1

En este ejemplo podemos ver que se seleccionaron los features del Dyno 1X y la base de datos relacional (SQL), esta es la configuraci´on mas b´asica que podemos obtener, la cual no genera costo en la plataforma Cloud Computing, por el Dyno seleccionado y la base de datos seleccionada. ver Tabla 6.6.

Componente Tipo Costo Mensua

Tipo Dyno 1 Dyno 1X 0 D´olares

Tipo Base Datos SQL - Hobby Dev 0 D´olares

Costo total 0 D´olares