magíster (msc)bibliotecadigital.usb.edu.co/bitstream/10819/4581/1...citar/how to cite [1]...

1

Diseño y construcción de un componente para el generador de código ZathuraCode que genere

proyectos con arquitectura basada en microservicios en Java.

Freddy Sebastián García Victoria, [email protected] Frank Edward Daza Gonzalez, [email protected]

Trabajo de Grado presentado para optar al título de Ingeniero de Sistemas

Asesor: Diego Armando Gomez Mosquera, Magíster (MSc) en Ingeniería de Software

Co Asesor: Maria Teresa Lopez Dueñas, Magíster (MSc) en Ingeniería de Software

Universidad de San Buenaventura Colombia

Facultad de Ingeniería

Ingeniería de Sistemas

Santiago de Cali, Colombia

2017

Citar/How to cite [1]

Referencia/Reference

Estilo/Style: IEEE (2014)

[1] M. T. Lopez Dueñas, D. A. Gomez Mosquera F. S. Garcia Victoria y F. E.

Daza Gonzalez, “Diseño y construcción de un componente para el

generador de código ZathuraCode que genere proyectos con

arquitectura basada en microservicios en Java.”, Trabajo de grado

Ingeniería de Sistemas, Universidad de San Buenaventura Cali, Facultad

de Ingeniería, 2017.

https://co.creativecommons.org/?page_id=13

https://co.creativecommons.org/?page_id=13

2

Bibliotecas Universidad de San Buenaventura

• Biblioteca Fray Alberto Montealegre OFM - Bogotá.

• Biblioteca Fray Arturo Calle Restrepo OFM - Medellín, Bello, Armenia, Ibagué.

• Departamento de Biblioteca - Cali.

• Biblioteca Central Fray Antonio de Marchena – Cartagena.

Universidad de San Buenaventura Colombia

Universidad de San Buenaventura Colombia - http://www.usb.edu.co/ Bogotá - http://www.usbbog.edu.co Medellín - http://www.usbmed.edu.co Cali - http://www.usbcali.edu.co Cartagena - http://www.usbctg.edu.co Editorial Bonaventuriana - http://www.editorialbonaventuriana.usb.edu.co/ Revistas - http://revistas.usb.edu.co/

Biblioteca Digital (Repositorio)

http://bibliotecadigital.usb.edu.co

3

RESUMEN Este proyecto inició como respuesta a una problemática que se evidenció en la empresa Vortexbird S.A.S, al notar las dificultades que se presentan al realizar un despliegue en producción de una ERP que se vende como servicio en la nube; en este proyecto en el cual se está trabajando, una de las mayores dificultades es que al ser un producto de software siempre está en actualización de controles de cambios y/o no conformidades por lo cual es necesario realizar despliegues a producción casi a diario. Al ser una aplicación monolítica con seis (6) módulos diferentes, alrededor de 247 tablas y 2.019 clases esta es empaquetada en un formato WAR (Web application ARchive); cada vez que es necesario subir al servidor de producción, es primordial detener todos los servicios que presta el software, ya que en el momento del despliegue, se tiene que eliminar el WAR antiguo por el nuevo. Este proceso es lento, poco eficiente y al realizarse un cambio en la aplicación, se tendrá que desplegar de nuevo evitando así que los clientes puedan usar la aplicación por un periodo determinado de tiempo (el tiempo varía entre el tamaño de la aplicación monolítica a desplegar, velocidad de internet, entre otros factores). Al ver este tipo de problemática, se decidió buscar una mejor manera de lidiar con los despliegues a producción de aplicaciones críticas, en ese momento se comenzó a realizar las investigaciones de un estilo arquitectónico llamado microservicios, el cual ha sido usado desde hace varios años por grandes empresas tecnológicas como Netflix, Google, Amazon, Facebook entre otras. En el presente proyecto se plantea una solución para la creación de proyectos de software con un estilo arquitectónico orientado a microservicios, la cual consiste en crear un módulo de microservicios que ampliará el funcionamiento de una herramienta de generación de código Java Zathuracode, ya que es una herramienta usada desde hace varios años en la industria de software local, en el ámbito académico, y es software libre, la cual asegura que puede ser usada por cualquier persona en cualquier parte del mundo sin costo alguno.

4

AGRADECIMIENTOS

A nuestras familias por el apoyo incondicional en nuestra vida y crecimiento como personas, a nuestra universidad en la cual, gracias a sus docentes, hemos aprendido y desarrollado nuestras habilidades profesionales y humanísticas, las cuales nos ayudarán a enfrentar los retos de la sociedad actual y futura. Muchas gracias a nuestro director de tesis Ing. Diego Armando Gómez Mosquera, por su orientación, dedicación, acompañamiento en el proceso de desarrollo de nuestro trabajo de grado y formación como profesionales, nuestra co-directora Ing. Maria Teresa López por su guía, acompañamiento en el desarrollo de documento de tesis y formación como profesionales, también y finalmente pero no menos importante al Ing. Johan Steve Bejarano, por su ayuda prestada en nuestro ámbito laboral y académico.

5

GLOSARIO

Recopilación de definiciones y término utilizados en el proyecto, incluir términos más importantes, poco conocidos, de difícil interpretación o que no sean comúnmente utilizados en el contexto.

• Microservicios: Es un estilo arquitectónico que estructura una aplicación como una colección de servicios ligeramente acoplados, que implementan capacidades empresariales. [1]

• Protocolo: Se trata del conjunto de pautas que posibilitan que distintos elementos que forman parte de un sistema establezcan comunicaciones entre sí, intercambiando información. [2]

• API: Interfaz de Programación de Aplicaciones, una API es una especie de “llave de acceso” a funciones que permiten hacer uso de un servicio web provisto por un tercero, dentro de una aplicación web propia. [3]

• REST: Es un conjunto de arquitecturas de desarrollo web que se apoya en el estándar HTTP, REST nos permite crear servicios y aplicaciones que pueden ser usadas por cualquier dispositivo o cliente que entienda HTTP.

• Mapeador: Es una técnica de programación para convertir datos entre dos tipos de objetos diferentes.

• Entidades: Una entidad es la representación de un objeto o concepto del mundo real que se describe en una base de datos.

• Hibernate: Es una herramienta de mapeo objeto-relacional (ORM) para la plataforma Java que facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación

• Gradle: Es básicamente una herramienta para automatizar el proceso de construcción de una aplicación como en la compilación, las pruebas, empaquetado gestión de librerías, entre otros.

• Espacio de trabajo: El espacio de trabajo tiene una estructura jerárquica. Los proyectos están en el nivel superior de la jerarquía y dentro de ellos puede tener archivos y carpetas.

• Plugin: Un plugin es aquella aplicación que, en un programa informático, añade una funcionalidad adicional o una nueva característica al software.

• Librerías: es un conjunto de implementaciones funcionales, codificadas en un lenguaje de programación, que ofrece una interfaz bien definida para la funcionalidad cuando invoca.

• Planificación de Recursos Empresariales (ERP): es un conjunto de sistemas de información que permite la integración de ciertas operaciones de una empresa, especialmente las que tienen que ver con la producción, la logística, el inventario, los envíos y la contabilidad. [4]

• Objetos de acceso de datos (DAO): Es un patrón es una abstracción y encapsulación de los accesos a las fuentes de datos, esto con el fin de poder usar varias fuentes de datos con sus diferentes configuraciones sin la necesidad de modificar elementos de la lógica del negocio o entidades. [5]

6

TABLA DE CONTENIDO

1. INTRODUCCIÓN ....................................................................................................................................... 9

1.1. Contexto ...................................................................................................................................... 9 1.2. Planteamiento del Problema ....................................................................................................... 9 1.3. Justificación del Problema ........................................................................................................... 9 1.4. Objetivo General ....................................................................................................................... 10 1.5 Objetivos Específicos ................................................................................................................. 10 1.6 Descripción de la Solución ......................................................................................................... 10 1.6.1 Proceso de Ingeniería ................................................................................................................ 10 1.6.1.1 Fase de estudio ..................................................................................................................... 11 1.6.1.2 Fase de definición .................................................................................................................. 11 1.6.1.3 Fase de desarrollo ................................................................................................................. 11 1.6.1.4 Fase de aplicación ................................................................................................................. 11 1.6.2 Productos de Software .............................................................................................................. 11 1.6.3 Productos No Software .............................................................................................................. 11

2. MARCO TEÓRICO ....................................................................................................................................... 13

2.1 Arquitectura de software ........................................................................................................... 14 2.2 Arquitectura multinivel (Multi-tier Architecture) ........................................................................ 14 2.3 Arquitectura orientada a servicios (SOA) ................................................................................... 15 2.4 Transferencia de estado representacional (REST)....................................................................... 16 2.5 Arquitectura de microservicios (MSA) ........................................................................................ 17 2.6 Docker ....................................................................................................................................... 18 2.7 Generador de código para JavaEE Zathuracode ......................................................................... 19

3. PROCESO DE INGENIERÍA DE SOFTWARE .............................................................................................. 22

3.1 Modelo de proceso de desarrollo de software. .......................................................................... 22 3.1.1 Descripción de Iteraciones realizadas ........................................................................................ 23 3.2 Educción de Requisitos .............................................................................................................. 28 3.2.1 Técnica utilizada: Grupo Focal ................................................................................................... 28 3.2.2 Técnica utilizada: lectura basada en perspectivas ...................................................................... 28 Se revisaron las fuentes y no se encontraron requisitos funcionales diferentes a los obtenidos en el grupo focal, sin embrago se obtuvo limitaciones y requisitos calidad. .............................................................. 29 3.2.3 Requisitos funcionales documentados ....................................................................................... 29 3.3 Análisis y Diseño ........................................................................................................................ 30 3.3.1 Objetivos de Arquitectura y Limitaciones. .................................................................................. 30 3.3.2 Requisitos No Funcionales. ........................................................................................................ 31 3.4 Diseño de la Arquitectura. ......................................................................................................... 32 3.5 Patrones de Diseño Utilizados.................................................................................................... 36 3.6 Justificación de Diseño ............................................................................................................... 36 3.7 Desarrollo .................................................................................................................................. 37 3.7.1 Tecnologías utilizadas.................................................................................................................... 37 3.7.2 Tecnologías utilizadas y su Relación con los Atributos de Calidad. ............................................. 37 3.8 Prototipos del Software ............................................................................................................. 38 3.8.1 Prototipos Zathuracode Versión 5.2 ........................................................................................... 38 3.8.2 Prototipos Zathuracode Versión 6.0 ........................................................................................... 39 3.9 Pruebas y Evaluación de Software ............................................................................................. 40 3.9.1 Resumen Pruebas Funcionales ................................................................................................... 40

7

3.10 Acceso a la Aplicación................................................................................................................ 54

4. ANÁLISIS DE RESULTADOS ..................................................................................................................... 56

4.1 Análisis de Impactos .................................................................................................................. 56 4.2 Utilización de herramientas ....................................................................................................... 56 4.3 Análisis de diseño de componentes ............................................................................................ 57 4.4 Cumplimiento de Objetivos ........................................................................................................ 57 4.5 Experiencia de diseño en ingeniería de software ........................................................................ 57 4.6 Trabajos Futuros........................................................................................................................ 58

5. REFERENCIAS ......................................................................................................................................... 60 6. ANEXOS ................................................................................................................................................. 64

6.1. PROTOTIPOS DE PANTALLA. ................................................................................................................... 64 6.1.1. ZATHURACODE VERSIÓN 5.2 ............................................................................................................. 64 6.1.2. ZATHURACODE VERSIÓN 6.0 ............................................................................................................. 70 6.2. CASOS DE PRUEBA .............................................................................................................................. 40 6.3. EVIDENCIA DE CASOS DE PRUEBA ............................................................................................................ 76

8

1. INTRODUCCIÓN

1.1 Contexto 1.2 Planteamiento del problema 1.3 Justificación del Problema 1.4 Objetivo General 1.5 Objetivos Específicos 1.6 Descripción de la solución 1.6.1 Descripción Proceso de Ingeniería 1.6.2 Productos de Software 1.6.3 Productos No Software

1.6.3.1.1.1.1.1.1 Objetivo General

1.6.3.1.1.1.1.1.2

1.6.3.1.1.1.1.1.3 1.6.3.1.1.1.1.1.4

9

1.6.3.1.1.1.1.1.5 1. INTRODUCCIÓN

1.1. Contexto

En la última década, gracias a la gran acogida por parte de los internautas [6] de aplicaciones o servicios en la nube [7] de empresas como Google, Facebook, Amazon, Netflix, entre otras, ha crecido de manera exponencial la información que se transmite y administran los componentes de hardware y de software de estas compañías. Esta situación ha marcado un antes y un después en la manera como se debe gestionar, almacenar y diseñar, la infraestructura tecnológica que maneja los datos de las compañías o internautas que usen servicios en la nube [7]. Para llevar a cabo la tarea de diseñar y desarrollar software que pueda soportar y escalar este tipo de situaciones de gran manejo de información actuales, se han venido utilizando diferentes estilos arquitectónicos de software, entre ellos, uno de los más usados ha sido el estilo arquitectónico por capas [8], el cual ha funcionado muy bien para la mayoría de problemas de pequeñas y medianas empresas, pero no para los nuevos desafíos que existen en la actual era de la información. Por esta razón, es que grandes empresas han empezado a implementar un “nuevo” estilo arquitectónico denominado: Arquitectura de Microservicios [9], el cual busca solucionar los antiguos problemas de las aplicaciones monolíticas por capas [8]. Teniendo en cuenta la tendencia mundial de grandes compañías tecnológicas de implementar y/o migrar sus infraestructuras hacia un estilo arquitectónico de microservicios, se tomó la decisión de diseñar y construir un componente para el generador de código ZathuraCode que esté en la capacidad de crear proyectos web en JAVA, con la arquitectura basada en microservicios [10].

1.2. Planteamiento del Problema

Con base al análisis previo, en este trabajo de grado se plantea la siguiente pregunta de investigación: ¿Cómo habilitar al generador de código Zathuracode para que genere código de aplicaciones con arquitectura orientada a microservicios?

1.3. Justificación del Problema

Una de las desventajas de las aplicaciones con arquitectura monolítica, ocurre cuando se necesitan subir cambios a una aplicación web que se encuentra alojada en un servidor, para esto es necesario detener todos los procesos que se están realizando dentro de esta aplicación así el cambio o los cambios no tengan nada que ver con los procesos realizados en ese momento. Otra de las desventajas de las aplicaciones con este tipo de arquitectura es la duplicación del código ya que al ser aplicaciones monolíticas no comparten entre ella las funcionalidades de sus módulos, para esto se planteó hace varios años una arquitectura que permitiera estar hecha de pequeños servicios que se pudieran juntar para cumplir la necesidad de uno o muchos clientes, lamentablemente en ese momento no había las tecnologías necesarias para sostener esta arquitectura llamada microservicios.

10

Conforme ha pasado el tiempo la tecnología ha ido creciendo de forma exponencial y ya se cuenta con los recursos como servidores con grandes capacidades que se pueden adaptar con clúster, diferentes protocolos de comunicación como REST o GraphQL que hacen posible una comunicación fácil de implementar con arquitectura basadas en microservicios, con esto comienza a surgir la necesidad de una herramienta que simplifique el proceso para el desarrollo de este tipo de arquitectura, una herramienta que permita la generación de código en java de proyectos con arquitectura orientada a microservicios; dada la gran demanda por parte de empresas multinacionales de la talla de Netflix, Google, Amazon, entre otras, y la lenta pero constante implementación de este estilo arquitectónico en empresas nacionales colombianas, hace constatar que existe un mercado emergente por parte de los equipos de desarrollo de software en Java para solucionar este tipo de problemas de ingeniería de software.

1.4. Objetivo General

Diseñar y construir un componente para el generador de código Zathuracode, que genere aplicaciones con una arquitectura basada en microservicios.

1.5 Objetivos Específicos

• Definir los requisitos claves para el desarrollo del componente a construir.

• Diseñar y construir un componente que permita a la herramienta Zathuracode generar

proyectos con arquitectura orientada a microservicios en Java.

• Evaluar el desarrollo del componente realizado por medio de un ejemplo práctico.

1.6 Descripción de la Solución

1.6.1 Proceso de Ingeniería

El modelo de procesos utilizado es un modelo por fases por lo cual el trabajo realizado se dividió en cuatro (4) fases ilustradas en la Figura 1:

Figura 1. Fases del Modelo.

11

Estas fases se detallan a continuación: 1.6.1.1 Fase de estudio

Se realizó una revisión de la información referente a la arquitectura orientada a microservicios, así como su relación con la arquitectura orientada a servicios (SOA) y, el ecosistema tecnológico en el que funcionan para definir y establecer las ventajas que ofrece este nuevo estilo arquitectónico para el generador de código Zathuracode en la generación de las aplicaciones en Java.

1.6.1.2 Fase de definición

Se definió el diseño de la estructura del componente que se construirá para el generador de código Zathuracode que genere proyectos con arquitectura basada en microservicios en Java.

1.6.1.3 Fase de desarrollo

Se desarrolló un componente de software que genere un estilo arquitectónico de microservicios para el generador de código Zathuracode.

1.6.1.4 Fase de aplicación

Se realizó pruebas con bases de datos PostgreSQL y Oracle del nuevo componente del generador de código de Zathuracode el cual permite generar proyectos con una arquitectura orientada a microservicios para aplicaciones web en Java.

1.6.2 Productos de Software

• Zathuracode versión 6.0.

1.6.3 Productos No Software

• Trabajo de grado. • Vídeo del funcionamiento del módulo de microservicios integrado en

Zathuracode.

12

2. MARCO TEÓRICO

2.1 Arquitectura de software 2.2 Arquitectura multinivel (Multi-tier Architecture) 2.3 Arquitectura orientada a servicios (SOA) 2.4 Transferencia de estado representacional (REST) 2.5 Arquitectura de microservicios (MSA) 2.6 Docker 2.7 Generador de código para JavaEE Zathuracode

13

2. MARCO TEÓRICO

Analizando el contexto de los microservicios expuesto anteriormente en la sección 1.1, se puede ver que existe en el mercado una gran demanda de empresas que buscan soluciones para sus sistemas de información modernos, ya que una empresa actual, suele tener diferentes necesidades las cuales puede suplir de diferentes formas, por ejemplo: su personal directo puede trabajar con una tecnología de base de datos tipo SQL y un lenguaje de programación Java, pero pueden contratar (ya sea por cuestiones financieras o estratégicas) a ingenieros de desarrollo que trabajen remotamente con un sistema de base de datos tipo NoSQL y un lenguaje de programación Python [30]. Cada equipo de trabajo podría realizar la solución a un problema específico (microservicio) usando la tecnología que más se adecue a sus necesidades, y aun así, poder acoplarse y comunicarse con otra cantidad de microservicios construidos por otros equipos de trabajo también, para ayudar a solucionar uno o varios problemas en una misma organización. Es de esperar que este estilo arquitectónico puede solucionar muchos problemas de la industria de software actual, pero también crea una complejidad mayor a la hora de realizar despliegues de sus módulos, ya que se soluciona el tener que parar el funcionamiento de toda la aplicación cada vez que se necesite actualizar un módulo de ella, pero si por ejemplo se tienen 1000 microservicios que desplegar independientemente, entonces la organización y el acoplamiento entre ellos se vuelve mucho más crítica que si solo tuviera que desplegar una gran aplicación monolítica en producción. Existen dos casos comunes en la industria del software actual cuando se habla tanto de microservicios como de tecnologías o metodologías emergentes, el primer caso es el de las empresas que son reacias al cambio, ellas probablemente no quieran ni saber sobre tecnologías nuevas para implementar en su organización y esto se debe a que siguen al pie de la letra el viejo dicho “lo que funciona no se toca”, el segundo caso es el de las pequeñas o medianas empresas que quieren implementar cuanta tecnología nueva o metodología que le prometan mejores resultados de calidad en sus procesos o productos, aún sin necesitar verdaderamente realizar un cambio o una mejora específica en su compañía. Los ejemplos de casos anteriores son muy comunes y si se quiere implementar un estilo arquitectónico orientado a microservicios en alguna compañía específica, lo primero que habría que preguntarse es ¿Disminuiría la complejidad de mis procesos de software al implementarlos? ¿Hay que contratar un personal especializado para implementarlos? ¿La calidad o ganancias de mi empresa aumentarán si se implemente este estilo arquitectónico? Solo si de verdad existe una necesidad objetiva y no una necesidad de seguir una nueva tendencia, entonces, habría que implementar este tipo de solución, porque hay que tener en cuenta que una nueva aplicación de pequeño a mediano alcance (pocos usuarios usándola, pocos módulos o líneas de código) no necesita una arquitectura de microservicios, por lo general, solo lo necesitan de verdad empresas que tengan sistemas donde sus miles o millones de usuarios necesiten realizar ciertas operaciones en tiempo real, o donde la complejidad del software que tiene una compañía, sea muy difícil de seguir escalando o mejorando por lo nuevos desarrolladores, dada la complejidad y el gran número de módulos acoplados que existan entre sí. Algo más a tener en cuenta es el ecosistema tecnológico que existe actualmente para realizar microservicios, es aquí cuando escuchamos tecnologías en gran auge como frameworks que permiten un fácil despliegue y des-acoplamiento en las aplicaciones (SpringBoot), contenedores

14

de aplicaciones para administrar microservicios de una manera sencilla (docker), protocolos de comunicación entre microservicios y los clientes que los consumen (API REST), y un estilo arquitectónico que podrías decirse es una evolución de la arquitectura orientada a servicios (SOA). A continuación, veremos en detalle de que trata cada uno componentes importantes en el ecosistema de los microservicios.

2.1 Arquitectura de software

La arquitectura de software “es el proceso de definición de una solución estructurada que satisface todos los requisitos técnicos y operativos, al tiempo que optimiza los atributos de calidad comunes, como el rendimiento, la seguridad y la capacidad de gestión. Implica una serie de decisiones basadas en una amplia gama de factores y cada una de estas decisiones puede tener un impacto considerable en la calidad, el rendimiento, la facilidad de mantenimiento y el éxito general de la aplicación” [11]. Como se puede evidenciar, hay una analogía entre lo que es la arquitectura en la construcción, y la arquitectura en el mundo de software. Gracias a un buen estilo arquitectónico aplicado a nuestros proyectos de software, podemos asegurar que este va a tener unas bases sólidas, con un diseño ya probado y por lo tanto nuestra construcción final (proyecto de software), va a ser probablemente una aplicación segura y de buena calidad. Con la arquitectura de software buscamos usar componentes reutilizables, esto lo hacemos por medio de patrones de diseño existentes. Es importante al iniciar un proyecto de software, definir los requisitos tanto funcionales como de calidad, para analizar una buena estructura o base (arquitectura), que puedan seguir los desarrolladores del software, así no tendrían que construir todos los módulos del sistema desde cero, y también para que exista una coherencia entre lo que el usuario final espera del producto, y lo que los desarrolladores entiendan que van a construir. Sin pautas arquitectónica claras, hay camino para la ambigüedad y muy probablemente, para un desarrollo de mala calidad.

2.2 Arquitectura multinivel (Multi-tier Architecture)

La arquitectura multinivel, es un estilo de arquitectura de software en la cual diferentes componentes de software, se encuentran organizados en diferentes niveles o capas, cada una provee una funcionalidad específica [12]. La forma más común de división de capas es una arquitectura que consiste en 3 niveles: nivel de presentación, nivel de lógica de negocio y nivel de gestión de datos. A continuación, en la figura 2, se ilustra el estilo arquitectónico multinivel:

15

Figura 2. Arquitectura multinivel.

2.3 Arquitectura orientada a servicios (SOA)

La arquitectura orientada a servicios (SOA) es un diseño de software compuesto por diferentes partes que interactúan entre sí, esto es a lo que se conoce un servicio. Estos se caracterizan por tener definido un contrato, el contrato es el que dicta lo que le entra al servicio y lo que él tiene que devolver, esto facilita la comunicación entre diferentes plataformas, se debe en gran medida al porque existen estándares como REST [13] o SOAP [14], lo que logra que sin importar el lenguaje este puede usar cualquier tipo de servicios. El objetivo trata de descomponer la lógica de negocio en pequeñas unidades de funcionalidad llamadas servicios, con esto se cambia el paradigma donde una aplicación resuelve una necesidad específica; gracias a esto pasamos a tener una “plataforma transversal” formada por varios servicios, haciendo uso de este no resolveremos las necesidades cambiantes del negocio, pero si se podrá combinar diferentes servicios para resolver una necesidad y responder de forma más ágil a las exigencias del negocio. Se puede pensar “entonces para tener una arquitectura orientada a servicios lo que tengo que hacer es crear servicios web a lo bestia” [15]. Para la arquitectura orientada a servicios (SOA) se necesita una buena base de servicios reutilizables y estos servicios que no sean para resolver una necesidad específica; un “contrato” con modelo de datos “normalizado”, de modo que facilite la interacción entre servicios, sustituir el concepto de interoperabilidad intrínseca. Se necesita categorizar, registrar todos los servicios de manera que se puedan consultar qué realiza y cómo se interactúa con el servicio (Contrato y Términos y Condiciones). No se necesita usar solamente un lenguaje en concreto a la hora de crear el servicio, estos deben implementarse con la tecnología que se necesite sin que afecte el resto de la plataforma. A continuación en la figura 3 se ilustran los servicios SOA:

16

Figura 3. Inventarios de servicios y catálogo SOA.

2.4 Transferencia de estado representacional (REST)

REST, REpresentational State Transfer, REST se definió en el 2000 por Roy Fielding, coautor principal también en la especificación HTTP, es un conjunto de arquitecturas de desarrollo web que se apoya en el estándar HTTP, REST nos permite crear servicios y aplicaciones que pueden ser usadas por cualquier dispositivo o cliente que entienda HTTP, por lo que es increíblemente más simple y convencional que otras alternativas como SOAP y XML-RPC. Se refiere a una colección de principios para el diseño de arquitectura en red. Estos principios resumen como los recursos son definidos. El término frecuentemente es utilizado en el sentido de describir cualquier interfaz que transmiten datos específicos sobre HTTP sin una capa adicional. Es posible diseñar un sistema de software de gran tamaño de acuerdo con la arquitectura propuesta por Roy Fielding sin utilizar HTTP o sin interactuar con la web. A continuación, en la figura 4 se ilustra un diseño de una API REST:

Figura 4 Diseño de una API REST.

17

2.5 Arquitectura de microservicios (MSA)

La arquitectura basada en microservicios es un estilo de arquitectura de software, por el cual se define que el software se puede dividir por pequeños servicios de modo que estos sean lo más independientes posibles entre ellos, esto no significa que todos los servicios no puedan estar relacionados, algunos necesitarán estar relacionados entre sí de manera irrefutable, de igual forma no existe una respuesta exacta para saber cómo de pequeño debe ser un servicio para ser considerado microservicio [16]. Los microservicios, son pequeños servicios autónomos que trabajan de forma coordinada. Una comparación gráfica en la figura 5 entre una aplicación de arquitectura monolítica y una arquitectura basada en microservicios:

Figura 5 Arquitectura de Microservicios. Aunque la idea de microservicios pueda sonar novedosa, esto surgió desde el uso de SOA (Services Oriented Architecture). De hecho, ellos parecen prácticamente iguales. La realidad es que de manera general entre los desarrolladores se entiende la arquitectura basada en microservicios como una evolución de SOA [15]. Aunque un microservicio puede ser tan pequeño o grande de acuerdo al tipo de software que se esté desarrollando, la idea es reunir en un microservicio una parte pequeña de una lógica de negocio, es decir, un microservicio sería un componente del negocio que realice una única función y pueda ser accedida por otros servicios. Cuando se habla de microservicios, hay que entender que en este tipo de arquitecturas se busca la descentralización de un solo tipo de estándar o tecnología que se usaría comúnmente en un programa monolítico. Esto es posible ya que un solo microservicio puede tener su propio lenguaje de programación, bases de datos y tecnologías afines, las cuales son escogidas para dar una mejor solución a cierta parte de la lógica de negocio. Por ejemplo: si el software necesita un componente

18

que maneje unas operaciones en tiempo real, se podría escribir un microservicio en C++ con una base de datos NoSQL, si se quiere un componente con una alta compatibilidad con bibliotecas en Java, se puede construir un microservicio en ese lenguaje y una base de datos Oracle, esa es una de las ventajas que tiene este estilo arquitectónico, pero hay que tener cuidado con algo y “es que el hecho de que algo pueda hacerse, no significa que deba hacerse”. 2.6 Docker

Docker es un desarrollo de código abierto, el cual permite empaquetar una aplicación de software con todas sus dependencias en una unidad estandarizada de software llamada contenedores [17]. En un principio docker se puede confundir con las máquinas virtuales, pero hay ciertas ventajas (o desventajas según el punto de vista) frente a estas. Imaginemos por un momento que tenemos un servidor físico tipo GNU/Linux, en el cual instalamos algunas máquinas virtuales, en las cuales se encontrarán nuestras aplicaciones empresariales. Al correr nuestra aplicación en una máquina virtual propia, significa que no solo hay que hacerle mantenimiento a esa aplicación u aplicaciones que se encuentran en nuestras máquinas virtuales, sino que al ser la máquina virtual un sistema operativo completo corriendo, pues este también consume recursos, aumenta complejidad en el despliegue de las aplicaciones, y si no se mantiene actualizado, será una brecha más de seguridad en nuestra aplicación. A continuación, se ilustra en la figura 6 el diseño actual de un servidor con varios sistemas operativos virtualizados sin docker:

Figura 6 Arquitectura de Microservicios.

19

La tecnología de Docker maneja el concepto de contenedores, en los cuales podemos empaquetar nuestras aplicaciones con sus dependencias, y estas ocupan menos recursos en nuestro servidor físico, así como evitamos el tener que administrar y actualizar cada sistema operativo virtualizado que se haya instalado el nuestro servidor. A continuación se ilustra en la figura 7 el diseño actual de un servidor con varios sistemas operativos virtualizados con docker:

Figura 7 Arquitectura de Microservicios.

Cada contenedor de Docker es independiente, por lo tanto, es fácilmente escalable y, si queremos parar una aplicación o si una aplicación falla, ésta no comprometer a ningún otro contenedor.

2.7 Generador de código para JavaEE Zathuracode

Zathuracode es un generador de código para apoyar el desarrollo de aplicaciones empresariales en JavaEE, a partir de un modelo de base de datos existente [18]. Zathuracode genera código JavaEE con un estilo de arquitectura por capas en la cual se dividen básicamente en: presentación, lógica de negocio, acceso a datos, recursos y la capa de administración de Spring Framework. La herramienta es de uso libre y se distribuye bajo la licencia Apache 2.0, esto garantiza que el producto nunca tendrá ningún costo.

20

A continuación, en la figura 8 se ilustra el diseño arquitectónico de la estructura base generada con Zathuracode:

Figura 8 Estilo arquitectónico de proyecto generado por Zathuracode.

21

3. PROCESO DE INGENIERÍA DE SOFTWARE

3.1 Modelo de proceso de desarrollo de software 3.2 Educción de Requisitos 3.3 Análisis y Diseño 3.4 Diseño de la Arquitectura. 3.5 Patrones de Diseño Utilizados 3.6 Justificación de Diseño 3.7 Desarrollo 3.8 Pruebas y Evaluación de Software 3.9 Acceso a la Aplicación

22

3. PROCESO DE INGENIERÍA DE SOFTWARE En este capítulo se presentan los procesos específicos de ingeniería aplicados para el desarrollo de este proyecto. Los procesos son: elección de un modelo de proceso, la educción de requisitos funcionales y no funcionales, definición de artefactos necesarios para el análisis y diseño, la elección de las herramientas, patrones y tecnologías que fueron usadas durante el proceso de desarrollo del software, culminando con las respectivas pruebas que validarán el cumplimiento de los objetivos propuestos. La presentación de dichos procesos tiene como objetivo evidenciar el desarrollo de competencias en términos de desarrollo de software, por parte de los autores del documento.

3.1 Modelo de proceso de desarrollo de software.

Para el desarrollo del trabajo de grado junto con el nuevo componente de microservicios para el generador de código en Java Zathuracode, se utilizó un modelo de desarrollo en espiral. “El modelo de desarrollo en espiral es un generador de modelos de proceso basado en el riesgo. Se utiliza para orientar la ingeniería concurrente de múltiples partes interesadas del software intensivo de Sistemas. Tiene dos rasgos distintivos principales. Uno es un Enfoque cíclico para el crecimiento incremental del grado de Definición y puesta en práctica, disminuyendo al mismo tiempo su grado de riesgo. El otro es un conjunto de puntos de anclaje para asegurar a los stakeholders soluciones de sistemas viables y mutuamente satisfactorias” [31]. Se usó este modelo por dos razones principales, en primer lugar, se tenía claro que el desarrollo del trabajo de grado tanto en su parte documental como el desarrollo de la aplicación, iban a realizarse de manera paralela para complementarse uno del otro, es decir, en cada iteración se consultaba información, se analizaba para modificar/mejorar el diseño existente, se implementaba código, se realizaba una entrega parcial y se comunicaba al director de tesis. En segundo lugar, era importante usar un modelo que permitiera un desarrollo ágil con entregas parciales, pero sin la necesidad de reuniones diarias o muy continuas como por ejemplo el marco de trabajo SCRUM, ya que por cuestiones laborales y de estudio, no era posible una reunión diaria (a veces semanal) con las partes implicadas (director, codirector de tesis y estudiantes).

La siguiente figura 9 representa los procesos del modelo en espiral:

23

Figura 9 Modelo en espiral

3.1.1 Descripción de Iteraciones realizadas

Iteración No.1 Inicio del trabajo de grado estableciendo educción de requisitos y entiendo funcionamiento de Zathuracode

Artefactos de Entrada: 1. Planteamiento del problema

1. Marc 2. Marco teórico del anteproyecto

Descripción:

Planeación: Se realizó una lluvia de ideas y una reunión con los ingenieros de sistemas de la empresa Vortexbird y una reunión con el director de tesis, para tener un cronograma y unos temas a consultar para la realización de un marco teórico del proyecto. Se realizó una revisión de la documentación existente sobre arquitecturas basadas en microservicios, casos de éxito, sus bases arquitectónicas provenientes de la arquitectura orientada a servicios, y su ecosistema. También, se estudió la arquitectura del generador de código en Java Zathuracode y tecnologías relacionadas para su futura modificación como Velocity.

Diseño: Se realizó el primer bosquejo del diseño de la arquitectura de Zathuracode orientado a microservicios. Construcción: Se estudió y modificó parte del código fuente de Zathuracode, para aprender su funcionamiento y estructura interna.

24

Retroalimentación: Se analizó la información obtenida en los pasos anteriores para definir los siguientes temas a estudiar, para ayudar en el desarrollo del componente de microservicios de Zathuracode. Comunicación: Se informó al director y codirector por medio de una reunión presencial sobre los resultados obtenidos hasta el momento del trabajo de grado.

Artefactos de Salida:

1. Documentación. 2. Lista de referencias de autores sobre microservicios. 3. Lluvia de ideas de la reunión con el grupo focal. 4. Vídeo del funcionamiento interno de Zathuracode. 5. Bosquejo del nuevo estilo arquitectónico. 6. Código fuente modificado.

Iteración No.2 Investigando sobre generación de entidades e inicio desarrollo del componente.

Artefactos de Entrada:

1. Documentación. 2. Lista de referencias de autores sobre microservicios. 3. Lluvia de ideas de la reunión con el grupo focal. 4. Vídeo del funcionamiento interno de Zathuracode. 5. Bosquejo del nuevo estilo arquitectónico. 6. Código fuente modificado.

Descripción:

Planeación: Analizando la información obtenida en la iteración 1, se realizó una consulta bibliográfica sobre otros generadores de código en Java existentes, así como otras formas de configuración de conexión de las entidades en Java con las bases de datos (Anotaciones JPA vs configuración XML de Hibernate). Diseño: Se escogió un protocolo de comunicación REST para el consumo de los microservicios. Construcción: Se construyeron los servicios REST, los cuales son la base para la creación de una API REST que comunicará los microservicios con el “exterior”. Retroalimentación: Se analizó la información obtenida en los pasos anteriores para definir los siguientes temas a estudiar, para ayudar en el desarrollo del componente de microservicios de Zathuracode. Comunicación: Se informó al director y codirector por medio de una reunión presencial sobre los resultados obtenidos hasta el momento del trabajo de grado.

Artefactos de Salida: 1. Artículos de sobre las anotaciones JPA. 2. Código fuente de la primera versión de los servicios REST.

25

Iteración No.3 Desarrollo de mapeadores necesario para la comunicación de los servicios, modificación de la lógica y finalización de desarrollo del componente.

Artefactos de Entrada:

1. Documentación. 2. Código fuente de la primera versión de los servicios REST. 3. Vídeo del funcionamiento interno de Zathuracode. 4. Artículos de sobre las anotaciones JPA.

Descripción:

Planeación: Analizando la información obtenida en la iteración 2, se realizó una consulta bibliográfica sobre los mapeadores de objeto relacionales, los cuales ayudarían a simplificar la comunicación de los servicios. También se realizó la documentación sobre casos de pruebas del trabajo de grado y marco teórico. Diseño: Se diseñó un mapeador propio para Zathuracode. Construcción: Se construyó el mapeador objeto relaciones para los servicios REST y se incluyeron los mapeadores a la capa de lógica de negocio de la Zathuracode. Retroalimentación: Se analizó la información obtenida en los pasos anteriores para definir los siguientes temas a estudiar, para ayudar en el desarrollo del componente de microservicios de Zathuracode. Comunicación: Se informó al director y codirector por medio de una reunión presencial sobre los resultados obtenidos hasta el momento del trabajo de grado.

Artefactos de Salida: 1. Consulta bibliográfica de los mapeadores de objeto relacional. 2. Código fuente de los mapeadores objeto relacional en la capa de

lógica de negocio y microservicios.

Iteración No.4 El componente seleccionable dentro de la interfaz para elegir si se desea generar el código sin capa de presentación.

Artefactos de Entrada: Los artefactos de salida de la iteración 2 y 3.

Descripción:

Planeación: Se construyó la documentación del trabajo de grado, y se entregó para una verificación y correcciones internas por parte del director y codirectora de tesis. Diseño: Se diseñó una funcionalidad para elegir generar el código de la aplicación con o sin capa de presentación. Construcción: Se construyó la funcionalidad para la generación opcional de la capa de presentación, se integró el componente de microservicios del motor Jender a los dos motores restantes de Zathuracode SkyJet y WallJ.

26

Retroalimentación: Se analizó la información obtenida en los pasos anteriores para definir los siguientes temas a estudiar, para ayudar en el desarrollo del componente de microservicios de Zathuracode. Comunicación: Se informó al director y codirector de tesis los resultados obtenidos hasta el momento.

Artefactos de Salida:

1. Documento de grado. 2. Zathuracode con la funcionalidad nueva de generación de proyectos

con estilo arquitectónico orientado a microservicios. 3. Funcionalidad de generar proyectos con o sin capa de presentación.

Iteración No.5 Pruebas y ajustes de la versión 6.0 de Zathuracode

Artefactos de Entrada: 1. Zathuracode con la funcionalidad nueva de generación de proyectos

con estilo arquitectónico orientado a microservicios. 2. Funcionalidad de generar proyectos con o sin capa de presentación.

Descripción:

Planeación: Se planearon cuáles serán los casos de pruebas a realizar. Diseño: Se diseñaron los casos de pruebas y las iteraciones a realizar. Construcción: Se ejecutaron las pruebas de la nueva versión de Zathuracode, con los resultados obtenidos se realizaron ajustes y una nueva iteración de las pruebas. Retroalimentación: Se analizó resultados obtenidos y se llegó a la conclusión que la nueva versión de Zathuracode está estable para su salida a producción. Comunicación: Se informó al director y codirector de tesis los resultados obtenidos hasta el momento.

Artefactos de Salida: 1. Zathuracode versión 6.0

En la figura 10 se ilustra el modelo en espiral con las iteraciones específicas del trabajo de grado.

27

Figura 10 Modelo En Espiral

28

3.2 Educción de Requisitos

PERSONAS:

• Ing. Juan Camilo Puente.

• Ing. Cesar Augusto Lopez.

• Ing. Mauricio Muñoz.

• Ing. Diego Armando Muñoz.

• Ing. Diego Armando Gomez

DOCUMENTOS:

• Migrando a microservicios. [19]

• Patrón: Arquitectura en microservicios. [20]

• Que son los microservicios. [21]

• Arquitectura Basada en Microservicios. [16].

• Arquitectura de Microservicios es una arquitectura de software ágil. [22]

3.2.1 Técnica utilizada: Grupo Focal

Se realizó un grupo focal con la participación de las como técnica de asistencia se usó una lluvia de ideas, para guiar esta lluvia de ideas se usó la pregunta ¿Qué necesita Zathuracode para agregar un componente que permita generar proyectos con estilo arquitectónico en microservicios? para el proceso de reducción de requisitos, las ideas obtenidas con el grupo fueron las siguientes:

1. Generar el código de las aplicaciones con controladores REST que sean consumidos como microservicios.

2. Generar entidades con validaciones de Hibernate.

3. Agregar un componente que permita generar el código sin la capa de presentación.

4. Para las entidades generar 5 microservicios que permitan crear un registro de la

entidad o tabla, modificarlo, borrarlo, consultar por llave primaria y consultar todos los registros de la tabla.

5. Para los controladores es necesario un controlador que mapeadores de objetos de

transferencia de datos (DTO) a entidades y viceversa.

6. Generar el código de aplicaciones con Gradle.

3.2.2 Técnica utilizada: lectura basada en perspectivas

29

Se revisaron las fuentes y no se encontraron requisitos funcionales diferentes a los obtenidos en el grupo focal, sin embrago se obtuvo limitaciones y requisitos calidad.

3.2.3 Requisitos funcionales documentados

En la siguiente tabla [1] se relaciona la respectiva especificación de requisitos, priorización de requisitos funcionales de 5 hasta 1 siendo 5 el menos relevante para los cumplimientos de los objetivos del trabajo de grado y 1 el más relevante para el cumplimiento de los objetivos del trabajo de grado, si poseen el mismo número estos tienen el mismo nivel de prioridad:

Ref. Prioridad Descripción Requisito Fuente de Info.

RF-1 2 Zathuracode debe permitir escoger generar el código con

capa de presentación o sin ella. GRUPO FOCAL

RF-2 1 Zathuracode para la base de datos seleccionada, para

cada tabla seleccionada debe generar un microservicio con protocolo REST.

GRUPO FOCAL

RF-3 1

Zathuracode para la base de datos seleccionada, para cada tabla seleccionada debe generar una operación en el

microservicio (RF-2) que permita crear un registro de la tabla objetivo.

GRUPO FOCAL

RF-4 1

Zathuracode para la base de datos seleccionada, para cada tabla seleccionada debe generar una operación en el microservicio (RF-2) que permita actualizar un registro de

la tabla objetivo.

GRUPO FOCAL

RF-5 1

Zathuracode para la base de datos seleccionada, para cada tabla seleccionada debe generar una operación en el microservicio (RF-2) que permita borrar un registro de la

tabla objetivo.

GRUPO FOCAL

RF-6 1

Zathuracode para la base de datos seleccionada, para cada tabla seleccionada debe generar una operación en el microservicio (RF-2) que permita consultar un registro de

la tabla por su llave primaria objetivo.

GRUPO FOCAL

RF-7 1

Zathuracode para la base de datos seleccionada, para cada tabla seleccionada debe generar una operación en el

microservicio (RF-2) que permita consultar todos los registros de una tabla objetivo.

GRUPO FOCAL

RF-8 4 Zathuracode debe leer los atributos de las tablas

seleccionadas de la base de datos. GRUPO FOCAL

30

RF-9 5

Zathuracode debe leer las restricciones de los atributos recogidos (RF-9) y en caso de tener dicha restricción

escribirle la restricción, la lista de las restricciones serán: -@NotNull -@IsEmpty

-@Size(max= (Tamaño Maximo)) -@Id

GRUPO FOCAL

RF-10 3 Zathuracode debe generar mapeadores que permitan

convertir un objeto de entidad a un objeto de transferencia de datos (DTO).

GRUPO FOCAL

RF-11 3 Zathuracode debe generar mapeadores que permitan

convertir un objeto de entidad a un objeto de transferencia de datos (DTO).

GRUPO FOCAL

Tabla 1 Especificación y priorización de requisitos funcionales

3.3 Análisis y Diseño 3.3.1 Objetivos de Arquitectura y Limitaciones.

En la tabla 2 se listarán las limitaciones del proyecto de Zathuracode (estas solo definirán las que tengan que ver con la versión creada a partir de este documento).

Ref. Descripción Requisito

LIM-1 Zathuracode solo puede elegir entre 2 motores de ingeniería inversa de JPA o Hibernate.

LIM-2

Para la base de datos seleccionada, para las tablas seleccionadas de la base de datos las capas generadas por Zathuracode serán Objeto de accesos a datos (DAO), Objetos de transferencia de datos (DTO), controladores rest (microservicios), lógica y capa de presentación (si selecciono que genere presentación).

LIM-3 Los proyectos del espacio de trabajo a elegir solo pueden ser proyectos con maven.

LIM-4 La anotación de validación de campo vacío solo se aplica a atributos de tipo de texto.

LIM-5 Todos los microservicios se van a generar en una capa independiente.

31

LIM-6 Para la comunicación de los microservicios generados será con json.

LIM-7

Para la usar la operación de crear por medio del microservicio es necesario enviar el objeto de transferencia de esa entidad con todos sus atributos es decir si la tabla cliente con las columnas de cliId, cliNombre, cliTelefono y cliMail el objeto de transferencia de datos tendrá que tener los atributos cliId, cliNombre, cliTelefono y cliMail.

LIM-8

Para la usar la operación de modificar por medio del microservicio es necesario enviar el objeto de transferencia de esa entidad con todos sus atributos es decir si la tabla cliente con las columnas de cliId, cliNombre, cliTelefono y cliMail el objeto de transferencia de datos tendrá que tener los atributos cliId, cliNombre, cliTelefono y cliMail.

LIM-9

Para la usar la operación de borrar por medio del microservicio es necesario enviar el objeto de transferencia de esa entidad con todos sus atributos es decir si la tabla cliente con las columnas de cliId, cliNombre, cliTelefono y cliMail el objeto de transferencia de datos tendrá que tener los atributos cliId, cliNombre, cliTelefono y cliMail.

LIM-8 Para la usar la operación de consultar todos los registros no es necesario enviar nada, solo llamar la operacion.

LIM-10 Para la usar la operación de consultar un registro por medio del microservicio es necesario enviar la llave primaria de la entidad.

LIM-11

Para la usar la operación de consultar un registro por medio del microservicio si es una llave primaria compuesta entonces deberá enviar un objeto de transferencia de datos (DTO) con los atributos es decir si la tabla cliente tiene como llave primaria compuesta las columnas de cliId y cliTipoDocumento el objeto de transferencia de datos tendrá que tener los atributos cliId y cliTipoDocumento.

Tabla 2 Limitaciones de Zathuracode

3.3.2 Requisitos No Funcionales. Basados en la norma ISO/IEC 9126 ISO/IEC 25030:2007 se definieron los atributos de calidad que deben garantizarse la versión 6.0 de Zathuracode Ejemplo.

Ref. Descripción Requisito

RFN-1

Mantenibilidad: Es la propiedad de un sistema que representa la cantidad de esfuerzo requerida para conservar su funcionamiento normal o para restituirlo una vez se ha presentado un evento de falla, para asegurar este atributo de calidad se exige que los proyectos a los cuales se les va a generar el código sean proyectos maven para que maven sea el encargado de gestionar las librerías de este, un ejemplo claro es cuando se van actualizar las librerías solo es ingresar la versión de la nueva librería en el pom.xml que Zathuracode genera.

32

RFN-2

Usabilidad: Es la capacidad de un sistema para ser entendido, atractivo, usado y aprendido, las pantallas del generador de código fueron diseñadas para ser entendibles por el usuario promedio siendo muy específico en las diferentes opciones que tiene y es fácilmente operable.

RFN-3 Portable: Es la habilidad del software para ser transferido de un ambiente a otro y funcionar en este, gracias a que Zathuracode es un plugin es portable y se puede usar en diferentes entornos de desarrollo.

Tabla 3 Matriz de especificación y clasificación de requisitos no funcionales.

3.4 Diseño de la Arquitectura.

Sera ideal aclarar que la arquitectura de Zathuracode no se modificó lo que se modifica son los estilos arquitectónicos de los proyectos/aplicaciones generadas por Zathuracode. Las aplicaciones generadas por el Zathuracode, manejan un estilo arquitectónico por capas las cuales se encuentran definidas en: Presentación, lógica, persistencia e integración. Esta división por capas, permite la reutilización de componentes, fácil mantenimiento, escalabilidad y mejora la seguridad del sistema. Como podemos ver en la siguiente imagen era la antigua arquitectura que se creaba con Zathuracode antes de implementarse el componente de microservicios 11:

Figura 11 Arquitectura de Zathuracode anterior a los microservicios.

Los estilos arquitectónicos de aplicaciones generadas por Zathuracode se modificaron y ahora se puede apreciar de dos maneras, una que contiene la capa de presentación Figura 3.4.2, y otra sin la capa de presentación Figura 12, las dos formas tienen ya una API REST para comunicarse con los servicios (o microservicios según es estilo arquitectónico que elija el usuario):

33

Figura 12 Arquitectura de Zathuracode con capa de presentación y API REST.

Figura 13 Arquitectura de Zathuracode sin capa de presentación y API REST.

Las figuras 14 y 15 son diagramas de actividades representan el proceso que se realiza a nivel de usuario y a nivel de aplicación en la versión anterior al desarrollo del trabajo de grado (Versión 5.2) y en su nueva versión (Versión 6.0), para el generador de código Zathuracode en lenguaje de programación Java:

34

Figura 14 Diagrama actividades Zathuracode versión 5.2.

35

Figura 15 Diagrama actividades Zathuracode versión 6.0.

36

3.5 Patrones de Diseño Utilizados

La estructura generada por Zathuracode incluye una diversa serie de patrones de diseño, los cuales son muy usados en la industria del software, pero solo se mencionaran los patrones utilizados para el nuevo componente de Zathuracode:

• Patrón DTO (Data Transfer Object): Es un patrón usado para transportar objetos entre procesos. La motivación de su uso está relacionada con el hecho que la comunicación entre procesos es realizada por interfaces, donde cada llamada es una operación costosa; pero más que reducir el costo, un objeto del patrón de DTO es una copia de las entidades y eso es lo que mandamos a comunicar en el microservicio. Con esto evitamos enviar directamente la entidad y exponer el modelo de datos y modelo de negocio. [19]

3.6 Justificación de Diseño

Zathuracode en su versión 5.2 (anterior a este trabajo) permite generar proyectos maven con arquitectura en capas: DAO, lógica y presentación, dando cumplimiento al requisito funcional No. 1 (Mantenibilidad). Para esta nueva versión 6.0, el objetivo fue que Zathuracode sea capaz de generar proyectos con arquitectura en microservicios; para esto era necesario generar los proyectos sin la capa de presentación y con los controladores REST funcionando como los microservicios; sin embargo, como en las aplicaciones generadas por Zathuracode está presente la capa de presentación, la arquitectura generada es una arquitectura por capas con microservicios. Por lo anterior se llegó a la conclusión que, para la nueva arquitectura, era necesario que el usuario definiera, a través de una selección, el curso de la arquitectura a tomar. Es decir, si el usuario decide tener una capa de presentación, la arquitectura generada es una arquitectura de capas con microservicios (DAO, lógica, controladores REST y presentación). Si el usuario decide no tener una capa de presentación, la arquitectura generada es una arquitectura de microservicios (DAO, lógica, controladores REST). Lo anterior asegura que Zathuracode tiene la capacidad de generar aplicaciones en 2 tipos de arquitecturas distintas.

37

3.7 Desarrollo

3.7.1 Tecnologías utilizadas

Las siguientes tecnologías han sido escogidas como resultado de nuestra investigación sobre microservicios, nuestra experiencia laboral, académica y, las restricciones que nos impone el uso de Zathuracode, ya que al ser un plugin de eclipse existente sobre el cual vamos a trabajar, debemos usar su ecosistema tecnológico para su desarrollo.

• Github 2017: Es una plataforma de desarrollo en la cual se puede alojar en repositorios nuestro el código fuente de proyectos de software, con un historial de versiones y, herramientas de foros u otras herramientas colaborativas. [20]

• Eclipse Mars: IDLE de desarrollo en Java, el cual sirve para crear plugin para él mismo (Zathuracode se distribuye como un plugin para Eclipse). [21]

• The Apache Velocity Project 1.7: Es un motor para la generación de plantillas basadas en Java. Con este motor, se pueden crear tanto plantillas para correos electrónicos, como plantillas de capas en Java, como DAO’s, Servicios, Vistas XHTML, entre otras. [22]

• JavaEE 8: Es un estándar de software empresarial manejado por la comunidad Java. En él se especifican diferentes estándares de codificación o arquitectura de componentes web en Java. [23]

• Hibernate 5.1.3: Es una herramienta de mapeo objeto-relacional, que nos permite realizar una ingeniería inversa de nuestros modelos de la base de datos, a entidades Java (POJOS). [24]

• Tomcat 8.0.42: Es un contenedor de aplicaciones que implementa el estándar de Java servlets, JavaServer Pages, Java Expression Language y Java Websockets technologies. Tomcat es un software de código abierto, y aunque en un principio de su desarrollo era recomendado para usar en etapa de desarrollo y aplicación pequeñas en producción, actualmente es muy usado en la industria de software en una gran variedad de tipo de aplicaciones, desde aplicaciones de misión crítica y gran escala, hasta pequeñas y medianas empresas. [25]

3.7.2 Tecnologías utilizadas y su Relación con los Atributos de Calidad.

La tecnología más relacionada con el atributo de calidad de mantenibilidad es Apache Velocity que nos permite fácilmente crear plantillas de código fuente que luego son exportadas a su extensión ejemplo el .xml, .java, .xhtml entre otros; Maven es una herramienta que permite gestionar las librerías de un proyecto Java, como funciona se hizo una plantilla llamada “pom.xml” la cual contiene las versiones de librerías que se usaran para el funcionamiento del proyecto de modo que solo es cambiar el número de la versión en la plantilla que Apache Velocity genera, cuando el proyecto termina de generar es Maven quien se encarga de buscar en línea y descargar la librería con la versión indicada, no sobra resaltar que Maven no se encuentra como tecnología utilizada ya que esta hace parte del proyecto generado mas no de Zathuracode.

38

3.8 Prototipos del Software

En esta sección se presentará el prototipo de pantalla solo de la pantalla modificada para el desarrollo del nuevo componente, los demás prototipos de pantallas se encontrarán en la sección de anexos en el punto 6.1.

3.8.1 Prototipos Zathuracode Versión 5.2

A continuación, se mostrarán las pantallas que posee Zathuracode en su versión 5.2 (versión anterior a la realización de este trabajo de grado:

Escena que representa: Selección proyecto, paquetes y motor de ingeniería inversa Funcionalidades: Lista los proyectos maven que se encuentran en el “workspace”, muestra el

contenido del proyecto para ser seleccionado y los motores de ingeniería inversa.

Zathuracode Versión 5.2 No. 3 – Selección proyecto, paquetes y motor de ingeniería inversa.

39

Tipo Usuario: Usuario.

3.8.2 Prototipos Zathuracode Versión 6.0

Ahora se presentan las pantallas de la versión 6.0 (versión realizada en este proyecto de grado)

Escena que representa: Selección proyecto, paquetes y motor de ingeniería inversa. Funcionalidades: Lista los proyectos maven que se encuentran en el “workspace”, muestra el

contenido del proyecto para ser seleccionado, los motores de ingeniería inversa y un cuadro seleccionable para generar código con Frontend (Arquitectura de capas con microservicios) o solo con Backend (Arquitectura de microservicios).



40

3.9 Pruebas y Evaluación de Software

A continuación, se muestran los casos de pruebas funcionales basadas en pruebas de caja negra, se aplicó la técnica de particiones de equivalencia.

3.9.1 Casos de Prueba Los casos de prueba especificados se describen en las tablas 4 - 17.

ITERACIÓN 1

ID CP-1

Nombre del Caso de Prueba: Generar proyectos sin capa de presentación y API REST.

Proceso o Funcionalidad: Creación de un proyecto con Zathuracode sin capa de presentación y API REST.

Descripción: Generar un proyecto con Zathuracode y no seleccionar la opción generar con frontend

ID de los Requisitos Relacionados: RF-1 Tipo de Prueba:

Positiva

Pasos para Ejecución:

1. Seleccionar la conexión a la base de datos. 2. Seleccionar el esquema de la base de datos. 3. Seleccionar las tablas deseadas. 4. Seleccionar las carpetas de configuración del

proyecto Java. 5. Seleccionar el motor de ingeniería inversa

Hibernate. 6. No seleccionar la casilla generar con capa de

presentación. 7. Seleccionar el motor Jender. 8. Dar clic en generar.

Variables de Entrada: Metadata de hibernate Valor de la casilla generar con frontend = false Motor elegido Jender

Resultados Esperados: Estructura por capas de un proyecto Java web, con sus capas de API REST, Lógica, Persistencia e Integración.

Observaciones: Técnica aplicada Particiones de equivalencia.

Estado: CUMPLE Tipo de Error:

Tabla 4 Caso de prueba 1

41

ID CP-2

Nombre del Caso de Prueba: Generar proyectos con capa de presentación y API REST.

Proceso o Funcionalidad: Creación de un proyecto con Zathuracode con capa de presentación y API REST.

Descripción: Generar un proyecto con Zathuracode y seleccionar la opción generar con frontend


Positiva




Hibernate. 6. Seleccionar la casilla generar con capa de


Variables de Entrada: Metadata de hibernate Valor de la casilla generar con frontend = true Motor elegido Jender

Resultados Esperados: Estructura por capas de un proyecto Java web, con sus capas de Presentación, API REST, Lógica, Persistencia e Integración.


Estado: NO CUMPLE Tipo de Error:

Bloqueante


42

ID CP-3





Positiva



proyecto Java. 5. Seleccionar el motor de ingeniería inversa JPA. 6. No seleccionar la casilla generar con capa de

presentación. 7. Seleccionar el motor SKYJET. 8. Dar clic en generar.






43

ID CP-4





Positiva











44

ID CP-5





Positiva




presentación. 7. Seleccionar el motor WallJ. 8. Dar clic en generar.






45

ID CP-6





Positiva






Variables de Entrada: Metadata de hibernate Valor de la casilla generar con frontend = true Motor elegido WallJ





46

ID CP-7

Nombre del Caso de Prueba: Integrar 2 microservicios generados con Zathuracode, en un proyecto con un estilo arquitectónico orientado a microservicios

Proceso o Funcionalidad: Generar un proyecto con al menos 2 microservicios generados en Zathuracode, para realizar prueba de alta disponibilidad

Descripción: Generar un proyecto con al menos 2 microservicios generados en Zathuracode con la arquitectura Jender

ID de los Requisitos Relacionados: RF-1, RF-2, RF-3, RF-4, RF-5, RF-6 Tipo de Prueba:

Positiva




Hibernate. 6. Seleccionar la casilla generar frontend. 7. Seleccionar el motor Jender. 8. Dar clic en generar. 9. Crear 3 proyectos, uno principal el cual se pueda

comunicar con otros dos proyectos generados (microservicios) solo con backend, interrumpir el funcionamiento de uno de los dos microservicios.

Variables de Entrada:

Metadata de hibernate. Valor de la casilla generar con frontend = false para generar los dos proyectos sin capa de presentación, Y con frontend = true, para general un proyecto con capa de presentación. Motor elejido Jender.

Resultados Esperados: Al estar corriendo la aplicación principal y detener uno de los dos microservicios, estos no van a interrumpir el funcionamiento de la aplicación principal.

Observaciones:



47

ITERACIÓN 2

ID CP-1





Positiva




Hibernate. 14. No seleccionar la casilla generar con capa de







48

ID CP-2





Positiva











49

ID CP-3





Positiva




presentación. 15. Seleccionar el motor SKYJET. 16. Dar clic en generar.






50

ID CP-4





Positiva











51

ID CP-5





Positiva




presentación. 15. Seleccionar el motor WallJ. 16. Dar clic en generar.






52

ID CP-6





Positiva






Variables de Entrada: Metadata de hibernate Valor de la casilla generar con frontend = true Motor elegido WallJ





53

ID CP-7

Nombre del Caso de Prueba: Integrar 2 microservicios generados con Zathuracode, en un proyecto con un estilo arquitectónico orientado a microservicios

Proceso o Funcionalidad: Generar un proyecto con al menos 2 microservicios generados en Zathuracode, para realizar prueba de alta disponibilidad

Descripción: Generar un proyecto con al menos 2 microservicios generados en Zathuracode con la arquitectura Jender

ID de los Requisitos Relacionados: RF-1, RF-2, RF-3, RF-4, RF-5, RF-6 Tipo de Prueba:

Positiva




Hibernate. 15. Seleccionar la casilla generar frontend. 16. Seleccionar el motor Jender. 17. Dar clic en generar. 18. Crear 3 proyectos, uno principal el cual se pueda

comunicar con otros dos proyectos generados (microservicios) solo con backend, interrumpir el funcionamiento de uno de los dos microservicios.

Variables de Entrada:

Metadata de hibernate. Valor de la casilla generar con frontend = false para generar los dos proyectos sin capa de presentación, Y con frontend = true, para general un proyecto con capa de presentación. Motor elejido Jender.

Resultados Esperados: Al estar corriendo la aplicación principal y detener uno de los dos microservicios, estos no van a interrumpir el funcionamiento de la aplicación principal.

Observaciones:



54

3.9.2 Resumen Pruebas Funcionales

En la primera iteración de las pruebas del caso de prueba 2, el robot Jender al generar con capa de presentación, lanzo una excepción debido a que no pudo encontrar la carpeta “WEB-INF” en la cual se guarda los contenedores de la página es decir la parte izquierda de la página, el contenido que va en la parte más baja de la página, el menú que se encuentra en la parte de arriba generado por Zathuracode; se encontró que la creación de las carpeta “facelets” que debe estar dentro de la carpeta “WEB-INF” se estaba copiando antes de la creación de la carpeta “WEB-INF”, para resolverlo se cambió de lugar en la parte del código donde se genera la carpeta “facelets” a un lugar donde se asegura que la carpeta “WEB-INF” ya sea creada.

La ejecución de los casos de prueba diseñados anteriormente, permitieron identificar que de los 7 casos de pruebas ejecutados, solo falló uno con un tipo de error bloqueante, es decir, pasaron el 85.71% de los casos de pruebas. Esto ayudó a identificar un error y corregirlo en la fase de pruebas de la primera iteración, en la segunda iteración pasaron los 7 casos de pruebas diseñados, es decir el 100% de los casos de pruebas. Los resultados obtenidos ayudaron a identificar que no existen problemas que interfieran con el buen funcionamiento del nuevo módulo de microservicios agregado a Zathuracode v. 6.0. Las evidencias de los casos de pruebas generados se encuentran en la sección de anexos punto 6.2.

3.10 Acceso a la Aplicación

Se diseñaron dos vídeos para mostrar el funcionamiento y uso de la aplicación desarrollada a manera de guía para los usuarios de la aplicación: 1. Vídeo 1: https://youtu.be/8PfNsXDpQMk.

2. Vídeo 2: https://youtu.be/xnmDhDmhPbw.

3. Aplicación (Servidor LIDIS): http://lidis.usbcali.edu.co/Proyectos/zathura.

https://youtu.be/8PfNsXDpQMk

https://youtu.be/xnmDhDmhPbw

http://lidis.usbcali.edu.co/Proyectos/zathura

55

4. ANÁLISIS DE RESULTADOS

4.1 Análisis de Impactos 4.2 Utilización de herramientas 4.3 Análisis de diseño de componentes 4.4 Cumplimiento de Objetivos 4.5 Experiencia de diseño en ingeniería de software 4.6 Trabajos Futuros

56

4. ANÁLISIS DE RESULTADOS

4.1 Análisis de Impactos

La propuesta de ingeniería discutida en el presente documento tiene diferentes impactos en el escenario en el cual se contextualiza el problema, desde las siguientes perspectivas: Ambiental, Económico, Global.

• Ambiental: El hecho de dividir una gran aplicación monolítica en varias partes (microservicios), tiene como finalidad, aparte de mejorar su escalabilidad, seguridad y mantenibilidad, el poder escalar de manera independiente cada microservicio en un servidor dedicado (no es obligación, pero es una ventaja). Esto tiene como ventaja que se pueden asignar los recursos necesarios para cada microservicio, pero también, se podría considerar que aumentaría el número de servidores ya sean físicos o virtuales, en los cuales se desplegará la aplicación, por lo tanto, aumentaría el uso energético de ésta, comparada con un único despliegue en un solo servidor (ya que al principio era solo una aplicación monolítica).

• Económico: Construir un proyecto con una arquitectura multinivel o estilo arquitectónico orientado a microservicios, tiene un tiempo de horas trabajo hombre considerable, por eso, al utilizar una herramienta que genere una buena parte del código fuente que usaremos en nuestro proyecto, supondría un ahorro económico para el desarrollo de los proyectos de software.

• Global: Zathuracode puede ser usado a nivel mundial sin ningún tipo de restricción, ya que es software libre y usa una licencia Apache 2.0. 4.2 Utilización de herramientas

• Github se utiliza como herramienta de gestión de la configuración, Zathuracode es un proyecto ya existente por lo cual se pidió permisos AUTORIZACION para realizar cambios sobre el repositorio, para subir al repositorio se creó una nueva rama llamada “testing” donde se realizaron los cambios para luego cuando la nueva versión de Zathuracode sea estable unir con la rama “master”.

• IDE Eclipse Mars debido a que en este Eclipse fue la versión en la que fue desarrollado inicialmente.

• Apache Velocity se utiliza para realizar las plantillas donde se generara el código de los mapeadores de entidades, los controladores REST, la generación de la nueva capa de lógica, las librería que utiliza el proyecto Java generado.

• Hibernate se usa como motor de ingeniería inversa para crear las entidades que pueden ser tanto las de JPA como las de Hibernate de estas entidades generadas.

• Tomcat fue usado para realizar las pruebas ya que es liviano y empaqueta de forma rápida los proyectos para probar local todo lo que se generó (Tomcat no hace parte de la generación de código, este fue instalado manualmente para realizar las pruebas).

57

4.3 Análisis de diseño de componentes

Durante el proceso de ingeniería de software realizado se utilizaron las siguientes vistas: Vista de Procesos y Vista de Desarrollo, en la cuales se permite ver el camino de ejecución de eventos que realizo por Zathuracode desde el lado del usuario y el motor de Zathuracode (ver diagramas de actividades figuras 15 y 16), así como se puede apreciar la estructura interna de Zathuracode con los nuevos componentes de microservicios (ver diagrama de componentes figura 17). El análisis y evaluación de los componentes ser realizó utilizando las técnicas de educción de requisitos expuestas en la sección 3.2 y los casos de prueba diseñados en la sección 3.9, gracias a las técnicas realizadas, se pudo diseñar, construir y evaluar el funcionamiento de los nuevos componentes que integran el generador de código Zathuracode. 4.4 Cumplimiento de Objetivos

• Se identificaron diferentes elementos para la construcción de un módulo con un estilo arquitectónico de microservicios para el generador de código Zathuracode, partiendo de diferentes fuentes bibliográficas y lluvias de ideas, obtenidas en reuniones siguiendo la técnica de grupos focales. De esta manera se cumplió el primer objetivo específico.

• Se logró diseñar y construir un componente que permitiera la generación de código en Zathuracode con un estilo arquitectónico de microservicios en Java. Para ello ser integraron nuevas tecnologías como un mapeador de objetos, una API REST y se agregaron anotaciones JPA para las entidades generadas, también, se agregó una nueva funcionalidad que permite generar proyectos con Zathuracode con una capa de presentación y sin ella. De esta manera se cumplió el segundo objetivo específico.

• Se diseñaron y aplicaron diferentes casos de pruebas para corroborar el funcionamiento del nuevo módulo de microservicios de Zathuracode, para ello, se realizó una prueba con la nueva versión de Zathuracode, con el modelo de datos de los proyectos de Glu ERP, radicación de cuentas y vin, los cuales son proyectos realizados por la empresa Vortexbird para empresas de la región del Valle del Cauca. De esta manera se cumplió el tercer objetivo específico.

4.5 Experiencia de diseño en ingeniería de software

Lo presentado en las secciones de Análisis de Impactos, Utilización de herramientas y Análisis de diseño de componentes se argumenta como una evidencia que, a lo largo del proceso de formación de la carrera de ingeniería de sistemas, culmina con esta experiencia de proyecto de grado integrando lo aprendido en el ámbito académico y profesional, se lograron alcanzar los siguientes resultados de aprendizaje:

• Habilidad para para entender el impacto de soluciones de ingeniería en un contexto global, económico, ambiental y social.

58

• Habilidad para identificar, analizar, seleccionar e integrar técnicas y herramientas de ingenierías para el desarrollo profesional de cada uno.

• Habilidad para diseñar un sistema, componente o proceso dando soluciones a necesidades, en un contexto dado.

4.6 Trabajos Futuros

Como trabajos futuros se proponen:

• Habilitar un componente para que el generador de código Zathuracode genere diferentes pruebas unitarias, que verifiquen la conexión a la base de datos, las operaciones de crear, modificar, actualizar o consultar registros de las tablas seleccionadas a generar por Zathuracode.

• En su versión 6.0 el generador de código Zathuracode genera las entidades con anotaciones de Hibernate, pero cuando se genera una entidad con atributos de tipos diferentes a los básicos de java, no emplaza los importes, debido a que esta nueva funcionalidad no hace parte del alcance inicial del componente de microservicios para el generador de código Zathuracode se propone como trabajo futuro habilitar a Zathuracode para que emplace correctamente los importes de las librerías correspondientes.

• Identificar y proporcionar soluciones a los problemas comunes que se encuentran los equipos de trabajo que implementan un estilo arquitectónico orientado a microservicios: distribución, consistencia y complejidad operacional [32].

• Agregar la funcionalidad de generación de código Java en Zathuracode con diferentes patrones de microservicios, como: Aggregator, Proxy, Chained, Branch, Shared Data, y Asynchronous Messaging [33].

59

5. REFERENCIAS

60

5. REFERENCIAS

[1] Que son los microservicios. Recurso disponible [En línea] http://microservices.io/ (Enlace existente 05/09/2016). [2] Protocolo de comunicación. Recurso disponible [En línea] http://definicion.de/protocolo-de-comunicacion/ (Enlace existente 07/01/2017) [3] Que es y para qué sirve una API. Recurso disponible [En línea] http://www.internetya.co/que-es-y-para-que-sirve-una-api/ (Enlace existente 07/01/2017) [4] Que es una erp. Recurso disponible [En línea] http://www.aner.com/que-es-un-erp.html (Enlace existente 07/01/2017) [5] Oracle Docs. DAO Pattern (Data Access Object). Recurso disponible [En línea]. http://www.oracle.com/technetwork/java/dataaccessobject-138824.html (Enlace existente 20/03/2017). [6] Real academia española. Definición de “internauta”. Recurso disponible [En línea] http://dle.rae.es/?id=LvqsKVk (Enlace existente 05/06/2016). [7] Barrie Sosinsky. Cloud Computing Bible. Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256, 2011, p. 24. [8] Frank Buschmann Regine Meunier Hans Rohnert Peter Sornmerlad Michael Stal of Siemens AG, Germany. Pattern - Oriented Software Architecture A System of Patterns. JOHN WlLEY & SONS Chichester . New York . Brisbane . Toronto . Singapore 1996, p. 31. [9] Martin Fowler. Definición de “arquitectura de microservicios”. Recurso disponible [En línea] http://martinfowler.com/articles/microservices.html#footnote-etymology (Enlace existente 05/06/2016). [10] Generador de código para JavaEE. Zathuracode. Recurso disponible [En línea] http://zathuracode.org/ (Enlace existente 05/06/2016). [11] ¿What is software architecture? Recurso disponible [En línea] https://msdn.microsoft.com/en-us/library/ee658098.aspx (Enlace existente 05/03/2016). [12] HEIKO SCHULDT Database and Information Systems Group, Department of Computer Science, University of Basel, Basel, Switzerland. Multi-Tier Architecture. Comp. by: MGrahalatshmiGalleys0000874184 Date:19/11/08 Time:17:15:12 Stage:First Proof File Path://ppdys1108/Womat3/Production/PRODENV/0000000005/0000008302/0000000016/ 0000874184.3D. P. 1. [13] Leonard Richardson and Sam Ruby. RESTFul Web Services. O’Reilly. Beijing Cambridge Farnham Köln Sebastopol Tokyo. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. 2007 p. 215.

http://microservices.io/

http://definicion.de/protocolo-de-comunicacion/

http://definicion.de/protocolo-de-comunicacion/

http://www.internetya.co/que-es-y-para-que-sirve-una-api/

http://www.internetya.co/que-es-y-para-que-sirve-una-api/

http://www.aner.com/que-es-un-erp.html

http://www.oracle.com/technetwork/java/dataaccessobject-138824.html

http://dle.rae.es/?id=LvqsKVk

http://martinfowler.com/articles/microservices.html#footnote-etymology

http://zathuracode.org/

https://msdn.microsoft.com/en-us/library/ee658098.aspx

https://msdn.microsoft.com/en-us/library/ee658098.aspx

61

[14] Michael P. Papazoglou, Web Services, 1st Edition, © Pearson Education Limited 2008. What is SOAP. Recurso disponible [En línea] https://www.cs.colorado.edu/~kena/classes/7818/f08/lectures/lecture_3_soap.pdf (Enlace existente 06/06/2016). [15] Miguel Arlandy Rodríguez. SOA vs. SOAP y REST. Recurso disponible [En línea]. https://www.adictosaltrabajo.com/tutoriales/soavs-soap-rest/#03 (Enlace existente 05/06/2016). [16] Santiago Pavón Gómez, Manuel Pérez, Herrera Cuadrillero. Arquitectura Basada en Microservicios. [Universidad Politécnica de Madrid]. Madrid. 2015 p. 9. [17] ¿What is Docker? Recurso disponible [En línea] https://www.docker.com/what-docker (Enlace existente 06/06/2016). [18] Zathuracode. Recurso disponible [En línea] http://zathuracode.org/ (Enlace existente 06/06/2016). [19] Migrando a microservicios. Recurso disponible [En línea] https://dzone.com/articles/migrating-to-microservices (Enlace existente 20/03/2017). [20] Patrón: Arquitectura en microservicios. Recurso disponible [En línea] http://microservices.io/patterns/microservices.html (Enlace existente 10/01/2017). [21] Que son los microservicios. Recurso disponible [En línea] http://microservices.io/ (Enlace existente 15/01/2017). [22] Arquitectura de Microservicios es una arquitectura de software ágil. Recurso disponible [En línea] http://www.javaworld.com/article/3075880/application-development/microservice-architecture-is-agile-software-architecture.html (Enlace existente 16/01/2017). [23] Adaptando de manera sencilla con automapper nuestros data transfer objects (dto) entity framework, wcf c#. Recurso disponible [En línea] https://jhonnyslopez.wordpress.com/2012/07/14/adaptando-de-manera-sencilla-con-automapper-nuestros-data-transfer-objects-dto-entity-framework-wcf-c/ (Enlace existente 20/03/2017). [24] Github Inc. ¿Qué es Github? Recurso disponible [En línea] https://github.com/about (Enlace existente 15/03/2017). [25] Eclipse Foundation. ¿Qué es Eclipse? Recurso disponible [En línea] http://www.eclipse.org/mars/ (Enlace existente 15/03/2017). [26] The Apache Velocity Project. ¿Qué es Velocity? Recurso disponible [En línea] http://velocity.apache.org (Enlace existente 15/03/2017). [27] Oracle. ¿What is Java technology and why do I need it? Recurso disponible [En línea] https://java.com/en/download/faq/whatis_java.xml (Enlace existente 05/06/2016).

https://www.cs.colorado.edu/~kena/classes/7818/f08/lectures/lecture_3_soap.pdf

https://www.adictosaltrabajo.com/tutoriales/soavs-soap-rest/#03

https://www.docker.com/what-docker

http://zathuracode.org/

https://dzone.com/articles/migrating-to-microservices

http://microservices.io/patterns/microservices.html

http://microservices.io/

http://www.javaworld.com/article/3075880/application-development/microservice-architecture-is-agile-software-architecture.html

http://www.javaworld.com/article/3075880/application-development/microservice-architecture-is-agile-software-architecture.html

https://jhonnyslopez.wordpress.com/2012/07/14/adaptando-de-manera-sencilla-con-automapper-nuestros-data-transfer-objects-dto-entity-framework-wcf-c/

https://jhonnyslopez.wordpress.com/2012/07/14/adaptando-de-manera-sencilla-con-automapper-nuestros-data-transfer-objects-dto-entity-framework-wcf-c/

https://github.com/about

http://www.eclipse.org/mars/

http://velocity.apache.org/

https://java.com/en/download/faq/whatis_java.xml

62

[28] Hibernate ORM. ¿Qué es Hibernate? Recurso disponible [En línea] http://hibernate.org/orm/ (Enlace existente 15/03/2017). [29] Apache Tomcat. ¿Qué es Apache Tomcat? Recurso disponible [En línea]. http://tomcat.apache.org (Enlace existente 29/03/2017). [30] Building Products at SoundCloud —Part I: Dealing with the Monolith. Phil Calçado. Recurso disponible [En línea] https://developers.soundcloud.com/blog/building-products-at-soundcloud-part-1-dealing-with-the-monolith (Enlace existente 22/05/2017).

[31] Ingeniería de software: el proceso para el desarrollo de software. Alfredo Weitzenfeld Ridel y Silvia Guardati Buemo. Recurso disponible [En línea]. http://weitzenfeld.robolat.org/wp-content/uploads/2015/01/WeitzenfeldGuardatiComputacion2008.pdf (Enlace existente 22/05/2017).

[32] Microservice Trade-Offs, Martin Fowler 01 July 2015. Recurso disponible [En línea]. https://martinfowler.com/articles/microservice-trade-offs.html (Enlace existente 22/05/2017). [33] Microservice Design Patterns, Arun Gupta. Recurso disponible [En línea]. https://dzone.com/articles/microservice-design-patterns (Enlace existente 22/05/2017).

http://hibernate.org/orm/

http://tomcat.apache.org/

https://soundcloud.com/pcalcado

https://developers.soundcloud.com/blog/building-products-at-soundcloud-part-1-dealing-with-the-monolith

https://developers.soundcloud.com/blog/building-products-at-soundcloud-part-1-dealing-with-the-monolith

http://weitzenfeld.robolat.org/wp-content/uploads/2015/01/WeitzenfeldGuardatiComputacion2008.pdf

http://weitzenfeld.robolat.org/wp-content/uploads/2015/01/WeitzenfeldGuardatiComputacion2008.pdf

https://martinfowler.com/

https://martinfowler.com/articles/microservice-trade-offs.html

https://dzone.com/users/217698/arungupta.html

https://dzone.com/articles/microservice-design-patterns

63

6. ANEXOS

6.1 Prototipos de pantalla. 6.2 Casos de prueba. 6.3 Evidencia de casos de pruebas.

64

6. ANEXOS

6.1. Prototipos de pantalla. 6.1.1. Zathuracode versión 5.2

Escena que representa: Lista de todas las conexiones a la base de datos realizadas por Zathuracode.

Funcionalidades: Crear conexiones a la base de datos, editar conexión o borrar conexión a la base de datos.


Zathuracode Versión 5.2 No.1 – Conexión a la base de datos.

65

Escena que representa: Lista de todas las tablas de la base de base de datos seleccionada.

Funcionalidades: Lista los esquemas de las bases de datos, muestra las tablas disponibles para ser generadas y tablas seleccionadas.


Zathuracode Versión 5.2 No.2 – Selección de las tablas de la base de datos.

66

Escena que representa: Selección proyecto, paquetes y motor de ingeniería inversa Funcionalidades: Lista los proyectos maven que se encuentran en el “workspace”, muestra el

contenido del proyecto para ser seleccionado y los motores de ingeniería inversa.



67

Escena que representa: Lista los robots para el motor de ingeniería inversa hibernate. Funcionalidades: Lista los motores que se pueden usar para generación de código.


Zathuracode Versión 5.2 No. 4 – Robots de ingeniería inversa de hibernate.

68

Escena que representa: Lista los robots para el motor de ingeniería inversa JPA. Funcionalidades: Lista los motores que se pueden usar para generación de código.


Zathuracode Versión 5.2 No. 5 – Robots de ingeniería inversa de JPA.

69




70

6.1.2. Zathuracode versión 6.0

Escena que representa: Lista de todas las conexiones a las bases de datos realizadas por Zathuracode.

Funcionalidades: Crear conexiones a la base de datos, editar conexión o borrar conexión a la base de datos.


Zathuracode Versión 6.0 No.1 – Conexión a la base de datos.

71

Escena que representa: Lista de todas las tablas de la base de base de datos seleccionada.

Funcionalidades: Lista los esquemas de las bases de datos, muestra las tablas disponibles para ser generadas y tablas seleccionadas.


Zathuracode Versión 6.0 No.2 – Selección de las tablas de la base de datos.

72

Escena que representa: Selección proyecto, paquetes y motor de ingeniería inversa. Funcionalidades: Lista los proyectos maven que se encuentran en el “workspace”, muestra el

contenido del proyecto para ser seleccionado, los motores de ingeniería inversa y un cuadro seleccionable para generar código con Frontend (Arquitectura de capas con microservicios) o solo con Backend (Arquitectura de microservicios).



73

Escena que representa: Lista los robots para el motor de ingeniería inversa hibernate. Funcionalidades: Lista los motores que se pueden usar para generación de código.


Zathuracode Versión 6.0 No. 4 – Robots de ingeniería inversa de hibernate.

74




75




76

6.2. Evidencia de casos de prueba

ITERACIÓN 1

1.

Figura 30 Proyecto generado con motor Jender sin capa de presentación


77


78


79



80

2.

Figura 18 Proyecto generado con motor Jender y capa de presentación

81

3.

Figura 19 Proyecto generado con motor SkyJet sin capa de presentación

Figura 21 Proyecto generado con motor Skkyjet sin capa de presentación

82


83



84

4.

Figura 25 Proyecto generado con motor Skyjet con capa de presentación

85


86



87

Figura 29 Proyecto generado con motor Skyjet con capa de presentación ITERACIÓN 2

1. Los resultados obtenidos fueron idénticos al punto 1 de la primera iteración por lo cual se toma a consideración no colocarlos en este punto.

2.

88



89


90



magíster (msc)bibliotecadigital.usb.edu.co/bitstream/10819/4581/1...citar/how to cite [1]...

Documents