Gobierno de arquitecturas híbridas REST y GRAPHQL basadas en acuerdos de nivel de servicio

GOBIERNO DE ARQUITECTURAS H´ IBRIDAS REST YGRAPHQL BASADAS EN ACUERDOS DE NIVEL DE SERVICIO ANTONIO QUI ˜ NA MERA Tesis Doctoral Directores: Dr. Pablo Fern´andez Montes y Dr. Jos´e Mar´ıa Garc´ıa Universidad de Sevilla julio 2022 First published in julio 2022 by Antonio Qui˜ na Mera Copyright © MMXXII https://www.researchgate.net/profile/Antonio-Quina-Mera [email protected] This is a copyleft document but the content is copyrighted Esta tesis doctoral ha sido parcialmente financiada por la Universidad T´ ecnica del Norte, por FEDER /Ministerio de Ciencia e Innovaci´ on - Agencia Estatal de Investigaci´ on en el marco del proyecto HORATIO (RTI2018-101204-B-C21), y por la Junta de Andaluc´ ıa en los proyectos APOLO (US-1264651) y EKIPMENT-PLUS (P18-FR-2895) Dr. Pablo Fern´ andez Montes, Profesor Titular del ´ Area de Lenguajes y Sistemas Inform´ aticos de la Universidad de Sevilla y Dr. Jos´ e Mar´ ıa Garc´ ıa, Profesor Titular del ´ Area de Lenguajes y Sistemas Inform´ aticos de la Universidad de Sevilla, HACEN CONSTAR que D. Antonio Qui˜ na Mera, Profesor Titular de la Universidad T´ ecnica del Norte - Ecuador, ha realizado bajo nuestra supervisi´ on el trabajo titulado Gobierno de arquitecturas h´ıbridas REST y GraphQL basadas en acuerdos de nivel de servicio Una vez revisado, autorizamos el comienzo de los tr´ amites para su presentaci´ on como Tesis Doctoral al tribunal que ha de juzgarlo. Fdo. Dr. Pablo Fern´ andez Montes y Dr. Jos´ e Mar´ ıa Garc´ ıa en la Universidad de Sevilla 19/07/2022 II AGRADECIMIENTOS III En primer lugar, agradezco a Dios por ser la base y gu´ ıa de mi vida, por darme la oportunidad de compartir con personas estupendas que de manera generosa desde sus espacios me han brindado su ayuda, experiencia y conocimientos para el culmino de este reto acad´ emico. A mis directores de tesis. A Pablo, por compartir su vasta experiencia en esta disciplina, y por impregnar su sello de calidad en el trabajo realizado. A Jos´ e Mari, por su practicidad para abordar problemas y aportar soluciones brillantes. Gracias a los dos por haber hecho posible la realizaci´ on de esta tesis. A Antonio Ruiz por ser un tutor y l´ ıder excepcional en este proyecto, por confiar en m´ ı y abrirme las puertas del programa de doctorado y del grupo de investigaci´ on ISA. A mi amada esposa Cathy por ser mi compa˜ nera de viaje, gracias por tu temple e incondicionalidad para superar las pruebas que se nos ha presentado y con la bendici´ on de Dios superar las que vengan a futuro. A mi hija Antonella que con sus cuatro a˜ nos ha cambiado mi visi´ on de la vida, y por ser una fuente inagotable de cari˜ no y ocurrencias que refresca, calma, y alborota mis d´ ıas, pero siempre alimenta mis ganas de seguir a delante. A mi madre Corita por estar siempre all´ ı alent´ andome para alcanzar mis sue˜ nos, a toda mi familia por su aliento, paciencia, y comprensi´ on por el tiempo no compartido. Destacar un agradecimiento especial a la Universidad T´ ecnica del Norte y sus autoridades por brindar las condiciones necesarias para la profesionalizaci´ on de sus profesores y as´ ı contribuir al crecimiento de la calidad en la educaci´ on superior de nuestro pa´ ıs. IV RESUMEN V En esta memoria, se presenta un trabajo de investigaci´ on con el objetivo de fomentar la gobernanza de arquitecturas h´ ıbridas REST y GraphQL basadas en acuerdos de nivel de servicio. En donde, se han desarrollado doce cap´ ıtulos estructurados en seis partes. Parte I: Introducci´on, contiene el planteamiento del problema y la metodolog´ ıa de investigaci´ on. Parte II: Estado de la cuesti´on, contiene b´ asicamente el estado de GraphQL y los acuerdos de nivel de servicios. Parte III: Propuesta, contiene por un lado, dos dise˜ nos experimentales para comprobar los efectos de las arquitecturas REST, GraphQL, e h´ ıbrida REST/GraphQL en la calidad de software. Por otro lado, la descripci´ on de un est´ andar denominado SLA4GraphQL para modelar y operativizar acuerdos de nivel de servicio (SLA) para APIs GraphQL. Parte IV: Validaci´on, contiene la validaci´ on de las propuestas expuestas en la parte III. Parte V: Conclusiones del estudio. Y finalmente Parte VI: Anexos. La importancia de elaborar un est´ andar para modelar y operativizar SLA ha sido motivado por tres aspectos. Primero, debido a que no existe en la comunidad cient´ ıfica una propuesta para modelar y operativizar acuerdos de nivel de servicio de una manera estandarizada. Segundo la importancia de proponer un ciclo de vida para el desarrollo de APIs basado en SLA. Tercero facilitar una herramienta que valide la especificaci´ on de documentos SLA basados en un est´ andar. La validaci´ on del est´ andar SLA4GraphQL consisti´ o en evaluar la viabilidad, flexibilidad y la idoneidad funcional mediante la instanciaci´ on del est´ andar en varios casos de APIs p´ ublicas. El resultado de la validaci´ on indica que el est´ andar SLA4GraphQL es viable, flexible, y tiene una idoneidad del 92.33% para modelar acuerdos de nivel de servicios para APIs GraphQL. VI ABSTRACT VII This document presents research work to promote the governance of hybrid REST and GraphQL architectures based on service-level agreements. Twelve chapters structured in six parts have been developed. Part I: Introduction, contains the problem statement and the research methodology. Part II: State of the art, basically includes the state of GraphQL and service level agreements. Part III: Proposal, contains, on the one hand, two experimental designs to test the effects of REST, GraphQL, and hybrid RES- T/GraphQL architectures on software quality. On the other hand, the description of a standard called SLA4GraphQL for modeling and operationalizing service level agreements (SLA) for GraphQL APIs. Part IV: Validation, contains the validation of the proposals presented in Part III. Part V: Conclusions of the study. And finally, Part VI: Annexes. The importance of developing a standard for modeling and operationalizing SLA has been motivated by three aspects. First, there is no proposal in the scientific community to model and operationalize SLAs in a standardized way. Second, the importance of proposing a lifecycle for API development based on SLAs. Third, to provide a tool to validate the specification of SLA documents based on a standard. The validation of the SLA4GraphQL standard consisted of assessing the feasibility, flexibility, and functional suitability by instantiating the standard in several instances of public APIs. The result of the validation indicates that the SLA4GraphQL standard is feasible, flexible, and has suitability of 92.33% for modeling service level agreements for GraphQL APIs. ´ INDICE GENERAL 9.2.3. Recolecci´ ondedatos.......................... 143 9.3. Resultados.................................... 144 9.3.1. Estad´ ısticadescriptiva......................... 144 9.3.2. Prueba de hip´ otesis........................... 148 9.4. Amenazasalavalidez ............................. 150 9.4.1. Validezinterna ............................. 150 9.4.2. Validezexterna ............................. 151 9.4.3. Validez de constructo . . . . . . . . . . . . . . . . . . . . . . . . . 151 9.4.4. Validez de la conclusi´ on........................ 152 9.5. Conclusiones y trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . 152 9.5.1. Conclusiones .............................. 152 9.5.2. Trabajofuturo.............................. 153 9.6. Resumen..................................... 153 10. Efectos de las arquitecturas h´ıbridas: Validaci´on 155 10.1. Introducci´ on................................... 156 10.2. Ejecuci´ ondelexperimento........................... 156 10.2.1.Muestra ................................. 156 10.2.2. Preparaci´ on ............................... 156 10.2.3. Recolecci´ ondedatos.......................... 158 10.3.Resultados.................................... 159 10.3.1. An´ alisis estad´ ıstico de la eficiencia . . . . . . . . . . . . . . . . . . 159 10.4.Amenazasalavalidez ............................. 161 10.4.1.Validezinterna ............................. 161 10.4.2.Validezexterna ............................. 162 XIV ´ INDICE GENERAL 10.4.3. Validez de constructo . . . . . . . . . . . . . . . . . . . . . . . . . 162 10.4.4. Validez de la conclusi´ on........................ 162 10.5. Conclusiones y trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . 163 10.5.1.Conclusiones .............................. 163 10.5.2.Trabajofuturo.............................. 164 10.6.Resumen..................................... 164 11. Acuerdos de nivel de servicio para APIs GraphQL: Validaci´on 165 11.1. Introducci´ on................................... 166 11.2. Dise˜ no de la validaci´ on............................. 166 11.2.1. Dise˜ no .................................. 167 11.2.2. Planificaci´ on, recopilaci´ on y an´ alisis................. 169 11.2.3. An´ alisis e informe conjunto . . . . . . . . . . . . . . . . . . . . . . 170 11.3. Evaluaci´ ondeViabilidad............................ 170 11.3.1. Definici´ on de los aspectos de viabilidad . . . . . . . . . . . . . . . 171 11.3.2. Caso: API GraphQL de CommerceTools . . . . . . . . . . . . . . . 171 11.4. Evaluaci´ ondeFlexibilidad........................... 190 11.4.1. Definici´ on de los aspectos de flexibilidad . . . . . . . . . . . . . . 191 11.4.2. Caso: API GraphQL de GitHub . . . . . . . . . . . . . . . . . . . . 191 11.4.3. Caso: API GraphQL de GitLab . . . . . . . . . . . . . . . . . . . . 197 11.5. Evaluaci´ on de Idoniedad Funcional . . . . . . . . . . . . . . . . . . . . . 201 11.6. Conclusiones y trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . 202 11.6.1.Conclusiones .............................. 202 11.6.2.Trabajofuturo.............................. 203 11.7.Resumen..................................... 203 XV ´ INDICE GENERAL V Conclusiones 205 12. Conclusiones y trabajos futuros 207 12.1. Consecuci´ ondeobjetivos ........................... 208 12.2.Publicaciones .................................. 211 12.2.1. Revistas internacionales . . . . . . . . . . . . . . . . . . . . . . . . 211 12.2.2. Congresos internacionales . . . . . . . . . . . . . . . . . . . . . . . 212 12.2.3. Participaci´ on en proyectos de investigaci´ on............. 213 12.3.Trabajofuturo .................................. 214 VI Anexos 217 A. Estudios primarios del Mapeo Sistem´atico de GraphQL 219 B. Efectos de las arquitecturas REST y GraphQL: Paquete de laboratorio 225 B.1. Entrenamiento.................................. 225 B.1.1. Encuesta demogr´ afica/diagn´ ostica.................. 225 B.1.2. Introducci´ on te´ orica del ambiente de desarrollo . . . . . . . . . . 226 B.1.3. Introducci´ on te´ orica al paradigma REST . . . . . . . . . . . . . . . 227 B.1.4. Introducci´ on te´ orica al paradigma GraphQL . . . . . . . . . . . . 227 B.1.5. Requisitos: Gesti´ ondePizzas..................... 227 B.1.6. Requisitos: Gesti´ ondeLibros..................... 229 B.1.7. Requisitos: Gesti´ ondeBlogs ..................... 232 B.2. Experimento................................... 236 B.2.1. Requisitos: Gesti´ ondeEventos.................... 237 B.2.2. Requisitos: Gesti´ ondeFacturas.................... 240 XVI ´ INDICE GENERAL B.2.3. Requisitos: Gesti´ ondeNotas ..................... 244 B.3. An´ alisis...................................... 246 B.3.1. Encuesta de Autoevaluaci´ on ..................... 246 Bibliograf´ıa 248 XVII ´ INDICE GENERAL XVIII ´ INDICE DE FIGURAS XIX 1.1. Ejemplo de over-fetching y under-fetching de una API REST frente a unaAPIGraphQL................................ 5 1.2. Tendencia de publicaciones por a˜ no ..................... 8 1.3. Tendencia de b´ usquedas por a˜ no ....................... 9 1.4. Resumen de contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1. Resumen del proceso experimental . . . . . . . . . . . . . . . . . . . . . . 23 2.2. Modelo de proceso de investigaci´ on en ciencias del dise˜ no ........ 24 3.1. Componentes principales del paradigma GraphQL . . . . . . . . . . . . 31 3.2. Definici´ on de documentos GraphQL . . . . . . . . . . . . . . . . . . . . . 32 3.3. Definici´ on del sistema de tipos (TypeSystemDefinition) ........... 33 3.4. Ejemplo de un sistema de tipos de GraphQL . . . . . . . . . . . . . . . . 34 3.5. Definici´ on de ejecutables en GraphQL . . . . . . . . . . . . . . . . . . . . 35 3.6. Ejemplos de definici´ on de ejecutables en GraphQL . . . . . . . . . . . . . 37 3.7. Ejemplo de respuesta en GraphQL . . . . . . . . . . . . . . . . . . . . . . 37 3.8. Ejemplo de introspecci´ onenGraphQL.................... 38 3.9. Arquitectura de software del artefacto . . . . . . . . . . . . . . . . . . . . 43 3.10. Evaluaci´ on estad´ ıstica del taller pr´ actico (Alfa de Cronbach) . . . . . . . 47 3.11. Evaluaci´ on estad´ ıstica de la encuesta de aceptaci´ on (c´ alculo AFC) . . . . 47 4.1. Ciclo de vida del desarrollo de APIs impulsado por SLA . . . . . . . . . 54 ´ INDICE DE FIGURAS 5.1. Definici´ ondelprocesoSMS .......................... 63 5.2. Identificaci´ ondeestudios ........................... 64 5.3. Autores por continente y por pa´ ıs....................... 75 5.4. Publicaciones por afiliaci´ on .......................... 76 5.5. Publicaciones por tipo de sede y por tipo de publicaci´ on ......... 77 5.6. Publicaciones por tipo de investigaci´ on ................... 80 5.7. Publicaciones por m´ etodos de investigaci´ on en los tipos de investigaci´ on de validaci´ on y evaluaci´ on........................... 80 5.8. Publicaciones por tipo de investigaci´ on y por a˜ no ............. 81 5.9. Publicaciones por ´ ambito de estudio y por dominio de aplicaci´ on . . . . 81 5.10. Publicaciones por ´ areas de conocimiento de la ingenier´ ıa del software . . 82 5.11. Publicaciones por dominios de contribuci´ on ................ 82 5.12. Tipos de contribuci´ on en las publicaciones . . . . . . . . . . . . . . . . . . 83 5.13. Tipo de contribuci´ on ”Implementaci´ on” en las publicaciones . . . . . . . 83 5.14. Componentes GraphQL en publicaciones . . . . . . . . . . . . . . . . . . 85 5.15. Publicaciones por contexto de estudio, por tipo de investigaci´ on y por tipodesede ................................... 86 5.16. Publicaciones por tipo de investigaci´ on, por a˜ no y por tipo de sede . . . 88 5.17. Publicaciones por tipo de contribuci´ on, por tipo de sede y por m´ etodo de investigaci´ on................................. 89 6.1. Respuestas de la encuesta diagn´ ostica .................... 99 6.2. Diagrama relacional de la base de datos de eventos . . . . . . . . . . . . 101 6.3. Diagrama relacional de la base de datos de facturas . . . . . . . . . . . . 102 6.4. Diagrama relacional de la base de datos de notas . . . . . . . . . . . . . . 103 7.1. Arquitectura del laboratorio experimental . . . . . . . . . . . . . . . . . . 116 XX ´ INDICE DE FIGURAS 8.1. Ejemplo del proceso de Objeto Ruta . . . . . . . . . . . . . . . . . . . . . 124 8.2. Ejemplo del objeto cuotas del SLA . . . . . . . . . . . . . . . . . . . . . . 125 8.3. Ejemplo del objeto tarifas del SLA . . . . . . . . . . . . . . . . . . . . . . 126 8.4. Ciclo de vida de desarrollo de APIs GraphQL basado en SLA . . . . . . 127 8.5. Proceso del registro del SLA Plan . . . . . . . . . . . . . . . . . . . . . . . 130 8.6. Validaci´ on de cuotas y tarifas del SLA Plan . . . . . . . . . . . . . . . . . 130 8.7. Implementaci´ on y Operaci´ on del SLA Plan . . . . . . . . . . . . . . . . . 131 8.8. Arquitectura de la herramienta SLA GraphQL Manager . . . . . . . . . . 133 8.9. RegistrodelSLAPlan.............................. 135 8.10. Registro del cliente a un SLA Plan de proveedor . . . . . . . . . . . . . . 136 8.11. Consumo del API Proveedor . . . . . . . . . . . . . . . . . . . . . . . . . 137 9.1. Escala de medici´ onderesultados....................... 145 9.2. Diagrama de caja y bigotes de la completitud . . . . . . . . . . . . . . . . 146 9.3. Diagrama de viol´ ındelaeficacia ....................... 147 9.4. Tendencia de la curva de aprendizaje . . . . . . . . . . . . . . . . . . . . . 148 10.1. Proceso de ejecuci´ on del experimento . . . . . . . . . . . . . . . . . . . . 157 10.2. Ejemplo de resultados de la corrida del programa Cliente ......... 158 10.3. Ejemplo de la recolecci´ on de resultados . . . . . . . . . . . . . . . . . . . 158 10.4. Diagrama BoxPlot de medias de la eficiencia . . . . . . . . . . . . . . . . 160 10.5. Comparaci´ on del tama˜ no de respuesta entre REST/GraphQL y REST . . 161 11.1. Dise˜ no de la validaci´ on de SLA4GraphQL .................. 167 11.2. Solicitud y respuesta de generaci´ on de TOKEN de acceso. . . . . . . . . 172 11.3. Interface cliente GraphiQL Explorer de la API CommerceTools. . . . . . 172 11.4. CommerceTools: Documento SLA - configuraciones generales . . . . . . 173 XXI ´ INDICE DE FIGURAS 11.5. CommerceTools: Limitaci´ on ”JSON document size” . . . . . . . . . . . . 173 11.6. CommerceTools: Limitaci´ on ”Field content size” . . . . . . . . . . . . . . 174 11.7. CommerceTools: Limitaci´ on”Slugs” ..................... 174 11.8. CommerceTools: Limitaci´ on ”Update actions per request” . . . . . . . . 174 11.9. CommerceTools: Limitaci´ on”Queries”.................... 175 11.10.CommerceTools: Limitaci´ on ”Search and facets” . . . . . . . . . . . . . . 176 11.11.CommerceTools: Limitaci´ on ”Categories” . . . . . . . . . . . . . . . . . . 176 11.12.CommerceTools: Limitaci´ on ”Product Variants” . . . . . . . . . . . . . . 176 11.13.CommerceTools: Limitaci´ on”Prices”..................... 177 11.14.CommerceTools: Limitaci´ on ”Product Discounts” . . . . . . . . . . . . . 177 11.15.CommerceTools: Limitaci´ on”Carts” ..................... 178 11.16.CommerceTools: Limitaci´ on ”Shopping Lists” . . . . . . . . . . . . . . . 179 11.17.CommerceTools: Limitaci´ on”Zones”..................... 179 11.18.CommerceTools: Limitaci´ on ”Tax Categories” . . . . . . . . . . . . . . . . 180 11.19.CommerceTools: Limitaci´ on ”Shipping Methods” . . . . . . . . . . . . . 180 11.20.CommerceTools: Limitaci´ on ”Customer Groups” . . . . . . . . . . . . . . 180 11.21.CommerceTools: Limitaci´ on ”Customers” . . . . . . . . . . . . . . . . . . 180 11.22.CommerceTools: Limitaci´ on ”Order Edits” . . . . . . . . . . . . . . . . . 181 11.23.CommerceTools: Limitaci´ on ”Carts - discount codes” . . . . . . . . . . . 181 11.24.CommerceTools: Limitaci´ on ”Discount Codes” . . . . . . . . . . . . . . . 182 11.25.CommerceTools: Limitaci´ on”Stores”..................... 182 11.26.CommerceTools: Limitaci´ on ”Store’s Inventory Supply Channels” . . . . 182 11.27.CommerceTools: Limitaci´ on ”Store’s Product Distribution Channels” . . 183 11.28.CommerceTools: Limitaci´ on ”Store’s Product Selections” . . . . . . . . . 183 11.29.CommerceTools: Limitaci´ on ”Refresh tokens” . . . . . . . . . . . . . . . . 184 XXII ´ INDICE DE FIGURAS 11.30.CommerceTools: Limitaci´ on ”Custom Objects” . . . . . . . . . . . . . . . 184 11.31.CommerceTools: Limitaci´ on ”Product Types” . . . . . . . . . . . . . . . . 184 11.32.CommerceTools: Limitaci´ on ”Extensions” . . . . . . . . . . . . . . . . . . 185 11.33.CommerceTools: Limitaci´ on ”Subscriptions” . . . . . . . . . . . . . . . . 185 11.34.CommerceTools: Limitaci´ on ”Audit Log Records” . . . . . . . . . . . . . 185 11.35.CommerceTools: Limitaci´ on ”GraphQL - query complexity” . . . . . . . 186 11.37.CommerceTools: Instalaci´ on de la librer´ ıa sla-graphql-manager . . . . . 186 11.36.CommerceTools: Creaci´ on del proyecto NodeJS . . . . . . . . . . . . . . . 187 11.38.CommerceTools: Configuraci´ on y uso de la librer´ ıa sla-graphql-manager 187 11.39.CommerceTools: Resultado de ejecuci´ on del programa NodeJS . . . . . . 188 11.40.CommerceTools: Resultado de ejecuci´ on del programa NodeJS, con errores de validaci´ on ................................ 188 11.41.Ejemplo c´ alculo de nodos en una llamada del API GitHub. . . . . . . . . 192 11.42.Ejemplo de una consulta para el c´ alculo de puntos del API GitHub. . . . 192 11.43.Interface del cliente GraphiQL Explorer de la API GitHub. . . . . . . . . 193 11.44.GitHub: Documento SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 11.45.GitHub: Configuraci´ on y uso de la librer´ ıa sla-graphql-manager . . . . . 195 11.46.GitHub: Resultado de ejecuci´ on del programa NodeJS . . . . . . . . . . . 196 11.47.GitLab: Documento SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 11.48.GitLab: Configuraci´ on y uso de la librer´ ıa sla-graphql-manager . . . . . 200 11.49.GitLab: Resultado de ejecuci´ on del programa NodeJS . . . . . . . . . . . 200 B.1. Diagrama relacional de la base de datos Pizza . . . . . . . . . . . . . . . . 230 B.2. Diagrama relacional de la base de datos Libros . . . . . . . . . . . . . . . 232 B.3. Requisitos y registro de soluci´ on de la gesti´ on de Libros . . . . . . . . . . 232 B.4. Diagrama relacional de la base de datos Blogs . . . . . . . . . . . . . . . 235 XXIII 1 PLANTEAMIENTO DEL PROBLEMA 3 Las grandes oportunidades nacen de haber sabido aprovechar las peque˜ nas Bill Gates (1955–), Magnate empresarial estadounidense Este primer cap´ıtulo presenta el problema que se aborda en el estudio, justificando su importancia, y las razones que han motivado su investigaci´on. El trabajo comienza con la secci´on §1.1, que expone la motivaci´on y planteamiento del problema. En la secci´on §1.2, se identifica la tendencia de estudio de los paradigmas usados en las arquitecturas de software orientada a servicios y microservicios. En la secci´on §1.3, se presenta el objetivo principal de este trabajo, como tambi´en los objetivos parciales que contribuyen a alcanzar dicho objetivo principal. En la secci´on §1.4, se describe el dise˜no de la investigaci´on, y los aportes alcanzados en el desarrollo de los objetivos planteados. En la secci´on §1.5, se lista los proyectos de investigaci´on en los que se enmarc´o el presente trabajo. Finalmente, la secci´on §1.6 describe la estructura del resto de la memoria. CAP´ ITULO 1. PLANTEAMIENTO DEL PROBLEMA 1.1 MOTIVACI ´ ON Hoy en d´ ıa, el software como servicio (SaaS, por sus siglas en ingl´ es de Software as a Service) ha recibido una atenci´ on significativa como uno de los tres principales modelos de servicios que brinda la computaci´ on en nube; los otros dos modelos es la plataforma como servicio (PaaS, por sus siglas en ingl´ es de Platform as a Service), y la infraestructura como servicio (IaaS, por sus siglas en ingl´ es de Infrastructure as a Service) [108,167]. El SaaS utiliza Internet para ofrecer a sus usuarios aplicaciones en la nube, estas aplicaciones junto con su infraestructura y plataformas subyacentes son gestionadas por un proveedor de servicios [108]; en donde, los arquitectos de software deben construir SaaS fiables y eficientes que superen los importantes problemas t´ ecnicos y funcionales de las aplicaciones en la nube, como el multi-tenancy, redundancia, recuperaci´ on o escalabilidad [167]. Por lo tanto, para los usuarios la selecci´ on del mejor proveedor de SaaS entre los disponibles es una actividad cr´ ıtica [133]. Para superar estos retos, la arquitectura de microservicios representa una clara tendencia tanto en el ´ ambito acad´ emico como en el industrial [103], donde grandes empresas de todo el mundo han evolucionado sus aplicaciones hacia este estilo arquitect´ onico [28]. En concreto, la Arquitectura de Microservicios (MSA, por sus siglas en ingl´ es de Microservice Architecture) se compone de peque˜ nas aplicaciones (microservicios) con una ´ unica responsabilidad (requisitos funcionales, no funcionales o multifuncionales) que pueden ser desplegados, escalados y probados de forma independiente [7,163]. Los microservicios pueden desarrollarse y modificarse de forma independiente utilizando diferentes lenguajes de programaci´ on o frameworks de desarrollo, apoyando as´ ı la agilidad del proceso de desarrollo de software [7,69]. Sus principales ventajas son la mantenibilidad, reutilizaci´ on, escalabilidad, disponibilidad y despliegue automatizado [103]. Los microservicios se comunican a trav´ es de mecanismos ligeros, normalmente utilizando el estilo arquitect´ onico REST (por sus siglas en ingl´ es de REpresentational State Transfer) para construir interfaces de programaci´on de aplicaciones (API, por sus siglas en ingl´ es de Application Programming Interface) denominadas REST API. Las organizaciones de software han adoptado r´ apidamente las APIs REST en el desarrollo de sus aplicaciones tras su creaci´ on en el a˜ no 2000 [178]. REST es el paradigma m´ as utilizado en el desarrollo de microservicios [188]. Sin embargo, a pesar de su popularidad, presenta algunos problemas de versionamiento de sus APIs y acceso a los datos, tales como: (i) la complejidad de las consultas (es decir, REST requiere m´ ultiples peticiones HTTP para obtener m´ ultiples recursos); (ii) el 4 1.1. MOTIVACI ´ ON over-fetching (es decir, una petici´ on REST devuelve m´ as datos de los que una aplicaci´ on necesita); y (iii) el under-fetching (es decir, un endpoint concreto de una API no devuelve suficiente informaci´ on, por lo que hay que hacer peticiones adicionales para obtener la informaci´ on requerida), lo que tambi´ en se conoce en la literatura como el problema de n+1 peticiones [110,174]. Para ilustrar los problemas de over-fetching y under-fetching encontrados en REST, se considera un escenario de consumo de una API REST y una API GraphQL de consultas de Blogs. En este escenario, una aplicaci´ on cliente necesita consultar los t´ ıtulos de los Posts de un usuario espec´ ıfico y los nombres de los tres ´ ultimos seguidores de ese usuario, ver figura §1.1 [125]. Figura 1.1: Ejemplo de over-fetching y under-fetching de una API REST frente a una API GraphQL Por un lado, la figura §1.1 a) muestra la solicitud y respuesta a una API REST, que solicita datos accediendo a tres URLs (tambi´ en conocidos como endpoints). El escenario propuesto se trata de una API REST de Blogs, en donde, el endpoint /users/<id> devuelve datos del usuario; el endpoint /users/<id>/posts devuelve las publicaciones del usuario; y el endpoint /users/<id>/followers devuelve una lista de seguidores por usuario. Por otro lado, la figura §1.1 b) muestra la petici´ on y respuesta a una API GraphQL; utilizando este paradigma, el usuario puede enviar s´ olo una petici´ on con los datos espec´ ıficos que necesita, entonces el servidor responde a esta ´ unica consulta con los datos solicitados [125,174]. En consecuencia, se observa que el under-fetching en 5 CAP´ ITULO 1. PLANTEAMIENTO DEL PROBLEMA REST surge cuando la petici´ on necesita acceder a tres endpoints para obtener los requisitos de datos, mientras que en GraphQL s´ olo se necesita un acceso para obtener los datos requeridos. A su vez, el over-fetching en REST se produce cuando cada acceso a un endpoint obtiene m´ as datos de los que necesita, mientras que GraphQL s´ olo se obtiene los datos solicitados. De acuerdo con lo antes mencionado, se observa que en la ´ ultima d´ ecada han surgido varios lenguajes de consulta como SPARQL, Cypher, Gremlin y GraphQL como alternativas de REST para el acceso a datos de APIs [146]. En esta memoria, se centrar´ a en el estudio de GraphQL debido al creciente inter´ es de su aplicaci´ on en la industria, en donde se ha mostrado como una alternativa para resolver los problemas encontrados en las API REST tradicionales [146,174]. GraphQL empez´ o en 2012 como una especificaci´ on desarrollada internamente en Facebook. En 2015, Facebook decidi´ o compartir GraphQL con una comunidad m´ as amplia [101], liberando tanto la especificaci´ on de c´ odigo abierto como una implementaci´ on de referencia a trav´ es de la comunidad graphql.org1. Desde entonces, la comunidad ha crecido, as´ ı como la adopci´ on en el entorno de producci´ on por parte de cientos de organizaciones como Atlassian, GitHub, Netflix, The New York Times y Twitter, entre otras [101,115]. Motivados por la acogida de GraphQL en la industria, se realiz´ o una revisi´ on y b´ usqueda inicial de la literatura en las principales bases de datos cient´ ıficas de la ingenier´ ıa de software, en donde se analiz´ o y se evidenci´ o que: No existen estudios detallados que muestren una visi´ on global de este tema en la comunidad cient´ ıfica, y por ende, se motiva la realizaci´on de una investigaci´on sistem´atica de la literatura y un estudio profundo acerca de GraphQL. Existe la necesidad de entender a profundidad en que condiciones y circunstancias es mejor utilizar una arquitectura REST, o una arquitectura GraphQL, o una arquitectura h´ ıbrida REST y GraphQL, por tal motivo, se motiva el estudio del efecto de este tipo de arquitecturas en la calidad del software. En este sentido, se ha observado que una pr´ actica com´ un de estudio de las arquitecturas h´ ıbridas REST y GraphQL (REST/GraphQL) es analizarlas desde un punto del vista en donde, una API GraphQL sea la interfaz principal de comunicaci´ on y est´ a consuma como origen de datos a las APIs REST, a esta pr´ actica se le conoce como envoltura (wrapper) [10,41,49,68,183], con la cual adem´ as, se puede reutilizar las APIs existentes. Para ofrecer una interfaz GraphQL, los 1Ver http://graphql.org 6 1.2. RELEVANCIA DEL PROBLEMA proveedores tienen que implementar, operar y evolucionar el API GraphQL para que envuelva y resuelva las consultas de GraphQL mediante la formulaci´ on de solicitudes contra las APIs REST existentes [183]. No existen estudios que hayan tratado la gesti´ on del ciclo de vida del desarrollo y operaci´ on del servicio de las arquitecturas GraphQL o arquitecturas h´ ıbridas REST/GraphQL, por tal raz´ on, se motiva el estudio de la gobernanza de este tipo arquitecturas. En este sentido, para entender de mejor manera la gobernanza de las arquitecturas GraphQL y arquitecturas h´ ıbridas REST/GraphQL. Por un lado, se observ´ o que la definici´ on de gobernanza difiere de acuerdo al dominio que se gobierne, como por ejemplo gobierno de TI, gobierno de la arquitectura, o gobierno de arquitectura orientada a los servicios (SOA, por sus siglas en ingl´ es de Service Oriented Architecture) [58]. Debido a que esta tesis se centra en el estudio del gobierno de arquitecturas orientadas a microservicios para el desarrollo de APIs; se acoge la definici´ on del modelo y gobierno de arquitecturas SOA. El modelo de gobierno SOA es simplemente un marco que permite a una organizaci´ on (proveedor) llegar a un consenso sobre el alcance, definici´ on y uso del gobierno de SOA; el gobierno de la SOA es una especializaci´ on que ampl´ ıa el gobierno de la TI y se centra en la gesti´ on eficaz del ciclo de vida de un servicio [170]. Por estos motivos, y porque hasta donde sabemos, no existe ninguna propuesta formal para gobernar arquitecturas GraphQL o arquitecturas h´ ıbridas REST/GraphQL (vista desde el punto de vista de envoltorios) mediante la gesti´ on de acuerdos de nivel de servicio (SLA); se motiva el estudio de la gobernanza de arquitecturas h´ıbridas REST y GraphQL mediante acuerdos de nivel de servicio. 1.2 RELEVANCIA DEL PROBLEMA La comunidad cient´ ıfica y tecnol´ ogica ha mostrado una tendencia en el desarrollo de aplicaciones utilizando arquitecturas microservicios basadas en REST, las cuales son expuestas como servicios en la nube. Por un lado, REST es un estilo arquitect´ onico ampliamente aceptado, sin embargo, ha presentado varios problemas de manejo de datos [188]. Por otro lado, GraphQL se muestra como una alternativa para atenuar estos inconvenientes presentados por REST [110,174]. Por tal raz´ on, se revis´ o el estado de GraphQL, en donde se evidenci´ o que es un 7 CAP´ ITULO 1. PLANTEAMIENTO DEL PROBLEMA paradigma importante que ha llamado la atenci´ on de la industria [101,115], sin embargo, no est´ a muy claro c´ omo ha sido su acogida en la comunidad cient´ ıfica. Por lo cual, se realiz´ o una revisi´ on en cinco bases de datos cient´ ıficas m´ as representativas en la ingenier´ ıa del software: ACM Digital Library2, SpringerLink3, IEEE Explore Library4, Scopus5, Google Scholar6y DBLP7[32,88,96]. Buscando estudios de revisi´ on sistem´ atica de la literatura (SLR, por sus siglas en ingles de Systematic Literature Review) y estudios de mapeo sistem´ atico (SMS, por sus siglas en ingl´ es de Systematic Mapping Study) acerca de GraphQL que muestren una visi´ on general de este tema; pero no se encontr´ o ning´ un estudio de este tipo, por este motivo, se encontr´ o relevante empezar un estudio profundo de GraphQL. Para comprobar la relevancia de estudio de GraphQL en la comunidad cient´ ıfica, se hizo una encuesta a las bases de datos cient´ ıficas antes mencionadas, preguntando la frecuencia de las publicaciones realizadas en el transcurso del tiempo. Adem´ as, se complement´ o esta comprobaci´ on mediante un an´ alisis de la tendencia de b´ usqueda del t´ ermino “graphql” en el buscador Google8mediante la herramienta Google Trends9. / 0% 20% 40% Year BDD 2015 %T. 2016 %T. 2017 %T. 2018 %T. 2019 %T. 2020 %T. Google Scholar Springer Link ACM Digital Library Scopus DBLP IEEE Explore 39 5 6 0 0 0 2 % 2 % 4 % 0 % 0 % 0 % 100 7 13 2 0 0 4 % 3 % 10 % 3 % 0 % 0 % 199 11 17 9 6 1 9 % 5 % 13 % 12 % 15 % 6 % 370 53 33 12 5 4 17 % 25 % 24 % 16 % 12 % 25 % 631 61 31 28 15 4 28 % 29 % 23 % 38 % 37 % 25 % 892 73 35 23 15 7 40 % 35 % 26 % 31 % 37 % 44 % Total (Sum, Avg) 50 1 %122 3 %243 10 % 477 20 % 770 3 0 % 1045 35 % (%T) Percent of total Figura 1.2: Tendencia de publicaciones por a˜ no 2Ver https://dl.acm.org 3Ver https://link.springer.com 4Ver https://ieeexplore.ieee.org 5Ver https://www.scopus.com/ 6Ver https://scholar.google.com 7Ver https://dblp.org 8Ver https://www.google.com 9Ver https://trends.google.com 8 1.3. OBJETIVOS DE LA INVESTIGACI ´ ON Por un lado, la figura §1.2 muestra la tendencia de las publicaciones acerca de GraphQL en las bases de datos; esto se logr´ o tabulando e ilustrando la frecuencia de publicaciones, y el porcentaje del total de publicaciones (%T.) por a˜ nos. En este an´ alisis se tom´ o en cuenta publicaciones desde 2015 (lanzamiento de GraphQL a la comunidad) hasta 2020, en donde se evidenci´ o un promedio de crecimiento anual del 7,4%, tambi´ en se evidenci´ o que en los ´ ultimos a˜ nos se obtuvo los mayores crecimientos, e inclusive la mayor´ ıa de las publicaciones (67%).. Por otro lado, la figura §1.3 muestra la tendencia del inter´ es de b´ usqueda del t´ ermino ”graphql” en la herramienta Google Trends. Los resultados obtenidos en cuanto al inter´ es de b´ usqueda se promediaron, catalogaron y tabularon por a˜ no en un rango de 0 a 100, en donde el valor de 100 indica la m´ axima popularidad del t´ ermino de b´ usqueda, en el an´ alisis indica que existe una tasa media de crecimiento anual del 13,61%. / Search of GraphQL by Year 0 500 1000 Search of GraphQL 2015 2016 2017 2018 2019 2020 35 1015 1062 455 131 755 0 50 100 Year Average of monthly search interest 2015 2016 2017 2018 2019 2020 2,92 84,58 88,50 37,92 10,92 62,92 Figura 1.3: Tendencia de b´ usquedas por a˜ no En base a los valores obtenidos en los dos an´ alisis anteriores, y a la problem´ atica que se aborda en este trabajo se concluye que GraphQL es un tema relevante de estudio. 1.3 OBJETIVOS DE LA INVESTIGACI ´ ON En este trabajo se estudiar´ a el estilo arquitect´ onico REST y el lenguaje de consulta GraphQL en el contexto del desarrollo de software con arquitecturas GraphQL y arquitecturas h´ ıbridas REST/GraphQL y la descripci´ on de contratos de niveles de servicio (SLA) para APIs GraphQL, por tal raz´ on: El objetivo principal de esta tesis es mejorar la gobernanza de arquitecturas h´ıbridas REST y GraphQL mediante acuerdos de nivel de servicio. 9 CAP´ ITULO 1. PLANTEAMIENTO DEL PROBLEMA Para alcanzar este objetivo se plantea como subobjetivos dar respuesta a las siguientes preguntas de investigaci´ on (PI): PI1: ¿Cu´ al es el estado actual de GraphQL? (Cap´ ıtulo §5). PI2: ¿Qu´ e condiciones y circunstancias hacen m´ as recomendable seguir el paradigma GraphQL frente al paradigma REST? (Cap´ ıtulos §6 y §9). PI3: ¿En qu´ e escenarios resultan adecuadas las arquitecturas h´ ıbridas REST/- GraphQL? (Cap´ ıtulos §7 y §10). PI4: ¿En qu´ e medida es posible modelar los acuerdos de APIs GraphQL? (Cap´ ıtulos §8 y §11). A su vez, la pregunta de investigaci´ on PI1se pudo concretar en las siguientes preguntas: PI1.1: ¿Se pueden implementar aplicaciones complejas con suficiente calidad usando el paradigma GraphQL? (Secci´ on §3.5) PI1.2: ¿Qui´ enes son los autores e instituciones que han investigado acerca de GraphQL? (Secci´ on §5.3.1). PI1.3: ¿D´ onde se han publicado los trabajos de investigaci´ on acerca de GraphQL? (Secci´ on §5.3.2). PI1.4: ¿Qu´ e tipos y m´ etodos de investigaci´ on se han utilizado en las publicaciones acerca de GraphQL? (Secci´ on §5.3.3). PI1.5: ¿Cu´ ando se han publicado los trabajos de investigaci´ on acerca de GraphQL? (Secci´ on §5.3.4). PI1.6: ¿Por qu´ e se ha estudiado el paradigma GraphQL? (Secci´ on §5.3.5). PI1.7: ¿C´ omo se ha introducido GraphQL en la comunidad cient´ ıfica? (Secci´ on §5.3.6). Del mismo modo, la pregunta de investigaci´ on PI2se pudo derivar en las siguientes preguntas: 10 1.4. RESUMEN DE LA CONTRIBUCI ´ ON PI2.1: ¿Cu´ al es el efecto del paradigma de desarrollo en la calidad del software?. PI2.2: ¿Cu´ al es la curva de aprendizaje de los paradigmas REST y GraphQL en el proceso de desarrollo de APIs?. Por su parte, la pregunta de investigaci´ on PI3se deriva en las siguientes preguntas: PI3.1: ¿Cu´ al es el efecto del desarrollo de una arquitectura h´ ıbrida REST/GraphQL en la calidad del software?. PI3.2: ¿En qu´ e escenarios es m´ as adecuado usar las arquitecturas h´ ıbridas REST/- GraphQL?. As´ ı mismo, la pregunta de investigaci´ on PI4se concreta en las siguientes preguntas: PI4.1: Viabilidad. ¿Ha sido posible instanciar el est´ andar SLA4GraphQL para modelar los acuerdos de nivel de servicio (SLA) de un caso en concreto?. PI4.2: Flexibilidad. ¿Ha sido posible instanciar el est´ andar SLA4GraphQL para modelar acuerdos de nivel de servicio (SLA) en distintos casos concretos?. PI4.3: Idoneidad Funcional. ¿En qu´ e medida el est´ andar SLA4GraphQL proporciona funciones que cumplan con necesidades establecidas en condiciones espec´ ıficas?. 1.4 RESUMEN DE LA CONTRIBUCI ´ ON Para llevar a cabo esta investigaci´ on, por un lado, se utiliz´ o la experimentaci´ on en la ingenier´ ıa de software como estrategia emp´ ırica [186], para comparar las condiciones adecuadas de uso de los paradigmas REST y GraphQL, como tambi´ en de las arquitecturas h´ ıbridas REST/GraphQL. Por otro lado, se us´ o el enfoque metodol´ ogico Ciencia del dise˜no (DSR, por sus siglas en ingl´ es de Design Science Research) que ayuda a crear y evaluar artefactos que resuelven problemas organizacionales identificados [175]. La figura §1.4 muestra el resumen de las aportaciones realizadas en este estudio. Primeramente, basado en la gu´ ıa propuesta por Wohlin et al. para la experimentaci´ on en ingenier´ ıa de la software, se defini´ o las siguientes actividades [186]: 11 CAP´ ITULO 1. PLANTEAMIENTO DEL PROBLEMA Estándar SLA4GraphQL Experimento efectos de los paradigmas REST y GraphQL Experimento efectos de las arquitectura s híbridas REST/GraphQL Validación del estándar SLA4GraphQL Especificación de modelado y operación de SLA para APIs GraphQL Ciclo de vida para el desarrollo de APIs GraphQL basado en SLA Fundamentos Estado de GraphQL Estado SLA Paradigma GraphQL Instanciación del estándar Caso: CommerceTools Herramienta SLA GraphQL Manager Instanciación del estándar Caso: GitHub Instanciación del estándar Caso: GitLab Evaluación de viabilidad del estándar Evaluación de flexibilidad del estándar Evaluación de idoneidad funcional del estándar Figura 1.4: Resumen de contribuciones 1. Entorno experimental. Se define los siguientes elementos del entorno experimental de los experimentos para comparar las condiciones adecuadas de uso de los paradigmas REST y GraphQL, como tambi´ en de las arquitecturas h´ ıbridas REST/- GraphQL: Objetivos, factores, tratamientos, variables, hip´ otesis, dise˜ no, sujetos experimentales, y tareas experimentales. 2. Operaci´on. Se define los siguientes elementos de la fase de operaci´ on de los experimentos para comparar las condiciones adecuadas de uso de los paradigmas REST y GraphQL, como tambi´ en de las arquitecturas h´ ıbridas REST/GraphQL: Preparaci´ on, ejecuci´ on, recolecci´ on y validaci´ on de datos. 3. An´alisis e interpretaci´on. Se define los siguientes elementos de la fase de an´ alisis e interpretaci´ on de datos de los experimentos para comparar las condiciones adecuadas de uso de los paradigmas REST y GraphQL, como tambi´ en de las arquitecturas h´ ıbridas REST/GraphQL: Estad´ ıstica descriptiva, depuraci´ on de datos, y/o test de hip´ otesis. 12 2 METODOLOG´ IA DE INVESTIGACI ´ ON 19 Una m´ aquina puede hacer el trabajo de cincuenta hombres ordinarios. Ninguna m´ aquina puede hacer el trabajo de un hombre extraordinario. Elbert Hubbard (1856 – 1915), Fil´ osofo, escritor, editor, y artista estadounidense En este cap´ıtulo, se describe la metodolog´ıa de investigaci´on utilizada a lo largo del estudio doctoral, la cual, se reporta en esta memoria. El objetivo del cap´ıtulo es fundamentar conceptualmente los m´etodos de investigaci´on aplicados en el desarrollo y documentaci´on de los diferentes cap´ıtulos. En la secci´on §2.1, se destaca una breve discusi´on del prop´osito de la utilizaci´on de los m´etodos de investigaci´on en los diferentes cap´ıtulos de la memoria. En la secci´on §2.2 muestra la descripci´on del m´etodo de investigaci´on ”Estudio de mapeo sistem´atico”. En la secci´on §2.3 muestra la descripci´on del m´etodo de investigaci´on ”Experimentaci´on en la ingenier´ıa de software”. En la secci´on §2.4 muestra la descripci´on del enfoque de investigaci´on ”Ciencia del Dise˜no”. CAP´ ITULO 2. METODOLOG´ IA DE INVESTIGACI ´ ON 2.1 INTRODUCCI ´ ON A lo largo de este cap´ ıtulo se describe los distintos enfoques y m´ etodos de investigaci´ on utilizados en el desarrollo de la presente memoria. En donde, en el cap´ ıtulo §3 se utiliz´ o el m´ etodo Estudio de mapeo sistem´atico para realizar una investigaci´ on sistem´ atica de la literatura acerca de GraphQL; en los cap´ ıtulos §6, §7, §9, §10 se utiliz´ o el m´ etodo de experimentaci´on en la ingenier´ıa de software para comprobar los efectos de las arquitecturas REST, GraphQL, e h´ ıbridas REST/GraphQL en la calidad del software; y en el cap´ ıtulo §11 se utiliz´ o el enfoque de la Ciencia del dise˜no para validar la propuesta SLA4GraphQL para modelar acuerdos de nivel de servicios (SLA) para APIs GraphQL, expuesta en el cap´ ıtulo §8. Estos m´ etodos se detallan a continuaci´ on. 2.2 ESTUDIO DE MAPEO SISTEM ´ ATICO El Estudio de Mapeo Sistem´ atico (SMS, por sus siglas en ingl´ es de Systematic Mapping Study), es un m´ etodo para construir un esquema de clasificaci´ on de temas de estudio en un campo de inter´ es. Contando el n´ umero de publicaciones para las categor´ ıas dentro de un esquema, se puede determinar la cobertura y la madurez del campo de investigaci´ on. Los resultados se presentan en mapas, gr´ aficos o datos tabulados que muestran los estudios primarios (es decir, estudios in´ editos que obtienen pruebas emp´ ıricas sobre un tema de inter´ es [48]) existentes del tema de estudio en diferentes categor´ ıas. Los estudios de mapeo suelen abarcar una gama m´ as amplia de publicaciones, ya que el an´ alisis se centra en los res´ umenes y los t´ erminos clave [120]. En la ingenier´ ıa de software, existen varias gu´ ıas para realizar estudios de mapeos sistem´ aticos como por ejemplo las propuestas de Petersen et al. [122], Kitchenham [87], Kitchenham y Charters [90], Kitchenham y Brereton [89], Budgen et al. [15], Arksey and O’Malley [2], Biolchini et al. [8], y Petticrew y Roberts [123]. A continuaci´ on, se describe los pasos principales del proceso para llevar a cabo un estudio de mapeo sistem´ atico [122]: Planificaci´on: Planificaci´ on del mapeo contiene: Identificaci´ on de la necesidad y alcance, Identificaci´ on de estudios, Extracci´ on y clasificaci´ on de datos, Visualizaci´ on, y Amenazas a la validez. Realizaci´on: Al realizar el mapeo hay que aplicar el proceso definido durante la fase de planificaci´ on. Se recomienda registrar la informaci´ on en todas las fases del 20 2.3. EXPERIMENTACI ´ ON EN LA INGENIER´ IA DE SOFTWARE proceso. Informe: Se recomienda seguir la siguiente estructura: introducci´ on, trabajos relacionados, m´ etodo de investigaci´ on, resultados, discusi´ on, conclusiones, y ap´ endices. Evaluaci´on del proceso: Se define r´ ubricas sobre la base de la lista de comprobaci´ on de la calidad, se definen criterios para la identificaci´ on de la necesidad, la identificaci´ on del estudio, la extracci´ on y clasificaci´ on de los datos y la discusi´ on de la validez. Divulgaci´on: Por lo general los resultados de los estudios de mapeo sistem´ aticos se publican en revistas, m´ as que en conferencias. 2.3 EXPERIMENTACI ´ ON EN LA INGENIER´ IA DE SOFTWARE Los experimentos investigan una hip´ otesis comprobable en la que se manipulan una o varias variables independientes para medir su efecto sobre una o varias variables dependientes [33]. Los experimentos se los realiza cuando se pretende controlar una situaci´ on y manipular el comportamiento de forma directa, precisa y sistem´ atica; los experimentos pueden orientarse a las personas o a la tecnolog´ ıa, cuando se orienta a los seres humanos, ´ estos aplican diferentes tratamientos a los objetos; cuando son orientados a la tecnolog´ ıa, normalmente se aplican diferentes herramientas a diferentes objetos [186]. En la ingenier´ ıa de software, existen varias gu´ ıas para realizar experimentos como por ejemplo las propuestas por Wohlin et al. [186], Jedlitschka et al. [78], Singer [148], Juristo y Moreno [82], y Kitchenham et al. [91]. Para la presente memoria, se utiliz´ o la gu´ ıa propuesta por Wohlin et al. [186] para aplicar la experimentaci´ on en varios estudios, en donde, se sigui´ o la estructura de la gu´ ıa que muestra en la Tabla §2.1 y el proceso que muestra la Figura §2.1. Tabla 2.1: Estructura de la gu´ ıa de Wohlin et al. Fases Actividades Descripci´ on 21 CAP´ ITULO 2. METODOLOG´ IA DE INVESTIGACI ´ ON Continuaci´ on de la Tabla §2.1 Alcance Alcance del experimento Se define el objetivo y las metas del experimen- to: Objeto de estudio (¿qu´ e se estudia?), Prop´ osito (¿cu´ al es la intenci´ on?), Enfoque cualitativo (¿qu´ e efecto se estudia?), Perspectiva (¿el punto de vista de qui´ en?), y Contexto (¿d´ onde se realiza el estudio?). Planificaci´ on Selecci´ on del contexto Se determina en detalle el contexto del experimento. Se establece formalmente las hip´ otesis (nula y alternativa). Se determina variables (independiente(s) y dependiente(s)). Se identifican los sujetos del estudio. Se dise˜ na el experimento, se prepara la instrumentaci´ on. Se considera la validez de los resultados (interna, externa, constructo y conclusi´ on). Formulaci´ on de hip´ otesis Selecci´ on de variables Selecci´ on de sujetos Dise˜ no del experimento Instrumentaci´ on Evaluaci´ on de la validez Operaci´ on Se prepara a los sujetos, as´ ı como el material necesario. En la ejecuci´ on se debe asegurar que el experimento se lleva a cabo seg´ un el plan y el dise˜ no del mismo. Procurar que los datos recogidos sean correctos. Preparaci´ on Ejecuci´ on Validaci´ on de datos An´ alisis e interpretaci´ on Estad´ ıstica descriptiva Reducci´ on del set de datos Prueba de hip´ otesis Se trata de entender los datos utilizando estad´ ıstica descriptiva. Se debe considerar si el conjunto de datos debe reducirse. Luego realizar una prueba de hip´ otesis mediante pruebas estad´ ısticas. Presentaci´ on y empaquetado Presentaci´ on y empaquetado Es la documentaci´ on de los resultados que pueden realizarse mediante un art´ ıculo de investigaci´ on para su publicaci´ on, y un paquete de laboratorio para su replicaci´ on. Fin de tabla 2.4 CIENCIA DEL DISE ˜ NO La Ciencia del Dise˜ no (DSR, por sus siglas en ingl´ es de Design Science Research) es fundamentalmente un paradigma de resoluci´ on de problemas, trata de crear innovaciones que definan las ideas, las pr´ acticas, las capacidades t´ ecnicas y los productos mediante los cuales el an´ alisis, el dise˜ no, la implementaci´ on, la gesti´ on y el uso de los sistemas de informaci´ on puedan llevarse a cabo de forma eficaz y eficiente [67]. La figura §2.2 muestra el modelo del proceso para realizar investigaciones usando el enfoque de la ciencia del dise˜ no. 22 2.4. CIENCIA DEL DISE ˜ NO Proceso experimental Idea del experimento Alcance del experimento Planificación del experimento Operación del experimento Operación del experimento Análisis e interpretación Presentación y paquete Informe del experimento Figura 2.1: Resumen del proceso experimental Los pasos principales del proceso de la ciencia del dise˜ no son [119]: Identificaci´on del problema y motivaci´on: Definir el problema de investigaci´ on espec´ ıfico para justificar el valor del desarrollo de una soluci´ on efectiva. Atomizar el problema conceptualmente puede ser ´ util para que la soluci´ on pueda captar la complejidad del problema. Objetivos de una soluci´on: Inferir los objetivos de una soluci´ on a partir de la definici´ on del problema. Los objetivos pueden ser cuantitativos, cualitativos, o podr´ ıan deducirse racionalmente de la especificaci´ on del problema. Los recursos necesarios para ello son el conocimiento del estado de los problemas y de las soluciones actuales y su eficacia. Dise˜no y desarrollo: Crear la soluci´ on de artefactos, estos deben ser potencialmente definidos de forma amplia, constructos, modelos, m´ etodos o instancias. Se determina la funcionalidad deseada del artefacto y su arquitectura para luego crear el artefacto real. Los recursos necesarios para pasar de los objetivos al dise˜ no y el desarrollo incluyen el conocimiento de la teor´ ıa que puede aportarse como soluci´ on. Demostraci´on: Demostrar la eficacia del artefacto para resolver el problema. Esto 23 CAP´ ITULO 2. METODOLOG´ IA DE INVESTIGACI ´ ON Secuencia nominal del proceso IDENTIFICACIÓN DEL PROBLEMA Y MOTIVACIÓN Definir el problema Mostrar la importancia OBJETIVOS DE UNA SOLUCIÓN ¿Qué haría un mejor artefacto mejor? DISEÑO Y DESARROLLO Artefacto DEMONSTRACIÓN Encuentre un contexto Utilizar el artefacto para resolver el problema EVALUACIÓN Observar la eficacia, eficiencia Volver a iterar al diseño COMUNICACIÓN Publicaciones académicas Publicaciones profesional ENFOQUE CENTRADO EN EL PROBLEMA SOLUCIÓN CENTRADA EN OBJETIVOS ENFOQUE CENTRADO EN EL DISEÑO Y EL DESARROLLO OBSERVANDO UNA SOLUCIÓN Posibles puntos de entrada para la investigación Inferencia Teoría Cómo conocer Métricas, análisis de conocimientos Conocimiento disciplinario Figura 2.2: Modelo de proceso de investigaci´ on en ciencias del dise˜ no podr´ ıa implicar su uso en la experimentaci´ on, la simulaci´ on, un estudio de caso, una prueba u otra actividad apropiada. Los recursos necesarios para la demostraci´ on incluyen el conocimiento efectivo de c´ omo utilizar el artefacto para resolver el problema. Evaluaci´on: Observar y medir la eficacia del artefacto para resolver el problema. Esta actividad consiste en comparar los objetivos de una soluci´ on con los resultados reales observados del uso del artefacto en la demostraci´ on, mediante el uso de m´ etricas y t´ ecnicas de an´ alisis pertinentes. Al final de esta actividad, los investigadores pueden decidir si volver al ”dise˜ no y desarrollo” para intentar mejorar la eficacia del artefacto o continuar con la comunicaci´ on y dejar las mejoras para proyectos posteriores. Comunicaci´on: Comunicar el problema y su importancia, el artefacto, su utilidad y novedad, el rigor de su dise˜ no y su eficacia, mediante publicaciones acad´ emicas o profesionales, los cuales, puede utilizar la estructura de este proceso para estructurar sus investigaciones emp´ ıricas (definici´ on del problema, revisi´ on de la literatura, desarrollo de la hip´ otesis, recogida de datos, an´ alisis, resultados discusi´ on y conclusi´ on). 24 ESTADO DE LA CUESTI ´ ON PARTE II 3 PARADIGMA GRAPHQL 27 La inteligencia consiste no s´ olo en el conocimiento, sino tambi´ en en la destreza de aplicar los conocimientos en la pr´ actica. Arist´ oteles (384 a.C. – 322 a.C.), Fil´ osofo y erudito griego En este cap´ıtulo, se introduce el marco conceptual denominado Paradigma GraphQL, que ilustra y ejemplifica la especificaci´on formal de GraphQL (versi´on junio del 2018). Adem´as, se responde la pregunta de investigaci´on PI1. ¿Cu´al es el estado actual de GraphQL?. En la secci´on §3.1, se destaca una breve discusi´on de los temas a tratar en este cap´ıtulo. En la secci´on §3.3, se presenta una caracterizaci´on de los principales componentes GraphQL. En la secci´on §3.4, se introduce la estructura conceptual y ejemplificaci´on de los componentes GraphQL. En la secci´on §3.5, se valida el paradigma GraphQL mediante la creaci´on y validaci´on de un artefacto tecnol´ogico basado en la implementaci´on del paradigma. Por ´ultimo, la secci´on §3.6, se muestra las principales conclusiones del cap´ıtulo. CAP´ ITULO 3. PARADIGMA GRAPHQL 3.1 INTRODUCCI ´ ON En las secciones §3.3, y §3.4, se introduce el marco conceptual denominado Paradigma GraphQL que ilustra y ejemplifica la estructura conceptual y funcional de la especificaci´ on formal de GraphQL (versi´ on junio del 2018) [162]. Adem´ as, en este cap´ ıtulo se concreta la pregunta de investigaci´ on PI1: ¿Cu´ al es el estado actual de GraphQL? con la sub pregunta: PI1.1: ¿Se pueden implementar aplicaciones complejas con suficiente calidad usando el paradigma GraphQL? Se responde a PI1.1 mediante el dise˜ no y validaci´ on de un artefacto (implementaci´ on del paradigma GraphQL), basado en el enfoque de investigaci´ on DSR. Tambi´ en, es necesario aclarar que la pregunta de investigaci´ on PI1se complementar´ a con seis sub preguntas adicionales en el cap´ ıtulo §5. 3.2 ANTECEDENTES Antes de introducir el paradigma GraphQL, se describe el concepto de REST, y sus principales diferencias con GraphQL. 3.2.1 REST REST, por sus siglas en ingl´ es de REpresentational State Transfer, es un estilo arquitect´ onico para sistemas hipermedia distribuidos, creado por Roy Thomas Fielding en 2000 [42]. REST es un conjunto de conceptos de dise˜ no basados en caracter´ ısticas y requisitos del software de red, que tiene como objetivo reducir la complejidad del desarrollo, mejorar la escalabilidad de los sistemas y reducir la carga de la comunicaci´ on [118,134]. La arquitectura de servicios REST plantea varios criterios principales de dise˜ no para su aplicaci´ on en la web: i) todas las cosas en Internet se abstraen como recursos; ii) cada recurso corresponde a un identificador de recurso ´ unico, es decir, una URI; iii) operar los recursos a trav´ es de la interfaz del conector gen´ erico aplicando acciones est´ andar como GET, POST, PUT, DELETE, HEAD del protocolo HTTP; iv) varias operaciones sobre los recursos no cambiar´ an el identificador del recurso; y v) todas las 28 3.4. SEM ´ ANTICA OPERACIONAL y un campo adicional (primaryFunction); i) define el objeto de entrada (HumanInput) que contiene un conjunto de campos utilizados en la mutaci´ on createHuman; y j) define SearchResult como un tipo de uni´ on utilizado para buscar datos en los tipos Human o Droid. 3.4.2 Definici´on de Ejecutables (Executable Definition). Se considera documentos ejecutables cuando son definidos por operaciones OperationDefinition o fragmentos (fragments) [162]. A continuaci´ on, se describen los componentes de las definiciones ejecutables; y en la figura §3.5 se muestra la relaci´ on y estructura conceptual de estos componentes. 1..n 0..n 0..n 1..1 0..1 1..n 0..n 0..n 1..n0..n Executable Definition 1..1 0..n 1..1 Value Possible values Association Generalization 1..n Fields query mutation subscription Component Operations 0..1 Variables Directives Arguments Default Values NamedType List Non-Null Type IntValue FloatValue StringValue BooleanValue NullValue EnumValue ListValue ObjectValue Operation Type 0..n 1..1 T SelectionSets Fragments T Composition Figura 3.5: Definici´ on de ejecutables en GraphQL Operaciones (Operations):son los elementos principales de las definiciones ejecutables, y pueden ser de tipo consulta (query), que son de s´ olo lectura y obtienen datos; mutaci´ on (mutation) que primero escriben y luego obtienen datos; y suscripci´ on (subscription), que son peticiones de larga duraci´ on que obtienen datos en respuesta a eventos de la fuente. Variables (Variables):se introducen para maximizar la reutilizaci´ on de las consultas GraphQL parametrizadas con variables, evitando la costosa construcci´ on de cadenas en los clientes durante el tiempo de ejecuci´ on. 35 CAP´ ITULO 3. PARADIGMA GRAPHQL Valores de Entrada (Input Values):pueden ser valores escalares, valores de enumeraci´ on, listas u objetos de entrada. Directivas (Directives):son una forma de describir comportamientos alternativos de ejecuci´ on y validaci´ on de tipos en un documento GraphQL; se utilizan de forma similar a descrita en las directivas del sistema de tipos. Argumentos (Arguments):alteran el comportamiento de los campos que ocasionalmente los aceptan. Los argumentos de las funciones se suelen asignar dentro de una implementaci´ on del servidor GraphQL. Conjuntos de Selecci´on (Selection Sets):se componen principalmente de campos. Su prop´ osito es restringir las solicitudes para seleccionar s´ olo el subconjunto necesario de la informaci´ on, evitando el exceso, y falta de obtenci´ on de datos. Campos (Fields):describen la informaci´ on disponible y pueden representar datos complejos o relaciones con otros datos; tambi´ en se consideran funciones conceptuales que devuelven valores. Fragmentos (Fragments):es la unidad b´ asica de composici´ on en GraphQL que permite reutilizar selecciones de campos que se repiten habitualmente. La figura §3.6 muestra ejemplos de las operaciones m´ as utilizadas (consultas y mutaciones) de la definici´ on ejecutable [153] relativa al sistema de tipos definido en la figura §3.4, en concreto: a) define la operaci´ on (NewHumans) que ejecuta la mutaci´ on (createHuman). Tambi´ en muestra tres formas de ejecutar el tipo de consulta (humans); b) ejecuta la consulta, pero sin definir el nombre de la petici´ on; c) define la petici´ on (queryOneHuman) que ejecuta la consulta acompa˜ nada del par´ ametro ”id” con el valor de uno; y d) define la petici´ on (queryWithFragment) que ejecuta la consulta utilizando el fragmento (FragmentTwoFields) que hace referencia a un conjunto de campos espec´ ıficos de la implementaci´ on (Human). Las herramientas de cliente se encargan de enviar estas solicitudes para su ejecuci´ on en el servicio GraphQL. 3.4.3 Respuesta (Response). La respuesta de una operaci´ on GraphQL es un mapa com´ unmente en formato JSON, que contiene tres entradas: datos, errores, y/o extensiones. Los datos contienen el resultado de la ejecuci´ on de la operaci´ on solicitada. Los errores aparecen cuando la 36 3.4. SEM ´ ANTICA OPERACIONAL Figura 3.6: Ejemplos de definici´ on de ejecutables en GraphQL ejecuci´ on ha encontrado un error. La extensi´ on est´ a reservada para que los implementadores puedan extender el protocolo sin restricciones de contenido [124,153,162]. La figura §3.7 muestra la respuesta a las solicitudes de ejecuci´ on de las operaciones de mutaci´ on y consulta realizadas en la figura §3.6. Figura 3.7: Ejemplo de respuesta en GraphQL 3.4.4 Introspecci´on (Introspection). Los servidores GraphQL soportan la introspecci´ on de su esquema mediante consultas al sistema de tipos utilizando el mismo lenguaje GraphQL [162]. La figura §3.8 muestra: a) una porci´ on del sistema de tipos establecido en la figura §3.4; b) una consulta de introspecci´ on; y c) la respuesta de esa consulta. 3.4.5 Validaci´on (Validation). GraphQL con la validaci´ on verifica si una petici´ on es sint´ acticamente correcta y se asegura de que es inequ´ ıvoca y sin errores de acuerdo con un esquema GraphQL dado. La validaci´ on se realiza antes de la ejecuci´ on. Sin embargo, un servicio GraphQL puede ejecutar una petici´ on sin validarla expl´ ıcitamente si se sabe que esa misma petici´ on ha 37 CAP´ ITULO 3. PARADIGMA GRAPHQL Figura 3.8: Ejemplo de introspecci´ on en GraphQL sido validada anteriormente. Las definiciones del sistema de tipos y las extensiones no son ejecutables y por lo tanto no se consideran durante la ejecuci´ on [162]. 3.4.6 Ejecuci´on (Execution). La ejecuci´ on de GraphQL s´ olo considerar´ a las definiciones ejecutables de Operaciones y Fragmentos. Mediante la ejecuci´ on de una solicitud enviada desde las herramientas de cliente, genera una respuesta en el contexto del universo de datos disponibles en un sistema de tipos proporcionado por el servicio GraphQL. S´ olo las peticiones que pasan las reglas de validaci´ on son realmente ejecutadas; si tiene errores de validaci´ on, ser´ an reportados en la lista de ”errores” dentro de la respuesta, y la petici´ on fallar´ a sin ejecuci´ on [162]. Cabe mencionar que existen casos de peticiones que pasan la validaci´ on, pero durante la ejecuci´ on presentan errores de datos, en esos casos, la ejecuci´ on devuelve el resultado de los datos, pero tambi´ en devuelve la descripci´ on de los errores ocurridos. 38 3.5. VALIDACI ´ ON DEL PARADIGMA GRAPHQL 3.4.7 Resolutores (Resolvers). Cada campo de cada tipo est´ a respaldado por una funci´ on llamada resolver que el desarrollador implementa con alg´ un lenguaje de programaci´ on en el servicio de GraphQL. Cuando se ejecuta un campo, se llama al resolver correspondiente para producir el valor de la respuesta [124,162]. 3.5 VALIDACI ´ ON DEL PARADIGMA GRAPHQL 3.5.1 Introducci´on El objetivo de este apartado es validar el paradigma GraphQL introducido en las secciones §3.1, §3.3, y §3.4. Para lo cual, se utiliz´ o la metodolog´ ıa del enfoque de investigaci´ on Ciencia del dise˜no (DSR) que indica como evaluar artefactos para resolver problemas organizacionales identificados [175]. En este sentido, el artefacto a validar ser´ a una prueba de concepto de la implementaci´ on del paradigma GraphQL. A continuaci´ on, se resume las actividades propuestas en DSR [119], y aplicadas en el contexto de la prueba de concepto: 1. Identificaci´on del problema y motivaci´on. Se define el problema que da lugar a una propuesta de investigaci´ on. En este segmento, se hace referencia a la problem´ atica presentada en el cap´ ıtulo §1, la cual, motiva la validaci´ on del paradigma GraphQL y el planteamiento de una pregunta de investigaci´ on. 2. Definici´on de los objetivos de la soluci´on. Es necesario conocer otras propuestas y especificar qu´ e se espera del artefacto a desarrollar. El objetivo definido es contestar la pregunta de investigaci´ on mediante la creaci´ on y validaci´ on de un artefacto tecnol´ ogico. Para lo cual, se defini´ o: i) El tema de implementaci´ on del artefacto; ii) Poblaci´ on y muestra del estudio; iii) Encuesta de aceptaci´ on del tema de implementaci´ on; iv) Propuestas existentes del tema de implementaci´ on; y v) Identificaci´ on de principales caracter´ ısticas y funcionalidades para el artefacto. 3. Dise˜no y desarrollo. Se da forma al artefacto. 39 CAP´ ITULO 3. PARADIGMA GRAPHQL En el dise˜ no del artefacto se defini´ o: Requerimientos, Diagrama de procesos, arquitectura de software, diagrama inicial de la base de datos. En el desarrollo se implement´ o el artefacto dise˜ nado siguiendo el marco de trabajo SCRUM2. 4. Demostraci´on. Implica el uso del artefacto desarrollado en una o m´ as instancias del problema analizando su aplicabilidad. En este caso, se despleg´ o el artefacto desarrollado en la nube, para un f´ acil acceso, y as´ ı constatar su aplicabilidad. 5. Evaluaci´on. Mediante evidencias emp´ ıricas, se analiza si el uso del artefacto cubre los objetivos esperados. Puede ser necesario realizar ajustes en el artefacto y volver, mediante un proceso iterativo, a la actividad de dise˜no y desarrollo. En este punto, se realiza la evaluaci´ on de la calidad en uso del artefacto usando las normas ISO/IEC 25010 [75], 25022 [76], y 25040 [73]. Para recabar las evidencias emp´ ıricas se realiz´ o un taller pr´ actico y una encuesta de satisfacci´ on del uso de la aplicaci´ on. 6. Comunicaci´on. Se publican los resultados de la investigaci´ on. La comunicaci´ on se realiza a trav´ es de esta memoria, y del art´ ıculo de conferencia Quality in use evaluation of a GraphQL implementation [129] presentado en el XVI Multidisciplinary International Congress on Science and Technology - CIT 20213 realizado del 14 al 18 de junio 2021 de manera virtual. 3.5.2 Identificaci´on del problema y motivaci´on El problema se lo identific´ o y describi´ o en el cap´ ıtulo §1, el cual, a su vez motiva a la validaci´ on del paradigma GraphQL introducido en las secciones anteriores §3.1, §3.3, y §3.4 para contestar la sub pregunta de investigaci´ on: PI1.1: ¿Se pueden implementar aplicaciones complejas con suficiente calidad usando el paradigma GraphQL? 3.5.3 Definici´on de los objetivos de la soluci´on El objetivo de la soluci´ on es contestar la pregunta de investigaci´ on PI1.1, mediante la creaci´ on y validaci´ on de un artefacto tecnol´ ogico; que en este caso consiste en rea- 2https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf 3https://cit-conferences.org 40 3.5. VALIDACI ´ ON DEL PARADIGMA GRAPHQL lizar una prueba de concepto de la implementaci´ on del paradigma GraphQL. Como tema de implementaci´ on, se consider´ o la automatizaci´ on de la gesti´ on de estudios de mapeos sistem´ aticos de la literatura (SMS). Poblaci´on y muestra: Debido al contexto de la investigaci´ on, el estudio se aplic´ o en una Poblaci´on conformada por veintid´ os profesores y veinte y cinco estudiantes de octavo nivel del Departamento de Software de la Universidad T´ ecnica del Norte, que ten´ ıan los conocimientos adecuados para validar este trabajo. De los cuales, mediante la aplicaci´ on de la t´ ecnica de muestreo no probabil´ ıstico por conveniencia, la muestra se conform´ o por cuarenta sujetos (15 profesores y 25 estudiantes). Encuesta de aceptaci´on: Para validar la viabilidad del tema de implementaci´ on se realiz´ o una encuesta de aceptaci´ on. La encuesta fue dirigida a la poblaci´ on de profesores y se conform´ o de 6 preguntas validadas por tres investigadores expertos en Ingenier´ ıa de Software antes de su ejecuci´ on. Los resultados indicaron que el 45,45% de los encuestados conoc´ ıan acerca de m´ etodos de revisi´ on de la literatura (SLR4/SMS), pero nadie conoc´ ıa una herramienta para llevarlos a cabo; adem´ as, el 100% indic´ o que les gustar´ ıa recibir una breve formaci´ on para utilizar una herramienta que gestione SMSs, lo que confirm´ o la motivaci´ on para realizar la automatizaci´ on de la gesti´ on de SMSs como prueba de concepto de la implementaci´ on de GraphQL. Propuestas existentes: Una vez establecido el tema de implementaci´ on, se realiz´ o una b´ usqueda bibliogr´ afica de herramientas que automaticen m´ etodos de estudios sistem´ aticos de la literatura. La b´ usqueda se realiz´ o en las bases de datos cient´ ıficas Scopus, DBLP, y Springer, en donde, luego de un an´ alisis de resultados se encontr´ o los estudios de Knutas et al. [92] y Kohl et al. [93] que exponen herramientas para gestionar estudios de revisi´ on sistem´ atica de la literatura (SLR) y SMS. Por un lado, Knutas [92] propone una aplicaci´ on llamada NAILS, que se conecta a la base de datos cient´ ıfica ”web of science” para elegir una colecci´ on de datos de estudios y exportar en archivos al servidor de an´ alisis basado en la web HAMMER para mostrar un an´ alisis estad´ ıstico de los datos introducidos. Tambi´ en ofrecen la opci´ on de descargar una aplicaci´ on basada en el lenguaje R para el estudio de la colecci´ on 4Revisi´ on sistem´ atica de la literatura (SLR, por sus siglas en ingl´ es de Systematic Literature Review), sirve para identificar, analizar e interpretar evidencia reportada relacionada a un conjunto de preguntas de investigaci´ on espec´ ıficas [88]. 41 CAP´ ITULO 3. PARADIGMA GRAPHQL de datos. Por otro lado, Kohl [93] realiza un revisi´ on de herramientas en l´ ınea que apoyan la realizaci´ on y el informe de revisiones y mapeos sistem´ aticos; muestra 22 aplicaciones, de las cuales dos aplicaciones Colandr yCADIMA de acceso libre que apoyan la automatizaci´ on de SMSs. Identificaci´on de principales caracter´ısticas y funcionalidades: Se empez´ o revisando las funcionalidades de las herramientas existentes, en donde, con Colandr se pudo realizar las fases b´ asicas para llevar a cabo SMSs, adem´ as, se distingui´ o las siguientes funcionalidades especiales: Planificaci´ on de trabajos, Citation Screening, Full-text Screening, Extracci´ on de Datos, e importaci´ on de colecciones de datos a trav´ es de archivos planos. Adem´ as, se revis´ o las funcionalidades de la herramienta CADIMA, que presentaba documentaci´ on detallada en cada paso del proceso; sin embargo, fue dif´ ıcil de utilizar, lo que suger´ ıa tener conocimientos previos de la aplicaci´ on para usarla correctamente. Como resultado de la revisi´ on de las herramientas NAILS,Colandr, y CADIMA, se logr´ o identificar varias caracter´ ısticas y funcionalidades principales que se deber´ ıa implementar en la prueba de concepto, estas funcionalidades son: Automatizaci´ on de las fases b´ asicas de los estudios de mapeo sistem´ atico; Importaci´ on de estudios primarios; Colaboraci´ on con herramientas de gesti´ on bibliogr´ afica; Exportar resultados de los estudios realizados; Documentaci´ on integrada en la herramienta de todo el proceso del SMS; y que sea de f´ acil acceso y uso. 3.5.4 Dise˜no y desarrollo Dise˜no El artefacto se dise˜ n´ o de acuerdo con el backlog de requerimientos establecidos para la automatizaci´ on de la gesti´ on de estudios de mapeos sistem´ aticos. Los requerimientos se conformaron por 15 historias de usuario, basadas en el proceso (ver Figura §5.1) propuesto en la gu´ ıa de Petersen et al. [122] y las caracter´ ısticas y funcionalidades identificadas en la secci´ on anterior §3.5.3. Adem´ as, se tom´ o como base la arquitectura orientada a microservicios para dise˜ nar una aplicaci´ on cliente-servidor; utilizando como proveedor una API-GraphQL, y como cliente, una aplicaci´ on web integrada con la API-Mendeley para la gesti´ on de referencias bibliogr´ aficas. La arquitectura de software de la aplicaci´ on se muestra en la Figura §3.9. 42 3.5. VALIDACI ´ ON DEL PARADIGMA GRAPHQL API-GraphQL (Provider) Web Application (Client) Apollo V 2.4.8 GraphQL V 14.3.1 Node.js V 12.0.0 Neo4j V 4.0.0 Apollo boost V 0.4.0 GraphQL V 14.3.1 React Bootstrap V 4.0.0 Mendeley API-REST V 1.0 V 16.8.6 Figura 3.9: Arquitectura de software del artefacto Desarrollo El desarrollo de la aplicaci´ on se realiz´ o desde el 03/06/2019 hasta el 06/12/2019 (220 horas) utilizando el marco de trabajo SCRUM. La aplicaci´ on denominada ”SMS- Online” se desarroll´ o conforme a los requerimientos establecidos en el dise˜ no. El equipo de trabajo estuvo formado por dos stakeholders, un product owner, un scrum master y un desarrollador. A continuaci´ on se muestra un resumen de las fases y artefactos utilizados en el desarrollo del artefacto de software, v´ ease Tabla §3.2. Tabla 3.2: Resumen del desarrollo e implementaci´ on del artefacto Fase Scrum Sprint (duraci´ on) Entregables Prejuego Sprint 0 (20 horas) Requerimientos: - 1 Backlog del producto - 15 historias de usuario Dise˜ no: - Diagrama de procesos (Figura §5.2.2) - Arquitectura de software - Diagrama inicial de la base de datos Juego Sprint 1 (42 horas) - Spring Backlog - Incremento del producto de software Sprint 2 (42 horas) Sprint 3 (42 horas) Sprint 4 (42 horas) Post-Juego Sprint 5 (32 horas) - 15 Pruebas de Aceptaci´ on - Despliegue del producto de software - Acta de entrega-recepci´ on 43 CAP´ ITULO 3. PARADIGMA GRAPHQL En esta fase, se destaca el uso del paquete neo4j-graphql.js5que facilit´ o la manipulaci´ on de datos utilizando en conjunto las tecnolog´ ıas GraphQL y Neo4j [111]. En concreto, el paquete neo4j-graphql.js traduce las consultas GraphQL a un ´ unico Cypher6, eliminando la necesidad de escribir resolutores de consultas GraphQL o de realizar consultas por lotes [56]. Adem´ as, se verific´ o los componentes GraphQL que se implementaron en el desarrollo de la aplicaci´ on SMS-Online. La Tabla §3.3 muestra los componentes implementados manualmente y generados por el paquete neo4j-graphql.js. Tabla 3.3: Componentes GraphQL implementados Componente Componente Implementado Proveedor Cliente clasificaci´ on Generado Desarrollado componentes Executable Definition Query ✓12 0 27 Mutation ✓62 1 40 Subscription X 0 0 0 Type System Definition Schema ✓0 1 0 Scalars ✓0 132 132 Objects ✓0 12 12 Interfaces ✓0 1 1 Unions ✓0 1 1 Enums ✓0 2 2 Input Object ✓63 0 0 Directives ✓0 14 0 3.5.5 Demostraci´on El artefacto (Aplicaci´ on Web) desarrollado se despleg´ o como un servicio en la nube para constatar su aplicabilidad. El artefacto se nombr´ o como SMS-Online y esta disponible en: https://appsms.utn.edu.ec:3000 3.5.6 Evaluaci´on En esta secci´ on, se evalu´ o el uso del artefacto desarrollado en la secci´ on anterior. Para lo cual, se evalu´ o la calidad en uso de la aplicaci´ on SMS-Online, utilizando los est´ andares ISO/IEC 25010, 25022, y 25040, en donde, se realiz´ o tres pasos: 1) definir un modelo de calidad; 2) medir la calidad en uso de la aplicaci´ on SMS-Online de acuerdo 5https://www.npmjs.com/package/neo4j-graphql-js 6Cypher es el lenguaje de consulta de grafos de Neo4j. 44 4 ACUERDOS DE NIVEL DE SERVICIO 51 Si decides hacer solo las cosas que sabes que van a funcionar, dejar´ as un mont´ on de oportunidades encima de la mesa. Jeff Bezos (1964 – ), Presidente Ejecutivo de Amazon En este cap´ıtulo, se introduce la base conceptual de los Acuerdos de nivel de servicio, en donde, se revisar´a sus principales conceptos; se analizar´a las principales propuestas existentes para gestionar SLA para APIs; y se describir´a la propuesta m´as adecuada, que servir´a como base te´orica para desarrollar la propuesta expuesta en el cap´ıtulo §8. En la secci´on §4.1, se destaca una breve discusi´on de los temas a tratar en este cap´ıtulo. En la secci´on §4.2, se presenta una comparativa de propuestas existentes para gestionar los acuerdos de nivel de servicios (SLA) para APIs. En la secci´on §4.3, se describe la propuesta m´as adecuada de acuerdo a la comparativa realizada en la secci´on §4.2. CAP´ ITULO 4. ACUERDOS DE NIVEL DE SERVICIO 4.1 INTRODUCCI ´ ON Los Acuerdos de Nivel de Servicio (SLA, por sus siglas en ingl´ es de Service-Level Agreements) se definen como la relaci´ on entre un proveedor de servicios y sus clientes. El acuerdo describe los productos y/o servicios que el cliente ha de recibir, las responsabilidades de cada parte, las condiciones econ´ omicas, c´ omo ser´ a medido el servicio y el esquema de reporte. Su objetivo es presentar de manera clara, concisa y medible lo que el proveedor hace para el cliente [172]. A medida que el dise˜ no de la arquitectura del software evoluciona hacia un paradigma de microservicios, las APIs se han convertido en un punto de inicio para construir aplicaciones, en donde, los proveedores de APIs ofrecen diferentes niveles de servicio con limitaciones a medida, normalmente basadas en el coste [46]. En este sentido, el objetivo de este cap´ ıtulo es realizar una comparativa entre varias propuestas existentes que gestionen acuerdos de nivel de servicios para APIs, para determinar la propuesta m´ as adecuada, la cual, se describir´ a con m´ as detalle y ser´ a utilizada como base te´ orica para el desarrollo del cap´ ıtulo §8 que pretende gestionar los acuerdos de nivel de servicio (SLA) para APIs GraphQL. 4.2 PROPUESTAS EXISTENTES DE SLA PARA APIS En esta secci´ on, se realiza un an´ alisis comparativo entre seis propuestas destacadas en los campos de la academia y la industria que pretenden gestionar las limitaciones y alcance de servicios web y APIs mediante la especificaci´ on de limitaciones de los servicios web y gesti´ on de acuerdos de nivel de servicios (SLA). Las principales caracter´ ısticas identificadas para la comparaci´ on son: C1: Dominio objetivo son los servicios web; C2: Modelar diferentes operaciones de un servicio; C3: Modelamiento de modelos jer´ arquicos; C4: Modelamiento de limitaciones temporales; y C5: Herramienta de soporte para modelar SLA. La Tabla §4.1 muestra la comparativa entre las principales propuestas existentes para gestionar SLA en APIs. Por otro lado, basados en los estudios emp´ ıricos [43,112] que analizaron un conjunto de 69 y 500 APIs industriales respectivamente, muestran entre sus principales conclusiones que: i) la mayor´ ıa de las APIs proporcionan diferentes capacidades y precios dependiendo del nivel o plan de consumo. ii) Las limitaciones de uso es un aspecto com´ un en las ofertas que describen las APIs. iii) Las limitaciones m´ as comunes 52 4.3. SLA4OAI: EST ´ ANDAR PARA DESCRIBIR SLA PARA APIS REST Tabla 4.1: Comparativa entre propuestas para gestionar SLA Propuesta C1 C2 C3 C4 C5 C6 ysla [37]✓ ✓ ✓ ✓ ✓ ✓ SLA4OAI [44]✓ ✓ ✓ ✓ ✓ ✓ L-USDL Ag. [47]✓ ✓ ✓ CSLA [94]✓ ✓ rSLA [161]✓ ✓ ✓ SLAC [169]✓ son cuotas sobre periodos de tiempo est´ aticos (e.g. diariamente), o tiempos din´ amicos (e.g. por segundo) en las solicitudes de la API. iv) Las ofertas pueden incluir un amplio n´ umero de m´ etricas sobre otros aspectos de la API que pueden ser dependientes o independientes del dominio, como por ejemplo el n´ umero de resultados devueltos o el consumo de CPU durante el procesamiento de la solicitud. A partir de las conclusiones de los estudios emp´ ıricos [43,112] y del resultado de la comparativa de las principales propuestas existentes para gestionar SLA en APIs mostrada en la tabla §4.1.Se ha identificado que el marco conceptual de la propuesta SLA4OAI expuesta en los trabajos [44,45,46,71] es la m´ as adecuada para fundamentar te´ oricamente la propuesta para describir SLA para APIs GraphQL que se desarrollar´ a en el cap´ ıtulo §8; debido a que SLA4OAI brinda un soporte no funcional del ciclo de vida del desarrollo de la API y que tiene un alto nivel de expresividad de las ofertas de la API. Por lo cual, en la siguiente secci´ on se describir´ a a detalle la propuesta SLA4OAI. 4.3 SLA4OAI: EST ´ ANDAR PARA DESCRIBIR SLA PARA APISREST SLA4OAI es un est´ andar de c´ odigo abierto propuesto por Gamez-Diaz et al. [44, 45,46,71]; se basa en los est´ andares de (OAI, por sus siglas en ingl´ es de OpenAPI- Specification) para describir SLA para APIs REST de una manera tecnol´ ogica neutral. 4.3.1 Ciclo de vida del desarrollo de APIs impulsado por SLA En esta secci´ on bas´ andose en Gamez-Diaz et al. [44,46], primero se identifica un conjunto m´ ınimo de etapas y actividades generales para abordar el ciclo de vida de 53 CAP´ ITULO 4. ACUERDOS DE NIVEL DE SERVICIO APIs, a la cual luego se le incorpora las actividades necesarias para gestionar acuerdos de nivel de servicio. Por un lado, se identifica que las actividades el ciclo de vida b´ asico de APIs comienzan por el desarrollo y prueba de la l´ ogica de las funcionalidades que proveer´ a el servicio del API. Luego, se realiza la actividad de despliegue en la que el artefacto desarrollado se configura para ser ejecutado en una infraestructura determinada. Por ´ ultimo, una vez que la API est´ a en funcionamiento, se inicia la operaci´ on en la que se pueden aceptar las solicitudes de los clientes. Este proceso es una simplificaci´ on que puede evolucionar para a˜ nadir pasos intermedios como pruebas o para incluir un modelo de ciclos evolutivos en el que se desplieguen progresivamente diferentes versiones. Por otro lado, para incorporar los acuerdos de nivel de servicio al proceso b´ asico del ciclo de vida, tanto el proveedor como el cliente de la API deben interact´ uan como se detalla en la Figura §4.1. Desarrollador Director de producto Operador de productos API Proveedor Desarrollo de funcionalidades SLA modelado SLA instrumentación Despliegue SLA implantación Operación Registro SLA Instancia de SLA Análisis de ofertas Selección de oferta Consumo API cliente Cliente Cliente Proveedor Ciclo de vida de desarrollo de la API impulsado por SLA Figura 4.1: Ciclo de vida del desarrollo de APIs impulsado por SLA 54 4.3. SLA4OAI: EST ´ ANDAR PARA DESCRIBIR SLA PARA APIS REST En la figura §4.1 se muestra que desde la perspectiva del proveedor, las actividades comienzan por el desarrollo funcional de las APIs, las cuales pueden implementarse en paralelo con un modelado de los acuerdos de nivel de servicio (SLA), en donde, se describe en documentos los planes de la oferta real de la API en t´ erminos de cuotas y tarifas, que luego se registran para que puedan ser accedidos por los clientes. Una vez que el desarrollo funcional como el modelado de los planes SLA hayan concluido, se debe llevar a cabo la instrumentaci´ on del SLA, en donde, las herramientas y/o artefactos desarrollados se deben parametrizar para que ajusten su comportamiento en funci´ on a los planes SLA establecidos; estas a su vez deben proporcionar m´ etricas adecuadas para poder analizar su estado en funci´ on al SLA establecido. Luego, mientras se realiza el despliegue de la API, se desarrolla una actividad paralela que implementa el SLA, el cual se debe configurar la infraestructura de despliegue para hacer cumplir el SLA antes de que la API llegue a la actividad de operaci´ on. Complementariamente, desde la perspectiva del cliente, una vez que el proveedor ha publicado la oferta de SLA (es decir, los planes) en el Registro de SLA inicia el an´ alisis de la oferta para seleccionar la opci´ on m´ as adecuada y para crear y registrar su SLA real; finalmente, el consumo de la API se lleva a cabo mientras la actividad de operaci´ on y su regulaci´ on se basa en los t´ erminos (como cuotas o tarifas) definidos en el SLA. 4.3.2 Roles en el ciclo de vida del desarrollo de APIs impulsado por SLA Los roles inmersos en el ciclo de vida de APIs impulsadas por SLA son [46]: Desarrollador: Este rol est´ a compuesto por el equipo responsable del desarrollo de una determinada API y de ponerla a disposici´ on de otros equipos. Sus casos de uso est´ an relacionados con la definici´ on de objetivos de nivel de servicio (SLO, por sus siglas en ingl´ es de Service Level Objectives). Director de producto: Este rol est´ a compuesto por personas de negocios, alineadas con los objetivos de la empresa. Sus casos de uso tienen como objetivo satisfacer las necesidades del cliente y conocer el panorama general de las dependencias entre los servicios. En concreto, conocer los SLO de las dependencias descendentes para poder crear productos que satisfagan las necesidades de los clientes. Operador de productos: Esta funci´ on est´ a compuesta por personas de administraci´ on de sistemas, que se encargan de supervisar e informar el rendimiento del servicio 55 CAP´ ITULO 4. ACUERDOS DE NIVEL DE SERVICIO en los SLO. Sus casos de uso tienen como objetivo notificar cualquier alerta o incidente y tomar medidas correctivas. Cliente: Este rol est´ a compuesto por el conjunto de clientes de la API. Sus casos de uso pretenden ser informados de los diferentes niveles de servicio y reclamar si los niveles de servicio no se est´ an cumpliendo. 4.3.3 Componentes de los acuerdos de nivel de servicio para APIs Los conceptos que se describen a continuaci´ on, ser´ an la base de los componentes del documento SLA que se revisar´ a en la secci´ on §4.3.4: Componentes generales del SLA El contexto (Context): describe aspectos como la versi´ on, las partes interesadas o el periodo de validez. Las m´etricas (Metrics): son elementos que se recogen y computan. El indicador de nivel de servicio (SLI, Service Level Indicator): es un caso particular de m´ etrica que se utiliza para evaluar un aspecto clave del sistema. El objetivo de nivel de servicio (SLO, Service Level Objective): es un objetivo num´ erico preciso (a menudo un ratio) para uno o m´ as SLI, que describe la fiabilidad o el rendimiento m´ ınimo aceptable de un sistema. Los t´erminos de garant´ıa (Guarantee terms): describen los compromisos sobre determinados SLI. El Acuerdo de Nivel de Servicio (SLA, Service Level Agreement): es, por tanto, un contrato firmado con un usuario. En particular, los SLI y los SLO son construcciones t´ ecnicas mientras que los SLA son construcciones empresariales. Las propiedades del servicio (Service properties): (o configuraci´ on) son las restricciones de atributos que se utilizan para dirigir el comportamiento de la API. Restricciones de la API Las cuotas (Quotas): describen las limitaciones de uso durante un periodo de tiempo determinado/est´ atico de tiempo. 56 4.3. SLA4OAI: EST ´ ANDAR PARA DESCRIBIR SLA PARA APIS REST Las tarifas (Rates): describen las limitaciones de uso durante un periodo de tiempo din´ amico. Limitaci´on de tiempo (Time constraint): Algunas APIs pueden ofrecer una serie de limitaciones en cuanto al tiempo en el que se solicita. La autenticaci´on (Authentication): es la verificaci´ on de las credenciales de la solicitud. Monetizaci´on de la API La fijaci´on de precios (Pricing): es la forma de monetizar las API. Los planes (Plans): son un enfoque para una amplia gama de necesidades empresariales mediante organizar los precios en un conjunto de niveles de planes. La medici´on (Metering): es el registro del uso de la API con suficiente detalle para realizar la tarificaci´ on. La tarificaci´on (Rating): es la conversi´ on de los registros del uso de la API en una cantidad de dinero. La facturaci´on (Billing): es la presentaci´ on a un usuario de la API de un informe de los importes adeudados, teniendo en cuenta cualquier descuento, cr´ edito de servicio impuestos y reparto de ingresos. El cobro (Collection): es la forma de recibir y registrar los pagos de cantidades adeudadas por los usuarios de las APIs. Cumplimiento de la ley (Enforcement): consiste en impedir que un usuario utilice una API luego de agotarse su cr´ edito de servicio prepagado o ha alcanzado un l´ ımite de cr´ edito. 4.3.4 Estructura del documento SLA para APIs REST Esta secci´ on muestra la especificaci´ on para describir los componentes de los documentos SLA, los cuales contendr´ an la configuraci´ on y los acuerdos de nivel de servicio de una API espec´ ıfica. La tabla §4.2 muestra el esquema del documento SLA usando los conceptos repasados en la secci´ on §4.3.3. 57 CAP´ ITULO 4. ACUERDOS DE NIVEL DE SERVICIO Tabla 4.2: Esquema del documento SLA Comienzo de tabla Componente Requerido Campo(s) Requerido Subcampo(s) Requerido context ✓ id ✓- - version ✓- - api ✓- - type ✓- - provider •- - consumer •- - validity •effectiveDate ✓ expirationDate • infrastructure ✓ supervisor ✓- - monitor ✓- - name •- - pricing • cost •- - custom •- - currency •- - billing •- - metrics ✓{name}• type ✓ format • description • unit • resolution • plans •{planName}• configuration • availability • pricing • quotas • rates • guarantees • quotas • {pathName}: {methodName}: {metricName} • max • custom • period • scope • rates • {pathName}: {methodName}: {metricName} • max • custom • period • scope • guarantees •{pathName}: {methodName}• objective ✓ period • window • 58 4.3. SLA4OAI: EST ´ ANDAR PARA DESCRIBIR SLA PARA APIS REST Continuaci´ on de la Tabla §4.2 Campo Requerido Campo(s) Requerido Subcampo(s) Requerido scope • configuration •name •- - Fin de tabla Leyendas:✓Campo requerido; •Campo opcional; - No aplica La documentaci´ on completa de la propuesta SLA for Open API Initiative Specification (Research Version), se puede acceder en el siguiente enlace: https://sla4oai.specs. governify.io/Specification.html 59 CAP´ ITULO 4. ACUERDOS DE NIVEL DE SERVICIO 60 5.2. GRAPHQL: ESTUDIO DE MAPEO SISTEM ´ ATICO Evaluaci´on de la b´usqueda: Petersen et al. [122] y Kitchenham [88] recomiendan mantener un bajo nivel de exigencia en la evaluaci´ on de la calidad de los estudios primarios porque los SMS tienen como objetivo proporcionar una visi´ on general del ´ area tem´ atica de la investigaci´ on. Por este motivo, se decidi´ o no excluir ning´ un estudio primario en esta secci´ on, lo que dio como resultado un conjunto de ochenta y cuatro estudios primarios para el mapeo (ver Anexo §A). 5.2.4 Fase 3: Extracci´on de datos y clasificaci´on En esta fase, se extrajo los datos necesarios de los estudios primarios para realizar una clasificaci´ on general que no depende del tema investigado (clasificaci´ on independiente del tema) y otra espec´ ıfica sobre el paradigma GraphQL (clasificaci´ on espec´ ıfica del tema) [122]. Esquema de clasificaci´on independiente del tema: A continuaci´ on se describen los campos de extracci´ on de datos basados en las facetas,sedes,tipos de investigaci´on,m´etodos de investigaci´on, y enfoques de estudio propuestos en Petersen et al. [122]: Autores: autor principal (primer autor) y coautores (el resto de los autores) de la publicaci´ on. Afiliaci´ on de los autores: primera afiliaci´ on de los autores de la publicaci´ on. Pa´ ıses: pa´ ıs de la afiliaci´ on de los autores. A˜ no: a˜ no de la publicaci´ on. Sede: nombre de la sede de la publicaci´ on. Tipos de sede: tipos de sedes revisados por pares como revistas, conferencias y talleres [122]. Adem´ as, se a˜ nadi´ o la literatura gris, como art´ ıculos acad´ emicos, tesis y disertaciones, para reducir un posible sesgo de publicaci´ on y proporcionar una visi´ on m´ as equilibrada de las pruebas recogidas para el estudio [116]. ´ Indice de sede: factor de impacto de los tipos de sede medido con Scimago Journal & Country Rank (SJR)9,Journal Citation Reports (JCR)10, y GII-GRIN-SCIE (GGS)11. 9https://www.scimagojr.com 10https://jcr.clarivate.com 11http://gii-grin-scie-rating.scie.es 67 CAP´ ITULO 5. ESTUDIO DE MAPEO SISTEM ´ ATICO DE GRAPHQL SJR calcula el factor de impacto Scimago Journal Rank (SJR) de las revistas y los pa´ ıses a partir de la informaci´ on de la base de datos Scopus (Elsevier B.V.) [143], mide las citas ponderadas de una revista seg´ un el ´ area cient´ ıfica y la relevancia de las revistas citadas [144]. Las subdisciplinas de las revistas se clasifican en cuatro cuartiles (Q1 a Q4) utilizando el ´ Indice de Citaci´ on SJR [36]. El JCR es un producto de Web of Science que proporciona una rica gama de m´ etricas de citaci´ on como el Journal Impact Factor™ (JIF) [23]. La clasificaci´ on por cuartiles de una revista (Q1 a Q4) se determina comparando una revista con otras de su categor´ ıa JCR bas´ andose en el JIF [24]. GGS es una iniciativa que proporciona una clasificaci´ on unificada de las conferencias de ciencias de la computaci´ on [50], v´ ease la tabla §5.1. Tabla 5.1: Calificaci´ on de Conferencias GGS Clase Clasificaci´ on Descripci´ on 1 A++, A+ conferencias de primera clase 2 A, A- eventos de muy alta calidad 3 B, B- eventos de buena calidad - Trabajo en progreso Trabajo en progreso Tipos de publicaci´ on: esta clasificaci´ on est´ a relacionada con los tipos de sede revisados por pares las cuales son: art´ ıculos de revistas, art´ ıculos de conferencias y art´ ıculos de talleres [122]. Para la literatura gris, de acuerdo con la clasificaci´ on de tesis del Ministerio de Educaci´ on Finland´ es12 se utiliz´ o: Tesis de licenciatura, tesis de m´ aster, y tesis de doctorado. Tipo de investigaci´ on: se basa en la clasificaci´ on de tipos de investigaci´ on propuesta por Wieringa [180] y se la complement´ o con una tabla de decisi´ on para desambiguar la clasificaci´ on de los estudios mediante la comprobaci´ on de una serie de condiciones propuestas por Petersen et al. [122], v´ ease la tabla §5.2. A continuaci´ on, se muestra y ordena los tipos de investigaci´ on seg´ un la madurez expuesta por los estudios [180,185]: •Investigaci´on de evaluaci´on, eval´ ua emp´ ıricamente la investigaci´ on de un problema o la aplicaci´ on de una t´ ecnica en la pr´ actica de la ingenier´ ıa. •Investigaci´on de validaci´on, desarrolla una soluci´ on novedosa y se eval´ ua emp´ ıricamente en un entorno de laboratorio (es decir, no se utiliza en la pr´ actica). 12https://aaltodoc2.org.aalto.fi/doc_public/ohjeet/publicationclassification2010.pdf 68 5.2. GRAPHQL: ESTUDIO DE MAPEO SISTEM ´ ATICO •Propuesta de soluci´on, este tipo de estudio propone una soluci´ on a un problema de investigaci´ on, y los beneficios se discuten pero no se eval´ uan. •Documentos filos´oficos, son estudios que estructuran una ´ area en forma de taxonom´ ıa o marco conceptual, por lo que proporciona una nueva forma de ver las cosas existentes. •Documentos de experiencia, son estudios que incluyen la experiencia del autor sobre qu´ eyc´ omo ocurri´ o algo en la pr´ actica. •Documentos de opini´on, estos estudios contienen la opini´ on del autor sobre un tema concreto sin basarse en trabajos de investigaci´ on y metodolog´ ıas relacionadas. Tabla 5.2: Clasificaci´ on de los tipos de investigaci´ on Tipo de investigaci´ on Condiciones Usado en la pr´ actica Soluci´ on novedosa Evaluaci´ on emp´ ırica Marco conceptual Opini´ on sobre algo Experiencia de los autores Investigaci´ on de evaluaci´ on V • V • F • Investigaci´ on de validaci´ on F • V • F • Propuesta de soluci´ on • V F • F • Documentos filos´ oficos F F F V F F Documentos de experiencia V F F • F V Documentos de opini´ on F F F F V F Leyenda si aplica: V=Verdadero, F=Falso, y •= irrelevante o no aplicable. M´ etodos de investigaci´ on: en este apartado basados en Petersen et al. [122] se identifica que los tipos de ”investigaci´ on de evaluaci´ on” e ”investigaci´ on de validaci´ on” necesitan una evaluaci´ on emp´ ırica mediante el uso de m´ etodos de investigaci´ on frecuentemente utilizados en la ingenier´ ıa de software [33,180,186]; en este sentido, analizamos y utilizamos el siguiente subconjunto de m´ etodos de investigaci´ on propuestos por [122]: 69 CAP´ ITULO 5. ESTUDIO DE MAPEO SISTEM ´ ATICO DE GRAPHQL •Encuesta, utilizada para identificar las caracter´ ısticas de una poblaci´ on amplia de individuos, se asocia estrechamente con el uso de cuestionarios para la recogida de datos [33]. •Estudio de caso, utilizado para investigar una entidad o fen´ omeno en su contexto de la vida real dentro de un tiempo y espacio espec´ ıfico [186]. •Experimento controlado, utilizado para investigar una hip´ otesis comprobable en la que se manipulan una o m´ as variables independientes para medir su efecto sobre una o m´ as variables dependientes [33]. •Simulaci´on, utilizado como una potente t´ ecnica para manejar la complejidad del modelo (cientos de variables din´ amicas y v´ ınculos causales). El uso de la simulaci´ on permite a los gestores evaluar de forma r´ apida y segura las implicaciones de una pol´ ıtica prevista antes de aplicarla [105]. •Prototipos, es un enfoque basado en una visi´ on evolutiva del desarrollo de software y un impacto en el proceso de desarrollo. Implica la producci´ on de las primeras versiones de trabajo (prototipos) del sistema de aplicaci´ on de caracter´ ısticas y la experimentaci´ on con ellos [14]. •An´alisis matem´atico, abarca las t´ ecnicas b´ asicas para identificar un conjunto de reglas de razonamiento de forma precisa en el sistema estudiado [9]. ´ Ambito de estudio: se refiere al contexto en el que se realiz´ o el estudio, estos pueden ser: ´ ambito acad´ emico, industrial o gubernamental [26]. En este sentido, establecimos la siguiente sem´ antica para definir los ´ ambitos mencionados: •Acad´emico: estudios realizados en entornos sint´ eticos que no implementan soluciones de uso p´ ublico. •”Industria” y ”Gobierno”: estudios realizados en entornos de pr´ actica de la industria/gobierno o que exponen soluciones de servicio p´ ublico. Esquema de clasificaci´on espec´ıfico del tema: A continuaci´ on, se describen los campos de extracci´ on de datos para la clasificaci´ on espec´ ıfica del paradigma GraphQL: ´ Areas de conocimiento: se consider´ o las ´ areas de conocimiento establecidas en la Gu´ ıa del Cuerpo de Conocimiento de la Ingenier´ ıa del Software (SWEBOK, por sus siglas en ingl´ es de Software Engineering Body of Knowledge) versi´ on 3.0 por la IEEE Computer Society13 [9]. Las ´ areas son: Requisitos de software, Dise˜ no 13https://www.computer.org 70 5.2. GRAPHQL: ESTUDIO DE MAPEO SISTEM ´ ATICO de software, Construcci´ on de software, Pruebas de software, Mantenimiento de software, Gesti´ on de la Configuraci´ on, Gesti´ on de la Ingenier´ ıa, Proceso de Ingenier´ ıa, Modelos y M´ etodos de Ingenier´ ıa, Calidad, Pr´ actica Profesional de la Ingenier´ ıa, Econom´ ıa de la Ingenier´ ıa, Fundamentos de la Computaci´ on, Fundamentos Matem´ aticos y Fundamentos de la Ingenier´ ıa. Dominio de contribuci´ on: se refiere al dominio en donde se aplica la contribuci´ on t´ ecnica del estudio, de acuerdo a la estructura de los principales componentes del paradigma GraphQL establecido en la figura §3.1, en donde, se identifica los dominios de Proveedor yCliente del servicio GraphQL. Se considera dominio Proveedor a cualquier contribuci´ on implementada en el servicio GraphQL, y el dominio Cliente son las contribuciones que consumen el servicio GraphQL. Tipo de contribuci´ on: es una clasificaci´ on de alto nivel de las contribuciones t´ ecnicas utilizando el paradigma GraphQL, para lo cual, se defini´ o la siguiente sem´ antica para identificar y clasificar los tipos de contribuci´ on: •Implementaci´on, se refiere a los estudios que utilizan el paradigma GraphQL para implementar software. •An´alisis, se refiere a los estudios que aportan un an´ alisis comparativo o una revisi´ on te´ orica para identificar formas de aplicar el paradigma GraphQL. •Integraci´on, se refiere a los estudios que presentan la integraci´ on de GraphQL con otras tecnolog´ ıas para dise˜ nar o construir soluciones. •Extensi´on, se refiere a los estudios que proponen un nuevo componente o funcionalidad en el paradigma GraphQL. •Aplicaciones, se refiere a estudios que proponen enfoques de soluciones aplicando el paradigma GraphQL pero sin llegar a su implementaci´ on. Componentes de GraphQL: en base a las secciones §3.3 y §3.4, se estableci´ o la siguiente clasificaci´ on: •Componentes de Servicio: Ejecuci´ on, Introspecci´ on, Resolutores, Sistema de Tipos, y Validaci´ on. •Componentes de Sistema de Tipos: Directivas, Enumeraciones, Objetos de Entrada, Interfaces, Objetos, Escalares, Esquemas, y Uniones. •Componentes de Ejecuci´on: Fragmentos, Mutaciones, Consultas y Suscripciones. 71 CAP´ ITULO 5. ESTUDIO DE MAPEO SISTEM ´ ATICO DE GRAPHQL API p´ ublica: se refiere a las APIs p´ ublicas de la vida real utilizadas en el estudio como un caso de uso o un sistema de apoyo. Por lo antes expuesto, en la tabla §5.3 se muestra la estructura de campos necesarios para la extracci´ on de datos, que tiene como objeto responder a las preguntas de investigaci´ on establecidas para este estudio de mapeo sistem´ atico. Los campos se derivan de la clasificaci´ on independiente y espec´ ıfica del tema de investigaci´ on, y de las estructuras de datos m´ ınimas recomendadas por Kuhrmann et al. [96] y Petersen et al. [122]. Tabla 5.3: Estructura de extracci´ on de datos No. Campo Relaci´ on Descripci´ on PI 1 No. 1 N´ umero de la publicaci´ on 2 T´ ıtulo 1 T´ ıtulo de la publicaci´ on 3 Autores 1..n Autores de la publicaci´ on PI1.1 4 Afiliaci´ on de los autores 1..n Instituci´ on de afiliaci´ on de los autores PI1.1 5 Pa´ ıses 1..n Pa´ ıs de las instituciones de los autores PI1.1 6 Sede 1 Nombre de la sede de publicaci´ on PI1.2 7 Tipo de sede 1 Clasificaci´ on de las sedes de publicaci´ on PI1.2 8 Tipo de publicaci´ on 1 Tipos de publicaci´ on de las sedes PI1.2 9 Acr´ onimo de sede 1 Acr´ onimo del nombre de la sede PI1.2 10 Tasa de inter´ es de la sede 1 Tasa de inter´ es de publicaci´ on de la sede PI1.2 11 Tipo de investigaci´ on 1 Tipo de investigaci´ on del estudio PI1.3 12 M´ etodo de investigaci´ on 1 M´ etodo de investigaci´ on usado en el estudio PI1.3 13 A˜ no 1 A˜ no de publicaci´ on PI1.4 14 Entorno del estudio 1 Contexto en el que se aplica el estudio PI1.5 15 ´ Area de conocimiento 1 ´ Areas de conocimiento del SWEBOK PI1.5 16 Dominio de contribuci´ on 1 Dominio en el que se aplica la contribuci´ on PI1.6 17 Tipo de contribuci´ on 1 Tipo de contribuci´ on que aporta la publicaci´ on PI1.6 18 Contribuci´ on 1..n Contribuci´ on t´ ecnica de la publicaci´ on PI1.6 19 Componentes GraphQL 1..n Componentes de GraphQL nombrados, ejemplificados, o utilizados en la publicaci´ on PI1.6 20 API p´ ublica 1..n APIs p´ ublicas utilizadas en la publicaci´ on PI1.6 5.2.5 Evaluaci´on de la validez En la realizaci´ on del SMS se ha intentado ser lo m´ as metodol´ ogico posible, por lo que se ha evaluado la validez en base a las directrices de [121,122], utilizando las siguientes consideraciones: 72 5.2. GRAPHQL: ESTUDIO DE MAPEO SISTEM ´ ATICO Validez descriptiva es la descripci´ on con precisi´ on y objetividad. Se intento minimizar esta amenaza introduciendo formularios de criterios de decisi´ on para la categorizaci´ on y clasificaci´ on general de estudios basados en la gu´ ıa de Petersen et al. [122] (v´ ease secci´ on §5.2.4). Adem´ as, se introdujo criterios de clasificaci´ on espec´ ıficos basados en los componentes del paradigma GraphQL (v´ eanse secciones §3.3 y §3.4). Validez te´orica determina la capacidad de capturar lo que pretendemos capturar [122]. Para minimizar esta amenaza, en la ”Identificaci´ on del Estudio”, se estableci´ o la cadena de b´ usqueda s´ olo con la palabra ”graphql” para obtener una muestra adecuada respecto a la poblaci´ on objetivo. Tambi´ en se eligi´ o dos estrategias para la b´ usqueda: se comenz´ o con una b´ usqueda autom´ atica a las bases de datos; y se la complement´ o con la estrategia de b´ usqueda manual, en donde se recuper´ o cuatro estudios los que se a˜ nadi´ o al conjunto de datos del estudio inicial. Para minimizar el riesgo de sesgo en la extracci´ on y clasificaci´ on de los datos, se realiz´ o un mapeo individual con el primer investigador, seguido de la revisi´ on de un segundo investigador. Las diferencias encontradas se validaron mediante una lectura conjunta del texto completo de la publicaci´ on y luego se discutieron hasta llegar a un consenso basado en las reglas de clasificaci´ on establecidas en la secci´ on §5.2.4. Generalizaci´on, seg´ un Petersen y Gencel [121], se debe considerar la generalizaci´ on interna (dentro de una poblaci´ on) y la generalizaci´ on externa (entre diferentes poblaciones). La validez interna asegura que el dise˜ no experimental de un investigador sigue de cerca el principio de causa y efecto; por lo tanto, en este estudio, se sigui´ o la mayor´ ıa de las recomendaciones metodol´ ogicas expuestas en la gu´ ıa de Petersen et al. [122]. Sin embargo, la existencia de clasificaciones manuales en el proceso, expone que los investigadores introduzcan algunos errores de selecci´ on de estudios. Por este motivo, se incluy´ o a este estudio una amplia gama de trabajos (incluyendo la literatura gris) y se introdujo m´ etodos de criterios de decisi´ on en las clasificaciones para minimizar este impacto. La validez externa mide la aplicabilidad de los resultados del estudio a otras situaciones, grupos o eventos (Generalizaci´ on). En este aspecto se intent´ o minimizar esta amenaza utilizando la gu´ ıa de Petersen et al. [122], que es popular para la realizaci´ on de SMS en la ingenier´ ıa del software. Adem´ as, se realiz´ o la clasificaci´ on espec´ ıfica de los componentes de GraphQL utilizando el paradigma expuesto en el cap´ ıtulo §3, el cual a su vez se bas´ o en el sitio oficial de la especificaci´ on formal de GraphQL. Validez interpretativa es cuando las conclusiones se extraen razonablemente, dados los datos. En este apartado, se minimiz´ o la amenaza de sesgo en la interpretaci´ on de 73 CAP´ ITULO 5. ESTUDIO DE MAPEO SISTEM ´ ATICO DE GRAPHQL las conclusiones de los resultados descritos por el primer autor, luego revisados por separado por los tres coautores, y despu´ es discutidos conjuntamente en reuniones de consenso para unificar las revisiones e interpretaciones. Repetibilidad requiere informaci´ on detallada sobre el proceso de investigaci´ on. En este estudio se informa detalladamente del proceso de SMS, se exponen los archivos del trabajo en repositorios digitales y se explican las medidas adoptadas para reducir las posibles amenazas a la validez. 5.3 RESULTADOS En esta secci´ on, se responde a las preguntas de investigaci´ on definidas en la secci´ on §5.1, mediante los resultados del proceso de extracci´ on de datos realizado en la secci´ on §5.2.4. 5.3.1 PI1.2 ¿Qui´enes son los autores e instituciones que investigan sobre el paradigma GraphQL? En esta pregunta, se descubre a los investigadores e instituciones m´ as activos en realizar estudios acerca del paradigma GraphQL. Por un lado, se muestra la informaci´ on de los autores que utilizaron el paradigma GraphQL en sus publicaciones, para lo cual, se consider´ o al primer autor de la publicaci´ on como autor principal y a los dem´ as autores como coautores, obteniendo 298 autor´ ıas en las publicaciones (84 autor´ ıas principales y 214 coautor´ ıas) correspondientes a 270 investigadores. La figura §5.3 muestra un resumen de los autores por pa´ ıs y continente; en donde, se observa que los autores afiliados a instituciones europeas lideran el n´ umero de contribuciones con un 60,74%; sin embargo, Estados Unidos es el pa´ ıs con m´ as autores, seguido de Alemania, donde destaca el n´ umero de autor´ ıas de los autores principales. La tabla §5.4 muestra los autores con mayor n´ umero de publicaciones. Por otro lado, La figura §5.4 muestra las instituciones de afiliaci´ on de los autores; se agrupo las instituciones que tienen una publicaci´ on en la categor´ ıa ”Otras”. Se encontr´ o 86 instituciones de 33 pa´ ıses, en donde la Universidad de Linkoping, de Suecia, es la que aport´ o m´ as publicaciones, seguida de la Universidad Aalto, de Finlandia, 74 5.3. RESULTADOS Principal Author and Co-Author by Country Country United States Germany Sweden Finland Spain Italy China Indonesia Czechia Pakistan South Africa Norway Chile Portugal Russia South Korea Brazil Canada Netherlands Poland Thailand Belgium United Kingdom Austria Bolivia Republic of Mac… Ecuador India Serbia Saudi Arabia Denmark France 8 11 10 10 6 2 2 3 2 3 2 2 2 2 2 33 29 19 16 13 10 9 7 7 6 4 4 4 3 3 3 3 3 2 2 2 2 2 2 Principal Author Co-Author Authors by Country Authors by Continent 0% 20% 40% 60% Continent Europe North America Asia South America Africa 60,74% 15,10% 14,77% 6,38% 3,02% 181 45 44 19 9 13,76% 13,42% 9,73% 8,72% 6,38% 4,03% 3,69% 3,36% 2,68% 2,68% 2,01% 2,01% 2,01% 1,68% 1,34% 1,34% 1,34% 1,34% 1,34% 21,01% 1,01% 1,01% 1,01% 1,01% 2 0,67% 0,67% 0,67% 0,67% 0,34% 5% 10% 15% 0 60 120 180 3 63,02% 3,02% 3,02% 6 8 0% Figura 5.3: Autores por continente y por pa´ ıs IBM Research, de Estados Unidos, y la Universidad RWTH Aachen, de Alemania. 5.3.2 PI1.3 ¿D´onde se publicaron los trabajos de investigaci´on? En esta pregunta se identific´ o las sedes, tipos de sede, tipos de publicaci´ on donde se han publicado los estudios de GraphQL y su impacto. En este sentido, primero se identific´ o y orden´ o los tipos de sede de acuerdo al rigor de la revisi´ on de sus publicaciones; cabe mencionar que se consider´ o la literatura gris para verificar el inter´ es de estudio de GraphQL en la academia. Luego, en las sedes se identific´ o y orden´ o los siguientes tipos de publicaci´ on por su impacto: tesis de licenciatura, tesis de maestr´ ıa, art´ ıculo de taller, art´ ıculo de conferencia y art´ ıculo de revista. Sin embargo, se identific´ o que las conferencias y talleres tienen dos formas de publicar sus estudios; la primera es publicar los estudios en las actas de las sedes, y la segunda es publicar las actas de la sede en un volumen de alguna revista, en donde el impacto de estos estudios se cataloga por el impacto de la revista; en este sentido, se subdividi´ o estos tipos de publicaci´ on en: art´ ıculos de conferencia (revista) y art´ ıculos de taller (revista). La figura §5.5 muestra las publicaciones por tipo de publicaci´ on y por tipo de sede. Se observ´ o que la mayor parte de las publicaciones (46,07%) son en conferencias, en 75 CAP´ ITULO 5. ESTUDIO DE MAPEO SISTEM ´ ATICO DE GRAPHQL Tabla 5.4: Los principales autores por publicaciones Autor Publicaciones como autor principal Publicaciones como coautor Total Publicaciones Hartig Olaf 3 3 6 Wittern Erik 2 1 3 Cha Lan 1 2 3 Taelman Ruben 2 - 2 Brito Gleison 2 - 2 Others 54 (64,29%) Linkoping University 5 (5,95%) Aalto University 3 (3,57%) IBM Research 3 (3,57%) RWTH Aachen University3 (3,57%) Masaryk University 2 (2,38%) Politecnico di Milano 2 (2,38%) Universitat Politécnica de Catalunya 2 (2,38%) University of Skövde 2 (2,38%) Universidad Politécnica de Madrid 2 (2,38%) University of Illinois at Urbana-Champaign 2 (2,38%) Haaga-Helia University of Applied Sciences 2 (2,38%) Federal University of Minas Gerais 2 (2,38%) Figura 5.4: Publicaciones por afiliaci´ on donde a su vez los estudios publicados en sedes revisadas por pares (revistas, conferencias, y talleres) son la mayor´ ıa 69,05%, y la revisi´ on acad´ emica es el 30,95%. A continuaci´ on, se muestra el impacto de las publicaciones medido por: GII-GRIN- SCIE (GGS), Scimago Journal & Country Rank (SJR), y Journal Citation Reports (JCR). En esta secci´ on, se aclara que el impacto de la literatura gris no es medible; por lo tanto, solo se analizar´ an los papers de talleres, conferencias y revistas. La tabla §5.5 muestra los papers de los talleres y su impacto medido en GGS y SJR. En donde, el ”Workshop on (Constraint) Logic Programming (WLP)”, publicado en la revista Electronic Proceedings in Theoretical Computer Science, se destaca con un SJR: 0,33. La tabla §5.6 muestra el impacto de los art´ ıculos de conferencia medido con GGS y SJR. Seg´ un la m´ etrica SJR, por un lado, las conferencias indexan sus actas directamente a la base cient´ ıfica Scopus, la cual asigna un ´ ındice SJR, pero no un cuartil; en este 76 5.3. RESULTADOS contr´ o publicaciones que proporcionaban m´ ultiples tipos de contribuci´ on; por lo tan- to, se clasific´ o 127 contribuciones t´ ecnicas en 84 publicaciones. La figura §5.12 muestra que los tipos de contribuci´ on m´ as frecuentes son la implementaci´ on y el an´ alisis de GraphQL. 0% 20% 40% Contribution type Contributions Implementation Analysis Applications Extension Integration 44,09% 37,01% 12,60% 4,72% 1,57% 56 47 16 6 Figura 5.12: Tipos de contribuci´ on en las publicaciones Contribuciones: Son las contribuciones t´ ecnicas espec´ ıficas que utilizan el paradigma GraphQL en las publicaciones. La figura §5.12 muestra que la mayor´ ıa de las contribuciones son de tipo ”Implementaci´ on” y ”An´ alisis”, por lo que a continuaci´ on se analizar´ a estas dos contribuciones. Por un lado, las contribuciones de tipo ”Implementaci´ on” realizan soluciones como wrappers, migraciones, y sobre todo (43 de 56 contribuciones) implementaciones de APIs GraphQL. La figura §5.13 muestra que la mayor´ ıa de las implementaciones (72,37%) fueron en el dominio del proveedor; esto implica de nuevo una oportunidad de investigaci´ on en el consumo del servicio GraphQL. / Publications by Domain of GraphQL Implementations 0% 50% %GT Nro Contribution Domain Provider Provid… Client 62,96% 35,19% 1,85% Publications by Implementation domain 0 20 40 60 Implementation domain Publications Provider Client 53 20 0% 20% 40% 60% 80% Implementation domain Contributions Provider Client 72,37% 27,63% Implementation domain Provider Client Publications by Domain of GraphQL Implementations 0 20 40 Nro Contribution Domain Provider Provid… Client 34 19 1 55 21 35 (62,50%) 20 (35,71%) 1 (1,79%) Figura 5.13: Tipo de contribuci´ on ”Implementaci´ on” en las publicaciones Por otro lado, las contribuciones de tipo ”An´ alisis” presentaron trabajos como revisiones te´ oricas, an´ alisis del tema, y las m´ as destacadas (35 de 47 contribuciones) reali- 83 CAP´ ITULO 5. ESTUDIO DE MAPEO SISTEM ´ ATICO DE GRAPHQL zaron comparaciones de GraphQL con otras tecnolog´ ıas. En este sentido, la tabla §5.9 muestra las diferentes comparaciones realizadas en los estudios; n´ otese que la mayor´ ıa de ellos comparan GraphQL con REST, en donde, los principales resultados y conclusiones reportados mencionan que al utilizar GraphQL, lograron reducir el n´ umero de campos, el tiempo y el tama˜ no de las respuestas en las APIs implementadas; en consecuencia, se concluye que los investigadores analizan GraphQL como una alternativa al paradigma tradicional REST para la implementaci´ on de APIs. Tabla 5.9: Comparaciones de GraphQL Camparaciones Publicaciones Porcentaje Entre REST y GraphQL [1,10,11,17,35,38,41,55,57,59,63,65,85, 95,102,110,113,114,135,141,149,158,160, 171,173,174,181] 77.14% Entre esquemas de APIs GraphQL [86,182] 5.71% Otras comparaciones con GraphQL [68,100,146,155,156,179] 17.15% 100% Componentes de GraphQL : En esta secci´ on, se mape´ o los componentes GraphQL mencionados, utilizados y ejemplificados en las publicaciones para entender la profundidad c´ omo la comunidad cient´ ıfica estudi´ o el paradigma GraphQL. La sem´ antica establecida de las clasificaciones para los componentes es (i) componentes mencionados, se refiere a los componentes mencionados en las publicaciones pero no necesariamente utilizados; y (ii) componentes ejemplificados, se refiere a los componentes ejemplificados pero no necesariamente utilizados en las publicaciones; (iii) componentes utilizados, se identifica los componentes utilizados como parte de la contribuci´ on t´ ecnica de GraphQL en las publicaciones. La figura §5.14 muestra el mapeo espec´ ıfico de los componentes de GraphQL, sus frecuencias y el porcentaje sobre el n´ umero total de publicaciones. Por un lado, los componentes m´ as mencionados, ejemplificados y utilizados en las publicaciones son las consultas, los esquemas, los objetos, los escalares y las mutaciones, lo que confirma que estos componentes son fundamentales para construir APIs GraphQL. Por otro lado, los componentes menos estudiados son las directivas, la validaci´ on y las suscripciones, lo que revela lagunas de investigaci´ on en estos componentes. La falta de estudios sobre las suscripciones llama la atenci´ on ya que se trata una de las tres operaciones b´ asicas del servicio GraphQL. 84 5.3. RESULTADOS / Classification Component Mentioned % Exemplified % Used % Service Type System Definition Execution Introspection Resolvers Type System Validation Directives Enums Input Object Interfaces Objects Scalars Schemas Unions 42 28 39 36 18 17 26 28 31 59 39 73 26 50,00 % 33,33 % 46,43 % 42,86 % 21,43 % 20,24 % 30,95 % 33,33 % 36,90 % 70,24 % 46,43 % 86,90 % 30,95 % 26 8 20 12 4 10 13 7 11 50 47 46 8 30,95 % 9,52 % 23,81 % 14,29 % 4,76 % 11,90 % 15,48 % 8,33 % 13,10 % 59,52 % 55,95 % 54,76 % 9,52 % 40 19 37 27 10 10 13 15 13 62 52 66 8 47,62 % 22,62 % 44,05 % 32,14 % 11,90 % 11,90 % 15,48 % 17,86 % 15,48 % 73,81 % 61,90 % 78,57 % 9,52 % Executable Definition Fragments Mutations Query Subscription 20 63 80 31 23,81 % 75,00 % 95,24 % 36,90 % 13 24 65 6 15,48 % 28,57 % 77,38 % 7,14 % 9 42 75 5 10,71 % 50,00 % 89,29 % 5,95 % Figura 5.14: Componentes GraphQL en publicaciones APIs p´ublicas utilizadas : Por ´ ultimo, se identific´ o la tendencia a utilizar APIs p´ ublicas en las publicaciones; en este sentido, se encontr´ o en uso de 15 APIs GraphQL o REST p´ ublicas utilizadas en 15 publicaciones (17,86%). Las API GraphQL p´ ublicas son GitHub en [10,11,19,62,97,142,182], Apollo Demo y Smalltalk GraphQL Demo en [109], y Yelp en [19,109]. Las APIs REST utilizadas son GitHub en [11,86,146]; APIs.guru en [86,97,183]; arXiv en [10]; Kentico Cloud’s Delivery en [17]; IBM Watson Language Translator en [183]; JAX-RS, jBPM, y KIE en [59]; Libraries. io en [86]; Toggl y Toggl Report en [151]; y Spotify en [18]. Se observ´ o que las API REST y API GraphQL de GitHub son las m´ as utilizadas, seguidas de APIs.guru; las cuales, se han hecho populares en la comunidad cient´ ıfica como fuente de informaci´ on para estudios emp´ ıricos. 85 CAP´ ITULO 5. ESTUDIO DE MAPEO SISTEM ´ ATICO DE GRAPHQL 5.4 CONCLUSIONES En esta secci´ on se presentan varias conclusiones obtenidas como respuesta a las preguntas de investigaci´ on planteadas en el estudio de mapeo sistem´ atico; adem´ as se complementa con el an´ alisis de algunas relaciones obtenidas entre los resultados. PI1.2. En la secci´ on §5.3.1 se observ´ o que las instituciones de Europa son l´ ıderes en el estudio acerca de GraphQL y tienen la mayor´ ıa de publicaciones (60,74%), seguidas con una distancia significativa por los otros continentes. Sin embargo, se not´ o que a´ un no existe una comunidad cient´ıfica especializada en este tema, aunque se destaca las aportaciones de la Universidad de Linkoping. PI1.3. En la secci´ on §5.3.2 se identific´ o que el 46,43% de publicaciones son art´ ıculos de conferencias, seguidos de la literatura gris, art´ ıculos de revistas y art´ ıculos de talleres. Adem´ as, en la figura §5.15 se muestra la relaci´ on con los resultados de PI1. 4 y PI1. 6para analizar que tipos de investigaci´ on y en que contexto se realiza los estudios por las sedes; se observ´ o que incluir la literatura gris en el estudio de mapeo sistem´ atico fue una decisi´ on adecuada ya que su producci´ on aport´ o el 53,84% de investigaci´ on de evaluaci´ on y validaci´ on. Opinion paper Solution proposal Evaluation research Journals Conferences Workshops 1 1,19% 2 2,38% 2 2,38% 2 2,38% 2 2,38% 3 3,57% 4 4,76% 5 5,95% 5 5,95% 5 5,95% 5 5,95% 6 7,14% 89,52% 8 9,52% 9 10,71% 17 20,24% Validation research Experience papers Gray literature 20,24% Academic Industrial 11,19% 7,14% 8 9,52% 17 15 17,86% 44,05% Venue type Research type 84 (100%) Study setting 84 (100%) 37 6 Figura 5.15: Publicaciones por contexto de estudio, por tipo de investigaci´ on y por tipo de sede Aunque GraphQL es un tema joven, se destaca publicaciones en conferencias relevantes como WWW (Clase 1: A++) y ESEC/FSE (Clase 1: A+) y en revistas del cuartil 1 como ”Molecular Biology, Cheminformatics” e ”IT Professional”. Sin 86 5.4. CONCLUSIONES embargo, se concluye que los estudios acerca de GraphQL se deber´ ıa aumentar y mejorar la calidad de sus pruebas emp´ ıricas. PI1.4. En la secci´ on §5.3.3 se identifica que la mayor´ ıa de investigaciones (61,91%) son de tipo validaci´ on o evaluaci´ on, lo que significa que realizaron una evaluaci´ on emp´ ırica en sus estudios. Sin embargo, en estos estudios, s´ olo el 17,86% se realizaron en la pr´ actica de la industria de la ingenier´ ıa de software (es decir, investigaci´ on de evaluaci´ on). Adem´ as, se analiz´ o los tipos de sede relativos a la investigaci´ on de ”validaci´ on” y ”evaluaci´ on”, en donde, sorpresiva mente la literatura gris muestra un 16,66% de estudios con evaluaciones emp´ ıricas incluso aplicadas en el entorno de la industria; esto indica que las universidades contribuyeron con estudios acad´ emicos relevantes en el estudio de GraphQL (v´ ease figura §5.15). En este sentido, surge la siguiente pregunta ¿es posible mejorar la calidad de la evidencia emp´ ırica de los estudios GraphQL? Con la informaci´ on recolectada en este estudio, se recomienda a los investigadores que para mejorar la calidad de la evidencia emp´ ırica, realicen sus estudios utilizando los m´ etodos descritos en la secci´ on §5.2.4. PI1.5. En la secci´ on §5.3.4 se encontr´ o a lo largo del tiempo un crecimiento de estudios en cantidad y calidad. La figura §5.16 muestra la relaci´ on entre los resultados de las preguntas PI1. 3, PI1. 4, y PI1. 5; en donde, se observa que a partir de 2019 aparecen trabajos de revistas que generalmente tienen m´ as rigor para su publicaci´ on, as´ ı como la calidad de la evidencia emp´ ırica expuesta en investigaciones de ”validaci´ on” y ”evaluaci´ on”. Estos resultados corroboran que la motivaci´ on para realizar el presente SMS fue acertada. PI1.6. En la secci´ on §5.3.5, por un lado, se analiz´ o el entorno de estudio en relaci´ on con el tipo de investigaci´ on, en donde, se observ´ o que la mayor´ ıa de publicaciones son de tipo de investigaci´ on de validaci´ on en el ´ ambito acad´ emico (v´ ease la figura §5.15); esto sugiere que los investigadores realizaron sus estudios en contextos sint´ eticos sin aplicarlos en la pr´ actica de la ingenier´ ıa del software. En este sentido, se encontr´ o que otro punto clave para mejorar la calidad de la investigaci´ on de GraphQL es aplicar los estudios en contextos industriales y gubernamentales. Por otro lado, se observ´ o que los estudios en las publicaciones utilizaron 7 de las 15 ´ areas de conocimiento de SWEBOK (v´ ease figura §5.10), abriendo una oportunidad de investigaci´ on en el resto de las ´ areas de conocimiento descritas en la 87 CAP´ ITULO 5. ESTUDIO DE MAPEO SISTEM ´ ATICO DE GRAPHQL JournalsConferencesWorkshopsGray literature 1 1,69% 1 1,69% 1 1,69% 2 2,38% 2 2,38% 1 1,69% 3 3,57% 3 3,57% 4 4,76% 4 4,76% 4 4,76% 5 5,95% 5 5,95% 7 8,33% 13 15,48% 8 9,52% 10 11,90% 10 11,90% Evaluation research Validation research Solution proposal Experience papers Opinion paper 1 1,69% 1 1,69% 1 1,69% 1 1,69% 1 1,69% 1 1,69% 1 1,69% 2 2,38% 2 2,38% 2 2,38% 2 2,38% 2 2,38% 3 3,57% 4 4,76% 4 4,76% 4 4,76% 3 3,57% 3 3,57% 5 5,95% 3 3,57% 6 7,14% 7 8,33% 13 15,48% 12 14,29% Venue type Year 84 (100%) Research type 84 (100%) 2016 2017 2018 2019 2020 2021 Figura 5.16: Publicaciones por tipo de investigaci´ on, por a˜ no y por tipo de sede Secci´ on §5.2.4. PI1.7. En la secci´ on §5.3.6 se responde c´ omo la comunidad cient´ ıfica estudi´ o el paradigma GraphQL a trav´ es de las siguientes m´ etricas de clasificaci´ on: contribuciones t´ ecnicas, sus tipos y dominios, componentes GraphQL y APIs p´ ublicas utilizadas en las publicaciones. La figura §5.17 muestra la relaci´ on entre PI1. 4 y PI1. 7, en donde, se nota que las contribuciones de tipo ”implementaci´ on” en las conferencias son los estudios m´ as concurrentes, dando a los investigadores una gu´ ıa para entender lo que se est´ a investigando y lo que falta investigar acerca de GraphQL y en donde publicarlo. Las conclusiones encontradas en esta secci´ on son en primer lugar, la identificaci´ on de una brecha de investigaci´ on en el dominio del cliente del servicio GraphQL, ya que el 72,73% de las contribuciones de las publicaciones se realizaron en el dominio del proveedor (v´ ease la figura §5.11). En segundo lugar, los tipos de contribuci´ on m´ as frecuentes de los estudios son la implementaci´ on y el an´ alisis de GraphQL (v´ ease la figura §5.17) publicados con una frecuencia similar en art´ ıculos de conferencias y literatura gris; en este sentido, se observa que las implementaciones pueden mejorar su calidad mediante la validaci´ on o evaluaci´ on de sus estudios utilizando los m´ etodos de investigaci´ on descritos en la secci´ on §5.2.4. En tercer lugar, en el tipo de contribuci´ on 88 5.5. RESUMEN / 2020 88 44 221717 Venue Type Implementation Analysis ApplicationsExtension Integration Implementation 1515 3131 1212 66 Analysis ApplicationsExtension Integration Journals Conferences Workshops Gray literature Research methods No method Research method 2323 22 32 32 22 1 4 1 Figura 5.17: Publicaciones por tipo de contribuci´ on, por tipo de sede y por m´ etodo de investigaci´ on ”an´ alisis”, se destacan las comparaciones entre REST y GraphQL (v´ ease la Tabla §5.9), mostrando claramente que la comunidad estudi´ o GraphQL como una alternativa a REST para implementar APIs web. En cuarto lugar, se logr´ o mapear los componentes del paradigma GraphQL que fueron mencionados, utilizados y ejemplificados en las publicaciones. De manera general, se observa que los componentes m´ as estudiados son las consultas, los esquemas, los objetos y los tipos escalares; concluimos que este comportamiento se debe a que estos componentes son fundamentales y necesarios para implementar APIs GraphQL (ver figura §5.14). En este sentido, se plantea otra pregunta de discusi´ on ¿hay componentes de GraphQL que deber´ ıan ser estudiados m´ as a profundidad? Esta pregunta nos sorprendi´ o porque la mayor´ ıa de los componentes no son tratados en detalle, incluyendo componentes esenciales como las mutaciones y las suscripciones, evidenciando otra laguna en los estudios. Por ´ultimo, se identific´ o que la API p´ ublica de GitHub es la m´ as utilizada en las publicaciones, y tambi´ en se identific´ o una cierta tendencia en implementar APIs REST p´ ublicas y sus equivalentes en APIs GraphQL. 5.5 RESUMEN GraphQL es un enfoque novedoso para el desarrollo de APIs que est´ a ganando adeptos, por lo cual, el foco principal de este apartado fue realizar un estudio de mapeo sistem´ atico (SMS) de la literatura para mostrar una visi´ on general de la investigaci´ on 89 CAP´ ITULO 5. ESTUDIO DE MAPEO SISTEM ´ ATICO DE GRAPHQL e identificar las tendencias y lagunas en el campo de GraphQL. El estudio de mapeo sistem´ atico respondi´ o a seis preguntas de investigaci´ on y clasific´ o los estudios en ´ areas generales y espec´ ıficas sobre GraphQL. En particular, se centr´ o en averiguar qui´ en, d´ onde, cu´ ando, qu´ e y por qu´ e se investig´ o GraphQL, as´ ı como en contextualizar las ´ areas espec´ ıficas de investigaci´ on con respecto al paradigma de GraphQL. Como conclusiones generales, se observ´ o que el estudio del paradigma GraphQL tiene una aceptaci´ on constante y creciente desde su aparici´ on. A pesar de que la aceptaci´ on de GraphQL como un enfoque novedoso para el desarrollo de APIs es cada vez mayor entre los profesionales, todav´ ıa no existe una comunidad cient´ ıfica ampliamente establecida en torno a este tema. En cuanto a los estudios analizados, se encontr´ o una tendencia de publicaci´ on en sedes de mayor calidad, aunque es necesario mejorar la calidad de la evidencia emp´ ırica de los estudios mediante la aplicaci´ on de m´ etodos de investigaci´ on ampliamente usados en la ingenier´ ıa de software, tambi´ en se recomienda realizar los estudios en entornos industriales y gubernamentales para fortalecer la base de conocimiento de GraphQL. Se encontr´ o que los componentes establecidos en el paradigma GraphQL necesitan ser validados y evaluados con mayor rigor. Se entiende que el tema es muy joven y necesita madurar en algunos aspectos, por lo que este estudio ayudar´ a a los investigadores a obtener una amplia visi´ on de lo que se ha investigado y de los posibles temas de investigaci´ on de GraphQL en el futuro. 90 PROPUESTA PARTE III 6.2. ENTORNO EXPERIMENTAL Figura 6.1: Respuestas de la encuesta diagn´ ostica var a los participantes a realizar las tareas de formaci´ on, estas fueron calificadas. Las tareas fueron las siguientes: i) Proyecto de desarrollo, el objetivo fue instalar el ambiente de desarrollo (ver Secci´ on §6.2.8), crear un proyecto de programaci´ on, configurar la conexi´ on a la base de datos, y realizar tareas de consulta de datos desde el proyec- to creado. ii) Desarrollo API REST, el objetivo es desarrollar una API REST, utilizando como base el proyecto creado en el apartado anterior, y consumido mediante la aplicaci´ on Postman1.iii) Desarrollo API GraphQL: el objetivo es desarrollar una API GraphQL, utilizando como base el proyecto creado en el primer apartado, y consumido mediante la aplicaci´ on GraphiQL2. Los casos utilizados en las tareas de formaci´ on fueron Pizzas, Libros, y Blogs, en donde, los artefactos utilizados fueron: un documento de requisitos y registro de soluci´ on, un diagrama relacional, una copia de seguridad y un script de creaci´ on de la base de datos. Los casos tienen diferente dificultad que b´ asicamente se presenta en la estructura y manejo de consultas de datos (ver Anexo §B.1). La Tabla §6.2 muestra las tareas, casos y actividades de formaci´ on previas a la ejecuci´ on del experimento. Durante la formaci´ on, los participantes asistieron a un total de seis clases s´ ıncronas en tres semanas. Cada semana se conform´ o por dos clases s´ ıncronas (3 horas y 2 horas), en donde en cada actividad, se realiza una introducci´ on te´ orica, una demostraci´ on pr´ actica, un taller pr´ actico de desarrollo de una API asistido por un experimentador, y como paso final se env´ ıo un deber para afianzar los conocimientos. Inicialmente, se empez´ o con 24 estudiantes como participantes, de los cuales uno se retir´ o en el transcurso de la formaci´ on, quedando finalmente 23 participantes para el experimento. 1Ver https://www.postman.com 2Ver https://github.com/graphql/graphiql 99 CAP´ ITULO 6. EFECTOS DE LAS ARQUITECTURAS REST Y GRAPHQL: DISE ˜ NO EXPERIMENTAL Tabla 6.2: Planificaci´ on de las tareas de formaci´ on Tareas Caso Actividades Duraci´ on (horas) Proyecto de desarrollo - Introducci´ on te´ orica a la arquitectura de software 0.5 Pizzas Ejemplo de creaci´ on de proyecto de desarrollo, conexi´ on y consulta de base de datos 2.5 Libros Taller pr´ actico de creaci´ on de proyecto y consulta de datos 2 Blogs Deber de creaci´ on de proyecto y consulta de datos 3 (ha) Desarrollo API REST - Introducci´ on te´ orica al paradigma REST 1 Pizzas Ejemplo de desarrollo de un API REST 2 Libros Taller pr´ actico de creaci´ on de un API REST 2 Blogs Deber de creaci´ on de un API REST 3 (ha) Desarrollo API GraphQL - Introducci´ on te´ orica al paradigma GraphQL 1 Pizzas Ejemplo de desarrollo de un API GraphQL 2 Libros Taller pr´ actico de creaci´ on de un API GraphQL 2 Blogs Deber de creaci´ on de un API GraphQL 3 (ha) Leyenda: ha - horas aut´ onomas Total 24 6.2.7 Tareas experimentales En esta secci´ on, se dise˜ n´ o tres tareas experimentales (eventos, facturas, notas) que tienen el mismo grado de complejidad entre ellas; y un grado de complejidad promedio comparado con las tareas de formaci´ on. Cada tarea tiene como objetivo implementar un API que realice operaciones de datos (CRUD, por su acr´ onimo en ingl´ es de Create, Read, Update, and Delete); pero no implica la creaci´ on de interfaces de usuario. Previo a la realizaci´ on de la tarea, se entreg´ o a los participantes los siguientes artefactos: una copia de seguridad de la base de datos; un script en lenguaje SQL de la estructura de la base de datos y datos de prueba (en el caso que el participante tenga inconvenientes en la carga de la copia de seguridad); un diagrama relacional de la base de datos; un archivo Microsoft Excel con los requisitos de las operaciones que deben implementar, y una secci´ on para que puedan registrar los tiempos y evidencias de resoluci´ on de cada requisito; y por ´ ultimo una plantilla de c´ odigo fuente del proyecto (basado en el ejemplo revisado en la etapa de formaci´ on). A continuaci´ on, se detalla los requisitos de las tareas experimentales: 100 6.2. ENTORNO EXPERIMENTAL Tarea experimental 1: Gesti´on de Eventos El objetivo de esta tarea es implementar una API que contenga las operaciones para la gesti´ on de eventos, de acuerdo a la estructura de datos que se presenta en el diagrama de la Figura §6.2. Figura 6.2: Diagrama relacional de la base de datos de eventos Los requisitos de operaciones de datos que debe proveer la API son: Insertar un registro de evento Actualizar un registro de evento Eliminar un registro de evento Consultar los registros de los eventos Consultar el registro de un evento, filtrado por el campo: eve id Asignar un participante a un evento Eliminar un participante de un evento Consulta compuesta: Consultar las salas y sus eventos • tablas: sala, evento • campos: sal id, sal nombre, eve nombre, y eve costo Consulta compuesta: Consultar un evento y sus participantes • tablas: evento, evento participante, participante 101 CAP´ ITULO 6. EFECTOS DE LAS ARQUITECTURAS REST Y GRAPHQL: DISE ˜ NO EXPERIMENTAL • campos: eve nombre, par cedula, par nombre, y evepar pago • par´ ametro: eve id Consulta compuesta: Consultar las salas y eventos de un participante • tablas: sala, evento, evento participante, participante • campos: sal nombre, eve nombre, eve costo, par nombre, y evepar pago • par´ ametro: par id Tarea experimental 2: Gesti´on de Facturas El objetivo de esta tarea es implementar una API que contenga las operaciones para la gesti´ on de facturas, de acuerdo a la estructura de datos que se presenta en el diagrama de la Figura §6.3. Figura 6.3: Diagrama relacional de la base de datos de facturas Los requisitos de operaciones de datos que debe proveer la API son: Insertar un registro de factura Actualizar un registro de factura Eliminar un registro de factura Consultar los registros de las facturas Consultar el registro de una factura, filtrado por el campo: fac id Asignar un producto a una factura Eliminar un producto de una factura 102 6.2. ENTORNO EXPERIMENTAL Consulta compuesta: Consultar los clientes y sus facturas • tablas: cliente, factura • campos: cli id, cli nombre, fac id, y fac fecha Consulta compuesta: Consultar una factura y sus productos • tablas: factura, factura producto, producto • campos: fac id, pro id, pro nombre, y facpro cantidad • par´ ametro: fac id Consulta compuesta: Consultar las facturas con sus productos, de un cliente • tablas: cliente, factura, factura producto, producto • campos: cli nombre, fac id, pro nombre, pro pvp, y facpro cantidad • par´ ametro: cli id Tarea experimental 3: Gesti´on de Notas El objetivo de esta tarea es implementar una API que contenga las operaciones para la gesti´ on de notas de alumnos, de acuerdo a la estructura de datos que se presenta en el diagrama de la Figura §6.4. Figura 6.4: Diagrama relacional de la base de datos de notas Los requisitos de operaciones de datos que debe proveer la API son: Insertar un registro de actividad 103 CAP´ ITULO 6. EFECTOS DE LAS ARQUITECTURAS REST Y GRAPHQL: DISE ˜ NO EXPERIMENTAL Actualizar un registro de actividad Eliminar un registro de actividad Consultar los registros de las actividades Consultar el registro de una actividad, filtrado por el campo: act id Asignar un estudiante a una actividad Eliminar un estudiante de una actividad Consulta compuesta: Consultar las materias y sus actividades • tablas: materia, actividad • campos: mat id, mat nombre, act nombre, y act descripcion Consulta compuesta: Consultar una actividad y la nota de los estudiantes • tablas: actividad, actividad nota, estudiante • campos: act nombre, est cedula, est nombre, y actnot nota • par´ ametro: act id Consulta compuesta: Consultar las materias, actividades y notas, de un estudiante • tablas: materia, actividad, actividad nota, estudiante • campos: mat nombre, act nombre, act descripcion, est nombre, y actnot nota • par´ ametro: est id 6.2.8 Instrumentaci´on En esta secci´ on se lista los artefactos que componen la instrumentaci´ on en cada fase del proceso experimental. La descripci´ on completa de los artefactos se pueden ver en el paquete de laboratorio del experimento disponible en el Anexo §B. Instrumentaci´on de las tareas de formaci´on Encuesta demogr´afica/diagn´ostica: Formulario de Microsoft Forms 365 Online (Anexo §B.1.1) Ambiente de desarrollo, se conforma de varias aplicaciones y tecnolog´ ıas que son similares para los paradigmas REST y GraphQL, las cuales se especifican a continuaci´ on: Ambiente de desarrollo integrado IDE: Visual Studio Code3v1.62 3Ver https://code.visualstudio.com 104 6.2. ENTORNO EXPERIMENTAL Lenguaje de programaci´ on: JavaScript4 Entorno de tiempo de ejecuci´ on de JavaScript: NodeJS5v14.17.5 Librer´ ıas npm6para REST/GraphQL: pg-promise v10.10.2, express v4.17.1 Librer´ ıas npm para GraphQL: graphql v15.5.0, graphql-server-express v1.4.1, graphqlimport v1.0.2, y graphql-tools v7.0.5 Motor de base de datos: PostgreSQL7v13, pgAdmin84 (herrramienta de administraci´ on) Aplicaci´ on cliente para el consumo del API REST: Postman9v8.12.2 Aplicaci´ on cliente para el consumo del API GraphQL: GraphiQL10 Introducci´on te´orica, se trata de artefactos de tipo presentaciones de Microsoft Power Point 36511, que introducen la teor´ ıa de los siguientes temas: Ambiente de desarrollo y arquitectura de software (Anexo §B.1.2). Estilo arquitect´ onico REST (Anexo §B.1.3). Lenguaje de consultas GraphQL (Anexo §B.1.4). Tareas de formaci´on, contienen artefactos de requisitos y dise˜ no de base de datos para el desarrollo de APIs, que fueron utilizados en las actividades de ejemplos, talleres pr´ acticos y deberes (ver tabla §6.2). La Tabla §6.3 muestra el listado de artefactos usados como instrumentaci´ on de las tareas de formaci´ on. Instrumentaci´on de las tareas experimentales Ambiente de desarrollo, se realiz´ o en el mismo ambiente de desarrollo que las tareas de formaci´ on. 4Ver https://www.javascript.com 5Ver https://nodejs.org 6Ver https://www.npmjs.com 7Ver https://www.postgresql.org 8Ver https://www.pgadmin.org 9Ver https://www.postman.com 10Ver https://github.com/graphql/graphiql 11https://www.microsoft.com/en-ww/microsoft-365/powerpoint 105 CAP´ ITULO 6. EFECTOS DE LAS ARQUITECTURAS REST Y GRAPHQL: DISE ˜ NO EXPERIMENTAL Tabla 6.3: Instrumentaci´ on de las tareas de formaci´ on Tarea Artefactos Anexo Gesti´ on de Pizzas Respaldo de la base de datos (archivo .backup) §B.1.5 Script estructura de la bdd y datos de prueba (archivo .sql) Diagrama relacional de la base de datos (archivo .png) Requisitos y registro del tiempo de soluci´ on (Microsoft Excel 365) Gesti´ on de Libros Respaldo de la base de datos (archivo .backup) §B.1.6 Script estructura de la bdd y datos de prueba (archivo .sql) Diagrama relacional de la base de datos (archivo .png) Requisitos y registro del tiempo de soluci´ on (Microsoft Excel 365) Gesti´ on de Blogs Respaldo de la base de datos (archivo .backup) §B.1.7 Script estructura de la bdd y datos de prueba (archivo .sql) Diagrama relacional de la base de datos (archivo .png) Requisitos y registro del tiempo de soluci´ on (Microsoft Excel 365) Tareas experimentales, al igual que las tareas de formaci´ on, contienen artefactos de requisitos y dise˜ no de base de datos para el desarrollo de APIs, que deben implementarse en los paradigmas REST y GraphQL, de acuerdo al dise˜ no del experimento establecido en la tabla §6.1. La instrumentaci´ on utilizada en las tareas experimentales se listan en la Tabla §6.4. Tabla 6.4: Instrumentaci´ on de las tareas experimentales Tarea Artefactos Anexo Gesti´ on de Eventos Respaldo de la base de datos (archivo .backup) §B.2.1 Script estructura de la bdd y datos de prueba (archivo .sql) Diagrama relacional de la base de datos (archivo .png) Requisitos y registro del tiempo de soluci´ on (Microsoft Excel 365) Gesti´ on de Facturas Respaldo de la base de datos (archivo .backup) §B.2.2 Script estructura de la bdd y datos de prueba (archivo .sql) Diagrama relacional de la base de datos (archivo .png) Requisitos y registro del tiempo de soluci´ on (Microsoft Excel 365) Gesti´ on de Notas Respaldo de la base de datos (archivo .backup) §B.2.3 Script estructura de la bdd y datos de prueba (archivo .sql) Diagrama relacional de la base de datos (archivo .png) Requisitos y registro del tiempo de soluci´ on (Microsoft Excel 365) Instrumentaci´on de las tareas de an´alisis Encuesta evaluativa: se utilizar´ a la misma encuesta demogr´ afica/diagn´ ostica, pero sin las preguntas demogr´ aficas. Se operativizar´ a mediante un formulario de Microsoft 106 6.2. ENTORNO EXPERIMENTAL Forms 365 Online (Anexo §B.1.1). Pruebas de aceptaci´on, se utilizar´ a una hoja de c´ alculo de Microsoft Excel 365 para registrar el resultado de las pruebas de aceptaci´ on que se realizar´ an a cada pregunta de las tareas experimentales de los participantes (Anexo §B.3.1). An´alisis estad´ıstico, el an´ alisis estad´ ıstico de los resultados del experimento se realizar´ a en las herramientas IBM SPSS Statistics12 v21.0, y Statgraphics13 v16.1.03. Ver los scripts de c´ alculos en el Anexo §B.3.1. 6.2.9 Recolecci´on de datos En la Tabla §6.5 se muestra la agenda de planificaci´ on de actividades previstas para ejecutar el dise˜ no del experimento presentado en la tabla §6.1. Tabla 6.5: Agenda del experimento Horario Actividades Tiempo (Min) 14H00-14H05 Indicaciones generales 5 14H05-14H10 Entrega del respaldo y script de la base de datos 5 14H10-14H25 Restauraci´ on de la base de datos 15 14H25-14H30 Entrega de requisitos - Sesi´ on 1 (Excel y diagrama relacional) 5 14H30-16H30 SESI ´ ON 1 120 16H30-16H40 Recolecci´ on de tareas 10 16H40-16H45 Receso 5 16H45-16H50 Entrega del respaldo y script de la base de datos 5 16H45-16H50 Restauraci´ on de la base de datos 5 16H50-17H00 Entrega de requisitos - Sesi´ on 2 (Excel y diagrama relacional) 5 17H00-19H00 SESI ´ ON 2 120 19H00-19H10 Recolecci´ on de tareas 10 Los experimentadores encargados de la ejecuci´ on del experimento, recolecci´ on del c´ odigo fuente de las tareas de los participantes, y medici´ on de la variable respuesta fueron (A. Qui˜ na, C. Guevara, y F. Chulde). Para la obtenci´ on de los elementos necesarios para las m´ etricas de calidad interna, en uso, y la curva de aprendizaje, se lo har´ a con las siguientes actividades: i) informaci´ on del documento Excel de requisitos, en donde los participantes registran el tiempo 12https://www.ibm.com/products/spss-statistics 13https://www.statgraphics.com 107 CAP´ ITULO 6. EFECTOS DE LAS ARQUITECTURAS REST Y GRAPHQL: DISE ˜ NO EXPERIMENTAL de soluci´ on de cada requisito, y evidencian con capturas de pantallas la ejecuci´ on de la soluci´ on. ii) Se cargar´ a el c´ odigo fuente de los participantes en un ambiente de desarrollo y luego se realizar´ a las pruebas de aceptaci´ on de la ejecuci´ on de cada pregunta de las tareas experimentales, luego el resultado se lo registrar´ a en una hoja de Excel de resultados. 6.2.10 An´alisis El an´ alisis estad´ ıstico del experimento se realizar´ a con las herramientas IBM SPSS Statistics, y Statgraphics. Para obtener el an´ alisis de los datos se utilizar´ a la media, desviaci´ on est´ andar, m´ ınimo, m´ aximo, rango, asimetr´ ıa y curtosis estandarizada. Mientras que, para comprobar la hip´ otesis se utilizar´ a el modelo lineal de efectos mixtos, el cual, es propuesto y validado en estudios similares [30,83]. 6.3 RESUMEN En este cap´ ıtulo, se ha presentado un dise˜ no experimental que tiene como objetivo analizar el proceso de desarrollo del software, con el prop´ osito de comparar el efecto de los paradigmas de programaci´ on GraphQL y REST con respecto a la calidad del software, desde un punto de vista de los investigadores en un contexto acad´ emico. En este sentido, se ha elaborado una serie de artefactos necesarios para operativizar las fases de formaci´ on, ejecuci´ on, y an´ alisis del experimento; que est´ an descritos con m´ as detalle en el Anexo §B. El experimento dise˜ nado en el presente cap´ ıtulo, se validar´ a en el Cap´ ıtulo §9, en donde se mostrar´ a los resultados de su ejecuci´ on, el an´ alisis, y conclusiones de dichos resultados. 108 7.2. ENTORNO EXPERIMENTAL 7.2.7 Tareas experimentales En esta secci´ on, se dise˜ n´ o un laboratorio computacional con dos tareas experimentales de acuerdo con el dise˜ no, tratamientos y casos de usos definidos para el experimento. Tarea experimental 1: Consulta a la API REST de Mendeley El objetivo de esta tarea es ejecutar los casos de uso de consultas de datos (ver secci´ on §7.2.6) en la API REST de Mendeley. Para lo cual, se debe desarrollar una aplicaci´ on cliente (Node JS) que implemente los casos de uso de consulta de datos a la API REST de Mendeley2disponible en la nube, de acuerdo al dise˜ no del experimen- to establecido en la tabla §7.1. Luego, la aplicaci´ on deber´ a almacenar las respuestas de las consultas en archivos con extensi´ on JSON. La aplicaci´ on se ejecutar´ a desde una PC-local, tal como se muestra en la arquitectura del laboratorio experimental (Figura §7.1). Tarea experimental 2: Consulta a la API GraphQL (envoltorio) El objetivo de esta tarea es ejecutar los mismos casos de uso de la tarea experimental 1, pero utilizando el lenguaje de consulta de GraphQL. Para lo cual, se debe desarrollar dos aplicaciones: la primera aplicaci´ on debe ser una API GraphQL que proporcione el servicio de datos de Mendeley; y la otra debe ser una aplicaci´ on que consuma mediante lenguaje GraphQL los datos expuestos por la primera API. En este sentido, se propone desarrollar la primera aplicaci´ on con una arquitectura h´ ıbrida REST/GraphQL, en donde, se implemente una API GraphQL que envuelva al API REST de Mendeley mediante la caracterizaci´ on de su esquema de datos en GraphQL, y se utilice como origen de datos al API REST de Mendeley. Para la segunda aplicaci´ on, se propone utilizar el mismo cliente de la tarea experimental 1, pero que ejecute los casos de uso de consultas a la API GraphQL y que de igual manera almacene las respuestas de las consultas en archivos con extensi´ on JSON, tal como se muestra en la arquitectura del laboratorio experimental propuesto en la Figura §7.1. 7.2.8 Instrumentaci´on En esta secci´ on se lista la instrumentaci´ on como infraestructura, tecnolog´ ıa, y librer´ ıas que componen el laboratorio computacional: 2https://dev.mendeley.com/ 115 CAP´ ITULO 7. EFECTOS DE LAS ARQUITECTURAS H´ IBRIDAS: DISE ˜ NO EXPERIMENTAL Laboratorio experimental Cloud PC-local API REST API GraphQL (Envoltorio) Resolvers Type System Cliente (Tareas experimentales) Consulta de datos Casos de uso GraphQL Consulta de datos Casos de uso REST Respuesta Respuesta Archivos (JSON) Respuesta Figura 7.1: Arquitectura del laboratorio experimental Especificaciones de la PC-local, es una computadora que tiene las siguientes caracter´ ısticas: Sistema Operativo: Windows 10 Pro 64-bit Procesador: Intel (R) Core (TM) i7-3110M CPU CPU @ 2.40GHz 2.40 GHz Memoria: RAM 8 GB Conexi´ on de internet de 75 MB de ancho de banda. Ambiente de desarrollo, se conforma de las siguientes aplicaciones y tecnolog´ ıas: Ambiente de desarrollo integrado IDE: Visual Studio Code v1.62 Lenguaje de programaci´ on: JavaScript Entorno de tiempo de ejecuci´ on de JavaScript: NodeJS v14.17.5 Librer´ ıas npm de la aplicaci´ on cliente: react 16.8.6, react-apollo 2.5.5 116 7.2. ENTORNO EXPERIMENTAL Librer´ ıas npm para el API GraphQL: graphql v15.5.0, graphql-server-express v1.4.1, graphql-import v1.0.2, y graphql-tools v7.0.5, cors 2.8.5 Aplicaci´ on cliente para el consumo del API REST: Postman v8.12.2 Aplicaci´ on cliente para el consumo del API GraphQL: GraphiQL Recolecci´on y an´alisis de datos, se conforma de las siguientes aplicaciones: Microsoft Excel 365 IBM SPSS v21.0 Statgraphics v16.1.03 7.2.9 Recolecci´on de datos En la Tabla §7.2 se muestra la estructura de los datos que tendr´ a el archivo Microsoft Excel, donde se registrar´ a los resultados de la ejecuci´ on del experimento dise˜ nado en tabla §7.1. Tabla 7.2: Estructura de la recolecci´ on de datos Campo Descripci´ on Nro. N´ umero de la muestra (auto-num´ erico) Caso de uso Caso de uso que se ejecuta Nivel Nivel de complejidad de la consulta del caso de uso Nro. Registros Cantidad de registros consultados en el caso de uso Repetici´ on N´ umero de repetici´ on de ejecuci´ on (valores entre 1 y 3) Paradigma REST, o GraphQL (representa la arquitectura h´ ıbrida REST/GraphQL) Tiempo Tiempo de respuesta de la ejecuci´ on del caso de uso medido en milisegundos Peso Tama˜ no del archivo de respuesta medido en bytes 7.2.10 An´alisis El an´ alisis estad´ ıstico del experimento se realizar´ a con las herramientas IBM SPSS Statistics, y Statgraphics. Para realizar las pruebas de normalidad de los datos, en donde, se utilizar´ a la desviaci´ on est´ andar, coeficiente de variaci´ on, m´ ınimo, m´ aximo, rango, sesgo estandarizado, y curtosis estandarizada. Mientras que, para comprobar la hip´ otesis se utilizar´ a el modelo lineal mixto. 117 CAP´ ITULO 7. EFECTOS DE LAS ARQUITECTURAS H´ IBRIDAS: DISE ˜ NO EXPERIMENTAL 7.3 RESUMEN En este cap´ ıtulo, se present´ o el dise˜ no experimental que tiene como objetivo analizar el proceso de desarrollo del software, con el prop´ osito de comparar la eficiencia de las arquitecturas h´ ıbridas REST/GraphQL con respecto a la calidad del software, desde un punto de vista de los investigadores en un contexto controlado de un laboratorio computacional. En este sentido, el experimento se dise˜ n´ o y document´ o basado en la gu´ ıa de Wohlin et al. [186] con la intenci´ on de ser lo m´ as metodol´ ogicos posibles para aportar una mayor validez a los resultados obtenidos. El experimento dise˜ nado en este cap´ ıtulo se validar´ a en el cap´ ıtulo §10, en donde se ejecutar´ a y mostrar´ a el an´ alisis de los resultados, conclusiones y trabajos futuros. 118 8 ACUERDOS DE NIVEL DE SERVICIO PARA APISGRAPHQL 119 La innovaci´ on distingue a los l´ ıderes de los seguidores. Steve Jobs (1955 – 2011), Empresario y magnate estadounidense En este cap´ıtulo, se presenta una propuesta para modelar y operativizar acuerdos de nivel de servicio (SLA, por sus siglas en ingl´es de Service Level Agreements) para APIs GraphQL. Adem´as, como parte de la propuesta se propone una herramienta para validar y registrar SLA Planes de proveedores de APIs GraphQL. En la secci´on §8.1, se destaca una breve discusi´on de los antecedentes y motivaci´on que impulsan el desarrollo de la propuesta.En la secci´on §8.2, se establece la especificaci´on de SLA para APIs GraphQL que contiene: i) La especificaci´on y esquema del documento de acuerdos de nivel de servicios (SLA); ii) Ciclo de vida del desarrollo de APIs GraphQL basado en SLA; iii) Procesos generales para modelar y operativizar los documentos SLA. La secci´on §8.3 se propone la herramienta SLA GraphQL Manager para registrar SLA Planes de proveedores de APIs GraphQL, y registrar clientes a los SLA Planes ofertados por los proveedores. Por ´ultimo, la secci´on §8.4 resume el cap´ıtulo. CAP´ ITULO 8. ACUERDOS DE NIVEL DE SERVICIO PARA APIS GRAPHQL 8.1 INTRODUCCI ´ ON La motivaci´ on de este cap´ ıtulo es contestar la pregunta de investigaci´ on PI4: ¿En qu´ e medida es posible modelar los acuerdos de APIs GraphQL?. Para lo cual, se propone un est´ andar de c´ odigo abierto llamado SLA4GraphQL, que sirve para describir SLA para APIs GraphQL, la que a su vez se considera como la principal contribuci´ on de la presente memoria. La especificaci´ on del est´ andar describe c´ omo modelar y operativizar acuerdos de nivel de servicio (SLA) para APIs GraphQL, que se podr´ a utilizar como instrumentaci´ on en la gobernanza de arquitecturas h´ ıbridas orientadas a microservicios. El objetivo de SLA4GraphQL, es presentar un est´ andar que establezca un contrato entre el proveedor de una API GraphQL y el cliente de consumo de la API, en donde, se establece expl´ ıcitamente los t´ erminos, limitaciones, y planes del servicio de la API. En primer lugar, se toma como base la propuesta SLA4OAI que promueve la especificaci´ on abierta para acuerdos de nivel de servicios (SLA) sobre las API REST definidas a trav´ es de la especificaci´ on OpenAPI [46,71] revisada en el cap´ ıtulo §4; a la cual, se propone complementar las especificaciones de modelado necesarias que cubran las particularidades del uso y consumo de acuerdos de nivel de servicios (SLA) para APIs GraphQL. Luego se establece un ciclo de vida para el desarrollo de APIs GraphQL basadas en SLA, y la descripci´ on de los principales procesos para operativizar los SLA. Adem´ as, se complementa la propuesta con una herramienta que valida el modelado de acuerdos y operativiza el registro de los planes SLA de proveedores, y el registro e instanciaci´ on de los planes para clientes de la API GraphQL. La propuesta SLA4GraphQL, se validar´ a en el cap´ ıtulo §11. 8.2 ESPECIFICACI ´ ON DE SLA PARA APISGRAPHQL En esta secci´ on, se propone un est´ andar de c´ odigo abierto llamado SLA4GraphQL que se basa en el est´ andar SLA4OAI [46,71] que especifica como describir acuerdos de nivel de servicios SLA para APIs GraphQL, el cual, se conforma por: la especificaci´ on del esquema del documento SLA (SLA Plan), un ciclo de vida para desarrollo de APIs, procesos de modelado y operativizaci´ on de SLA, y una herramienta para registrar y validar los SLA modelados. La descripci´ on de SLA es neutral de la tecnolog´ ıa del proveedor de la API GraphQL, con la intenci´ on de fomentar la innovaci´ on en la do- 120 8.2. ESPECIFICACI ´ ON DE SLA PARA APIS GRAPHQL cumentaci´ on y operativizaci´ on de APIs. Los proveedores que exponen APIs GraphQL podr´ an importar por medio de sus herramientas tecnol´ ogicas los componentes y m´ etricas claves de los SLA, para implementar las limitaciones establecidas en ellos de una manera estandarizada. 8.2.1 Especificaci´on del documento SLA Plan El documento SLA o tambi´ en mencionado en la memoria como SLA, o SLA Plan, contiene los acuerdos de nivel de servicio para una API GraphQL descrito en un archivo de extensi´ on (.yaml o .yml) con formato de serializaci´ on de datos YALM1. El esquema del documento SLA, est´ a basado en la estructura propuesta en SLA4OAI [71]. La Tabla §8.1 muestra la descripci´ on del objeto SLA, que contiene la estructura de los principales componentes del documento SLA para la propuesta SLA4GraphQL, y al mismo tiempo en la columna ”SLA4OAI” de la tabla se muestra la comparaci´ on de los componentes que tienen el mismo comportamiento y descripci´ on que la especificaci´ on SLA4OAI; en donde, se establece con el valor de ”Si” a los componentes que tienen la misma especificaci´ on y comportamiento entre las propuestas SLA4GraphQL y SLA4OAI. Tabla 8.1: Objeto SLA Comienzo de tabla Componente Tipo Descripci´ on SLA4OAI Contexto Objecto Contexto Obligatorio Contiene la informaci´ on principal del contexto SLA. Si Infraestructura Objecto Infrastructura Obligatorio Proporciona informaci´ on sobre las herramientas utilizadas para la gesti´ on del SLA como almacenamiento, c´ alculo, o gobernanza. Si Fijaci´ on de precios Objecto Precios Opcional. Describe la informaci´ on general de los precios de la API. Si M´ etricas Objecto M´ etricas Obligatorio Una lista de m´ etricas para usar en el contexto del SLA. No Planes Objecto Planes Opcional Un conjunto de planes para definir diferentes niveles de servicio por plan. No 1https://yaml.org/ 121 CAP´ ITULO 8. ACUERDOS DE NIVEL DE SERVICIO PARA APIS GRAPHQL Continuaci´ on de la Tabla §8.1 Componente Tipo Descripci´ on SLA4OAI Cuotas Objecto Cuotas Opcional Cuotas globales, estas son las cuotas predeterminadas, pero cada plan podr´ ıa anularlas m´ as adelante. No Tarifas Objecto Tarifas Opcional Tarifas globales, estas son las tarifas predeterminadas, pero podr´ ıan ser anuladas por cada plan m´ as adelante. No Garant´ ıas Objecto Garant´ ıas Opcional Garant´ ıas globales, estas son las garant´ ıas predeterminadas, pero podr´ ıan ser anuladas por cada plan m´ as adelante. Si Configuraciones Objecto Configuraciones Opcional Defina las configuraciones predeterminadas, luego cada plan puede ser anulado. Si Fin de tabla En este sentido, en esta secci´ on para los componentes que tienen el mismo comportamiento y descripci´ on que el est´ andar SLA4OAI, no se describir´ an sus especificaciones y se asumir´ an las especificaciones desplegadas por SLA4OAI [71] en https: //sla4oai.specs.governify.io/Specification.html y en el cap´ ıtulo §4; los componentes que no se describir´an son: contexto, infraestructura, fijaci´ on de precios, m´ etricas, garant´ ıas, y configuraci´ on. Por el contrario, en esta secci´ on se profundizar´ a las especificaciones de los componentes: planes, cuotas, y tarifas; que justamente especifican las particularidades del manejo para las APIs GraphQL. Objeto de cuotas (quotasObject) Este componente se estructura por un conjunto de objetos operaci´ on (operationObject) que contiene las operaciones disponibles del servicio de la API GraphQL proveedor. La finalidad de este objeto es describir las cuotas de las operaciones espec´ ıficas que proporcionar´ a el servicio de la API. La Tabla §8.2 muestra la estructura del objeto cuotas. Tabla 8.2: Objeto Cuotas (quotasObject) Patr´ on de campo Tipo Descripci´ on {nombreOperaci´ on}Objecto Operaci´ on Opcional Describe las operaciones del API GraphQL. Objeto Operaci´on (operationObject): contiene dos de las tres operaciones dispo- 122 8.2. ESPECIFICACI ´ ON DE SLA PARA APIS GRAPHQL nibles del servicio de la API GraphQL proveedor: consultas (queries) y mutaciones (mutations), en este punto, es importante aclarar que la operaci´ on suscripciones (subscriptions) se implementar´ a en una siguiente versi´ on de SLA4GraphQL. La Tabla §8.3 muestra la estructura del objeto operaci´ on. Tabla 8.3: Objeto Operaci´ on (operationObject) Patr´ on de campo Tipo Descripci´ on {nombreRuta}Objecto Ruta Opcional Son las rutas de los recursos consulta o mutaci´ on del API GraphQL. Objeto Ruta (pathObject): muestra la ruta de las consultas o mutaciones de la API GraphQL utilizando expresiones de rutas del lenguaje XPath2. La Tabla §8.4 muestra la estructura del Objeto Ruta. Tabla 8.4: Cuota: Objeto Ruta (pathObject) Patr´ on de campo Tipo Descripci´ on {nombreM´ etrica}Objecto L´ ımite Opcional Son los l´ ımites de la m´ etrica en la operaci´ on quer- y/mutation de la API GraphQL. En este aspecto, es necesario aclarar que GraphQL expone sus recursos (operaciones) a trav´ es de una ´ unica ruta (endpoint), por tal motivo, para obtener y validar las rutas espec´ ıficas de las operaciones se utiliz´ o las consultas de introspecci´ on al esquema de la API. Las respuestas de las consultas de introspecci´ on contienen en datos el esquema de la API, la que puede ser le´ ıda de una manera recursiva y/o referencial de objetos, por lo cual, es necesario realizar un tratamiento en la respuesta de la consulta para obtener el esquema de la API y seleccionar sus recursos (operaciones) de una manera m´ as simple. Por la naturaleza de los datos, en el tratamiento se estructur´ o el esquema del API en un documento de mapa de nodos jer´ arquico en formato XML para poder navegar y consultar sus objetos principales como operaciones, par´ ametros de operaciones y campos de respuesta de las operaciones. En este sentido, se analiz´ o varias opciones para cubrir estos requisitos; y una de las opciones m´ as viables fue utilizar el lenguaje XPath para buscar y seleccionar recursos en una estructura jer´ arquica de documentos XML. Por consiguiente, se estructur´ o el esquema del API GraphQL en un documento XML, para ser consultado mediante expresiones de rutas con el lenguaje XPath. Con el ´ animo de ilustrar esta secci´ on, en la Figura §8.1 se muestra a) un ejemplo de una consulta de introspecci´ on del esquema de API GraphQL; b) un ejemplo 2https://www.w3schools.com/xml/xpath_intro.asp 123 CAP´ ITULO 8. ACUERDOS DE NIVEL DE SERVICIO PARA APIS GRAPHQL de la respuesta de la consulta de introspecci´ on; c) un ejemplo de transformaci´ on de la respuesta a formato XML; y d) un ejemplo de una expresi´ on regular para escoger el elemento ”product” de la consulta ”InStore” del esquema de una API GraphQL. Figura 8.1: Ejemplo del proceso de Objeto Ruta Objeto L´ımite (limitObject): determina los l´ ımites permitidos de las m´ etricas aplicadas a la ruta de consulta o mutaci´ on de la API. Los nombres de las m´ etricas se pueden definir de dos maneras: por un lado, se puede utilizar las m´ etricas definidas en el Objeto M´ etricas, o por otro lado se puede hacer referencia a las funciones XPath3; en este caso, se deber´ a poner el nombre de la funci´ on XPath antecedido por el s´ ımbolo ” ”, por ejemplo: ” count”. Las funciones XPath son: boolean, ceiling, choose, concat, contains, count, current, document, element-available, false, floor, format-number, function-available, generate-id, id, key, lang, last, local-name, name, namespace-uri, normalize-space, not, number, position, round, starts-with, string, string-length, substring, substring-afteri, substring-before, sum, system-property, translate, true, unparsedentity-url. 3https://developer.mozilla.org/en-US/docs/Web/XPath/Functions 124 B.1. ENTRENAMIENTO Microsoft Power Point 3653que est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\01 Formaci´on\02 introducci´on-te´orica\01 introducci´onambiente-desarrollo.pptx”. B.1.3 Introducci´on te´orica al paradigma REST Es una presentaci´ on te´ orica acerca del estilo arquitect´ onico REST que sirvi´ o como base para el desarrollo de APIs REST en las tareas de formaci´ on y tareas experimentales. Este artefacto es un archivo de Microsoft Power Point 365 que est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\01 Formaci´on\02 introducci´on-te´orica\02 introducci´on-rest.pptx”. B.1.4 Introducci´on te´orica al paradigma GraphQL Es una presentaci´ on te´ orica acerca de GraphQL como lenguaje de consulta y tiempo de ejecuci´ on de APIs, que sirvi´ o como base para el desarrollo de APIs GraphQL en las tareas de formaci´ on y tareas experimentales. Este artefacto es un archivo de Microsoft Power Point 365 que est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\01 Formaci´on\02 introducci´on-te´orica\03 introducci´on-graphql.pptx”. B.1.5 Requisitos: Gesti´on de Pizzas Los artefactos de las tareas de requisitos a lo largo del experimento concretamente especifican requisitos de proyectos de desarrollo de APIs. En donde, cada caso contiene cuatro artefactos, de los cuales: las copias de seguridad y archivos de scripts de la base de datos se generaron desde la herramienta de administraci´ on pgAdmin 4 del motor de la base de datos PostgreSQL; los diagramas realacionales son archivos de gr´ aficos con extensi´ on PNG generados desde la herramienta Online Diagrams.net (draw.io)4; y los documentos de requisitos y registro de soluci´ on son archivos de Microsoft Excel 3655. A continuaci´ on, se muestra los requisitos de operaciones b´ asicas CRUD, y dise˜ no de base de datos para administrar Pizzas; que concretamente fueron utilizadas en las siguientes tareas de formaci´ on (ver Tabla §6.2): ST02- Ejemplo de creaci´ on de proyecto 3https://www.microsoft.com/es-ww/microsoft-365/powerpoint 4https://www.diagrams.net/ 5https://www.microsoft.com/es-ww/microsoft-365/excel 227 AP´ ENDICE B. EFECTOS DE LAS ARQUITECTURAS REST Y GRAPHQL: PAQUETE DE LABORATORIO de desarrollo, conexi´ on y consulta de base de datos; ST06-Ejemplo de desarrollo de un API REST; y ST10-Ejemplo de desarrollo de un API GraphQL. Copia de seguridad de la base de datos Es un archivo binario con extensi´ on .backup que contiene una copia de seguridad de la base de datos de Pizza, usado para que los participantes del experimento crearan esta base de datos en sus ambientes de desarrollo, y puedan desarrollar los ejemplos mostrados en las clases s´ ıncronas de la formaci´ on. El artefacto est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\01 Formaci´on\03 requisitos-tareas\01 gesti´on-pizzas\pizza.backup”. Script estructura de la BDD y datos de prueba Es un archivo con extensi´ on .sql que contiene scripts de creaci´ on de la estructura, e inserci´ on de datos de prueba de la base de datos Pizza, en lenguaje de consulta estructurado (SQL, por sus siglas en ingl´ es de Structured Query Language). El objetivo de este archivo es brindar a los participantes del experimento una alternativa de creaci´ on de la base de datos; o en el caso que el archivo pizza.backup no les funcion´ o por alguna raz´ on t´ ecnica. Este artefacto est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\01 Formaci´on\03 requisitos-tareas\01 gesti´on-pizzas\pizza.sql”. A continuaci´ on, se muestra el contenido del archivo pizza.sql: CREATE TABLE pizza ( id serial NOT NULL, name text NOT NULL, origin text NOT NULL, PRIMARY KEY (id) ); CREATE TABLE ingredient ( id serial NOT NULL, name text NOT NULL, calories integer NOT NULL, PRIMARY KEY (id) ); CREATE TABLE pizza ingredient 228 B.1. ENTRENAMIENTO ( id serial NOT NULL, pizza id integer NOT NULL, ingredient id integer NOT NULL, FOREIGN KEY (ingredient id) REFERENCES ingredient (id), FOREIGN KEY (pizza id) REFERENCES pizza (id) ); INSERT INTO pizza(id, name, origin) VALUES (1, ’Pizza Napolitana’, ’Italia’); INSERT INTO pizza(id, name, origin) VALUES (2, ’Pizza Carbonara’, ’Italia’); INSERT INTO ingredient(id, name, calories) VALUES (1, ’Queso mozzarella’, 280); INSERT INTO ingredient(id, name, calories) VALUES (2, ’Salsa de tomate’, 29); INSERT INTO ingredient(id, name, calories) VALUES (3, ’Anchoas’, 10); INSERT INTO ingredient(id, name, calories) VALUES (4, ’Queso parmesano’, 431); INSERT INTO ingredient(id, name, calories) VALUES (5, ’Cebollas’, 20); INSERT INTO ingredient(id, name, calories) VALUES (6, ’Bacon’, 541); INSERT INTO pizza ingredient(pizza id, ingredient id) VALUES (1, 1); INSERT INTO pizza ingredient(pizza id, ingredient id) VALUES (1, 2); INSERT INTO pizza ingredient(pizza id, ingredient id) VALUES (1, 3); INSERT INTO pizza ingredient(pizza id, ingredient id) VALUES (2, 2); INSERT INTO pizza ingredient(pizza id, ingredient id) VALUES (2, 4); INSERT INTO pizza ingredient(pizza id, ingredient id) VALUES (2, 5); INSERT INTO pizza ingredient(pizza id, ingredient id) VALUES (2, 6); Diagrama relacional de la base de datos Es un gr´ afico con extensi´ on .png que contiene el diagrama relacional de la estructura de la base de datos Pizza (ver figura §B.1), que sirvi´ o como complemento para especificar los requisitos de la gesti´ on de Pizza en las tareas de formaci´ on. Este artefacto est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de- laboratorio\01 Formaci´on\03 requisitos-tareas\01 gesti´on-pizzas\pizza-diagrama.png”. B.1.6 Requisitos: Gesti´on de Libros Los artefactos de esta tarea muestran los requisitos de operaciones b´ asicas CRUD, y dise˜ no de base de datos para administrar Libros; que concretamente fueron utilizadas en las siguientes tareas de formaci´ on (ver Tabla §6.2): ST03- Taller pr´ actico de creaci´ on de un proyecto y consulta de datos; ST07-Taller pr´ actico de creaci´ on de un API REST; 229 AP´ ENDICE B. EFECTOS DE LAS ARQUITECTURAS REST Y GRAPHQL: PAQUETE DE LABORATORIO Figura B.1: Diagrama relacional de la base de datos Pizza y ST11-Taller pr´ actico de creaci´ on de un API GraphQL. Copia de seguridad de la base de datos Es un archivo binario con extensi´ on .backup que contiene una copia de seguridad de la base de datos de Libros, usado para que los participantes del experimento crearan esta base de datos en sus ambientes de desarrollo, y puedan desarrollar los talleres establecidos en las clases s´ ıncronas de formaci´ on. El artefacto est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\01 Formaci´on\03 requisitos-tareas\02 gesti´on-libros\libros.backup”. Script estructura de la bdd y datos de prueba Es un archivo con extensi´ on .sql que contiene scripts de creaci´ on de la estructura, e inserci´ on de datos de prueba de la base de datos Libros, en lenguaje de consulta SQL. El objetivo de este archivo es brindar a los participantes del experimento una alternativa de creaci´ on de la base de datos. Este artefacto est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\01 Formaci´on\03 requisitos-tareas\01 gesti´on-libros\libros.sql”. A continuaci´ on, se muestra el contenido del archivo libros.sql: CREATE TABLE autor ( aut id serial NOT NULL, aut nombre text NOT NULL, aut pais text , PRIMARY KEY (aut id) ); CREATE TABLE libro ( lib id serial NOT NULL, 230 B.1. ENTRENAMIENTO lib titulo text NOT NULL, lib editorial text , PRIMARY KEY (lib id) ); CREATE TABLE autor libro ( aut lib id serial NOT NULL, aut id integer NOT NULL, lib id integer NOT NULL, aut lib autor principal boolean, PRIMARY KEY (aut id, lib id), FOREIGN KEY (aut id) REFERENCES autor (aut id), FOREIGN KEY (lib id) REFERENCES libro (lib id) ); INSERT INTO autor(aut id, aut nombre, aut pais) VALUES (1, ’Mario Piattini’, ’Argentina’); INSERT INTO autor(aut id, aut nombre, aut pais) VALUES (2, ’Javier Garzas’, ’Espa˜ na’); INSERT INTO libro(lib id, lib titulo, lib editorial) VALUES (1, ’Calidad del producto y proceso software’, ’Ra-Ma’); INSERT INTO libro(lib id, lib titulo, lib editorial) VALUES (2, ’Calidad de Sistemas de Informaci´ on’, ’Ra-Ma’); INSERT INTO libro(lib id, lib titulo, lib editorial) VALUES (3, ’F´ abricas de software’, ’Ra-Ma’); INSERT INTO autor libro(aut id, lib id, aut lib autor principal) VALUES (1, 1, true); INSERT INTO autor libro(aut id, lib id, aut lib autor principal) VALUES (1, 2, true); INSERT INTO autor libro(aut id, lib id, aut lib autor principal) VALUES (2, 3, true); INSERT INTO autor libro(aut id, lib id, aut lib autor principal) VALUES (1, 3, false); Diagrama relacional de la base de datos Es un gr´ afico con extenci´ on .png que contiene el diagrama relacional de la estructura de la base de datos Libros (ver figura §B.2), que sirvi´ o como complemento para especificar los requisitos de la gesti´ on de Libros en las tareas de formaci´ on. Este artefacto est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de- laboratorio\01 Formaci´on\03 requisitos-tareas\02 gesti´on-libros\libros-diagrama.png”. Requisitos y registro del tiempo de soluci´on Es una hoja de c´ alculo que contiene los requisitos para el desarrollo de un API, consta de diez operaciones de datos CRUD. Adem´ as, contiene una secci´ on para registrar la hora de inicio, fin, y el porcentaje de soluci´ on de cada requisito. Este artefacto est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\01 231 AP´ ENDICE B. EFECTOS DE LAS ARQUITECTURAS REST Y GRAPHQL: PAQUETE DE LABORATORIO Figura B.2: Diagrama relacional de la base de datos Libros Formaci´on\03 requisitos-tareas\02 gesti´on-libros\libros-requisitos-registro.sql”. En la Figura §B.3, se muestra la captura de pantalla de una parte del archivo librosrequisitos-registro.xlsm. Figura B.3: Requisitos y registro de soluci´ on de la gesti´ on de Libros B.1.7 Requisitos: Gesti´on de Blogs Los artefactos de esta tarea muestran los requisitos de operaciones b´ asicas CRUD, y dise˜ no de base de datos para administrar Blogs; que concretamente fueron utilizadas en las siguientes tareas de formaci´ on (ver Tabla §6.2): ST04- Deber de creaci´ on de un 232 B.1. ENTRENAMIENTO proyecto y consulta de datos; ST08-Deber de creaci´ on de un API REST; y ST12-Deber de creaci´ on de un API GraphQL. Copia de seguridad de la base de datos Es un archivo binario con extensi´ on .backup que contiene una copia de seguridad de la base de datos de Blogs, usado para que los participantes del experimento crearan esta base de datos en sus ambientes de desarrollo, y puedan desarrollar los deberes en las horas as´ ıncronas de trabajo establecidas para la formaci´ on. El artefacto est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\01 Formaci´on\03 requisitos-tareas\03 gesti´on-blogs\blogs.backup”. Script estructura de la bdd y datos de prueba Es un archivo con extensi´ on .sql que contiene scripts de creaci´ on de la estructura, e inserci´ on de datos de prueba de la base de datos Blogs, en lenguaje de consulta SQL. El objetivo de este archivo es brindar a los participantes del experimento una alternativa de creaci´ on de la base de datos. Este artefacto est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\01 Formaci´on\03 requisitos-tareas\01 gesti´on-blogs\blogs.sql”. A continuaci´ on, se muestra el contenido del archivo blogs.sql: CREATE TABLE autor ( aut id SERIAL not null, aut usuario TEXT not null, aut nombre TEXT not null, primary key (aut id) ); CREATE TABLE categoria ( cat id SERIAL not null, cat titulo TEXT not null, primary key (cat id) ); CREATE TABLE publicacion ( pub id SERIAL not null, cat id INTEGER null, aut id INTEGER null, pub titulo TEXT not null, 233 AP´ ENDICE B. EFECTOS DE LAS ARQUITECTURAS REST Y GRAPHQL: PAQUETE DE LABORATORIO pub descripcion TEXT not null, primary key (pub id), FOREIGN KEY (aut id) REFERENCES autor (aut id), FOREIGN KEY (cat id) REFERENCES categoria (cat id) ); CREATE TABLE comentario ( com id SERIAL not null, pub id INTEGER null, aut id INTEGER null, com descripcion TEXT not null, primary key (com id), FOREIGN KEY (aut id) REFERENCES autor (aut id), FOREIGN KEY (pub id) REFERENCES publicacion (pub id) ); CREATE TABLE reaccion ( rea id SERIAL not null, com id INTEGER not null, aut id INTEGER not null, rea like BOOLEAN not null, primary key (com id, aut id), FOREIGN KEY (aut id) REFERENCES autor (aut id), FOREIGN KEY (com id) REFERENCES comentario (com id) ); INSERT INTO autor (aut usuario, aut nombre) VALUES (’Ponchito12’,’Francisco Orellana’); INSERT INTO autor (aut usuario, aut nombre) VALUES (’MarioXD’,’Mario Venegas’); INSERT INTO autor (aut usuario, aut nombre) VALUES (’Karlita20’,’Carla Guerra’); INSERT INTO categoria (cat titulo) VALUES (’Software’); INSERT INTO categoria (cat titulo) VALUES (’Mecanica’); INSERT INTO categoria (cat titulo) VALUES (’Moda’); INSERT INTO categoria (cat titulo) VALUES (’Gastronomia’); INSERT INTO publicacion (cat id, aut id, pub titulo, pub descripcion) VALUES (1,2,’API REST y GraphQL’,’¿Cu´ al le gusta mas?’); INSERT INTO publicacion (cat id, aut id, pub titulo, pub descripcion) VALUES (1,3,’Java’,’¿Cuanta experiencia tienen?’); INSERT INTO publicacion (cat id, aut id, pub titulo, pub descripcion) VALUES (2,2,’Carros electricos’, ’Donde se llena la bateria’); INSERT INTO publicacion (cat id, aut id, pub titulo, pub descripcion) VALUES (4,3,’El mejor hornado’,’¿Donde es el mejor hornado?’); INSERT INTO comentario (pub id, aut id, com descripcion) VALUES (1,1,’REST’); 234 B.1. ENTRENAMIENTO INSERT INTO comentario (pub id, aut id, com descripcion) VALUES (1,2,’No lo se’); INSERT INTO comentario (pub id, aut id, com descripcion) VALUES (4,3,’Otavalo’); INSERT INTO reaccion (com id, aut id, rea like) VALUES (1,2,true); INSERT INTO reaccion (com id, aut id, rea like) VALUES (3,2,true); INSERT INTO reaccion (com id, aut id, rea like) VALUES (2,3,true); Diagrama relacional de la base de datos Es un gr´ afico con extenci´ on .png que contiene el diagrama relacional de la estructura de la base de datos Blogs (ver figura §B.4), que sirvi´ o como complemento para especificar los requisitos de la gesti´ on de Libros en las tareas de formaci´ on. Este artefacto est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de- laboratorio\01 Formaci´on\03 requisitos-tareas\03 gesti´on-blogs\blogs-diagrama.png”. Figura B.4: Diagrama relacional de la base de datos Blogs Requisitos y registro del tiempo de soluci´on Es una hoja de c´ alculo que contiene los requisitos para el desarrollo de un API, consta de diez operaciones de datos CRUD. Adem´ as, contiene una secci´ on para registrar la hora de inicio, fin, y el porcentaje de soluci´ on de cada requisito. Este artefacto est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\01 235 AP´ ENDICE B. EFECTOS DE LAS ARQUITECTURAS REST Y GRAPHQL: PAQUETE DE LABORATORIO Formaci´on\03 requisitos-tareas\03 gesti´on-blogs\blogs-requisitos-registro.sql”. En la Figura §B.5, se muestra la captura de pantalla de una parte del archivo blogsrequisitos-registro.xlsm. Figura B.5: Requisitos y registro de soluci´ on de la gesti´ on de Blogs B.2 EXPERIMENTO En esta secci´ on, se detalla los artefactos usados en las tareas experimentales del experimento descritas en la secci´ on §6.2.7. Estas tareas consisten en especificar los requisitos de tres casos de proyectos de desarrollo de APIs. Cada caso contiene cuatro ar- 236 B.2. EXPERIMENTO laboratorio\02 Experimento\01 requisitos-tareas\02 gesti´on-facturas\facturas-diagrama.png”. Requisitos y registro del tiempo de soluci´on Es una hoja de c´ alculo que contiene los requisitos para el desarrollo de un API, consta de diez operaciones de datos CRUD. Adem´ as, contiene una secci´ on para registrar la hora de inicio, fin, y el porcentaje de soluci´ on de cada requisito. En este sentido, se construy´ o dos artefactos con el mismo contenido, pero diferenciando el paradigma (API-REST / API-GraphQL) en el t´ ıtulo de las tareas. Los artefactos est´ an disponibles en las siguientes direcciones del paquete de laboratorio: ”Paquete-de-laboratorio\02 Experimento\01 requisitos-tareas\01 gesti´on-facturas\facturas-requisitos-registro-rest.xlsm”, y”Paquete-de-laboratorio\02 Experimento\01 requisitos-tareas\02 gesti´on-facturas\facturasrequisitos- registro-graphql.xlsm”. En la Figura §B.7, se muestra la captura de pantalla de una parte del archivo facturasrequisitos-registro-rest.xlsm. Figura B.7: Requisitos y registro de soluci´ on de la gesti´ on de facturas 243 AP´ ENDICE B. EFECTOS DE LAS ARQUITECTURAS REST Y GRAPHQL: PAQUETE DE LABORATORIO B.2.3 Requisitos: Gesti´on de Notas Esta tarea experimental contiene los requisitos y dise˜ no de base de datos para el desarrollo de un API (REST o GraphQL) que contenga las operaciones b´ asicas CRUD de la gesti´ on de Notas. Copia de seguridad de la base de datos Es un archivo con extensi´ on .backup que contiene una copia de seguridad de la base de datos de Notas, usado por los participantes del experimento para crear la base de datos en sus ambientes de desarrollo. El archivo est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\02 Experimento\01 requisitostareas\03 gesti´on-notas\notas.backup”. Script estructura de la bdd y datos de prueba Es un archivo con extensi´ on .sql que contiene los scripts de creaci´ on de la estructura de la base de datos Notas, e inserci´ on de datos de prueba en lenguaje SQL. El objetivo de este archivo es brindar a los participantes una alternativa de creaci´ on de la base de datos. El archivo est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\02 Experimento\01 requisitos-tareas\03 gesti´on-notas\notas.sql”. A continuaci´ on, se muestra el contenido del archivo notas.sql: CREATE TABLE estudiante ( est id SERIAL not null, est nombre TEXT not null, est cedula TEXT not null, est correo TEXT not null, PRIMARY KEY (est id) ); CREATE TABLE materia ( mat id SERIAL not null, mat nombre TEXT not null, mat nivel TEXT not null, mat paralelo TEXT not null, mat estado BOOLEAN not null, PRIMARY KEY (mat id) ); CREATE TABLE actividad ( 244 B.2. EXPERIMENTO act id SERIAL not null, mat id INTEGER null, act nombre TEXT not null, act descripcion TEXT not null, PRIMARY KEY (act id), FOREIGN KEY (mat id) references materia (mat id) ); CREATE TABLE actividad nota ( act id INTEGER not null, est id INTEGER not null, actnot nota DECIMAL(8,2) not null, PRIMARY KEY (act id, est id), FOREIGN KEY (act id) references actividad (act id), FOREIGN KEY (est id) references estudiante (est id) ); insert into materia (mat nombre, mat nivel, mat paralelo, mat estado) values (’Programaci´ on Orientada Objetos’, ’Primero’, ’A’,true); insert into materia (mat nombre, mat nivel, mat paralelo, mat estado) values (’Base de Datos’, ’Tercero’, ’A’,true); insert into materia (mat nombre, mat nivel, mat paralelo, mat estado) values (’Desarrollo de software para MIPYMES’, ’Quinto’, ’A’,true); insert into materia (mat nombre, mat nivel, mat paralelo, mat estado) values (’Construcci´ on de software’, ’Quinto’, ’B’,true); insert into materia (mat nombre, mat nivel, mat paralelo, mat estado) values (’Inteligencia artificial’, ’Sexto’, ’B’,true); insert into estudiante (est nombre, est cedula, est correo) values (’Daniel Guerra’, ’1004100901’,’[email protected]’); insert into estudiante (est nombre, est cedula, est correo) values (’Ricardo Avila’, ’1004100902’,’[email protected]’); insert into estudiante (est nombre, est cedula, est correo) values (’Dennis Chicaiza’, ’1004100903’,’[email protected]’); insert into estudiante (est nombre, est cedula, est correo) values (’Ervin Cabascango’, ’1004100904’,’[email protected]’); insert into estudiante (est nombre, est cedula, est correo) values (’Ronal Moreira’, ’1004100905’,’[email protected]’); insert into estudiante (est nombre, est cedula, est correo) values (’Gabriel Garz´ on’, ’1004100906’,’[email protected]’); insert into estudiante (est nombre, est cedula, est correo) values (’Daniel Mejia’, ’1004100907’,’[email protected]’); insert into estudiante (est nombre, est cedula, est correo) values (’Fabio Checa’, ’1004100908’,’[email protected]’); insert into estudiante (est nombre, est cedula, est correo) values (’Edward Elric’, ’1004100909’,’[email protected]’); insert into estudiante (est nombre, est cedula, est correo) values (’Dark Alchemist’, ’1004100900’,’[email protected]’); insert into actividad (mat id, act nombre, act descripcion) values (1,’Objetos en Java’,’Declaraci´ on y acceso a funciones de un objeto’); insert into actividad (mat id, act nombre, act descripcion) values (2,’Dise˜ no Base de Datos’,’Dise˜ no en Power Designer y exportaci´ on script’); insert into actividad (mat id, act nombre, act descripcion) values (5,’Redes neuronales’,’Explicaci´ on y ejercicio con CNN’); insert into actividad nota (act id, est id, actnot nota) values (1, 1, 8.00); 245 AP´ ENDICE B. EFECTOS DE LAS ARQUITECTURAS REST Y GRAPHQL: PAQUETE DE LABORATORIO insert into actividad nota (act id, est id, actnot nota) values (1, 2, 6.50); insert into actividad nota (act id, est id, actnot nota) values (2, 3, 7.00); insert into actividad nota (act id, est id, actnot nota) values (2, 4, 5.00); insert into actividad nota (act id, est id, actnot nota) values (3, 6, 7.70); insert into actividad nota (act id, est id, actnot nota) values (3, 10, 10.00); Diagrama relacional de la base de datos Es un archivo con extensi´ on .png que contiene el diagrama relacional de la estructura de la base de datos Notas, (ver figura §6.4), que sirvi´ o como complemento de los requisitos de software del caso Gesti´ on de Notas en la tarea experimental. El archivo est´ a disponible en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de- laboratorio\02 Experimento\01 requisitos-tareas\03 gesti´on-notas\notas-diagrama.png”. Requisitos y registro del tiempo de soluci´on Es una hoja de c´ alculo que contiene los requisitos para el desarrollo de un API, consta de diez operaciones de datos CRUD. Adem´ as, contiene una secci´ on para registrar la hora de inicio, fin, y el porcentaje de soluci´ on de cada requisito. En este sentido, se construy´ o dos artefactos con el mismo contenido, pero diferenciando el paradigma (APIREST / API-GraphQL) en el t´ ıtulo de las tareas. Los artefactos est´ an disponibles en las siguientes direcciones del paquete de laboratorio: ”Paquete-de-laboratorio\02 Experimen- to\01 requisitos-tareas\01 gesti´on-notas\notas-requisitos-registro-rest.xlsm”, y ”Paquete-de- laboratorio\02 Experimento\01 requisitos-tareas\02 gesti´on-notas\notas-requisitos-registro- graphql.xlsm”. En la Figura §B.8, se muestra la captura de pantalla de una parte del archivo notasrequisitos-registro-rest.xlsm. B.3 AN´ ALISIS B.3.1 Encuesta de Autoevaluaci´on En esta secci´ on se utiliz´ o la misma encuesta del Anexo §B.1.1 pero sin la informaci´ on demogr´ afica. La encuesta se ejecut´ o luego de realizar el experimento, con la finalidad que los participantes auto eval´ uen su percepci´ on de facilidad de uso, consumo y aprendizaje de los paradigmas estudiados. 246 B.3. AN ´ ALISIS Figura B.8: Requisitos y registro de soluci´ on de la gesti´ on de notas Este artefacto se operativiz´ o en un formulario privado de Microsoft Forms 365, que no tiene acceso p´ ublico. Por este motivo se presenta la encuesta en un archivo .pdf en la siguiente direcci´ on del paquete de laboratorio: ”Paquete-de-laboratorio\03 An´alisis\01 encuesta-autoevaluaci´on\encuesta-auto-evaluaci´on.pdf”. 247 AP´ ENDICE B. EFECTOS DE LAS ARQUITECTURAS REST Y GRAPHQL: PAQUETE DE LABORATORIO 248 BIBLIOGRAF´ IA 249 Al final de cada referencia bibliogr´ afica aparece un enlace a cada p´ agina en que se cita dicha referencia. [1] Tobias Andersson, H˚ akan Reinholdsson, Fredrik Stridh, and Dawit Mengistu. REST API vs GraphQL: A literature and experimental study. PhD thesis, Kristianstad University, 2021. (pages 79, 84, 223). [2] Hilary Arksey and Lisa O’Malley. Scoping studies: towards a methodological framework. International journal of social research methodology, 8(1):19–32, 2005. (page 20). [3] Hilary Arksey and Lisa O’Malley. Scoping studies: Towards a methodological framework. International Journal of Social Research Methodology: Theory and Practice, 8(1):19–32, 2005. (page 63). [4] Ilmari Autio, Petri Vuorimaa, and Virpi Huhtinen. News API implementation with serverless GraphQL. PhD thesis, Aalto University, Espoo, 2020. (pages 79, 221). [5] Georgios Bakirtzis, Tim Sherburne, Stephen Adams, Barry Horowitz, Peter Beling, and Cody Fleming. An ontological metamodel for cyber-physical system safety, security, and resilience coengineering. Software and Systems Modeling, page 25, 2021. (pages 79, 222). [6] Victor R Basili. Software modeling and measurement: the goal/question/metric paradigm. Encyclopedia of Software Engineering, 1994. (pages 94, 110). [7] Saˇ sa Baˇ skarada, Vivian Nguyen, and Andy Koronios. Architecting Microservices: Practical Opportunities and Challenges. Journal of Computer Information Systems, 00(00):1–9, 2018. (page 4). [8] Jorge Biolchini, Paula Gomes Mian, Ana Candida Cruz Natali, and Guilherme Horta Travassos. Systematic review in software engineering. System engineering and computer science department COPPE/UFRJ, Technical Report ES, 679(05):45, 2005. (page 20). BIBLIOGRAF´ IA [9] Pierre Bourque and Richard E. Fairley. SWEBOK v.3 - Guide to the Software Engineering - Body of Knowledge. IEEE Computer Society, New Jersey, version 3. edition, 2014. (page 70). [10] Gleison Brito, Thais Mombach, and Marco Tulio Valente. Migrating to GraphQL: A Practical Assessment. In SANER 2019 - Proceedings of the 2019 IEEE 26th International Conference on Software Analysis, Evolution, and Reengineering, pages 140–150, Hangzhou, 2019. IEEE. (pages 6, 78, 79, 84, 85, 220). [11] Gleison Brito and Marco Tulio Valente. REST vs GraphQL: A controlled experiment. In Proceedings - IEEE 17th International Conference on Software Architecture, ICSA 2020, pages 81–91, Salvador, 3 2020. Institute of Electrical and Electronics Engineers Inc. (pages 29, 78, 79, 84, 85, 221). [12] John Brooke. SUS: A Retrospective. Journal of Usability Studies, 8(2):29–40, 2013. (page 45). [13] Mike Bryant. GraphQL for archival metadata: An overview of the EHRI GraphQL API. In Proceedings - 2017 IEEE International Conference on Big Data, Big Data 2017, volume 2018-Janua, pages 2225–2230, Boston, 12 2017. Institute of Electrical and Electronics Engineers Inc. (pages 78, 79, 220). [14] Reinhard Budde, Karlheinz Kautz, Karin Kuhlenkamp, and Heinz Z¨ ullighoven. Prototyping An Approach to Evolutionary System Development. Springer-Verlag Berlin Heidelberg, Berlin, 1992. (page 70). [15] David Budgen, Mark Turner, Pearl Brereton, and Barbara A Kitchenham. Using mapping studies in software engineering. In Ppig, volume 8, pages 195–204, 2008. (page 20). [16] Valerio Cassani, Stefano Gianelli, Maristella Matera, Riccardo Medana, Elisa Quintarelli, Letizia Tanca, and Vittorio Zaccaria. On the Role of Context in the Design of Mobile Mashups. In Gaedke M. Daniel F., editor, 2nd International Rapid Mashup Challenge, RMC 2016, volume 696, pages 108–128. Springer Verlag, Lugano, 2017. (pages 78, 79, 220). [17] David ˇ Cech´ ak and Bruno Rossi. Using GraphQL for Content Delivery in Kentico Cloud. PhD thesis, Masaryk University, 2017. (pages 79, 84, 85, 220). [18] Lujing CEN and Evan PATTON. Block Affordances for GraphQL in MIT App Inventor. In International Conference on Computational Thinking Education 2019, pages 250 BIBLIOGRAF´ IA 147–150, Hong Kong, 2019. The Education University of Hong Kong. (pages 78, 79, 85, 220). [19] Alan Cha, Erik Wittern, Guillaume Baudart, James Davis, Louis Mandel, and Jim Laredo. A principled approach to GraphQL query cost analysis. In ESEC/FSE 2020 - Proceedings of the 28th ACM Joint Meeting European Software Engineering Conference and Symposium on the Foundations of Software Engineering, pages 257– 268, New York, 2020. Association for Computing Machinery. (pages 78, 79, 85, 221). [20] Natchaporn Chaengmongkol, Somnuek Sinthupuan, Attawit Changkamanon, and Snit Sitti. Student Behavior Report Management System on Somsri.IO. In 2021 18th International Conference on Electrical Engineering/Electronics, Computer, Telecommunications and Information Technology (ECTI-CON), pages 581–584, Chiang Mai, 2021. IEEE. (pages 78, 79, 223). [21] B Chase Richard, Jacobs F Robert, and J Aquilano Nicholas. Administraci´on de operaciones-Producci´on y cadena de suministros. Mc. Graw Hill, Mexico, 12 edition, 2009. (page 96). [22] David Chaves-Fraga, Freddy Priyatna, Ahmad Alobaid, and Oscar Corcho. Exploiting Declarative Mapping Rules for Generating GraphQL Servers with Morph-GraphQL. International Journal of Software Engineering and Knowledge Engineering, 30(6):785–803, 2020. (pages 79, 221). [23] Clarivate. Journal Citation Reports™: Reference Guide, 2021. (page 68). [24] Clarivate. Quartiles in JCR on the InCites Platform, 2021. (page 68). [25] Commercetools. Limits — HTTP API — commercetools, 2021. (pages 14, 168). [26] Nelly Condori-Fernandez, Maya Daneva, Klaas Sikkel, Roel Wieringa, Oscar Dieste, and Oscar Pastor. A systematic mapping study on empirical evaluation of software requirements specifications techniques. 2009 3rd International Symposium on Empirical Software Engineering and Measurement, ESEM 2009, 1:502–505, 2009. (page 70). [27] Florian Daniel, Maristella Matera, Elisa Quintarelli, Letizia Tanca, and Vittorio Zaccaria. Context-aware access to heterogeneous resources through on-the-fly mashups. In Reijers H.A. Krogstie J., editor, 30th International Conference on Advanced Information Systems Engineering, CAiSE 2018, volume 10816 LNCS, pages 119–134, Tallinn, 2018. Springer Verlag. (pages 78, 219). 251 BIBLIOGRAF´ IA [28] Paolo Di Francesco, Patricia Lago, and Ivano Malavolta. Architecting with microservices: A systematic mapping study. Journal of Systems and Software, 150:77–97, 2019. (page 4). [29] Tom´ as D´ ıaz, Federico Olmedo, and ´ Eric Tanter. A Mechanized Formalization of GraphQL. In CPP 2020 - Proceedings of the 9th ACM SIGPLAN International Conference on Certified Programs and Proofs, co-located with POPL 2020, pages 201– 214, New Orleans, 2020. Association for Computing Machinery, Inc. (pages 78, 79, 220). [30] ´ Africa Domingo, Jorge Echeverr´ ıa, ´ Oscar Pastor, and Carlos Cetina. Evaluating the influence of scope on feature location. Information and Software Technology, 2021. (page 108). [31] James Dustyn and Kevin Chen-Chuan Chang. Lion: listen online. Using GraphQL as a mediator for data integration and ingestion. PhD thesis, University of Illinois at Urbana-Champaign, 2018. (pages 79, 220). [32] Tore Dyba, Torgeir Dingsoyr, and Geir Hanssen. Applying Systematic Reviews to Diverse Study Types: An Experience Report. In First International Symposium on Empirical Software Engineering and Measurement, pages 225–234, Washington, 2007. IEEE. (pages 8, 65). [33] Steve Easterbrook, Janice Singer, Margaret-Anne Storey, and Daniela Damian. Selecting Empirical Methods for Software Engineering Research. Guide to Advanced Empirical Software Engineering, 1(2007934531):285–311, 2008. (pages 21, 69, 70). [34] Naresh Eeda and Nazim Madhavji. Rendering real-time dashboards using a GraphQL- based UI Architecture. PhD thesis, Western University, 2018. (pages 79, 220). [35] Thomas Eizinger, L¨ owenstein Bernhard, and Lukasz Juszczyk. API Design in Distributed Systems: A Comparison between GraphQL and REST. PhD thesis, University of Applied Sciences Technikum Wien, 2017. (pages 84, 219). [36] Elsevier. FAQs - Journal Metrics - Scopus.com, 2017. (page 68). [37] Robert Engel, Shashank Rajamoni, Bryant Chen, Heiko Ludwig, and Alexander Keller. ysla: reusable and configurable slas for large-scale sla management. In 252 BIBLIOGRAF´ IA guideline. Empirical Software Engineering, 22(6):2852–2891, 2017. (pages 8, 63, 65, 72). [97] Dominik Adam Kus, Istv´ an Koren, and Ralf Klamma. A Link Generator for Increasing the Utility of OpenAPI-to-GraphQL Translations. In WWW2020, page 4, Taipei, 5 2020. Association for Computing Machinery (ACM) Digital Library. (pages 78, 79, 85, 220). [98] Miguel A. Laguna and Yania Crespo. A systematic mapping study on software product line evolution: From legacy system reengineering to product line refactoring. Science of Computer Programming, 78(8):1010–1034, 2013. (page 65). [99] Binod Lama and Miguel Valero. Implementing Graphql in Existing REST API. PhD thesis, Universitat Polit´ ecnica de Catalunya, Barcelona, 2019. (pages 79, 221). [100] Markus Larsson, David ˚ Angstr¨ om, Sijin Cheng, and Olaf Hartig. A Performance Comparison of Auto-Generated GraphQL Server Implementations. PhD thesis, Link¨ oping University, 2020. (pages 79, 84, 221). [101] Byron Lee. Introducing the GraphQL Foundation – Lee Byron – Medium, 2018. (pages 6, 8). [102] Eunggi Lee, Kiwoong Kwon, and Jungmee Yun. Performance Measurement of GraphQL API in Home ESS Data Server. In 2020 International Conference on Information and Communication Technology Convergence (ICTC), volume 2020-Octob, pages 1929–1931, Jeju, 2020. IEEE. (pages 78, 79, 84, 222). [103] Shanshan Li, He Zhang, Z. Jia, Z. Li, C. Zhang, J. Li, Q. Gao, Jidong Ge, and Zhihao Shan. A dataflow-driven approach to identifying microservices from monolithic applications. Journal of Systems and Software, 157:16, 2019. (page 4). [104] Lu Liang, Chunfeng Ma, Tengfei Du, Yufei Zhao, Xiaoyong Zhao, Mengmeng Liu, Zhonghua Wang, and Jianping Lin. Bioactivity-explorer: a web application for interactive visualization and exploration of bioactivity data. Journal of Cheminformatics, 11(1):1–6, 2019. (pages 79, 219). [105] Chi Y. Lin, Tarek Abdel-Hamid, and Joseph S. Sherif. Software-Engineering Process Simulation model (SEPS). Journal of Systems and Software, 38(3):263–277, 1997. (page 70). [106] Jonas Lind, Kieron Soames, Patrick Lambrix, and Olaf Hartig. Detecting Cycles in GraphQL Schemas. PhD thesis, Link¨ oping University, 2018. (pages 79, 219). 259 BIBLIOGRAF´ IA [107] Mhairi McNeill. About RStudio - RStudio, 2020. (page 46). [108] Peter M Mell and Timothy Grance. The NIST Definition of Cloud Computing. Technical report, National Institute of Standards and Technology, Gaithersburg, 2011. (page 4). [109] Daniela Meneses, Alison Fernandez, Andreina Cota, Juan Sandoval, Milton Mamani, Alexandre Bergel, and Stephane Ducasse. Deviation Testing: A Test Case Generation Technique for GraphQL APIs. In 11th International Workshop on Smalltalk Technologies (IWST), page 9, New York, 2018. Association for Computing Machinery. (pages 77, 79, 85, 221). [110] Suresh Mukhiya, Fazle Rabbi, Violet Pun, Adrian Rutle, and Yngve Lamo. A graphql approach to healthcare information exchange with hl7 fhir. In The 9th International Conference on Current and Future Trends of Information and The 9th International Conference on Current and Future Trends of Information and Communication Technologies in Healthcare (ICTH 2019) Communication Technologies in Healthcare, volume 160, pages 338–345, Coimbra, 2019. Elsevier B.V. (pages 5, 7, 78, 79, 84, 220). [111] Neo4j. Cypher Query Language - Developer Guides, 2020. (page 44). [112] Andy Neumann, Nuno Laranjeiro, and Jorge Bernardino. An analysis of public rest web service apis. IEEE Transactions on Services Computing, 2018. (pages 52, 53). [113] Falco Nogatz and Dietmar Seipel. Implementing GraphQL as a query language for deductive databases in SWI-Prolog using DCGs, quasi quotations, and dicts. In 30th Workshop on (Constraint) Logic Programming, WLP 2016 and 29th Workshop on (Constraint) Logic Programming, WLP 2015, volume 234, pages 42–56, Leipzig, 2017. Open Publishing Association. (pages 29, 77, 84, 220). [114] Camille Oggier. How fast GraphQL is compared to REST APIs. PhD thesis, Haaga- Helia University of Applied Sciences, Helsinki, 2020. (pages 79, 84, 221). [115] Olin Emily and The Linux Foundation. The Linux Foundation Announces Intent to Form New Foundation to Support GraphQL - The Linux Foundation, 2018. (pages 6, 8). [116] Arsenio Paez. Grey literature: An important resource in systematic reviews. Journal of Evidence-Based Medicine, 10(May):1–8, 2017. (pages 66, 67). 260 BIBLIOGRAF´ IA [117] Jos´ e Carlos Paiva, Alicja Haraszczuk, Ricardo Queir´ os, Jos´ e Paulo Leal, Jakub Swacha, and Sokol Kosta. FGPE Gamification Service: A GraphQL Service to Gamify Online Education. In World Conference on Information Systems and Technologies WorldCIST 2021, volume AISC 1368, pages 480–489, Terceira Island, 2021. Springer, Cham. (pages 78, 79, 222). [118] Cesare Pautasso. Restful web services: principles, patterns, emerging technologies. In Web Services Foundations, pages 31–51. Springer, 2014. (page 28). [119] K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee. A design science research methodology for information systems research. Journal of management information systems, 24(3):45–77, 2007. (pages 13, 23, 39, 166). [120] Kai Petersen, Robert Feldt, Shahid Mujtaba, and Michael Mattsson. Systematic mapping studies in software engineering. In 12th International Conference on Evaluation and Assessment in Software Engineering, EASE 2008, page 11, Bari, 2008. BCS Learning and Development Ltd. (pages 20, 63). [121] Kai Petersen and Cigdem Gencel. Worldviews, research methods, and their relationship to validity in empirical software engineering research. In Proceedings - Joint Conference of the 23rd International Workshop on Software Measurement and the 8th International Conference on Software Process and Product Measurement, IWSMMENSURA 2013, pages 81–89, Ankara, 2013. IEEE Computer Society. (pages 72, 73). [122] Kai Petersen, Sairam Vakkalanka, and Ludwik Kuzniarz. Guidelines for conducting systematic mapping studies in software engineering: An update. Information and Software Technology, 64:1–18, 2015. (pages 20, 42, 63, 65, 67, 68, 69, 72, 73, 80). [123] Mark Petticrew and Helen Roberts. Systematic reviews in the social sciences: A practical guide. John Wiley & Sons, 2008. (page 20). [124] Prisma. Execution — GraphQL, 2017. (pages 37, 39). [125] Prisma. GraphQL vs REST - A comparison, 2017. (page 5). [126] Freddy Priyatna, David Chaves-Fraga, Ahmad Alobaid, and Oscar Corcho. Morph-GraphQL: GraphQL servers generation from R2RML mappings (SESE). In 31st International Conference on Software Engineering and Knowledge Engineering, SEKE 2019., volume 2019-July, pages 291–296, Lisbon, 2019. Knowledge Systems Institute Graduate School. (pages 78, 79, 220). 261 BIBLIOGRAF´ IA [127] Ossi Puustinen. GraphQL for building microservices. PhD thesis, Tampere University, 2020. (pages 79, 222). [128] Antonio Qui˜ na-Mera, Pablo Fernandez, Jos´ e Mar´ ıa Garc´ ıa, and Antonio Ruiz- Cort´ es. Efectos de las arquitecturas REST y GraphQL: Paquete de laboratorio, apr 2022. (page 225). [129] Antonio Qui˜ na-Mera, Pablo Fern´ andez, Jos´ e Mar´ ıa Garc´ ıa, Edwin Bastidas, and Antonio Ruiz-Cort´ es. Quality in use evaluation of a GraphQL implementation. In Proceedings - XVI Multidisciplinary International Congress on Science and Technology, CIT 2021, page 0, 6330 Cham, Switzerland, 2021. Springer Nature Switzerland AG. (pages 40, 212). [130] Meuthia Rachmaniah, Maya Maharani Krismanti, and Muhammad Idzhar Darissalam. Tokocabai marketplace application based on web using extreme programming method. In 2020 International Conference on Computer Science and Its Application in Agriculture, ICOSICA 2020, pages 1–7, Bogor, 2020. IEEE. (pages 78, 79, 223). [131] Damaraju Raghavarao and Lakshmi Padgett. Repeated measurements and crossover designs. John Wiley & Sons, 2014. (page 97). [132] Saqib Rasool, Raees Khan, and Adnan Noor Mian. GraphQL and DC-WSN- Based Cloud of Things. IT Professional, 21(1):59–66, 1 2019. (pages 79, 219). [133] Muhammad Raza, Farookh Khadeer, Omar Khadeer, and Ming Zhao. A comparative analysis of machine learning models for quality pillar assessment of SaaS services by multi-class text classification of users ’ reviews. Future Generation Computer Systems, 101:341–371, 2019. (page 4). [134] Leonard Richardson, Mike Amundsen, Michael Amundsen, and Sam Ruby. RESTful Web APIs: Services for a Changing World. ” O’Reilly Media, Inc.”, 2013. (page 28). [135] Aleksi Ritsil¨ a. GraphQL: The API Design Revolution. PhD thesis, Haaga-Helia University of Applied Sciences, Helsinki, 2017. (pages 79, 84, 221). [136] Roberto Rodriguez-Echeverria, Javier C´ anovas, and Jordi Cabot. Towards a UML and IFML Mapping to GraphQL. In Wimmer M. Garrigos I., editor, 17th International Conference on Web Engineering, ICWE 2017, volume 10544 LNCS, pages 149–155, Rome, 2018. Springer Verlag. (pages 78, 79, 220). 262 BIBLIOGRAF´ IA [137] Piotr Roksela, Marek Konieczny, and Slawomir Zielinski. Evaluating execution strategies of GraphQL queries. In N. Herencsar, editor, 2020 43rd International Conference on Telecommunications and Signal Processing, TSP 2020, pages 640–644, Milan, 2020. Institute of Electrical and Electronics Engineers Inc. (pages 78, 79, 221). [138] Yana Rose, Jose M. Duarte, Robert Lowe, Joan Segura, Chunxiao Bi, Charmi Bhikadiya, Li Chen, Alexander S. Rose, Sebastian Bittrich, Stephen K. Burley, and John D. Westbrook. RCSB Protein Data Bank: Architectural Advances Towards Integrated Searching and Efficient Access to Macromolecular Structure Data from the PDB Archive. Journal of Molecular Biology, 433(11):166704, 2021. (pages 79, 223). [139] Per Runeson, Martin Host, Austen Rainer, and Bjorn Regnell. Case study research in software engineering: Guidelines and examples. John Wiley & Sons, 2012. (pages 166, 167). [140] Fatima Samea, Farooque Azam, Muhammad Rashid, Muhammad Waseem Anwar, Wasi Haider Butt, and Abdul Wahab Muzaffar. A model-driven framework for data-driven applications in serverless cloud computing. PLoS ONE, 15(8 August):1–32, 2020. (pages 79, 220). [141] Jaime Sayago, Evelin Flores, and Andres Recalde. Comparative Analysis Between Standards Oriented to Web Services: SOAP, REST and GRAPHQL. In International Conference on Applied Technologies, volume 1193 CCIS, pages 286–300, Quito, 2019. Springer. (pages 78, 79, 84, 221). [142] Jonas Schurmann, Tim Tegeler, and Bernhard Steffen. Guaranteeing Type Consistency in Collective Adaptive Systems. In 9th International Symposium on Leveraging Applications of Formal Methods, ISoLA 2020, pages 311–328, Rhodes, 2020. Springer Nature Switzerland. (pages 78, 79, 85, 222). [143] SCImago. SJR - About Us, 2012. (page 68). [144] SCImago. SJR - Help, 2019. (page 68). [145] Pavel Seda, Pavel Masek, Jindriska Sedova, Milos Seda, Jan Krejci, and Jiri Hosek. Efficient Architecture Design for Software as a Service in Cloud Environments. In 10th International Congress on Ultra Modern Telecommunications and Control Systems and Workshops, ICUMT 2018, pages 317–322, Moscow, 11 2018. IEEE Computer Society. (pages 78, 79, 219). 263 BIBLIOGRAF´ IA [146] Philipp Seifer, Johannes H¨ artel, Martin Leinberger, Ralf L¨ ammel, and Steffen Staab. Empirical study on the usage of graph query languages in open source Java projects. In SLE 2019 - Proceedings of the 12th ACM SIGPLAN International Conference on Software Language Engineering, co-located with SPLASH 2019, pages 152–166, Athens, 10 2019. Association for Computing Machinery, Inc. (pages 6, 78, 79, 84, 85, 221). [147] Klaas Sijtsma. On the use, the misuse, and the very limited usefulness of cronbach’s alpha. Psychometrika, 74(1):107–120, 2009. (page 47). [148] Janice Singer. Using the american psychological association (apa) style guidelines to report experimental results. In Workshop on Empirical Studies in Software Engineering (WSESE 1999), pages 71–75. Citeseer, 1999. (page 21). [149] Akansha Singh and N. Jeyanthi. MVP Architecture Model with Single Endpoint Access for Displaying COVID 19 Patients Information Dynamically. In Proceedings - 2020 12th International Conference on Computational Intelligence and Communication Networks, CICN 2020, pages 471–476, Bhimtal, 2020. IEEE. (pages 78, 79, 84, 222). [150] Dmitry Sklyarov, Ari Rantala, and Oy Movya. The Web service development with React , GraphQL and Apollo. PhD thesis, JAMK University of Applied Sciences, 2020. (pages 79, 223). [151] Jeremias Snellman, Timo Mantere, Petri V¨ alisuo, and Tim Wallin Gambi. Implementation and Evaluation of a Graphql-Based Web Application for Project Follow Up. PhD thesis, University of Vaasa, Vaasa, 2019. (pages 79, 85, 221). [152] M. Solari and S. Vegas. Classifying and analysing replication packages for software engineering experimentation. In 7th International Conference on Product Focused Software Process Improvement (PROFES 2006)-Workshop Series in Empirical Software Engineering (WSESE), 2006. (page 171). [153] Facebook Open Source. Schemas and Types — GraphQL, 2015. (pages 34, 36, 37). [154] Vlatko Spasev, Ivica Dimitrovski, and Ivan Kitanovski. An Overview of GraphQL : Core Features and Architecture. In ICT Innovations Conference 2020, page 14, Skopje, 2020. Springer. (pages 78, 79, 222). 264 BIBLIOGRAF´ IA [155] Karin Staring, Stelios Vitalis, Linda Brink, and Bal´ azs Dukai. Combination of CityJ- SON with PostgreSQL, MongoDB and GraphQL. PhD thesis, Delft University of- Technology, 2020. (pages 79, 84, 222). [156] Patrick St¨ unkel, Ole von Bargen, Adrian Rutle, and Yngve Lamo. GraphQL Federation: A Model-Based Approach. The Journal of Object Technology, 19(2):21, 2020. (pages 79, 84, 221). [157] Mahsud M. Sultanov, Yulia A. Gorban, Aleksey A. Smirnov, and Viktor A. Yurov. Development of a centralized system for data storage and processing on operation modes and reliability indicators of power equipment. In Proceedings of the 3rd 2021 International Youth Conference on Radio Electronics, Electrical and Power Engineering, REEPE 2021, pages 3–7, Moscow, 2021. IEEE. (pages 78, 79, 222). [158] Gede Susrama, Mas Diyasa, Gideon Setya Budiwitjaksono, Hafidz Amarul, and Ilham Ade. Comparative Analysis of Rest and GraphQL Technology on Nodejs- Based Api Development. In 5th International Seminar of Research Month 2020, volume 2021, pages 43–52, Zoom/Live Streaming Youtube, 2021. Nusantara Science and Technology Proceedings. (pages 78, 79, 84, 222). [159] Ruben Taelman, Miel Vander Sande, and Ruben Verborgh. Bridges between GraphQL and RDF. In W3C Workshop on Web Standardization for Graph Data. W3C, pages 4–7, Berlin, 2019. W3C. (pages 77, 219). [160] Teemu Taskula, Eero Hyvonen, Janne Kario, and Keski-Luopa Jukka. Advanced Data Fetching with GraphQL: Case Bakery Service. PhD thesis, Aalto University, 2019. (pages 79, 84, 219). [161] Samir Tata, Mohamed Mohamed, Takashi Sakairi, Nagapramod Mandagere, Obinna Anya, and Heiko Ludwig. rsla: A service level agreement language for cloud services. In 2016 IEEE 9th International Conference on Cloud Computing (CLOUD), pages 415–422. IEEE, 2016. (page 53). [162] The GraphQL Foundation. GraphQL, 2018. (pages 28, 29, 30, 32, 35, 37, 38, 39). [163] Johannes Th¨ ones. Microservices. IEEE Software, 32:4, 2015. (page 4). [164] Istv´ an T´ oth-Kir´ aly, G´ abor Orosz, Edina Dombi, Bal´ azs Jagodics, D´ avid Farkas, and Camille Amoura. Cross-cultural comparative examination of the Academic Motivation Scale using exploratory structural equation modeling. Personality and Individual Differences, 106:130–135, 2017. (page 47). 265 BIBLIOGRAF´ IA [165] Ville Touronen, Jussi Kangasharju, and Matti Luukkainen. Microservice architecture patterns with GraphQL. PhD thesis, University of Helsinki, Helsinki, 2019. (pages 79, 221). [166] Tri Tran and Janne Salonen. Build a GraphQL application with Node. js and React. PhD thesis, Metropolia University of Applied Sciences, 2019. (pages 79, 220). [167] Wei Tek Tsai, Xiao Ying Bai, and Yu Huang. Software-as-a-service (SaaS): Perspectives and challenges. Science China Information Sciences, 57(5):1–15, 2014. (page 4). [168] H Ulrich, J Kern, D. Tas, A. K. Kock-Schoppenhauer, F. ¨ Uckert, J. Ingenerf, and M. Lablans. QL 4 MDR: A GraphQL query language for ISO 11179-based metadata repositories. BMC Medical Informatics and Decision Making, 19(1):7, 2019. (pages 79, 220). [169] Rafael Brundo Uriarte, Francesco Tiezzi, and Rocco De Nicola. Slac: A formal service-level-agreement language for cloud computing. In 2014 IEEE/ACM 7th International Conference on Utility and Cloud Computing, pages 419–426. IEEE, 2014. (page 53). [170] R. Varadan, K. Channabasavaiah, S. Simpson, K. Holley, and A. Allam. Increasing business flexibility and soa adoption through effective soa governance. IBM Systems Journal, 47(3):473–488, 2008. (page 7). [171] Andrea Vazquez-Ingelmo, Juan Cruz-Benito, and Francisco Garc´ ıa-Penalvo. Improving the OEEU’s data-driven technological ecosystem’s interoperability with GraphQL. In 5th International Conference on Technological Ecosystem for Enhancing Multiculturality, TEEM 2017, volume Part F1322, page 8, Cadiz, 10 2017. Association for Computing Machinery. (pages 78, 79, 84, 220). [172] Mario G Piattini Velthuis. Auditor´ıa de Tecnolog´ıas y Sistemas de Informaci´on. Grupo Editorial RA-MA, 2008. (page 52). [173] Milena Vesi´ c and Nenad Koji´ c. Comparative Analysis of Web Application Performance In Case of Using REST Versus GraphQL. In Fourth International Scientific Conference ITEMA 2020, pages 1–9, ONLINE-Virtual, 2020. (pages 29, 78, 79, 84, 222). [174] Maximilian Vogel, Sebastian Weber, and Christian Zirpins. Experiences on migrating RESTful Web Services to GraphQL. In ICSOC Workshops 2017, page 283–295, Malaga, 2018. Springer Verlag. (pages 5, 6, 7, 78, 79, 84, 219). 266 BIBLIOGRAF´ IA [175] R. H. Von Alan, S. T March, J. Park, and S. Ram. Design science in information systems research. MIS quarterly, 28(1):75–105, 2004. (pages 11, 39). [176] Kai Von-R¨ onne and Dirk Riehle. GraphQL-based generic and domain specific query interfaces for the JValue ODS. PhD thesis, Friedrich-Alexander University Erlangen-N¨ urnberg, 2020. (pages 79, 222). [177] Chen Wang, Luigi Marini, Chieh Li Chin, Nickolas Vance, Curtis Donelson, Pascal Meunier, and Joseph T. Yun. Social media intelligence and learning environment: An open source framework for social media data Collection, Analysis and Curation. In IEEE 15th International Conference on eScience, eScience 2019, pages 252–261, San Diego, 9 2019. IEEE Computer Society. (pages 78, 79, 221). [178] Shaohua Wang, Iman Keivanloo, and Ying Zou. How do developers react to RESTful API evolution? Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 8831:245–259, 2014. (page 4). [179] Jeroen Maurits Werbrouck, Madhumitha Senthilvel, Jakob Beetz, and Pieter Pauwels. Querying heterogeneous linked building data with context-expanded GraphQL queries? In CEUR Workshop Proceedings, volume 2389, pages 21–34, Lisbon, 2019. CEUR-WS. (pages 77, 79, 84, 220). [180] Roel Wieringa, Neil Maiden, Nancy Mead, and Colette Rolland. Requirements engineering paper classification and evaluation criteria: A proposal and a discussion. Requirements Engineering, 11(1):102–107, 2006. (pages 68, 69). [181] Daniel Wikander, Johan Holmberg, and Mia Persson. Exploring the quality attribute and performance implications of using GraphQL in a data-fetching API. PhD thesis, Malm¨ o University, Malm¨ o, 2020. (pages 79, 84, 221). [182] Erik Wittern, Alan Cha, James Davis, Guillaume Baudart, and Louis Mandel. An Empirical Study of GraphQL Schemas. In 17th International Conference on Service- Oriented Computing, ICSOC 2019, pages 3–19, Toulouse, 2019. Springer. (pages 78, 79, 84, 85, 220). [183] Erik Wittern, Alan Cha, and Jim A. Laredo. Generating GraphQL-wrappers for REST(-like) APIs. In 18th International Conference on Web Engineering, ICWE 2018, volume 10845 LNCS, pages 65–83, Caceres, 2018. Springer Verlag. (pages 6, 7, 78, 79, 85, 219). 267 BIBLIOGRAF´ IA [184] Claes Wohlin. Guidelines for Snowballing in Systematic Literature Studies and a Replication in Software Engineering. In 18th International Conference on Evaluation and Assessment in Software Engineering, page 10, London, 2014. Association for Computing Machinery. (page 65). [185] Claes Wohlin, Per Runeson, Paulo Anselmo Da Mota Silveira Neto, Emelie Engstr¨ om, Ivan Do Carmo Machado, and Eduardo Santana De Almeida. On the reliability of mapping studies in software engineering. Journal of Systems and Software, 86(10):2594–2610, 2013. (page 68). [186] Claes Wohlin, Per Runeson, Martin H¨ ost, Magnus C. Ohlsson, Bj¨ orn Regnell, and Anders Wessl´ en. Experimentation in Software Engineering. Springer-Verlag Berlin Heidelberg, Berlin, Heidelberg, 1 edition, 2012. (pages 11, 21, 69, 70, 118, 150, 161). [187] M. Zelkowitz and D. Wallace. Experimental Models for Validating Technology. Computer, 31(5):23–31, 1998. (page 97). [188] Olaf Zimmermann. Microservices tenets: Agile approach to service development and deployment. Computer Science - Research and Development, 32(3-4):301–310, 2017. (pages 4, 7). 268