Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain

Nicolás Sánchez Gómez Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain - Ph. D. Tesis - Directores Ph. D. Jesús Torres Valderrama Ph. D. Manuel Mejías Risoto Tutora Ph. D. María José Escalona Cuaresma Departamento de Lenguajes y Sistemas de Información E.T.S. de Ingeniería Informática. Universidad de Sevilla Sevilla, octubre de 2023 Nicolás Sánchez Gómez Ph. D. Tesis Página 2 / 251 A Merchi, mi compañera de vida, si no te hubiera conocido te habría soñado, y a nuestros retoños Nicolás y Manuel, nuestros pilares, la luz que ilumina nuestros días, con todo mi cariño. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 3 / 251 Nicolás Sánchez Gómez Ph. D. Tesis Página 4 / 251 Índice de Contenido Reconocimientos ............................................................................... 13 Prólogo ........................................................................................... 15 Resumen......................................................................................... 16 Summary ........................................................................................ 19 Capítulo I. Introducción ....................................................................... 22 I.1. Antecedentes ........................................................................... 22 I.1.1. Grupo Engineering and Science for Software Systems ..................... 22 I.1.2. Propuesta metodológica SofIA.................................................. 24 I.1.3. Proyecto SmartISBN ............................................................. 27 I.2. Identificación del problema .......................................................... 30 I.3. Estrategia de investigación ........................................................... 34 I.4. Hipótesis preliminar ................................................................... 37 I.5. Objetivos de la Tesis .................................................................. 39 I.5.1. Objetivo general .................................................................. 39 I.5.2. Objetivos específicos ............................................................. 41 I.6. Estructura de la Tesis ................................................................. 42 I.7. Resumen del Capítulo ................................................................. 43 Capítulo II. Contexto de la investigación ................................................. 44 II.1. Ingeniería del software............................................................... 46 II.2. Model-Driven Engineering ........................................................... 48 II.3. Tecnología blockchain ................................................................ 52 II.3.1. Antecedentes ..................................................................... 57 Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 5 / 251 II.3.2. Aspectos generales .............................................................. 60 II.3.3. Smart contracts .................................................................. 65 II.5. Identificación de la problemática existente ....................................... 80 II.6. Visión general de la solución propuesta ........................................... 85 II.7. Resumen del Capítulo ................................................................ 88 Capítulo III. Trabajos relacionados ........................................................ 89 III.1. Planificación de la revisión sistemática (planning) ............................. 91 III.1.1. Necesidad de realizar la revisión ............................................. 91 III.1.2. Preguntas de investigación ................................................... 94 III.1.3. Protocolo de revisión ........................................................... 95 III.2. Ejecución del protocolo de revisión (conducting) ............................. 104 III.2.1. Identificación, selección y análisis de estudios primarios ............. 105 III.2.2. Riesgos identificados ......................................................... 107 III.3. Presentación de los resultados obtenidos (reporting) ........................ 108 III.4. Conclusiones tras finalizar este trabajo ........................................ 119 III.5. Resumen del Capítulo ............................................................. 124 Capítulo IV. Metamodelos .................................................................. 126 IV.1. Metamodelo de smart contract .................................................. 131 IV.1.1. Metamodelo de smart contract ............................................. 132 IV.1.2. Perfil UML ...................................................................... 139 IV.2. Metamodelo de pruebas funcionales ............................................ 142 IV.2.1. Metamodelo de pruebas funcionales de smart contract ................ 146 IV.2.2. Perfil UML ...................................................................... 151 IV.3. Relaciones entre los metamodelos .............................................. 152 IV.4. Resumen del Capítulo ............................................................. 153 Nicolás Sánchez Gómez Ph. D. Tesis Página 6 / 251 Capítulo V. Mecanismos y herramienta de soporte a la generación de pruebas .. 155 V.1. Obtención del modelo de smart contract ....................................... 158 V.2. Transformaciones a realizar ....................................................... 163 V.2.1. Transformación para la obtención del modelo de escenario de Caso de Uso ....................................................................................... 164 V.2.2. Transformación para la obtención del modelo de Casos de Prueba ... 165 V.3. Herramienta de soporte ............................................................ 167 V.3.1. Sintaxis definidas en Enterprise Architect ................................. 168 V.3.2. Nuevo «Add-in» para Enterprise Architect ................................. 170 V.4. Resumen del Capítulo .............................................................. 173 Capítulo VI. Casos prácticos y validación ............................................... 174 VI.1. Proyecto SmartAuditor ............................................................ 175 VI.1.1. Referencia ...................................................................... 175 VI.1.2. Visión global del proyecto ................................................... 175 VI.1.3. Aplicación de la propuesta .................................................. 177 VI.1.4. Conclusiones del proyecto ................................................... 187 VI.2. Otros trabajos ...................................................................... 189 VI.3. Resumen del Capítulo ............................................................. 191 Capítulo VII. Resultados, trabajo futuro y conclusiones .............................. 193 VII.1. Aportaciones de este trabajo de Tesis ......................................... 194 VII.2. Trabajos futuros ................................................................... 195 VII.3. Conclusiones ....................................................................... 197 VII.4. Conclusions ........................................................................ 198 Glosario de términos ........................................................................ 200 Referencias .................................................................................... 217 Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 7 / 251 Producción y actividad investigadora .................................................... 225 Anexo. Características clave de la tecnología blockchain ............................. 229 A.1. Aspectos generales ................................................................. 229 A.1.1. Distribuida (o descentralizada) .............................................. 229 A.1.2. Segura ........................................................................... 230 A.1.3. Confiable ........................................................................ 231 A.1.4. Transparente (y con privacidad) ............................................ 232 A.1.5. Trazable ......................................................................... 232 A.1.6. Irrevocable e inmutable ...................................................... 233 A.2. Aplicaciones de esta tecnología ................................................... 234 A.3. Funcionamiento de la red blockchain ............................................ 240 A.3.1. Bloques .......................................................................... 240 A.3.2. Nodos ............................................................................ 244 A.3.3. Fichas (tokens) ................................................................. 246 A.3.4. DApps (aplicaciones descentralizadas) ..................................... 247 A.3.5. Oráculos ......................................................................... 250 Nicolás Sánchez Gómez Ph. D. Tesis Página 8 / 251 Índice de Figuras Figura 1. Ejemplo de un caso de prueba funcional generado mediante SofIA ....... 25 Figura 2. Pautas de SofIA para la generación de pruebas funcionales tempranas .. 26 Figura 3. Arquitectura tecnológica de la plataforma SmartISBN ....................... 28 Figura 4. Marco metodológico de la investigación en Design Science ................ 35 Figura 5. Esbozo del Graphical Abstract de la Tesis Doctoral .......................... 40 Figura 6. Arquitectura de capas de MDE ................................................... 49 Figura 7. Ciclo de vida basado en modelos, en comparación con el tradicional .... 51 Figura 8. Marco de referencia de los smart contracts en la blockchain ............... 55 Figura 9. Cómo funciona blockchain ........................................................ 62 Figura 10. Tipos de plataformas blockchain ............................................... 63 Figura 11. Ejemplo de uso de los smart contracts ....................................... 67 Figura 12. Componentes básicos del Contracto Triple Ricardiano ..................... 69 Figura 13. Asociaciones de un Contrato Triple Ricardiano .............................. 71 Figura 14. Anatomía de smart contract en la blockchain ............................... 73 Figura 15. Estructura básica de smart contract en la blockchain ...................... 76 Figura 16. Ejemplo estructura básica de smart contract de Ethereum ............... 79 Figura 17. Tipo Class “Sample” .............................................................. 80 Figura 18. Enfoque MDE para modelar smart contracts ................................. 85 Figura 19. Graphical Abstract de la Tesis - versión detallada - ........................ 86 Figura 20. Estudios obtenidos de las bibliotecas digitales ............................. 106 Figura 21. Análisis de los resultados obtenidos de cada biblioteca digital. ......... 106 Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 9 / 251 Figura 22. Proceso de generación de pruebas funcionales ............................ 129 Figura 23. Pautas seguidas para la generación de pruebas funcionales ............ 131 Figura 24. Propuesta de metamodelo de smart contract .............................. 132 Figura 25. Perfil UML para el metamodelo de smart contract ........................ 141 Figura 26. Ejemplo de Diagrama UML de Casos de Uso .............................. 143 Figura 27. Ejemplo de Diagrama UML de Actividad .................................... 143 Figura 28. Ejemplo de modelado de decisión mediante DMN ........................ 144 Figura 29. Ejemplo de diagrama de Requisitos de Decisión .......................... 144 Figura 30. Ejemplo de Tabla de Decisión ................................................ 145 Figura 31. Ejemplo de escenarios de Caso de Uso ..................................... 146 Figura 32. Metamodelo de pruebas funcionales ......................................... 146 Figura 33. Perfil UML para el metamodelo de pruebas funcionales .................. 151 Figura 34. Relaciones de trazabilidad entre metamodelos ............................ 152 Figura 35. Ejemplo de un diagrama de Actividad de un Caso de Uso .............. 156 Figura 36. Escenarios obtenidos por SofIA .............................................. 157 Figura 37. Modelo de smart contract ..................................................... 159 Figura 38. Tabla de decisión de un diagrama DMN .................................... 159 Figura 39. Transformaciones para la obtención de pruebas funcionales ............ 163 Figura 40. Pseudocódigo de las transformaciones ...................................... 164 Figura 41. Pseudocódigo de la transformación T1 ...................................... 165 Figura 42. Pseudocódigo transformación T2 ............................................. 166 Figura 43. Proyecto «MDG Technology» en Enterprise Architect .................... 168 Figura 44. Asistente de Enterprise Architect para generación del fichero “MDG Technology” ................................................................................... 170 Figura 45. Extracto del código de la clase Transformación ........................... 171 Nicolás Sánchez Gómez Ph. D. Tesis Página 16 / 251 Resumen Los sistemas software son cada vez más multidisciplinares y complejos. Su implementación de forma satisfactoria se ha convertido en un desafío continuo para cualquier tipo de empresa u organismo. Llevar a cabo la “transformación digital” de una empresa u organización implica, entre otras cosas, la adopción de tecnologías digitales avanzadas al objeto de mejorar su funcionamiento, eficiencia, productos y servicios. Es decir, para las empresas y organizaciones supone la aceptación e integración de tecnologías como internet, la nube y los servicios en línea, el internet de las cosas, la automatización de procesos, el análisis masivo de datos, la inteligencia artificial, y otros avances tecnológicos. En este contexto, hace ya unos años, apareció la tecnología blockchain. Ésta constituye también una de esas tecnologías que están impulsando la comentada “transformación digital”, gracias a sus características únicas y su potencial para abordar ciertas limitaciones de los sistemas tradicionales. Además, dado su carácter transversal 1 , esta tecnología está permitiendo la disrupción en la economía y en la empresa más allá de las conocidas criptomonedas. Solo habría que realizar una búsqueda rápida por internet para evidenciar que estamos asistiendo a una importante apuesta del mercado hacia los desarrollos basados en esta tecnología disruptiva. Esto es debido, fundamentalmente, a su capacidad para transformar la forma en que se registran las transacciones y la manera en que se almacenan y recuperan los datos. 1 Se adapta a numerosos sectores tales como agricultura, industria, finanzas, administración pública, seguros, legal, logística, automoción, aeroespacial, etc. (prácticamente a todos). Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 17 / 251 En la tecnología blockchain, los llamados smart contracts (contratos inteligentes) podrían actuar como complemento o sustituto de los contratos legales, ya que pueden automatizar y ejecutar acuerdos de manera eficiente y transparente. Estos “contratos digitales” se registran en un lenguaje informático que es desplegado y ejecutado en una plataforma blockchain. Estos scripts contienen una serie de reglas y condiciones preestablecidas y, cuando se cumplen las mismas, el smart contract permite la ejecución de las acciones programadas, sin necesidad de intervención humana o de terceros. Una de las características intrínsecas de la blockchain es su inmutabilidad, es decir, la capacidad de un “libro mayor” de blockchain para permanecer como un historial permanente, indeleble e inalterable de transacciones. Por tanto, es necesario, por no decir fundamental, que antes de desplegar un smart contract en una red empresarial, estos scripts pasen por unos minuciosos procesos de verificación al objeto de validar que su funcionamiento sea el esperado. Un error o defecto en el código de estos programas, por su naturaleza inmutable, puede conducir a resultados inesperados o no deseados y, lo más grave, podría causar un efecto no reparable. Además, desde un punto de vista ingenieril, todo cambio tecnológico debería ir acompañado de un adecuado aseguramiento de la calidad, tanto de los productos software como del proceso productivo para su desarrollo y puesta en marcha. Pero, hoy en día, existen pocas utilidades, técnicas o métodos que proporcionen una solución, de forma global, para ello. Repasando la literatura existente, la tecnología blockchain está aún en sus inicios desde el punto de vista de la calidad del software. Aunque ya empiezan a ver la luz propuestas interesantes de desarrollo y enfoques metodológicos concretos, las propuestas para el aseguramiento de la calidad de los smart contracts y, sobre todo, las propuestas para abordar el testing temprano, son aún escasas o muy ambiguas. Todo esto se ha hecho evidente tras el trabajo previo de investigación realizado como parte de la presente Tesis Nicolás Sánchez Gómez Ph. D. Tesis Página 18 / 251 Doctoral, donde se ha identificado que todavía son muy escasos los estudios primarios enfocados a dar una respuesta, aunque sea parcial, a esta línea de trabajo. Una vez identificado el problema y los objetivos perseguidos en relación al aseguramiento de la calidad de los smart contract, a lo largo de esta Tesis Doctoral se ha intentado dar respuesta a la siguiente pregunta de investigación: “¿Los principios que rigen las pruebas tempranas en el ciclo de vida del desarrollo de software son aplicables, en un contexto blockchain, para garantizar la calidad funcional de los smart contracts?”. Para ello, se ha analizado de forma detallada los componentes y el funcionamiento de la tecnología blockchain y, más en concreto, de los smart contract. Además, se han analizado posibles soluciones, hasta identificar una solución factible para resolver el problema identificado. En concreto, en este trabajo se ha definido un mecanismo que nos permite generar pruebas funcionales de los smart contracts a partir de las especificaciones facilitadas por el área usuario o cliente y, se ha implementado una utilidad que de soporte a la ejecución de este mecanismo de generación de pruebas funcionales de forma sistemática. Es más, gracias a un proyecto de I+D+i como es el Proyecto SmartAuditor, entre otros, se ha podido dar una respuesta práctica a estos trabajos y en un contexto industrial, siendo este proyecto pionero en resolver de forma satisfactoria esta problemática, mediante nuestra propuesta de solución basada en la aplicación de los principios del testing temprano durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 19 / 251 Summary The software systems are becoming increasingly multidisciplinary and complex. Their successful implementation has become a continuous challenge for any type of company or organisation. Carrying out the "digital transformation" of a company or organization involves, among other things, the adoption of advanced digital technologies to improve its operations, efficiency, products and services. In other words, for companies and organizations, it involves the acceptance and integration of technologies such as the internet, cloud computing and online services, the internet of things, process automation, big data analytics, artificial intelligence, and others. In this context, blockchain technology appeared a few years ago. It is also one of those technologies that are driving the aforementioned “digital transformation”, thanks to its unique characteristics and its potential to address certain limitations of traditional systems. Moreover, given its transversality, this technology is enabling disruption in the economy and in business beyond the well-known cryptocurrencies. A quick search on the Internet is enough to see that we are witnessing a significant market commitment to developments based on this disruptive technology. This is mainly due to its ability to transform the way transactions are recorded and the manner in which data is stored and retrieved. Nicolás Sánchez Gómez Ph. D. Tesis Página 20 / 251 In blockchain technology, so-called smart contracts could act as a complement or substitute for legal contracts, as they can automate and execute agreements efficiently and transparently. These "digital contracts" are recorded in a computer language that is deployed and executed on a blockchain platform. These scripts contain a series of pre-established rules and conditions and, when these are satisfied, the smart contract allows the execution of the programmed actions, without the need for human or thirdparty intervention. One of the intrinsic characteristics of the blockchain is its immutability, i.e., the ability of a blockchain "ledger" to remain a permanent, indelible and unalterable history of transactions. Therefore, it is necessary, if not essential, that before deploying a smart contract on an enterprise network, these scripts go through an exhaustive verification process to validate that their operation is as expected. An error or bug in the code of these programs, due to their immutable nature, can lead to unexpected or undesired results and, more seriously, could cause an unrepairable effect. Moreover, from an engineering point of view, any technological change should be accompanied by adequate quality assurance, both of the software products and of the production process for their development and implementation. However, nowadays, there are very few utilities, techniques or methods that provide an adequate solution for this. Reviewing the existing literature, blockchain technology is still in its infancy from the point of view of software quality. Although interesting development proposals and concrete methodological approaches are beginning to emerge, proposals for quality assurance of smart contracts and, above all, proposals to address early testing, are still scarce or very ambiguous. All this has become evident after the previous research work carried out as part of this Doctoral Thesis, where it has been identified that there are still very few primary studies focused on providing an answer, even if only partial, to this line of work. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 21 / 251 Having identified the problem and the objectives pursued in relation to the quality assurance of smart contracts, throughout this Doctoral Thesis, we have tried to answer the following research question: "Are the principles governing early testing in the software development lifecycle applicable, in a blockchain context, to ensure the functional quality of smart contracts?”. For this purpose, the components and operation of blockchain technology and, more specifically, of smart contracts have been analysed in detail. In addition, possible solutions have been analysed, until a feasible solution to solve the identified problem has been identified. Specifically, in this work we have defined a mechanism that allows us to generate functional tests of smart contracts from the specifications provided by the user area or client and, we have implemented a utility that supports the execution of this mechanism for generating functional tests, in a systematic way. Moreover, thanks to a R&D&i project such as SmartAuditor Project, among others, it has been possible to give a practical response to these tasks in an industrial context, being this project a pioneer in solving this problem satisfactorily, through our proposed solution based on the application of the principles of early testing during the development life cycle of smart contracts in blockchain technology. Nicolás Sánchez Gómez Ph. D. Tesis Página 22 / 251 Capítulo I. Introducción “The last thing you know, is where to start” - Blaise Pascal - I.1. Antecedentes I.1.1. Grupo Engineering and Science for Software Systems El grupo de investigación y de trabajo Engineering and Science for Software Systems (ES3) del Departamento de Lenguajes y Sistemas Informáticos (LSI) de la Escuela Técnica Superior de Ingeniería Informática (ETSII) de la Este Capítulo inicia la Tesis Doctoral presentando, por un lado, los antecedentes de la investigación realizada, el problema existente y la estrategia de investigación y, por otro, la hipótesis de partida y los objetivos y retos de la presente Tesis. Además, en este mismo Capítulo se expone cómo se ha estructurado el presente trabajo de investigación y los Capítulos que la componen, con la intención de realizar una adecuada presentación global de la misma. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 23 / 251 Universidad de Sevilla (US), es un grupo reconocido en el Plan Andaluz de Investigación como grupo PAIDI 2 TIC-021 y está adscrito como equipo de trabajo a la Fundación FIDETIA (Fundación para la Investigación y el Desarrollo de las tecnologías de la información en Andalucía) de la ETSII y a la Fundación FIUS (Fundación para la Investigación en la Universidad de Sevilla). Durante más de 15 años, este grupo ha participado y participa en diversos proyectos de investigación de ámbito autonómico, nacional e internacional, y en numerosos proyectos de transferencia de resultados de investigación y en proyectos de I+D+i en cooperación nacional o internacional. El grupo ES3, aparte de participar en diferentes proyectos de investigación, destaca por su dilatada colaboración con el tejido empresarial. Las actuales líneas de trabajo del grupo se podría encuadrar, aunque no limitar, dentro de la ingeniería de requisitos, el testing software y el aseguramiento de la calidad durante el desarrollo de sistemas de información (orientados o no a la web), dando un rol especial a la ingeniería de pruebas, el desarrollo de técnicas y protocolos que mejore la competitividad de las empresas de cualquier ámbito de negocio en base a la gestión eficaz y eficiente de sus procesos de negocio y en la definición, generación y transformación de modelos bajo el paradigma de la ingeniería dirigida por modelos. El grupo ES3 también contempla soluciones enmarcadas en tecnologías referentes como RPA (Robotic Process Automation), AI (Artificial Intelligence), blockchain y es experto en dar soporte a empresas y organismos en sus procesos de Transformación Digital. 2 PAIDI. Plan Andaluz de Investigación, Desarrollo e Innovación Nicolás Sánchez Gómez Ph. D. Tesis Página 24 / 251 I.1.2. Propuesta metodológica SofIA NDT (Navigational Development Techniques) es una propuesta metodológica (Escalona, 2008) incluida dentro del paradigma de la ingeniería dirigida por modelos, que se definió inicialmente para cubrir las necesidades en el desarrollo Web. Esta propuesta, basada en el uso de herramientas CASE (Computer Aided Software Engineering), partía de la definición de metamodelos formales para la fase de requisitos y de la definición de un conjunto de transformaciones que permiten generar los modelos de la fase análisis (Escalona, 2008). La etapa de ingeniería de requisitos comienza con la definición de los objetivos del sistema, para posteriormente ir capturando y definiendo los actores y los requisitos del mismo: requisitos funcionales, requisitos de almacenamiento de información, requisitos de interacción y requisitos no funcionales. En los últimos años, esta propuesta metodológica enfocada al aseguramiento de la calidad de los resultados durante el desarrollo software, además de cambiar su nombre por SofIA, ha evolucionado para ofrecer una suite de herramientas y un soporte completo para todo el ciclo de vida de desarrollo de software. Actualmente, SofIA (Escalona, 2022) (Escalona, 2023) cubre tres fases relevantes: (1) El análisis de requisitos, considerando los diferentes tipos de requisitos, así como la elaboración de mockups (prototipos); (2) El diseño, que incluye la arquitectura y el modelo de comportamiento de la solución, así como el modelo de persistencia; (3) La fase de pruebas, que incluye los distintos tipos de pruebas durante todo el desarrollo de software. Además, SofIA también permite gestionar la trazabilidad de los artefactos (Escalona, 2023). Por ejemplo, si la ejecución de un caso de prueba no se ha podido completar, se podría rastrear qué requisito funcional generó este caso de prueba. Empresas como Airbus, Fujitsu, Lantia, NTT Data o la Administración Pública andaluza han utilizado con éxito esta metodología y sus herramientas. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 25 / 251 De forma ilustrativa, en la Figura 1, se muestra un ejemplo de un caso de prueba funcional obtenida a partir de un caso de uso modelado mediante este marco metodológico. Figura 1. Ejemplo de un caso de prueba funcional generado mediante SofIA Gracias a la suite de herramientas que proporciona SofIA, se puede definir tanto la fase de requisitos como la fase de análisis y diseño de un proyecto, así como generar las pruebas funcionales del sistema de forma temprana y sistemática, a partir de los casos de uso previamente elaborados. En concreto, para generar las pruebas funcionales, este marco metodológico realiza una serie de actividades, tal y como muestra la Figura 2. Nicolás Sánchez Gómez Ph. D. Tesis Página 32 / 251 RQ1. ¿Se podrían evitar o minimizar los posibles defectos o errores de los smart contracts, si se hiciera un descubrimiento, refinamiento, modelización y especificación funcional mediante requisitos?. RQ2. ¿Se podrían evitar o minimizar esos posibles defectos o errores si, además, se inicia la actividad de pruebas del software en fases tempranas del desarrollo de estos programas informáticos? (como ya se hace en otro tipo de sistemas). Aparentemente, desde el punto de vista ingenieril y dado el know-how del grupo de investigación en esta temática, todas estas actividades (elicitación, refinamiento, modelización y especificación funcional mediante requisitos) permiten mejorar la calidad de cualquier software y, por ende, todo apunta a que también deberían permitir mejorar la calidad de estos programas informáticos, llamados smart contracts. Por tanto, en la presente Tesis Doctoral nos centraremos en detallar por qué es necesario mejorar la calidad de los smart contracts, en estudiar cómo se puede mejorar la calidad de éstos y, sobre todo, en verificar si mejoraría su calidad si se realizaran pruebas funcionales desde las etapas tempranas del desarrollo del software, es decir, aplicando los principios de lo que se conoce como “testing temprano”, “pruebas tempranas” o “early testing”. Estos principios se basan en la idea de incorporar pruebas de software lo antes posible en el ciclo de vida de desarrollo, con el objetivo de identificar y solucionar problemas de manera temprana, siguiendo las directrices marcadas por el estándar ISO 29119 Ingeniería de software y sistemas - Pruebas de software -. Estos principios se podrían resumir de la siguiente forma (Abrahäo, 2022): Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 33 / 251 • Realización de pruebas desde el inicio. Las pruebas deben comenzar en las etapas tempranas del ciclo de vida de desarrollo, antes de que se empiece a escribir o generar el código. Esto implica contemplar las pruebas durante las especificaciones, los requisitos, etc. para asegurar su comprensión y sea realizable su implementación. • Automatización de pruebas. Se debe buscar la automatización de las pruebas, lo que implica establecer los escenarios y los casos de prueba automatizados que puedan ejecutarse de manera rápida y repetible. Esta automatización ayuda a identificar rápidamente problemas y reduce el tiempo y esfuerzo requerido para realizar pruebas manuales repetitivas. • Ejecución de pruebas continuas. Las pruebas deben realizarse de manera continua a lo largo del ciclo de vida de desarrollo y no esperar hasta el final del proceso de desarrollo para probar el software. Se deben realizar pruebas de forma regular y frecuente, lo que facilita la detección de problemas de manera temprana y abordar las posibles soluciones antes de que se conviertan en costosos errores de difícil corrección. • Prevención y realimentación: El enfoque principal del testing temprano es prevenir problemas en lugar de encontrarlos. Se busca identificar y corregir posibles errores, deficiencias o inconsistencias antes de que se conviertan en defectos más graves. Un feedback rápido permite, a los equipos de desarrollado, corregir errores de manera oportuna y mejorar el software de manera iterativa. • Colaboración multidisciplinaria. El testing temprano requiere la colaboración de diferentes roles y disciplinas dentro del equipo de desarrollo de software. Éstos deben trabajar desde el principio para garantizar que se realicen las pruebas adecuadas y se aborden los problemas de manera efectiva. Nicolás Sánchez Gómez Ph. D. Tesis Página 34 / 251 Estos principios promueven una cultura de calidad y mejora continua en el desarrollo de software, permitiendo la detección temprana de problemas y la entrega de software más confiable y robusto. I.3. Estrategia de investigación Es evidente que un soporte metodológico ayuda a cualquier investigador a garantizar la calidad de sus resultados y, sobre todo, a organizar el contenido de sus conclusiones. También ayudaría a estructurar y presentar el contenido de su investigación de una forma más comprensible. Por tanto, durante la realización de esta Tesis Doctoral se ha tenido como marco metodológico de referencia el método Design Science (Johannesson, 2014) (Wieringa, 2014) (Dresch, 2015). Este método contiene directrices generales que facilita: (i) Llevar a cabo las actividades, (ii) Elegir las estrategias y métodos de investigación que se utilizarán en las actividades y (iii) Relacionar la investigación con una base de conocimientos ya existente. Mediante la aplicación de este método, los resultados obtenidos deben estar relacionados con una base de conocimientos existente para garantizar que la investigación producida exprese conocimientos válidos y fiables. Para ello, este marco de trabajo describe cinco actividades relacionadas que definen las preguntas que el investigador debe responder y los resultados que se deben producir. Estas actividades comienzan definiendo el problema y continúan hasta demostrar y evaluar los artefactos producidos que resuelven un problema identificado. Cada actividad está asociada a directrices que ofrecen consejos prácticos que apoyan y facilitan el trabajo de investigación, ayudando a garantizar el rigor científico. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 35 / 251 Figura 4. Marco metodológico de la investigación en Design Science (Johannesson, 2014) En concreto, como se puede apreciar en la Figura anterior, las actividades que componen este marco de trabajo son: • Explicar el problema. Durante esta actividad se estudia las causas fundamentales del problema y su objetivo es proporcionar una comprensión esencial de un problema. • Definir los requisitos. Esta actividad define los requisitos y propone un esbozo de solución. • Diseñar/desarrollar el artefacto. Esta actividad es el desarrollo teórico del enfoque de la solución, que incluye el artefacto en cuestión. • Demostrar el artefacto. Se utiliza el artefacto, planteado en la etapa anterior, en uno o varios casos para demostrar que puede resolver el problema. Nicolás Sánchez Gómez Ph. D. Tesis Página 36 / 251 • Evaluar el artefacto. La última actividad determina la eficacia del artefacto para resolver el problema para el que fue diseñado. En esta metodología, un problema se define como una brecha entre el estado actual y el deseable, siendo necesario generalizar el problema al que se hace frente y contar con los conocimientos de la bibliografía de investigación existente. Teniendo en cuenta este método, explicar el problema se compondría de varias subactividades: • Definir el problema con precisión para garantizar que diferentes personas lo entiendan de la misma manera. Un entendimiento común ayuda a las personas a compartir la misma visión de un problema y ayuda a limitar el alcance del proyecto de investigación, • Justificar el problema, describiendo su propósito, el entorno y los retos, de forma que se esté de acuerdo en que merece la pena abordarlo y, • Encontrar las causas del problema, lo que ayuda a definir una solución para mitigarlo. En la presente Tesis Doctoral, explicar el problema se ha abordado de la siguiente manera: • En el Capítulo II se describe y justifica el problema, determinando el contexto de éste de forma precisa, concisa y comprensible. • En el Capítulo III se destaca la importancia del problema y se señala la generalización del problema abordado. Para ello, se describen estudios primarios disponibles en la literatura que han identificado o experimentado previamente el problema descrito. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 37 / 251 La segunda actividad, relativa a definir los requisitos, abordaría la pregunta: "¿Qué solución resolvería el problema identificado y qué requisitos a cubrir son los más importantes?". En el Capítulo IV se aborda esta pregunta y se describe una solución que permitiría resolver el problema identificado. La siguiente actividad, relativa a diseñar/desarrollar el artefacto, debe proporcionar los mecanismos o utilidades que permitan resolver el problema identificado. En el Capítulo V se identifica y detalla el artefacto desarrollado, a partir de la solución planteada en el Capítulo anterior. La última actividad, relativa a evaluar el artefacto, se centra en cómo usar el artefacto desarrollado y, sobre todo, en su evaluación práctica. Con esta actividad se intenta determinar hasta qué punto lo producido hasta el momento cumple con lo esperado (de acuerdo con el problema que motivó la investigación). En el Capítulo VI, de la presente Tesis, se recogen dichos casos prácticos y los resultados obtenidos tras su validación. I.4. Hipótesis preliminar La pregunta general de investigación (RQ - Research Question) que nos planteamos en este trabajo de investigación sería la siguiente: PREGUNTA DE INVESTIGACIÓN (RQ) ¿Los principios que rigen las pruebas tempranas en el ciclo de vida del desarrollo de software son aplicables, en un contexto blockchain, para garantizar la calidad funcional de los smart contracts?. Tabla 1. Pregunta general de investigación de la Tesis Nicolás Sánchez Gómez Ph. D. Tesis Página 38 / 251 Por tanto, esta Tesis se enfrenta al reto de aplicar los principios de las pruebas tempranas en el contexto de la blockchain y, más en concreto, en el aseguramiento de la calidad funcional de los smart contracts, su pilar fundamental. Desde nuestro punto de vista, al adaptar y aplicar estos principios de manera adecuada, se puede mejorar la confiabilidad y seguridad de los smart contracts, antes de que estos programas informáticos sean compilados, desplegados y ejecutados en una plataforma blockchain. Partiendo de esta RQ y el contexto general del presente trabajo, el reto de este trabajo de investigación sería demostrar que la RESPUESTA a esta pregunta es AFIRMATIVA. Luego, teniendo estas premisas en cuenta, la hipótesis de partida de esta Tesis sería la siguiente. HIPÓTESIS DE PARTIDA La aplicación de los principios y técnicas del testing temprano sobre el ciclo de vida de desarrollo de software, podría ayudar a generar pruebas funcionales de los smart contracts, de forma independiente de la plataforma blockchain, al objeto de garantizar que las transacciones realizadas a través de estos programas informáticos se ejecutan conforme a las especificaciones, condiciones y reglas preestablecidas. Tabla 2. Hipótesis de partida de la Tesis Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 39 / 251 I.5. Objetivos de la Tesis I.5.1. Objetivo general Partiendo de la hipótesis de partida y teniendo en cuenta nuestro objetivo de demostrar que podemos resolver de forma afirmativa la RQ recogida en la Tabla 1, en este apartado se hace mención al objetivo general de este trabajo de Tesis. Este objetivo queda plasmado en la Tabla 3. OBJETIVO GENERAL Desarrollar una solución, basada en los principios del testing temprano, para generar pruebas funcionales a partir de las especificaciones de los smart contract, lo que permitirá validar la calidad funcional de estos programas informáticos, independientemente de la plataforma blockchain que se vaya a emplear. Tabla 3. Objetivo general de la Tesis La Figura 5 muestra un primer esbozo del Graphical Abstract de la presente Tesis Doctoral. Esta ilustración recoge el flujo de trabajo o mecanismo previsto que, desde nuestro punto de vista, permitirá aplicar los principios de pruebas tempranas durante el ciclo de vida del desarrollo de software y, más en concreto, del desarrollo de los smart contracts. Como se puede apreciar en dicha Figura, el proceso se inicia con la definición de las especificaciones, condiciones y reglas a tener en cuenta en los smart contracts, detalles que normalmente son facilitados por el área usuaria o clientes. Toda esta información será modelada por el equipo de analistas mediante un lenguaje estructurado, a partir de unos metamodelos previamente establecidos y, posteriormente, estos modelos podrán ser Nicolás Sánchez Gómez Ph. D. Tesis Página 40 / 251 implementados por el equipo de desarrollo. De manera paralela a este proceso, aplicando los resultados de este trabajo de Tesis, se podrán ir generando de forma sistemática pruebas funcionales asociadas a la solución global y, de forma temprana, el equipo de trabajo podrá ir verificando que la funcionalidad de la solución, que incluye los smart contracts, es la esperada. Figura 5. Esbozo del Graphical Abstract de la Tesis Doctoral Como muestra la Figura anterior, las pruebas funcionales obtenidas a partir del modelado de la solución global – que incluye los smart contracts -, podrán ser ejecutadas, por el equipo de pruebas, una vez implementado el código, al objeto de asegurar que la solución global o las específicas, como son los smart contract, generan los resultados esperados. Es decir, el equipo de trabajo podrá validar que todas las características y funcionalidades de la solución global, se comportan según las especificaciones, condiciones, reglas, etc. facilitadas y sin ningún problema. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 41 / 251 Este modo de trabajo, además, garantizaría que la obtención de las pruebas funcionales a ejecutar, se hacen de manera independiente a la implementación del código, siguiendo así los principios establecidos y las buenas prácticas recogidas en la norma UNE EN ISO 29119 (Tuya, 2009). I.5.2. Objetivos específicos Una vez establecido el objetivo general de la presente Tesis, en la tabla siguiente se exponen los objetivos específicos que nos ayudarán a alcanzarlo. Objetivo Descripción OBJ-00 Valorar la importancia del problema, describiendo estudios primarios disponibles en la literatura que han identificado, experimentado o analizado previamente el problema descrito. OBJ-01 Identificar qué artefactos podrían aportar una solución para el problema identificado, planteando alguna estructura que permita modelar los smart contracts y las pruebas funcionales, a partir de las especificaciones, condiciones, reglas, etc. OBJ-02 Definir un mecanismo que nos permita generar pruebas funcionales de los smart contracts, en fases tempranas del ciclo de vida de desarrollo, a partir de la solución propuesta y de la manera más automática posible. OBJ-03 Implementar una utilidad o herramienta que facilite la concreción de la solución propuesta y que, a su vez, permita ejecutar el mecanismo de generación de pruebas funcionales de los smart contracts de forma sistemática. OBJ-04 Evaluar la solución propuesta, los mecanismos propuestos y la herramienta implementada, mediante verificaciones y validaciones en un contexto industrial. Tabla 4. Objetivos específicos de la Tesis Doctoral Nicolás Sánchez Gómez Ph. D. Tesis Página 48 / 251 cada vez más utilizadas con el objetivo de lograr que la reutilización esté integrada, de forma sistémica, en las diferentes fases del SDLC. Numerosos autores (Elallaoui, 2016) (García-García, 2014) (Whittle, 2013) (Escalona, 2011) (Escalona, 2008) (Baker, 2007) indican los beneficios de usar el paradigma MDE. Estos autores indican que se podrían usar diversas técnicas para obtener las especificaciones del software y, a partir de éstas, realizar una automatización de las pruebas funcionales. En concreto, estos autores proponen el uso sistemático de UML (Unified Modeling Language), lo que permitiría la transformación de modelados de requisitos en modelados de prueba e incluso obtener el código fuente del software. II.2. Model-Driven Engineering Model-Driven Engineering (MDE), como se ha comentado, es una disciplina dentro de la ingeniería del software que tiene por objetivo dar soporte a las actividades de producción de software, utilizando los modelos como principal artefacto. Un concepto clave para trabajar con modelos es el metamodelo. Por ejemplo, podemos crear un modelo de un vehículo mediante diferentes técnicas como puede ser un prototipo o un plano, donde dicho modelo representaría un elemento del mundo real. Estas dos ideas normalmente serían suficientes, pero en esta disciplina se discute sobre el concepto de metamodelo, es decir, ¿cómo construir modelos?. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 49 / 251 Figura 6. Arquitectura de capas de MDE En concreto, el Object Management Group (OMG) (OMG, 2006) propone una arquitectura MDE de varios niveles, tal y como se muestra en la Figura 6: - M3 (Meta-metamodelo). En este nivel se definen los conceptos, los atributos y las relaciones para los elementos del nivel M2, mientras que los elementos situados en el nivel M2 son las instancias de los elementos del nivel M3. - M2 (Metamodelo). En este nivel, teniendo en cuentas las especificaciones del nivel M3, se definen los elementos válidos de un modelo específico del nivel M1, mientras que los elementos situados en el nivel M1 serían las instancias de los elementos del nivel M2. En el caso de un metamodelo elaborado según UML (OMG, 2011), es posible citar ejemplos de conceptos que se encuentran en este nivel como es 'Clase', 'Atributo' o 'Asociación'. Nicolás Sánchez Gómez Ph. D. Tesis Página 50 / 251 - M1 (Modelo). El nivel M1 define las clasificaciones de los elementos del nivel M0, mientras que los elementos situados en el nivel M0 son las instancias de los elementos del nivel M1. Un ejemplo en este nivel, según UML, sería un modelo de caso de uso o una clase como, por ejemplo, los conceptos "Cliente", "Venta" o "Libro" y sus atributos "Nombre", "Autor", etc. - M0 (Realidad). En este nivel hay instancias de modelos de M1, como por ejemplo objetos "Libro" instanciados. El elemento clave en todo este proceso es la transformación entre modelos, que puede definirse como el proceso por el cual un modelo se convierte en otro modelo del mismo sistema. Estas transformaciones se realizan mediante la asociación de constructores del metamodelo origen con los constructores correspondientes del metamodelo destino. Existen dos tipos de transformaciones: Model-to-Model (M2M) y Model-to-Text (M2T), según el modelo destino corresponda a otro modelo abstracto del sistema o a un modelo de código (texto). En MDE, desde hace años, las herramientas de modelado o CASE están ayudando a documentar la funcionalidad de los procesos de negocio y, a través de las transformaciones de los modelos, a automatizar la generación del código fuente del software (Bézivin, 2012). Es más, dado que los modelos suelen ser más fáciles de entender que el código fuente del software (Forward, 2008), el uso del modelado UML u otros estándares se han extendido bastante, ya que su uso está permitiendo mejorar la productividad y la calidad del desarrollo (Forward, 2008). Según algunos autores (Lu, 2018), es más fácil comprobar la corrección de un modelo y las herramientas de modelado pueden garantizar, además, que el código desplegado no ha sido modificado después de su generación a partir del modelo. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 51 / 251 Figura 7. Ciclo de vida basado en modelos, en comparación con el tradicional (Conrad, 2005) Como se puede apreciar en la Figura 7, en comparación con el SDLC tradicional donde las fases están claramente separadas, los desarrollos que han seguido un SDLC basado en el paradigma MDE, donde las fases de especificaciones de requisitos, diseño e implementación han evolucionado juntas con mucha más fuerza y de forma paralela a la fase de pruebas (Conrad, 2005). Además, algunos autores (Seebache, 2018) indican que el SDLC basado en el paradigma MDE contribuye a describir y comprender un producto software de varias maneras: ayuda al equipo de trabajo a comunicar la visión del sistema que se está construyendo; permite especificar la estructura y conducta del producto software, facilitando la visualización del mismo para usuarios o clientes. Otros (PivotPoint TechnologyTM, 2019) sostienen que las principales ventajas de este enfoque, guiado por modelos, son que: (1) los requisitos son una parte integral del modelo y partes del modelo pueden remontarse a los requisitos, lo que se conoce como trazabilidad de los requisitos; (2) los modelos pueden utilizarse para representar el comportamiento esperado de un producto software bajo pruebas, reduciendo los errores durante el SDLC; (3) la automatización de los casos de prueba garantizan que la implementación del producto software sea más fiable e, incluso, se facilita la generación de un código fuente de calidad. Nicolás Sánchez Gómez Ph. D. Tesis Página 52 / 251 En este contexto, la verificación del modelado es llevado a cabo para evaluar la exactitud entre lo modelado y el producto software que se desea obtener. Si un modelado no cumpliera con las especificaciones funcionales indicadas, se debería introducir modificaciones en el mismo, al objeto de rectificar los errores de análisis y/o diseño, siendo este enfoque la columna vertebral sobre la que se sustentan las “pruebas tempranas”. Las "Pruebas tempranas" es uno de los 7 principios de las pruebas de calidad de software (Homès, 2013) y establece que “las pruebas deben comenzar lo antes posible en el ciclo de vida del desarrollo de software, de modo que cualquier defecto en los requisitos o la fase de diseño se capture en las primeras etapas”. Este razonamiento es de vital importancia para la correcta implementación de los procesos de calidad de software en cualquier proyecto, ya que detectar defectos lo más temprano posible tiene impacto directo sobre distintos aspectos del proyecto, tales como: calidad, tiempo, presupuesto e incluso la reputación del proyecto de cara al usuario final o cliente. Es importante destacar que los avances tecnológicos requieren de arquitecturas cada vez más flexibles y sostenibles. Esto ha provocado que, en los últimos años, exista un mayor interés en este nuevo paradigma basado en modelos, ya que ha demostrado ser enormemente robusto, flexible y escalable en comparación con las estrategias tradicionales. Además, cuenta con conceptos como la independencia de la plataforma y la reutilización, ya que los diseños basados en modelos pueden reutilizarse para añadir más funcionalidad y/o cambiar la arquitectura de destino (Rodrigues, 2012). II.3. Tecnología blockchain Blockchain es una tecnología software disruptiva que avanza a pasos agigantados (Olea, 2019). Constituye una de esas tecnologías fundamentales que impulsan la “transformación digital” de una empresa u organización y, Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 53 / 251 dado su carácter transversal 6 , está permitiendo la disrupción en la economía y en la empresa más allá de las criptomonedas. Este potencial, principalmente, se basa en su capacidad para ofrecer a personas, empresas u organizaciones un canal de comunicación que permite transferir derechos, valores o activos reales (tokenización), a través de Internet, de forma segura y confiable. Aunque a menudo esta tecnología se confunde con la criptomoneda Bitcoin, blockchain solo es la tecnología subyacente utilizada para operar por esa u otras criptomonedas. Esta tecnología software, de forma resumida, se trataría de una base de datos distribuida 7 , conocida como libro mayor, anexa a un software. En esta base de datos solo se registran transacciones validadas por la red. Estas transacciones son almacenadas en unidades elementales llamadas bloques. Estos bloques de datos, físicamente independientes, una vez validados por el “mecanismo de consenso” establecido en la red, se agregan a una cadena secuencial de bloques vinculados mediante funciones hash criptográficas. Esta forma de organización de la información confiere a la tecnología blockchain una de sus principales propiedades: la detección de la integridad de los datos registrados. No es posible añadir, eliminar o modificar la información almacenada en un bloque sin que se produzca un cambio en el valor del hash utilizado como vínculo en el bloque siguiente. Esta propiedad, conocida también como inmutabilidad, garantiza la detección de fallos en la integridad de los bloques almacenados. Además, algunos autores destacan que esta característica intrínseca de la blockchain es un beneficio clave ya que: 6 Se adapta a numerosos sectores tales como agricultura, industria, finanzas, administración pública, seguros, legal, logística, automoción, aeroespacial, etc. (prácticamente a todos). 7 La información no se almacena en un único ordenador, sino en múltiples terminales conectados entre sí a través de Internet. Nicolás Sánchez Gómez Ph. D. Tesis Página 54 / 251 • Permitiría que un libro mayor de la blockchain permanezca como un historial permanente, indeleble e inalterable de transacciones (Crosby, 2016) • Transformaría el proceso de auditoría en un procedimiento rápido y eficiente, dando más confianza e integridad a los datos que las empresas u organizaciones usan y comparten todos los días (Argañaraz, 2019). • Facilitaría la realización de auditorías externas e internas, siendo la trazabilidad una de las funcionalidades más destacadas de esta tecnología sobre otras soluciones (Westerkamp, 2020). Profundizando un poco en esta característica intrínseca, en una red blockchain es extremadamente difícil cambiar las transacciones registradas, ya que cada bloque está vinculado al bloque anterior al incluir el hash de ese bloque anterior. Este hash incluye el hash de raíz del árbol de Merkle (Merkle, 1988) de todas las transacciones en el bloque anterior y, si una sola transacción fuera a cambiar, no solo cambiaría el hash raíz del árbol de Merkle, sino también el hash contenido en el bloque modificado. Además, cada bloque subsiguiente debería actualizarse para reflejar este cambio. Por tanto, cualquier intento de manipulación de una transacción de un bloque validado provocaría un cambio en los hashes propagados, hasta llegar al hash raíz. Por tanto, si se detectara un intento de cambio, éste se invalida automáticamente y, lo mismo sucedería, si se intentan añadir transacciones. Esta tecnología, además, permite a cualquier persona, empresa u organización realizar transacciones de manera fiable y precisa, mediante el uso de los llamados smart contracts (Tapscott, 2017). Estos smart contracts, de forma muy resumida, no son más que programas informáticos que se ejecutan automáticamente, sin intermediarios, en redes blockchain (Sheikh, 2019). Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 55 / 251 Desde una perspectiva jurídica, el término “contrato” es un “acuerdo de voluntades por el que se exige el cumplimiento de una cosa determinada”. Este acuerdo está escrito en términos legales, términos entendibles por los humanos, y crea o transfiere derechos y obligaciones entre dos o más partes. En esencia, es un documento dónde se identifican las partes contratantes, se define lo que se puede hacer, cómo se puede hacer, qué pasa si algo no se hace, etc. (Legerén-Molina, 2018). Desde una perspectiva ingenieril, las especificaciones funcionales que los smart contracts deben satisfacer serían análogos a los términos, condiciones y reglas en un contrato legal convencional. Figura 8. Marco de referencia de los smart contracts en la blockchain Por tanto, como se muestra en la Figura anterior, un smart contract podría dar respuesta a un acuerdo entre partes, pero escrito como un script (programa informático). Este script sería entendible por las maquinas, y las operaciones realizadas a través de él quedarían automáticamente registradas en la red blockchain donde éste se despliegue. Los términos de este “contrato digital” no son más que comandos, sentencias en el código que lo forma, independientemente del lenguaje de programación utilizado. Es importante indicar que los smart contracts puede codificar la ejecución automatizada de acuerdos, como se ha comentado, pero no todos los smart contracts tiene que ser acuerdos y no siempre codifican necesariamente acciones entre más de una parte. Por ejemplo, en las aplicaciones Nicolás Sánchez Gómez Ph. D. Tesis Página 56 / 251 descentralizadas (DApps), los smart contracts se utilizan para ejecutar lógica empresarial y transacciones sin necesidad de una autoridad central. Otro ejemplo, sería los tokens no fungibles (NFTs) que son representaciones digitales únicas de activos. En este caso, los smart contracts se utilizan para respaldar la creación, venta y transferencia de estos tokens únicos. Aunque no son contratos en el sentido tradicional, se basan en la tecnología de smart contracts para funcionar. Éstos son solo algunos ejemplos en los que los smart contracts se utilizan en aplicaciones más allá de los contratos tradicionales y la interacción entre múltiples partes. La tecnología blockchain y los smart contracts tienen un amplio potencial y pueden ser aplicados de diversas formas según las necesidades específicas de cada caso. Si nos centramos en un caso de uso de un smart contract en transacciones comerciales, se puede apreciar con más detalle la importancia y potencial de estos programas informáticos. Por ejemplo, imaginemos que por un lado tenemos a una empresa que vende yogures y, por el otro, a una cadena de hipermercados que los compra. Están en diferentes países y es la primera vez que van a hacer negocios juntos. Acudir a un smart contract les facilitaría la transacción ya que estos programas operan de forma automática, esto significa que no es necesaria la verificación de una entidad supervisora y, además, garantizaría que cada una de las partes cumple con lo acordado en dicho contrato. Para ello, es imprescindible que cada una de las partes que intervienen en dicho contrato conozca, acepten y firmen con anterioridad las condiciones y los pasos que se van a permitir ejecutar durante su vigencia. Una vez desplegado el smart contract en una red blockchain, no se puede alterar la funcionalidad programada, es decir, tanto el smart contract, como cada paso o sentencia conformada en el programa informático es registrada en la blockchain y no se podrían modificar – dada la característica intrínseca de inmutabilidad de esta tecnología -. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 57 / 251 A continuación, para disponer de un mayor conocimiento sobre esta tecnología, se exponen sus antecedentes y las características generales de su funcionamiento para, posteriormente, detallar los aspectos clave de los smart contracts, su pieza angular. II.3.1. Antecedentes La blockchain no apareció de la nada, ya que fue el producto de la evolución de las Fintech y las monedas virtuales en las últimas décadas. El uso generalizado de Internet, a finales del siglo pasado, favoreció el surgimiento de las monedas digitales como una extensión de los sistemas electrónicos de efectivo. Se desarrollaron numerosos proyectos para crear nuevas monedas digitales (Amsyar, 2020): DigiCash y CyberCash, por nombrar solo algunos. A pesar del enorme éxito alcanzado en la década de los noventa, muchos de estos proyectos dejaron de existir a principios de este siglo, ya sea por quiebra o clausurados por las autoridades, dado que era difícil generar confianza en tales entornos sin una autoridad central, y la creación de una moneda digital confiable pasó a ser todo un hándicap. El avance de la criptografía y la aparición de algunas soluciones inteligentes, afortunadamente, trajeron la esperanza de romper ese punto muerto. En 2008, Satoshi Nakamoto (Nakamoto, 2008) aceptó el desafío y presentó una moneda digital llamada bitcoin. Para administrar la propiedad y asegurar el sistema, esta nueva moneda aprovechó eficazmente los métodos criptográficos, de ahí el nombre de criptomoneda. Nakamoto resolvió los problemas antes indicados al introducir lo que inicialmente llamó cadena de bloques. En su documento técnico publicado (Nakamoto, 2008), presentó su visión de un nuevo sistema de efectivo electrónico peer-to-peer — bitcoin — y describió en detalle su maquinaria subyacente — blockchain. Desde su aparición, la blockchain ha revolucionado el panorama financiero, al permitir la transferencia segura de valor monetario en entornos sin “confianza”, es decir, sin depender de intermediarios externos como bancos Nicolás Sánchez Gómez Ph. D. Tesis Página 64 / 251 Normalmente, las organizaciones que abren una blockchain privada lo hacen aplicando permisos, al objeto de poner restricciones sobre acceso y uso de la red. El mecanismo de control de acceso puede variar, ya que pueden ser los participantes quienes decidan futuros entrantes o puede ser una autoridad reguladora quien otorgue las licencias para participar. Los permisos de escritura se mantienen centralizados a una organización y los permisos de lectura pueden ser públicos o restringidos. También existe la blockchain federada o de consorcio, éstas intentan eliminar la completa autonomía de una sola entidad sobre una blockchain. En este tipo de redes, básicamente, hay un grupo de organizaciones que se unen para tomar decisiones para toda la red (estos grupos son llamados consorcios o federaciones). Al contrario que en las blockchain públicas, en estas redes no se permite a ninguna persona con acceso a internet participar en el proceso de verificar transacciones y el proceso de consenso es controlado por un grupo de nodos preseleccionados. Otra categorización se puede establecer en función de quien puede leer o escribir en la blockchain, es decir, son redes con permisos (Permissioned) o sin permisos (Permissionless). Por tanto, teniendo en cuenta estas categorizaciones, una blockchain puede ser Publica, con o sin permiso o Privada, con o sin permisos. Para mayor compresión de esta tecnología, en el Anexo de la presente Tesis, se ha incluido información detallada sobre las características de esta tecnología, trabajo realizado para identificar claramente y analizar como esta tecnología gestiona la información de manera segura y trazable, proporcionando transparencia y privacidad a los usuarios. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 65 / 251 II.3.3. Smart contracts Como ya se ha comentado, un smart contract es un programa informático diseñado para ejecutarse automáticamente en una red blockchain. Estos programas amplían la funcionalidad de la red blockchain y permiten a partes no confiables establecer confianza en la ejecución veraz de un acuerdo (Shailak, 2020). En un contexto empresarial, es habitual realizar una integración entre los procesos de negocio y la red blockchain (Viriyasitavat, 2019), siendo los smart contracts la pieza clave para realizar esta integración ya que, desde un punto de vista externo, estos programas informáticos constituyen los puntos de integración con la red blockchain. Ocurre lo mismo cuando la blockchain requieren datos externos, datos que están fuera de la red, siendo los smart contracts ese punto de unión con el mundo exterior, a través del Oráculo (plataforma externa a la blockchain). Aunque Ethereum blockchain fue una de las soluciones pioneras en usar los smart contracts, actualmente el mundo empresarial tiene a su disposición una extensa lista de plataformas que los usan (Nanayakkara, 2021)(Kuo, 2019). En estas plataformas, los smart contracts se invocan utilizando diferentes protocolos, técnicas y formatos de datos, pero la forma de implementarlos parece que es como la de un tipo Class en cualquier lenguaje de programación orientado a objetos (OOPL, siglas de Object-Oriented Programming Language). Esta característica de programación, junto con el factor humano, hacen que el proceso de desarrollo de estos programas sean propensos a errores. En un contexto de multiplataformas y, sobre todo, teniendo en cuenta las peculiares características de la tecnología blockchain, los smart contracts deberían ser diseñados e implementados utilizando las mejores prácticas que permitan reducir el número de errores de codificación y los errores operativos (Huang, 2017). Nicolás Sánchez Gómez Ph. D. Tesis Página 66 / 251 A continuación, al objeto de seguir profundizando en las características de los smart contracts, se analiza su finalidad, su aplicación desde un punto de vista legal, su anatomía y como se estructuran. I.3.3.1. Finalidad Como ya se ha comentado, uno de los pilares fundamentales de la tecnología blockchain es el smart contracts. La primera conceptualización de este término fue publicada por Nick Szabo (Szabo, 1994) que lo definió como un conjunto de cláusulas, datos y protocolos. Estos protocolos implementarían algoritmos para verificar automáticamente el cumplimiento de las condiciones establecidas y serían más “inteligentes”, que los contratos en papel ya que hacen cumplir automáticamente las obligaciones de las partes. La primera plataforma blockchain en implementar los smart contracts fue Ethereum (Buterin, 2014), creando un lenguaje de programación para dichos contratos llamado Solidity, el cual es Turing completo (Ethereum, 2022). Por tanto, un smart contract es un script escrito en algún lenguaje “maquina”, que permite a un dispositivo ejecutar de forma automatizada las instrucciones previamente programadas, prescindiendo de cualquier tipo de intervención humana. Las instrucciones que contiene ese script no son más que sentencias y comandos en el código que lo forma. Se podría decir que, cada una de las cláusulas que contiene ese script, se ha redactado siguiendo el paradigma "if X then Y, else Z". Luego la máquina que ejecute ese código, lo hará inexorablemente en la forma programada. Con esta ejecución, las partes asegurarían que ciertas acciones o eventos ocurran en el marco de ese conjunto de cláusulas y condiciones. De forma resumida, el objetivo general de un smart contract sería satisfacer o validar las condiciones acordadas, sin necesidad de intermediarios y Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 67 / 251 almacenar el resultado de dicha ejecución en la blockchain. De forma resumida, la siguiente ilustración auto-explicativa muestra el uso de los smart contracts. Figura 11. Ejemplo de uso de los smart contracts Con estas mimbres, cualquier bien (dinero, propiedades, etc.) podría ser compartido entre partes de manera transparente sin la necesidad de un tercero de confianza, eliminando los posibles conflictos de intereses. Obviamente, el hecho de eliminar la autoridad central o un tercero de confianza en un proceso de negocio y delegar esa tarea en un smart contract hace que su diseño y programación deba ser rigurosa, ya que no debe contener errores de ningún tipo que puedan provocar situaciones no previstas, ni deseables. Por último, aunque ya se ha mencionado, es importante recalcar que los smart contracts pueden codificar la ejecución automatizada de acuerdos, tal y como ya se ha expuesto, pero no todos los smart contracts tiene que ser acuerdos y no siempre codifican necesariamente acciones entre más de una parte. Nicolás Sánchez Gómez Ph. D. Tesis Página 68 / 251 II.3.3.2. Ámbito legal La cuestión de si los smart contracts son legalmente vinculantes puede variar según la jurisdicción y la interpretación legal específica de cada país. En general, los smart contracts se consideran como una forma de contrato que utiliza la tecnología blockchain y la ejecución automatizada para hacer cumplir los términos y condiciones establecidos en dicho acuerdo. En concreto, la legalidad de éstos depende de varios factores, entre ellos (Legerén-Molina, 2018): • Jurisdicción: Cada país puede tener leyes y regulaciones diferentes con respecto a la validez y el reconocimiento de los contratos, incluidos los smart contracts. Algunos países pueden tener leyes específicas relacionadas con los contratos electrónicos y la tecnología blockchain. • Intención y consentimiento: Como en cualquier contrato, la legalidad de un smart contract depende de que todas las partes involucradas tengan la intención de cumplir con sus términos y hayan otorgado su consentimiento de manera voluntaria y consciente. • Ejecución y cumplimiento: Si un smart contract se implementa correctamente y las condiciones se cumplen según lo previsto, puede considerarse legalmente vinculante. • Efectos legales: Los smart contracts deben ser capaces de producir efectos legales en un sistema legal determinado para ser reconocidos como vinculantes. Esto implica que las acciones o transacciones realizadas a través del smart contract deben tener relevancia legal en el contexto en el que se utilizan. En algunas jurisdicciones, los smart contracts ya han sido reconocidos como legalmente vinculantes y válidos para ciertos tipos de transacciones. Sin embargo, en otros lugares, todavía se están estudiando y desarrollando Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 69 / 251 marcos legales para abordar adecuadamente los aspectos legales de esta tecnología emergente. No obstante, una de las cuestiones principales que se debaten en el ámbito legal es si estos programas informáticos podrán algún día llegar a ser considerados, o no, como un sustituto de los contratos legales. Esto se refiere tanto a su legitimidad como a los requisitos para formalizar un contrato legal (Werbach, 2017) (Legerén-Molina, 2018). En este sentido, existen algunas iniciativas muy interesantes como es el contrato Ricardiano (Grigg, 2004). Este es un método para registrar un documento como un contrato en derecho y, vincularlo de forma segura a otros sistemas. En concreto, este autor introduce el concepto de contrato Ricardiano en un primer sistema de pago electrónico, donde un documento contractual se podía firmar electrónicamente y se intercambiaba digitalmente de forma encriptada. Por tanto, un este tipo de contrato no es más que un archivo de texto que está firmado criptográficamente por un emisor legal y que expresa algún valor para sus titulares (Grigg, 2004). Si se analiza en detalle la estructura de un contrato legal, éste contiene aspectos operativos que pueden ser automatizados mediante software. Por ejemplo, los pagos periódicos de un préstamo hipotecario podrían ser susceptibles de ello, pero también existen otros aspectos de “naturaleza interpretativa”. Figura 12. Componentes básicos del Contracto Triple Ricardiano Nicolás Sánchez Gómez Ph. D. Tesis Página 70 / 251 Grigg, siendo consciente de este problema, perfeccionó el Contrato Ricardiano dando lugar al Contrato Triple Ricardiano (véase Figura 12), indicando tres componentes básicos: • Prosa legal. Los contratos legales, algunas de sus cláusulas, no contienen descripciones de comportamiento procesables por una máquina, ya que estos aspectos “no operativos” son intangibles, ambiguos o de naturaleza interpretativa y se enmarcaría en la prosa legal o jurídica. • Código. Este componente, escrito en un lenguaje de programación ejecutable por máquinas, permite a los sistemas de software automatizar ciertas partes del contrato legal subyacente, es decir, este componente recoge los aspectos “operativos” de los contratos legales. • Parámetros. Representan los resultados de la negociación a nivel de un acuerdo concreto y vinculante entre partes. El código y los componentes de la prosa legal los considera como “plantillas”, que se concretan para un fin determinado y es donde se fijan los valores concretos de estos parámetros, por ejemplo, el plazo para pagar una deuda o la subida anual de un arrendamiento. Teniendo en cuenta el Contrato Triple Ricardiano y la división propuesta: datos (Parámetros); aspectos operativos (Código) y no operativos (Prosa), la estructura de un smart contract debería guardar cierta similitud con las asociaciones mostradas en la Figura 13. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 71 / 251 Figura 13. Asociaciones de un Contrato Triple Ricardiano Esta estructuración del Contrato Triple Ricardiano es como una tupla que puede tener o no un conjunto de relaciones jurídicas entre partes (Prosa legal) y donde Datos e Interesados (Conjunto de datos) son parte del componente Parámetros - pudiendo no existir partes interesadas, ni datos – y Acciones (especificaciones funcionales) y Restricciones (especificaciones de comportamiento) son partes del componente Código. No obstante, aunque todo el tema legal o jurídico es una temática bastante interesante, todo este debate queda fuera del alcance de la presente Tesis Doctoral, es decir, en ningún momento se ha evaluado o evalúa cualquier conflicto filosófico relativo a la ubicación exacta de los smart contracts dentro del ámbito legal. A día de hoy, los expertos jurídicos todavía difieren - desde un punto de vista conceptual - sobre si los smart contracts realmente se ajustan a la definición de contrato legal, aludiendo también a si éstos se ajustan adecuadamente al ciclo de vida del contrato y si cumplen los pasos legalmente requeridos para celebrar un acuerdo vinculante (Werbach, 2017) (Legerén-Molina, 2018). Nicolás Sánchez Gómez Ph. D. Tesis Página 72 / 251 Luego, centrándonos en la Figura 13 y dejando al margen los aspectos legales, un smart contract debería permitir un acuerdo entre partes, que serían los interesados 8 y, existe una automatización del smart contract, gracias a las acciones y restricciones establecidas, ya que éstas se aplican automáticamente, de forma autónoma, mediante la ejecución del Código. En concreto: • Las acciones se componen de actividades u operaciones a realizar, y es atómica desde el punto de vista de su aplicación. Además, las acciones pueden recibir datos y también puede leer y escribir datos. Estas acciones pueden contener pasos y el hecho de que una acción se pueda realizar, o no, puede estar sujeto a restricciones de comportamiento. • Las restricciones modelan los términos y condiciones del acuerdo, es decir, imponen restricciones en cuanto a cuándo se puede realizar una acción, si las circunstancias permiten o no ejecutar la acción, etc. Por tanto, en un smart contract, una restricción vincula la ejecución de una acción al cumplimiento de las condiciones y reglas. Una restricción puede leer datos y podría afectar a una o más acciones. II.3.3.3. Anatomía Un smart contract es una colección de código (sus funciones) y datos (su estado) que residen, una vez desplegado, en una dirección específica en la red blockchain (Ethereum, 2022). 8 Estos, también conocidos como firmantes, pueden ser una persona, una organización o cualquier otra entidad capaz de celebrar un acuerdo legal. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 73 / 251 En concreto, los componentes básicos de un smart contract son las propiedades y la lógica y, el libro mayor (ledger) donde reside el smart contract una vez desplegado y los datos. Cada uno de estos componentes puede ser mapeado directamente en conceptos técnicos, donde las propiedades representan un esquema de datos y la lógica representa el código y, la base de datos sería el libro mayor. Figura 14. Anatomía de smart contract en la blockchain Como muestra la Figura 14, los smart contracts se ejecutan al recibir una transacción (entrada de datos y eventos) y, durante su ejecución, pueden enviar mensajes (salida de datos y eventos) a otros contratos o sistemas externos (Ethereum, 2022). Estos mensajes contienen la dirección del remitente y la del destinatario, así como los parámetros de entrada del smart contract del destinatario y los datos a transferir al destinatario, si procede. Nicolás Sánchez Gómez Ph. D. Tesis Página 80 / 251 • Constructores. Utilizados para inicializar el smart contract, lo que permite que los datos pasados al instanciar el smart contract, puedan ser inicializados y almacenados como variables de estado. A diferencia de otros OOPL, Solidity (Ethereum) solo puede especificar un constructor. • Funciones. Son las operaciones que un contrato puede realizar y, por lo tanto, constituyen su funcionalidad. La representación UML del tipo Class, del smart contract “Sample” de la Figura 16, sería la siguiente (ver Figura 17): Figura 17. Tipo Class “Sample” II.5. Identificación de la problemática existente La blockchain es una tecnología inmutable, transparente y segura para registrar el estado y la propiedad de un activo (Sultan, 2018). Este activo puede ser algo tangible y diverso como dispositivos IoT, una obra de arte, etc. e incluso podría ser algo intangible como, por ejemplo, la propiedad intelectual, los derechos de autor, etc. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 81 / 251 Solo hay que hacer una búsqueda por internet para ver que ya existen numerosas plataformas blockchain que usan smart contracts (Ethereum, Hyperledger, Stellar o EOS, entre otros) (Zheng Z., 2020). Estas plataformas permiten construir y ejecutar estos programas informáticos sin seguir las buenas prácticas de la ingeniería software y, lo más preocupante, sin pasar por rigurosos procesos de prueba. Esto significa que el software desplegado en estas redes puede estar ejecutando código con errores, bugs y vulnerabilidades. Viendo esta problemática, ya han aparecido empresas auditoras de smart contracts. Por ejemplo, OpenZepelin (www.openzeppelin.com) cuya oferta de servicios plantea desde la auditoría del código hasta la construcción de smart contracts. Otras empresas especializadas en este tipo de servicios son ConsenSys (consensys.net), Quantstamp (quantstamp.com) o Certik (www.certik.com) que ofrecen servicios de detección de vulnerabilidades o violaciones de seguridad en el código de los smart contract. Dada la característica intrínseca de inmutabilidad de la blockchain, es fundamental que antes de desplegar código en una red blockchain empresarial, este software pase por rigurosos procesos de evaluación y validación. Un error o defecto en el código de un smart contract puede tener consecuencias graves y potencialmente irreparables en una red blockchain. Algunos escenarios que pueden surgir si un smart contract tuviera un error o defecto: • Pérdida de fondos. Si un smart contract tiene un error de programación que permite que los fondos almacenados en él sean manipulados o robados, esos fondos podrían perderse permanentemente. Una vez que se ejecuta el smart contract en la blockchain, sus operaciones son inmutables y no se podría volver atrás. Nicolás Sánchez Gómez Ph. D. Tesis Página 82 / 251 • Paralización de contratos. Un defecto en un smart contract podría provocar un fallo en su funcionamiento, lo que puede llevar a que el contrato quede inaccesible o bloqueado. Si el contrato afectado es esencial para el funcionamiento de otras aplicaciones o contratos, podría generar problemas en cadena. • Comportamientos inesperados. Los errores en el código pueden hacer que el smart contract se comporte de manera inesperada o impredecible. Esto podría conducir a resultados no deseados o incluso perjudiciales para las partes involucradas en las transacciones. • Congestión de la red. Un smart contract con un defecto puede entrar en un bucle infinito o realizar operaciones costosas en tiempo de computación. Esto puede provocar congestión y afectar el rendimiento general de la red blockchain. Es importante destacar que, debido a la naturaleza inmutable de la blockchain, una vez que un smart contract ha sido desplegado, no se puede cambiar su código. Si se descubre un error después de su despliegue, no se puede simplemente corregir el código existente. La única opción sería crear un nuevo contrato con el código corregido y, en la medida de lo posible, migrar los fondos y la lógica del contrato antiguo al nuevo. Sin embargo, esto dependerá de la complejidad y el impacto del error y puede ser difícil o incluso imposible de realizar en ciertos casos. Para mitigar estos riesgos, es fundamental realizar pruebas exhaustivas, revisiones de código y auditorías de seguridad antes de desplegar un smart contract en la red blockchain. Además, se recomienda seguir las mejores prácticas de desarrollo de smart contract y mantenerse actualizado con las últimas investigaciones y avances en seguridad para minimizar la posibilidad de errores costosos. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 83 / 251 Además, desde nuestro punto de vista, sería una buena práctica que las especificaciones del producto software, así como las especificaciones, condiciones y reglas que deben cumplir los smart contracts fueran una parte integral de un marco de trabajo único. Esto supone que, en el caso de las pruebas funcionales, todos los requisitos del negocio han sido recopilados previamente y éstos serán verificados y validados a través de los casos de prueba, con argumentos válidos y no válidos, con valores límite o realizando combinaciones de argumentos. Probar manualmente todas las extensiones funcionales de cualquier software no solo es difícil, sino también ineficiente. Es más, probar el funcionamiento de una solución no es posible sin la generación automática de pruebas funcionales, debido a las numerosas combinatorias existentes en las condiciones previas del caso de prueba. Por tanto, desde nuestro punto de vista, es más eficiente que este marco de trabajo se sustente en una plataforma y que ésta, además, permita organizar la documentación elaborada por vistas o puntos de vista, al objeto de que ésta sea entendible por todas las partes interesadas. Teniendo en cuenta estas premisas y sin olvidar que se requieren pruebas funcionales y no funcionales para validar y corregir el comportamiento general del software, podemos ya entender la hipótesis planteada en el presente trabajo de Tesis Doctoral (Tabla 2): “La aplicación de los principios y técnicas del testing temprano sobre el ciclo de vida de desarrollo de software, podría ayudar a generar pruebas funcionales de los smart contracts, de forma independiente de la plataforma blockchain, al objeto de garantizar que las transacciones realizadas a través de estos programas informáticos se ejecutan conforme a las especificaciones, condiciones y reglas preestablecidas”. Nicolás Sánchez Gómez Ph. D. Tesis Página 84 / 251 Es importante indicar que el enfoque de las pruebas del software siempre debe estar centrado en la funcionalidad, la seguridad y el rendimiento, pero esta Tesis Doctoral se centrará solo en la funcionalidad. Es decir, se centrará en la posibilidad de aplicar mecanismos sistemáticos para asegurar la calidad funcional de los smart contracts, en un contexto blockchain, desde etapas tempranas del ciclo de vida del desarrollo. Todo lo indicado hasta ahora parece que podría ayudar a reducir el número de defectos de estos scripts (programas informáticos) y, con ello, minimizar el posible impacto de transacciones no reversibles en una red blockchain. Por tanto, como ya se ha comentado, este trabajo pretende dar respuesta a la pregunta de investigación (Tabla 1): ¿Los principios que rigen las pruebas tempranas en el ciclo de vida del desarrollo de software son aplicables, en un contexto blockchain, para garantizar la calidad funcional de los smart contracts?. Es decir, se podrían obtener casos de prueba funcionales en fases tempranas del ciclo de vida de desarrollo de los smart contracts, de forma sistemática y automatizada, que permitan mejorar la verificación y validación del comportamiento definido y esperado de estos programas informáticos, antes de ser desplegados en una red blockchain. Para ello se propone, como se irá viendo a continuación, aplicar técnicas de ingeniería software y técnicas de modelado y transformaciones propias del paradigma MDE, que permitan instanciar casos de prueba funcionales a partir de una especificación desarrollada mediante requisitos funcionales y, sobre todo, a partir de los acuerdos, condiciones y reglas de negocio, establecidos entre las partes. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 85 / 251 II.6. Visión general de la solución propuesta Como se ha venido analizando en la presente Tesis, la aplicación del paradigma de la ingeniería dirigida por modelos ha ofrecido soluciones adecuadas para la generación de pruebas tempranas en otros contextos y, sobre todo, ya ha sido aplicado con éxito en numerosos proyectos de investigación y de transferencia por el grupo ES3. Por tanto, el reto que nos planteamos en la presente Tesis para resolver la problemática existente es abordar una solución encaminada al uso de metamodelos, modelos y a transformaciones entre modelos, aprovechando los trabajos previos ya implementados en la solución SofIA e incluir aquellos mecanismos que sean necesarios para alcanzar nuestros objetivos. En concreto, el punto de partida de nuestra visión general de la solución es el esquema que se muestra en la Figura 18. Este diseño basado en el paradigma de la ingeniería dirigida por modelos (MDE) tiene como objetivo obtener uno de los pilares de la solución global, la modelización (descripción) del smart contract. Figura 18. Enfoque MDE para modelar smart contracts Nicolás Sánchez Gómez Ph. D. Tesis Página 86 / 251 Este enfoque, como se puede apreciar, es intrínsecamente jerárquico donde el código del smart contract podría llegar a ser una instancia de un modelo de smart contract concreto (que resuelve un problema concreto). El modelo del smart contract proporcionaría un plano general de los acuerdos, operaciones, condiciones y reglas que fueron negociados por las partes interesadas. En concreto, este modelo sería una instanciación del metamodelo de smart contract. Este metamodelo es el artefacto encargado de describir e interrelacionar, de forma abstracta, los elementos que estructuran cualquier smart contract, así como las pautas a tener en cuenta sobre su lógica. Con este enfoque, ya se podría plantear una visión más detallada del esbozo de Graphical Abstract (recogido en la Figura 5). En concreto, en la Figura 19 se muestra este detalle, donde se propone definir el modelo de smart contract y los modelos de pruebas funcionales, ambos, a partir de sus metamodelos respectivos que estarán interrelacionados. Figura 19. Graphical Abstract de la Tesis - versión detallada - Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 87 / 251 Como se puede apreciar en la Figura anterior, lo que se propone es generar el modelo de pruebas funcionales desde el modelo de smart contract, usando para ello un motor de transformaciones que instanciará un conjunto de conversiones que se definen. La trazabilidad entre metamodelos, que aparece en la Figura, se refiere a la necesidad de establecer relaciones y conexiones entre los metamodelos, lo que permitirá rastrear y entender cómo los diferentes metamodelos se relacionan entre sí y es útil para: garantizar que los modelos derivados de diferentes metamodelos son consistentes entre sí, evitando conflictos o discrepancias en la información representada; comprender cómo los cambios en un metamodelo afectan a otros modelos que dependen de él, lo que facilita el análisis de impacto de los cambios propuestos y facilita la reutilización de elementos de modelos entre diferentes metamodelos, lo que puede ahorrar tiempo y esfuerzo en el proceso de modelado. La trazabilidad entre metamodelos puede lograrse mediante la definición de relaciones formales entre los elementos de los diferentes metamodelos, estableciendo mapeos y enlaces entre ellos. Estos mapeos pueden ser unidireccionales o bidireccionales, dependiendo de las necesidades y la complejidad de los mismos. Por tanto, en posteriores Capítulos, se estudiará como obtener estos modelos a partir de la instanciación de un metamodelo de smart contract y de un metamodelo de pruebas, respectivamente. Metamodelos que también habrá que definir. En el siguiente Capítulo, antes de seguir avanzando, se presenta el estudio del estado del arte en el contexto del ciclo de vida de desarrollo de los smart contracts, al objeto de analizar si hay estudios primarios que hayan abordado la ingeniería dirigida por modelos u otras buenas prácticas para analizar, diseñar, probar y/o implementar los smart contracts. Nicolás Sánchez Gómez Ph. D. Tesis Página 88 / 251 II.7. Resumen del Capítulo En este Capítulo se ha concretado el ámbito de investigación en la que se desarrolla la presente Tesis Doctoral. En concreto, se ha realizado, por un lado, una introducción del concepto de ingeniería del software, del paradigma de la ingeniería dirigida por modelos y del concepto de reutilización que, según la literatura existente, permite mejorar la calidad del software que se construye y facilita la reutilización de elementos de modelos entre diferentes metamodelos. Por otro lado se ha realizado un análisis pormenorizado de la tecnología blockchain y, sobre todo, de los smart contracts, detallando su finalidad, su anatomía y su estructura. Una vez contextualizada la investigación, se ha identificado el problema existente, el cual es consecuencia de las características intrínsecas de la tecnología blockchain, su inmutabilidad - característica que la tecnología blockchain destaca como un beneficio clave -. Esta característica obliga a que todo software que se despliegue en una red blockchain, deba pasar por rigurosos procesos de evaluación y de validación, ya que un defecto o error en cualquier smart contract desplegado y ejecutado en una red blockchain podría causar un efecto no reparable. Por último, este Capítulo finaliza aportando una visión general de la solución objetivo y los retos a los que nos enfrentamos al objeto de mitigar dicho problema. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 89 / 251 Capítulo III. Trabajos relacionados “If you spend too much time thinking about a thing, you’ll never get it done”. – Bruce Lee – Una revisión sistemática de la literatura nos ha permitido reunir diversos trabajos de investigación donde se estudian algunos de los problemas a los que se enfrenta esta Tesis Doctoral. En concreto, en este Capítulo se analizan diferentes estudios al objeto de explorar posibles lagunas en la literatura existente y, sobre todo, motivar la producción de esta Tesis Doctoral basada en la hipótesis de investigación descrita anteriormente. Como se podrá apreciar posteriormente, los resultados obtenidos y expuestos en este Capítulo muestran que hay margen de acción para aportar nuevos enfoques en esta línea de trabajo. Nicolás Sánchez Gómez Ph. D. Tesis Página 96 / 251 A continuación, se indica la estrategia y criterios que se siguieron: Estrategia de búsqueda Esta estrategia es el procedimiento que se sigue para localizar los estudios primarios más relevantes indexados en diferentes bibliotecas digitales. En nuestro caso, esta estrategia se centró en localizar artículos publicados en revistas de revisión por pares, presentados en congresos relevantes, y se hizo en dos pasos: 1. Se definieron las palabras clave a utilizar en el protocolo de búsqueda. Éstas se fueron concretando después de observar los n resultados obtenidos en búsquedas previas. Estas búsquedas preliminares nos permitieron refinar el conjunto de palabras clave y seleccionar las más adecuadas al objeto de mejorar la calidad de los resultados. En la Tabla 7 se muestran estas palabras clave que finalmente fueron utilizadas, donde cada columna es un conjunto acotado de términos relacionados, utilizados para realizar la búsqueda en el título (Title), en el resumen (Abstract) o en las palabras clave (Keywords) de los artículos. Tabla 7. Palabras clave Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 97 / 251 2. Una vez establecidas las palabras claves, éstas fueron utilizadas de forma sistemática para realizar búsquedas en diferentes bibliotecas digitales. Para este propósito, se utilizaron combinaciones de las palabras claves como indica la siguiente ecuación. (esta fórmula formaliza la expresión booleana de las palabras clave utilizadas en las búsquedas) Respecto a las bibliotecas digitales a utilizar, algunos autores establecen criterios para seleccionar las bibliotecas más adecuadas. Por ejemplo, (Ngai, 2011) propone más de diez bibliotecas digitales como Academic Search Premier, ACM Digital Library, Emerald Full Text o IEEE Xplore Digital, entre otras. Sin embargo, durante el proceso de realización de búsquedas preliminares, se observó que muchos estudios fueron devueltos repetidamente por diferentes bibliotecas digitales, por lo que se decidió utilizar solo las siguientes bases de datos: ACM Digital Library, IEEE Xplore Digital Library, ScienceDirect, Elsevier's Scopus y Springer Link. Las referencias obtenidas se gestionaron utilizando la herramienta JabRef (Feyer, 2017) y hojas de cálculo. Una vez quedaron establecidas las palabras clave y las bibliotecas digitales a emplear, las expresiones de búsqueda se formalizaron utilizando la Equation1 (E1) indicada anteriormente y se ejecutaron en cada biblioteca digital. En concreto, se seleccionaron metadatos de cada artículo como fuentes de información, formalizándose el uso de estos metadatos según la siguiente ecuación: Nicolás Sánchez Gómez Ph. D. Tesis Página 98 / 251 (esta fórmula formaliza la expresión booleana para la búsqueda en los metadatos de un artículo) Dado que cada biblioteca digital tiene su propia sintaxis para indicar expresiones de búsqueda personalizadas y éstas, además, tienen limitaciones como el número máximo de cláusulas lógicas que se pueden emplear, se tuvieron que construir sentencias específicas para cada biblioteca digital empleada. En la Tabla 8 se muestra cada una de las consultas que se tuvieron que utilizar para este cometido. Tabla 8. Consultas de búsqueda por biblioteca digital Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 99 / 251 También fue necesario modificar algunas consultas de búsqueda utilizando determinados filtros, sobre todo, debido al considerable número de resultados obtenidos tras las búsquedas. Estos filtros, normalmente, son proporcionados por cada biblioteca digital. En concreto, se realizaron consultas por áreas científicas, por temas específicos y con año de publicación mayor o igual a 2016, ya que a partir de este año se comenzaron a obtener artículos relevantes, según los criterios de búsqueda predefinidos. Por último, es importante indicar que el protocolo de búsqueda definido fue ampliado utilizando la técnica Snowball (Wohlin, 2013), “bola de nieve” en español. Esta técnica, cuyo objetivo es identificar otros posibles estudios relevantes, nos permitió ampliar el proceso de búsqueda para abarcar tanto las listas de referencias como las citas en cada artículo en estudio. Proceso de selección En este momento es cuando se ejecuta, de forma iterativa, el proceso de selección para obtener los estudios relevantes. Trabajos que, posteriormente, deben ser analizados teniendo en cuenta los objetivos de esta SLR. Nicolás Sánchez Gómez Ph. D. Tesis Página 100 / 251 A continuación, en la Tabla 9, se reflejan las fases seguidas en el proceso de selección de estudios primarios para su análisis. Fase Descripción Investigadores participantes Ph1 Lectura de Título, Abstract y Keywords de Estudios Primarios para identificar el objetivo de la investigación Investigador principal Ph2 Cribado: exclusión de estudios primarios que tratan otros temas Investigador principal Ph3 1ª reunión de consenso Todos Ph4 Análisis de las exclusiones tras leer al texto completo de los estudios primarios e inclusión de estudios tras aplicar la técnica de “bola de nieve”. Todos Ph5 2ª reunión de consenso Todos Tabla 9. Fases seguidas en el proceso de selección de estudios primarios Como se puede apreciar, el proceso de selección que se siguió incluye reuniones presenciales. En concreto, la primera reunión (Ph3) tuvo como objetivo resolver cualquier duda cuando se aplican los criterios de inclusión / exclusión. En estos casos, se hace necesario realizar una revisión completa de los estudios, llamémosle, dudosos. Después de esta lectura, todos los investigadores deciden, de forma conjunta, incluir o excluir finalmente el estudio primario identificado. La segunda reunión presencial (Ph5) se realizó tras aplicar la técnica ''bola de nieve'' indicada anteriormente. Su objetivo es también resolver cualquier duda cuando se evalúen los estudios obtenidos por esta técnica o cuando se apliquen criterios de exclusión/inclusión sobre los mismos. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 101 / 251 Criterios de exclusión/inclusión Los criterios de exclusión/inclusión establecidos fueron acordados de forma objetiva y fueron agrupados en cada fase del proceso de selección seguido, tal y como muestra la Tabla 10. Fase Criterio de inclusión o exclusión Ph1 Se realizó una búsqueda automática en cada biblioteca digital. En esta fase se tiene en cuenta los estudios primarios devueltos por las consultas de búsqueda. Ph2 Sólo estudios primarios en inglés, se obtiene el texto completo y, con año de publicación mayor o igual a 2016 (ya que tras analizar numerosos trabajos de años anteriores, sólo a partir de este año empezamos a identificar artículos que cumplían los criterios de búsqueda definidos). Se excluyen trabajos no relacionados con el tema de investigación. Esta fase de exclusión incluyó la eliminación de trabajos duplicados tras la lectura del título (Title) y el resumen (Abstract) del trabajo. En caso de duda sobre algún documento, éste se incluiría de forma preliminar. La decisión final se consideraría y evaluaría en la siguiente fase. Ph3 No hay nuevos criterios de exclusión al ser la 1ª reunión, pero es posible incluir trabajos relevantes que se hayan identificado. En esta fase, también se analizaron detalladamente todos los artículos "dudosos", teniendo en cuenta todo su contenido. Ph4 En esta fase se aplicó la técnica de "bola de nieve", por lo que fue necesario volver a aplicar los criterios de la fase 2 (Ph2). Ph5 En esta 2ª reunión no se consideran nuevos criterios de exclusión/inclusión, pero todos los investigadores analizaron detalladamente todos los estudios "dudosos", teniendo en cuenta todo su contenido. Tabla 10. Criterio de exclusión/inclusión por fase. Nicolás Sánchez Gómez Ph. D. Tesis Página 102 / 251 Como se puede apreciar en la tabla anterior, se tuvieron en cuenta solo artículos escritos en inglés y publicados en revistas de buena reputación, es decir, revistas indexadas en Journal Citation Reports; JCR) o conferencias prestigiosas (es decir, nivel de conferencia A*, A, B y C categorizado en CORE Conference Rank e incluidas en el ranking GII-GRIN-SCIE). Además, se decidió excluir encuestas, discusiones, revisiones o estudios de opinión relacionados con la temática buscada. Criterios de Calidad Se definieron estos criterios de calidad para obtener los mejores resultados para futuras investigaciones. En concreto, la Tabla 11 muestra los criterios de calidad (QC, siglas de Quality Criteria) aplicados en esta SLR, así como el peso que tendría cada criterio. Id. Preguntas (y puntuación) Peso QC1 En cuanto al SDLC, ¿el estudio presenta de forma clara los objetivos previstos, el alcance de la solución aportada y sus conclusiones?. Posibles respuestas (puntuación): - Sí (+1) - No (+0) 10% QC2 ¿El estudio detalla o contextualiza alguna fase del SDLC? Posibles respuestas (puntuación): - Todas las fases (+2) / Algunas fases (+1) - Ninguna (+0) 10% QC3 ¿El estudio aplica la ingeniería dirigida por modelos? ¿Promueve un inicio temprano de la fase de pruebas? Posibles respuestas (puntuación): - Ambas preguntas (+2) / Una de las preguntas (+1) - Ninguna (+0) 40% QC4 ¿El estudio hace referencia a la generación automática de código utilizando ontologías específicas de dominio, plantillas y/o aplicando la ingeniería dirigida por modelos? 30% Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 103 / 251 Posibles respuestas (puntuación): - Todas las indicadas (+2) / Al menos una (+1) - Ninguna (+0) QC5 ¿El Estudio está validado científicamente? Posibles respuestas (puntuación): - Estudio de caso o experimento (+1) - No validado (+0) 10% Tabla 11. Tabla con criterios de calidad La puntuación acumulada, según peso, para cada criterio constituiría la calificación de calidad (CC) del estudio primario, siendo la calificación máxima un 10. Por ejemplo, si un estudio tiene como puntuación en QC1 un 1 y en QC4 un 1, su calificación sería 2,5. Este valor sale en función del peso indicado, es decir, si la QC1 solo tiene dos posibles respuestas la calificación solo podrá ser 0 o 1 y, si la QC4 tiene 3 posibles respuestas, la calificación de calidad solo podrá un 0, 1,5 o 3. Es importante tener en cuenta que estos QC no se utilizan para excluir artículos, sino que se utilizan para determinar qué artículo es más relevante y representativo para futuras investigaciones. Esquema de datos y validación del protocolo de revisión Dado que el análisis de cada estudio primario podría convertirse en una tarea ardua, debido a la información heterogénea existente y las diferentes estructuras de cada estudio. Se propuso un esquema de caracterización (ver Tabla 12) para homogeneizar este análisis y reducir así la complejidad de esta tarea. Nicolás Sánchez Gómez Ph. D. Tesis Página 104 / 251 Característica Descripción Tipo de publicación Revista (journal) o conferencia en la que se publica el estudio primario Área de negocio Área donde se aplicó el enfoque del estudio primario Descripción y motivación Esta característica representa una breve descripción de cada estudio primario y su motivación Fase del ciclo de vida Se refiere a la fase del SDLC en la que se centra la propuesta del estudio primario Tabla 12. Esquema de caracterización Y, por último, siguiendo las recomendaciones dadas en el método de Kitchenham, el protocolo SLR fue revisado para obtener un proceso de revisión integral. En concreto, se aplicaron algunas búsquedas aleatorias para refinar las palabras clave definitivas y los criterios de exclusión/inclusión, entre otros aspectos. Sin embargo, finalmente decidimos buscar el asesoramiento de expertos en la realización de SLR para definir un proceso sistemático, completo e integral. En este sentido, participó como externo un Catedrático de Ingeniería del Software de la Universidad de Sevilla (España) experto para validar nuestro protocolo de revisión. III.2. Ejecución del protocolo de revisión (conducting) El objetivo de esta fase del proceso es presentar los estudios primarios obtenidos después de ejecutar el protocolo de revisión definido. También se detalla la puntuación de calidad de cada trabajo de investigación analizado, teniendo en cuenta los criterios de calidad indicados anteriormente. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 105 / 251 III.2.1. Identificación, selección y análisis de estudios primarios La Tabla 13 muestra la distribución de estudios primarios obtenidos tras aplicar los criterios de inclusión/exclusión establecidos en cada fase del protocolo de selección. Tabla 13. Distribución de estudios primarios Como se puede observar en la Tabla anterior, para cada biblioteca digital, se muestra el número de artículos obtenidos en cada fase del protocolo de revisión, por ejemplo, en la fase 3 (Ph3) quedaron 22 estudios a tener en cuenta. Además, esta tabla muestra los estudios obtenidos después de aplicar la técnica de ''bola de nieve'' (3 estudios). Para agilizar el manejo de los resultados, estos últimos artículos no fueron clasificados por biblioteca digital. Los estudios primarios obtenidos durante el protocolo de búsqueda, en comparación con los estudios finalmente seleccionados quedaron recogidos de forma ilustrativa en la Figura 20. Nicolás Sánchez Gómez Ph. D. Tesis Página 112 / 251 Como muestra la Tabla 15, las fases más abordadas por los autores fueron: (A1) Requisitos, análisis o diseño (68%), (A2) Codificación (40%), (A3) Pruebas (28%) y (A4) Otras fases (12%). Analizando los resultados obtenidos, tenemos que un 12% de los estudios primarios no están referenciados a ninguna fase concreta (son muy generalista), pero hay otros trabajos como el de Marchesi et at (PS01) y el de Tsai et al. (PS05) que destacan sobre el resto. En concreto, el estudio PS01 propone un proceso de desarrollo de software para especificar los requisitos, analizar, diseñar, desarrollar, probar e implementar aplicaciones blockchain y el estudio PS05 propone un marco de trabajo con cinco etapas: desarrollo de plantillas de smart contracts, a partir del análisis de dominios, modelo formal de smart contracts, desarrollo de código a partir de plantillas, verificación y validación. Parece, por tanto, que algunos esfuerzos de la comunidad científica van encaminados actualmente a implementar algún tipo de ciclo de vida de desarrollo. No obstante, en el contexto de la blockchain, los procesos analizados consisten solo en un número determinado de fases no vinculadas, al no estar dispuestas en un orden claro de precedencia y las entradas/salidas de cada etapa tampoco están claramente definidas. Es importante destacar, por el peso que debe tener en la tecnología blockchain, el hecho de que la fase con menor impacto en la literatura identificada es la de pruebas de software. Como ya se ha comentado, desde nuestro punto de vista, las aplicaciones en un contexto blockchain difieren bastante de otras aplicaciones tradicionales, ya que una vez que se implementa un smart contract, su ejecución no se puede revertir. Por ello, es fundamental realizar pruebas robustas, poniendo énfasis en la elicitación de requisitos, en su verificación y validación y en la depuración de código tras la ejecución de las pruebas. Es más, las pruebas deberían implicar la simulación de todas las posibles variables esperadas e inesperadas para cada smart contract y para los desencadenantes que ejecutan las transacciones. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 113 / 251 RQ2. ¿Promueven la ingeniería de software basada en modelos, el inicio temprano de la fase de prueba o la generación automática de smart contracts?. Desde hace unos años, como ya se ha comentado, el uso de herramientas de modelado o herramientas CASE, así como el uso del estándar UML han ayudado a documentar la funcionalidad de los procesos empresariales y a utilizar transformaciones entre modelos para automatizar, incluso, la generación de código. Por ejemplo, entre los estudios primarios seleccionados, Marchesi et al. (PS01) y Syahputra et al. (PS19) destacan este aspecto al proponer la utilización de diagramas UML para describir los requisitos de las aplicaciones. En este contexto, la aparición del lenguaje de modelado para la especificación de casos de prueba (U2TP) que cerró la brecha entre diseñadores y probadores al proporcionar una buena razón para usar UML, ha permitido que los diagramas UML de requisitos y análisis se puedan reutilizar para las pruebas (Gutiérrez, 2008) (Gutiérrez, 2015) y, lo que es más importante, permiten que se puedan comenzar las pruebas en una fase temprana del desarrollo del sistema. Además, como ya se ha indicado anteriormente, realizar una ingeniería del software basada en modelos es importante, ya que aporta las siguientes ventajas (Ramos, 2011) (Pohl, 2012): • Se pueden implementar las mejores prácticas y generar códigos bien probados, lo que reduce la aparición de código vulnerable. Las herramientas basadas en modelos pueden mejorar la verificación / validación del código mediante la aplicación de técnicas de prueba desde las primeras etapas del ciclo de vida de desarrollo. Nicolás Sánchez Gómez Ph. D. Tesis Página 114 / 251 • El código de software es más difícil de entender que los modelos. Por lo tanto, es más fácil comprobar la exactitud de un modelo. El código del software también se puede generar automáticamente a partir de herramientas basadas en modelos, lo que garantiza que el código generado no se haya modificado después de obtenerlo. • La ingeniería basada en modelos se puede aplicar en múltiples plataformas. En este sentido, la Tabla 16 muestra la distribución de los estudios primarios (PS, siglas de Primary Studies) en relación con las propuestas de los diferentes autores. Tabla 16. Distribución de los estudios primarios según el alcance de la propuesta Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 115 / 251 Las propuestas abordadas por los autores, como se muestra en la Tabla 16, están relacionadas con: (B1) Aplicación de la ingeniería del software basada en modelos (48%), (B2) Promover el testing temprano (5%), y (B3) Propuesta de generación automática de código (48%). Viendo los resultados obtenidos, aunque como se ha indicado el testing temprano ayuda a reducir el número de errores y asegurar la calidad del software, parece que los esfuerzos de la comunidad científica no están dirigidos hacía este enfoque. La realidad es que muchos proyectos siguen realizando las pruebas al final del ciclo de vida de desarrollo, es decir, después de la fase de codificación. Esto implica que muchas veces no tienen suficiente tiempo para detallar, ni hacer pruebas rigurosas y de forma adecuada, dando lugar a posibles reajustes que podrían afectar a la calidad del software (Jain, 2016). Las pruebas tempranas, desde nuestro punto de vista, proporcionaría tiempo suficiente para identificar la ausencia o inadecuación de cualquier requisito funcional. Además, los casos de prueba obtenidos a partir de las especificaciones de estos requisitos funcionales podrían ayudar a identificar o revelar posibles fallos (Jain, 2016). Está claro que para realizar las pruebas funcionales del software, éste debe estar construido, luego evidentemente que las pruebas funcionales, como tal, hay que realizarlas después de su codificación. Otro asunto diferente, desde nuestro punto de vista, es que desde las etapas iniciales del ciclo de vida del desarrollo, estas pruebas deben ser tenidas en cuenta, e incluso es deseable obtener los casos de prueba de forma más o menos automática al objeto de tener una amplia cobertura funcional. El testing temprano o el early testing va en esta línea. Nicolás Sánchez Gómez Ph. D. Tesis Página 116 / 251 Por suerte, algunos autores como Koul et al. (PS06) destacan la necesidad de asegurar la calidad del software desde etapas tempranas, indicando los desafíos a los que se enfrentan actualmente las pruebas de este tipo de aplicaciones. Estos autores, además, reconocen la necesidad de diseñar herramientas y técnicas específicas para las pruebas de este tipo software, al objeto de garantizar altos estándares de calidad. Está claro que el papel de las pruebas no es solo verificar la "corrección" del software, sino más bien descubrir defectos a tiempo y poder rectificarlo lo antes posible. Realizar pruebas exhaustivas, que cubren el 100% de la funcionalidad de un software no es factible en ningún caso, pero es importante eliminar el mayor número de errores o defectos, lo antes posible. Luego, si se aplicaran las técnicas de testing temprano, los programas informáticos y, por ende, los smart contracts, podrían implementarse con mayor fiabilidad y menores costes de desarrollo. Respecto a la generación automática de smart contracts, un aspecto importante a considerar es la técnica que los autores proponen emplear. En la Tabla 17 se muestra la distribución de estudios primarios (PS, siglas de Primary Studies) con respecto a las diferentes técnicas propuestas. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 117 / 251 Tabla 17. Distribución de los estudios primarios según las técnicas de generación de código (smart contract) propuestas La generación automática del código del smart contract utilizando un proceso de ingeniería del software basado en modelos, eliminaría el esfuerzo manual requerido en la codificación desde el diseño y, por lo tanto, aceleraría el proceso, al tiempo que disminuye la posibilidad de errores en comparación con la codificación manual de los requisitos o modelos. No obstante, como muestra la tabla anterior, las técnicas más usadas o propuestas por los autores son: (C1) Generación utilizando ontologías y/o reglas semánticas específicas del dominio (4%), (C2) Generación utilizando ingeniería basada en modelos (4%) y (C3) Generación a través de plantillas u otras utilidades (28%). Nicolás Sánchez Gómez Ph. D. Tesis Página 118 / 251 La ingeniería de software basada en modelos ha ido ganando terreno en el desarrollo de software, especialmente en dominios críticos (Bialy, 2017). Es más, la generación automática de código a partir de dicha ingeniería es un paso importante, ya que ofrece la posibilidad de implementar, verificar y validar el software a partir de los requisitos. En este sentido, resulta interesante el estudio de Syahputra et al. (PS19) que proponen el uso de una plataforma de smart contracts que permita generar smart contracts para tecnologías blockchain heterogéneas, haciendo uso de UML y OCL (Object Constraint Language). Está claro que una buena práctica es establecer un ciclo de vida de desarrollo que aproveche las tecnologías de generación de código, pero éste debe adherirse bien a los principios de la ingeniería del software, buscando la reducción de la complejidad y la trazabilidad de los requisitos. RQ3. ¿Qué métodos de validación científica o empírica se utilizaron en las diferentes propuestas? Después de analizar los estudios primarios seleccionados, solo el 12% de los artículos (3 de 25 estudios) utilizaron una validación científica, tal y como se muestra en la Tabla 18. El mayor porcentaje, un 44% (11 de 25 estudios) de los estudios primarios, realizaron su evaluación mediante estudios de casos experimentales o pruebas de concepto y con éste mismo porcentaje, hay estudios que ni siquiera cuentan con un plan de validación, lo que dificulta enormemente la verificación de sus afirmaciones. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 119 / 251 Tabla 18. Distribución de estudios primarios según el modelo de validación científica utilizado III.4. Conclusiones tras finalizar este trabajo Los resultados obtenidos en la SLR realizada (Sánchez-Gómez, 2020b) nos ha permitido identificar y, sobre todo, analizar el estado del arte de las publicaciones científicas relacionadas con la temática de la presente Tesis. En dicha SLR se siguió el método más reciente de Kitchenham (Kitchenham, 2013) y, tras realizar el protocolo planteado y los criterios establecidos, se identificó un total de 25 estudios primarios que tenían en cuenta algún aspecto del ciclo de vida de desarrollo de los smart contracts. Desde nuestro punto de vista, la elicitación de requisitos y las pruebas de software se encuentran entre los aspectos más importantes del ciclo de vida de desarrollo. Pero estos estudios primarios, casi siempre, han pasado de puntillas por estas fases. No obstante, destaca Marchesi et al. (PS01), que proponen un proceso de desarrollo de software teniendo en cuenta las típicas fases del ciclo de vida del mismo, pero se focalizan en la aplicación de metodologías Agiles. En su estudio proponen el uso de diagramas UML para describir el diseño de las aplicaciones e, incluso, proporcionan un modelado de las interacciones entre el software tradicional y el entorno blockchain. Otros autores como Syahputra et al. (PS05) discuten sobre el proceso de desarrollo a partir de una plataforma de smart contract. Esta plataforma tiene Nicolás Sánchez Gómez Ph. D. Tesis Página 120 / 251 como objetivo crear un smart contract para tecnologías blockchain heterogéneas y proponen el uso de UML, además de OCL, para el diseño. Todos los estudios primarios, de alguna manera u otra, indican la necesidad de obtener un software que funciona correctamente. Pero, en el caso de los smart contracts, creemos que se debe hacer mayor hincapié en las pruebas funcionales, de seguridad y de rendimiento. Como se ha repetido anteriormente, dada la característica de inmutabilidad de la red blockchain, es esencial que antes de desplegar estos scripts en un entorno empresarial, los smart contracts pasen rigurosos procesos de verificación y validación, ya que un error o defecto en él podría causar un efecto no reparable. Por tanto, las pruebas son esenciales para validar y corregir el comportamiento de un smart contract antes de su publicación. Si nos centramos en las pruebas funcionales, objeto de la presente Tesis, probar de manera eficiente un smart contract antes de implementarlo, asegurará que este funcione como se espera, es decir, según las especificaciones funcionales establecidas. En las pruebas funcionales, todas las reglas o requisitos empresariales, incluidos los argumentos válidos y no válidos, los valores de límite y las combinaciones de argumentos, deben verificarse con casos de prueba. En este sentido, algunos autores como Koul et al. (PS06) destacan la necesidad de asegurar la calidad del software desde etapas tempranas. Por tanto, este estudio coincide parcialmente con nuestro planteamiento de obtener casos de prueba en fases tempranas del ciclo de vida de desarrollo de smart contracts. Además, estos autores reconocen la necesidad de diseñar herramientas y técnicas específicas para las pruebas de este tipo de software, al objeto de garantizar altos estándares de calidad. Después de dar por finalizada la SLR, se vio de forma clara la necesidad de explorar una nueva línea de investigación, potencialmente muy interesante, como es la aplicación del paradigma de la ingeniería dirigida por modelos ya que, como se ha expuesto en Capítulos anteriores, parece que este paradigma puede facilitar los mecanismos necesarios para verificar y validar Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 121 / 251 los smart contracts, ya que allana el camino para aplicar técnicas de prueba tempranas antes de que los smart contracts se implementen y desplieguen en la red blockchain. El uso de este enfoque ha dado resultados muy satisfactorios en otras tecnologías, luego su utilización en este contexto parece muy prometedora. Este estudio concluyó indicando que los modelos tradicionales de desarrollo no son los más adecuados dadas las necesidades identificadas para el desarrollo de smart contracts. Es más, después de terminar la SLR, han seguido apareciendo nuevos estudios relevantes, como los indicados a continuación. Nuevos estudios relevantes • Vandenbogaerde et al. (Vandenbogaerde, 2019) proponen un marco de trabajo basado en gráficos para calcular las métricas de diseño de software para el lenguaje Solidity (Ethereum). Concluyen indicando que la mayoría de los smart contract analizados son bastante sencillos desde el punto de vista de la orientación a objetos y que se deben desarrollar nuevas métricas de diseño específicas para los smart contracts. • Ladleif et al. (Ladleif, 2019) pretenden allanar el camino hacia un enfoque basado en modelos para el desarrollo de smart contracts legales. Para ello, combinan los conocimientos de la literatura sobre derecho e informática jurídica con las capacidades de los enfoques de modelado existentes y ofrecen un modelo que encapsula los componentes esenciales de los smart contracts legales. Los autores indican que ese modelo podría utilizarse como referencia para los diseñadores de lenguajes que pretendan una representación holística de los smart contracts legales en una arquitectura basada en modelos. Además, puede servir de base para comparar los marcos de modelado Nicolás Sánchez Gómez Ph. D. Tesis Página 128 / 251 Para ello, por un lado, habría que definir los metamodelos que permitan describir los conceptos y las relaciones que entre ellos se producen y, por otro, diseñar las transformaciones necesarias entre modelos para poner en pie todo el proceso, teniendo en cuenta que estas transformaciones se sustentan en las relaciones que se establecen entre los conceptos del metamodelo. En la Tabla 19, se indica a modo de resumen, tanto los metamodelos previstos, como las transformaciones necesarias en el Capítulo: Metamodelos - Metamodelo de smart contract. - Metamodelo de pruebas funcionales de smart contract. Transformaciones - Transformación (T1) para obtener modelo de escenarios de Caso de Uso. - Transformación (T2) para obtener modelo de Casos de Prueba. Tabla 19. Metamodelos y transformaciones de la solución. Partiendo de estos metamodelos y transformaciones, podemos definir un procedimiento sistemático de generación de las pruebas funcionales a partir de los smart contracts. En la Figura 22, se muestra el procedimiento propuesto. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 129 / 251 Figura 22. Proceso de generación de pruebas funcionales Gracias al metamodelo de smart contract se podrá precisar la información necesaria para definir un modelo concreto de smart contract a partir de la sintaxis concreta de los requisitos funcionales y de los acuerdos, condiciones y reglas. El metamodelo va a marcar las reglas para que podamos instanciar un modelo acorde a todas las restricciones que en dicho metamodelo se han definido. La transformación T1 nos va a permitir obtener un modelo de escenarios de Casos de uso. Este modelo debe ser acorde al metamodelo de pruebas funcionales. Enriqueciendo y combinado el modelo de escenarios de Caso de Uso con los datos de prueba, se podrá obtener el modelo de Casos de Prueba mediante la transformación T2. Por ser más detallados, respecto a las transformaciones indicadas en la Tabla 19, habría que indicar que: Nicolás Sánchez Gómez Ph. D. Tesis Página 130 / 251 • La Transformación T1 es la transformación de un modelo de smart contract a un modelo de escenarios de Caso de Uso (transformación M2M). El modelo de smart contract proporciona una descripción general de lo que éste debe hacer, mientras que el modelo de escenario de Caso de Uso se centra en cómo se llevarán a cabo las interacciones entre los usuarios y el sistema para cumplir con esos requisitos. El objetivo de esta transformación es generar dicho modelo de escenarios conforme al metamodelo de pruebas funcionales de un smart contract, partiendo para ello del modelo de smart contract (modelo que se obtuvo conforme al metamodelo de smart contract). • La Transformación T2 es la transformación a un modelo de Casos de Prueba (transformación M2M) a partir de un modelo de escenario de Casos de Uso. Esto implica convertir las interacciones de los usuarios y el sistema, descritas en los escenarios, en pasos detallados y específicos que puedan ser ejecutados y validados para verificar que el software funciona correctamente. Teniendo en cuenta los datos de prueba, el objetivo de esta transformación es generar el modelo de Casos de Prueba conforme al metamodelo de pruebas funcionales, quedando descrita cada acción que el actor realiza y cómo el sistema debe responder a esa acción. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 131 / 251 Todas estas pautas, partiendo del Graphical Abstract de la Tesis, quedarían ilustradas de la siguiente forma. Figura 23. Pautas seguidas para la generación de pruebas funcionales A continuación, en línea con todo lo expuesto, se define nuestra propuesta de metamodelo de smart contract y, posteriormente, la del metamodelo de pruebas funcionales. IV.1. Metamodelo de smart contract A continuación se define este metamodelo poniendo el foco, sobre todo, en los términos y las condiciones operativas - partes del contrato que se puede automatizar – del smart contract, dejando al margen todo lo relativo a los aspectos legales o jurídicos que, como ya ha indicado, quedan fuera del ámbito de esta Tesis Doctoral. Nicolás Sánchez Gómez Ph. D. Tesis Página 132 / 251 IV.1.1. Metamodelo de smart contract En la Figura 24 se muestra el metamodelo de smart contract propuesto y, como se puede apreciar, este modelo se ha definido siguiendo la propuesta MOF (Meta-Object Facility) y se ha representado mediante un diagrama UML de clases, siguiendo las directrices del OMG. Figura 24. Propuesta de metamodelo de smart contract Teniendo en cuenta los componentes del Contrato Triple Ricardiano (ver Figura 13), la anatomía y estructura de los smart contract, la información relativa a Interesados y Datos (Conjunto de Datos) estarían representados por la Metaclass Dato, las Acciones por la Metaclass Funcion y los pasos de estas acciones por la Metaclass Paso y, por último, las Restricciones estarían representadas por la Metaclass Regla. Además, como ya se ha indicado, los constructores, modificadores y eventos son metaclases más específicas de la Metaclass Funcion. Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 133 / 251 Para describir con más detalle nuestra propuesta, se seguirá el mismo esquema que utiliza UML (OMG, 2016), pero las relaciones entre clases, atributos y métodos no se indicarán en esta descripción, ya que son específicas de UML y se pueden obtener del estándar. En concreto, en las siguientes tablas se describirán cada una de estas metaclases que conforman el metamodelo propuesto, utilizando para ello el esquema de definición que el propio UML v2.5.1. utiliza para definir las metaclases de sus propios metamodelos (OMG, 2016). • Metaclass SmartContract Descripción Representa a la entidad smart contract. Debe tener un nombre único al objeto de poder identificarlo de manera unívoca. Generalización Ninguna Atributos + nombre: String [1] Descripción corta y concisa con la que los usuarios podrán identificar de manera unívoca al smart contract. + descripcion: String [1] Descripción amplia sobre cuál es el cometido del smart contract. Operaciones Ninguna Nicolás Sánchez Gómez Ph. D. Tesis Página 134 / 251 Asociaciones + esValueVariableDe: Dato [0..*] Conjunto de datos (variables) de memoria del smart contract (Value variable). + esStateVariableDe: Dato [0..*] Conjunto de datos (variables) de estado del smart contract (State variable). + compuestoPor: Funcion [0..*] Conjunto de funciones (métodos) que componen el smart contract. + esConstructorDe: Constructor [0..*] Conjunto de constructores que componen el smart contract. + esModificadorDe: Modificador [0..*] Conjunto de modificadores que componen el smart contract. + esEventoDe: Evento [0..*] Conjunto de eventos que componen el smart contract. Restricciones Ninguna Tabla 20. Metaclass SmartContract • Metaclass Dato Descripción Los datos son fundamentales para establecer cuál es la funcionalidad a ejecutar durante la instanciación de un smart contract ya que permiten establecer caminos alternativos en el flujo de datos y la ejecución del proceso y, además, son elementos de construcción para definir las restricciones en el proceso. Éste es el propósito de la Metaclass Dato. Generalización Ninguna Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 135 / 251 Atributos + name: String [1] Descripción corta y concisa con la que identificar de manera unívoca a la variable. + tipoDato: DataType [1] Establece cuál es el tipo de dato. Los posibles valores de este tipo han sido modelados por medio del enumerado DataType, cuya lista de valores (Integer, String, Boolean) puede ser ampliada en cualquier momento. Operaciones Ninguna Asociaciones + compuestoPor: Dato [1..*] Conjunto o estructura en el que datos, de diversos tipos, pueden agruparse en un dato personalizado. Una vez que los tipos de datos se agrupan en una estructura, el nombre de la estructura representa los subconjuntos de variables que contiene. + esValueVariableDe: SmartContract [1] (Asociación de composición) Establece el smart contract en el cual se está definiendo este dato. + esStateVariableDe: SmartContract [1] (Asociación de composición) Establece el smart contract en el cual se está definiendo este dato. + esEntradaDe: Funcion [1] (Asociación de composición) Establece la función (método) que hace uso de este dato. + esSalidaDe: Funcion [1] (Asociación de composición) Establece la función (método) que devuelve este dato. Restricciones Respecto a la asociación «compuestaPor», es necesario definir una restricción en el modelo para controlar que una estructura no se contenga a sí misma, con el propósito de evitar que un usuario pueda definir de manera indeterminada y recursiva una estructura. Tabla 21. Metaclass Dato • Metaclass Funcion Descripción Esta Metaclass es el epicentro del metamodelo y es el elemento alrededor del cual orbitan el resto de los elementos del metamodelo. Representa cualquier acción que pueda contener el smart contract. Nicolás Sánchez Gómez Ph. D. Tesis Página 136 / 251 Generalización Ninguna Atributos + nombre: String [1] Descripción corta y concisa con la que identificar de manera unívoca a la función (o método). + descripcion: String [1] Descripción amplia sobre cuál es la funcionalidad que se cubre en esta función (o método). Operaciones Ninguna Asociaciones + compuestoPor: SmartContract [1] (Asociación de composición) Establece el smart contract en el cual se está definiendo esta función. + esEntradaDe: Dato [0..*] Conjunto de variables de entrada de la función del smart contract. + esSalidadDe: Dato [0..*] Conjunto de variables de salida de la función del smart contract. + compuestoPor: Paso [1..*] Conjunto de pasos (sentencias), ordenados, con la funcionalidad de esta función (método). Restricciones Ninguna Tabla 22. Metaclass Funcion • Metaclass Constructor Descripción Esta Metaclass representa a los constructores que pueda contener el smart contract. Un constructor no deja de ser una función dentro de un smart contract, pero es la encargada de ejecutar cierto código de inicialización cuando se crea una instancia del contrato. Generalización Metaclass Función Atributos Ninguno Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 137 / 251 Operaciones Ninguna Asociaciones + esConstructorDe: SmartContract [1] Establece el smart contract en el cual se está definiendo este constructor. Restricciones Ninguna Tabla 23. Metaclass Constructor • Metaclass Modificador Descripción Esta Metaclass representa a los modificadores que pueda contener el smart contract. Los modificadores son utilizados para modificar el comportamiento de las funciones del smart contract. Generalización Metaclass Funcion Atributos Ninguno Operaciones Ninguna Asociaciones + esModificadorDe: SmartContract [1] Establece el smart contract en el cual se está definiendo este modificador. Restricciones Ninguna Tabla 24. Metaclass Modificador Nicolás Sánchez Gómez Ph. D. Tesis Página 144 / 251 Figura 28. Ejemplo de modelado de decisión mediante DMN Como se puede apreciar en la Figura 28, de una decisión depende el camino a seguir, camino A o camino B, luego cobra bastante importancia la capacidad que nos da DMN para automatizar dicha toma de decisión o de al menos describirla cubriendo todos los casos posibles y de forma exacta. En la Figura 29, se muestra un ejemplo de diagrama de Requisitos de Decisión (nivel 2). Figura 29. Ejemplo de diagrama de Requisitos de Decisión Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 145 / 251 Como se puede apreciar en la Figura 29, las notaciones básicas de este diagrama son: • Conocimiento. Representada por una forma de documento con un nombre y ligada al rectángulo de la decisión con una línea punteada (esta línea puede terminar con un círculo). Las decisiones se derivan o soportan en el conocimiento involucrado en: políticas, regulaciones, mejores prácticas. • Datos. Representada por un ovalo con el nombre del o los datos y va ligado al rectángulo de la decisión con una línea solida con una cabeza de flecha apuntándola. Datos relacionados con las preguntas y respuestas de la decisión y • Decisiones. Representadas por un rectángulo con el nombre de la decisión. Permitiendo preguntas y respuestas validas en el contexto del negocio, la organización y el proceso. Donde la lógica de decisión (nivel 3) requiere de datos de entradas para determinar una salida (decisión), tal y como se muestra en la figura siguiente. Figura 30. Ejemplo de Tabla de Decisión • Un escenario es una instancia de un Caso de Uso, es decir es una descripción de una ruta específica a través del flujo del diagrama de comportamiento. En la Figura 31 se muestran posibles rutas (en amarillo) de un diagrama de Actividad, siendo cada una un escenario de Caso de Uso. Nicolás Sánchez Gómez Ph. D. Tesis Página 146 / 251 Figura 31. Ejemplo de escenarios de Caso de Uso • Un Caso de Prueba representa un conjunto de datos de prueba de entrada que ejecutan un escenario (secuencia de pasos) para obtener unos datos de salida esperados (resultados). En línea con lo expuesto, a continuación se define nuestra propuesta de metamodelo de pruebas funcionales de un smart contract. IV.2.1. Metamodelo de pruebas funcionales de smart contract En la Figura 32, se muestra nuestra propuesta de metamodelo de pruebas funcionales, así como los elementos y relaciones que componen nuestra propuesta. Figura 32. Metamodelo de pruebas funcionales Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 147 / 251 La Figura 32 muestra los elementos que se han definido para normalizar la información que recoge una prueba funcional. El elemento central de este metamodelo es la Metaclass CasoPrueba, la cual está relacionado con un requisito funcional y las especificaciones de comportamiento y está compuesto por pasos de Caso de Prueba. En las siguientes tablas se describe con mayor nivel de detalle los elementos que aparecen en la Figura 32. Para ello, se seguirá haciendo uso de la estructura de OMG para la documentación de UML y especificaciones relacionadas, es decir, se seguirá la misma estructura utilizada durante la definición del metamodelo de smart contract. • Metaclass Escenario Descripción Ésta representa al escenario de Caso de Uso, es decir, es una instancia del Caso de Uso. Generalización Ninguna Atributos + descripcion: String [1] Descripción detallada del escenario que se pretende cubrir. Operaciones Ninguna Asociaciones + compuestoDe: CasoPrueba [1..*] Conjunto de Casos de Prueba que componen el escenario. + esEntradaDe: DatoPrueba [0..*] Conjunto de variables de entrada a tener en cuenta en el escenario. + esSalidaDe: DatoPrueba [0..*] Conjunto de variables de salida a tener en cuenta en el escenario. Restricciones Ninguna Tabla 28. Metaclass Escenario Nicolás Sánchez Gómez Ph. D. Tesis Página 148 / 251 • Metaclass CasoPrueba Descripción Esta es el elemento alrededor del cual orbitan el resto de los elementos del metamodelo. Este Metamodelo representa las funcionalidades a probar (en nuestro caso es una “Funcion”). Generalización Ninguna Atributos + description: String [1] Descripción detallada sobre cuál es la funcionalidad a probar. Operaciones Ninguna Asociaciones + compuestoDe: Escenario [1] (Asociación de composición) Escenario del Caso de Prueba. + esEntradaDe: DatoPrueba [0..*] Conjunto de variables de entrada del Caso de Prueba. + esSalidaDe: DatoPrueba [0..*] Conjunto de variables de salida del Caso de Prueba. + compuestoDe: PasoCasoPrueba [1..*] Conjunto de pasos, ordenados, con la funcionalidad o comportamiento del Caso de Prueba. Restricciones Ninguna Tabla 29. Metaclass CasoPrueba • Metaclass DatoPrueba Descripción El concepto de datos de prueba es fundamental para establecer cuál es la funcionalidad / comportamiento concreto a probar ya que permite establecer caminos alternativos en el flujo de datos y en la ejecución del proceso. Éste es el propósito de la Metaclass DatoPrueba. Generalización Ninguna Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 149 / 251 Atributos + nombre: String [1] Descripción corta y concisa con la que identificar de manera unívoca el dato. + tipoDato: DataType [1] Establece cuál es el tipo de dato. Los posibles valores de este tipo han sido modelados por medio del enumerado DataType, cuya lista de valores (Integer, String, Boolean) puede ser ampliada en cualquier momento. Operaciones Ninguna Asociaciones + esEntradaDe: Escenario [1] Escenario del conjunto de variables de entrada. + esSalidaDe: Escenario [1] Escenario del conjunto de variables de salida. + esEntradaDe: CasoPrueba [1] (Asociación de composición) Caso de Prueba del conjunto de variables de entrada. + esSalidaDe: CasoPrueba [1] (Asociación de composición) Caso de Prueba del conjunto de variables de salida. Restricciones Ninguna Tabla 30. Metaclass DatoPrueba • Metaclass PasoCasoPrueba Descripción La estructura de un Caso de Prueba se construye a través de un conjunto ordenado de pasos de prueba. Éstos son representados mediante la Metaclass PasoCasoPrueba (en nuestro caso son los pasos de la “Funcion”). Generalización Ninguna Atributos + descripcion: String [1] Descripción detallada sobre cuál es la funcionalidad o comportamiento que cubre el paso de Caso de Prueba. Operaciones Ninguna Nicolás Sánchez Gómez Ph. D. Tesis Página 150 / 251 Asociaciones + compuestoDe: CasoPrueba [1] (Asociación de composición) Caso se Prueba del conjunto de reglas, ordenadas, con el comportamiento. + compuestoDe: ReglaCasoPrueba [0..*] Conjunto de reglas con el comportamiento del paso de Caso de Prueba. Restricciones Ninguna Tabla 31. Metaclass PasoCasoPrueba • Metaclass ReglaCasoPrueba Descripción El comportamiento de un paso del Caso de Prueba se puede construir a través de un conjunto ordenado de reglas. Éstas son representadas mediante la Metaclass ReglaCasoPrueba (en nuestro caso son las reglas de un paso de “Funcion”). Generalización Ninguna Atributos + descripcion: String [1] Descripción detallada sobre cuáles son las reglas de comportamiento a tener en cuenta en el paso de Caso de Prueba. Operaciones Ninguna Asociaciones + compuestoDe: PasoCasoPrueba [1] (Asociación de Agregación) Establece el paso en el cual se está definiendo esta Regla. Restricciones Ninguna Tabla 32. Metaclass ReglaCasoPrueba Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 151 / 251 IV.2.2. Perfil UML De igual manera que el metamodelo de smart contract, nuestra propuesta de metamodelo de pruebas funcionales de un smart contract sigue los principios MOF y el estándar UML. Luego, para hacer este metamodelo totalmente compatible con UML, en este apartado se propone el siguiente UML Profile que, como ya se indicó, no es más que un mecanismo de extensión genérico para personalizar el modelo UML propuesto. Figura 33. Perfil UML para el metamodelo de pruebas funcionales Como se puede apreciar en la Figura 33, tenemos: Metaclass Escenario que es un estereotipo de Activity [Class] al igual que la Metaclass PasoCasoPrueba, la Metaclass CasoPrueba son estereotipos de UseCase [Class], la Metaclass DatoPrueba es un estereotipo de Property [Class], y, por último, la Metaclass ReglaCasoPrueba es un estereotipo de Constraint [Class]. Como ya se ha indicado, gracias a estos estereotipos se puede cambiar o complementar la semántica de cualquier elemento. Nicolás Sánchez Gómez Ph. D. Tesis Página 152 / 251 Es importante recalcar, de nuevo, que la simplicidad de este UML Profile no implica que no se haya obtenido una herramienta con un enorme potencial, todo lo contrario, ya que la definición del metamodelo de pruebas funcionales y el UML Profile nos van a permitir definir claramente cualquier concepto involucrado en una prueba funcional de un smart contract y emparejar cada concepto con conceptos similares en UML. Es decir, se podrán utilizar todos los mecanismos de extensión que UML ofrece para obtener una definición formal de una prueba funcional de un smart contract. IV.3. Relaciones entre los metamodelos Como se comentó al inicio del Capítulo, las relaciones que se establecen de manera teórica, entre los conceptos definidos en el metamodelo de smart contracts y el metamodelo de pruebas funcionales, son la base que nos van a permitir definir y generar las transformaciones entre ellos. En la Figura 32, se presentan las relaciones que se producen entre estos conceptos y que usaremos en el siguiente Capítulo para la definición de las transformaciones. Figura 34. Relaciones de trazabilidad entre metamodelos Aplicación de los principios de las pruebas tempranas durante el ciclo de vida de desarrollo de los smart contracts en la tecnología blockchain Página 153 / 251 En la figura, los conceptos relativos al metamodelo de smart contracts se han representado de color verde. El uso de este tipo de decoraciones está autorizado por UML y aumentan la legibilidad de nuestra representación. Estos conceptos, se relacionan, como se pueden ver, con los conceptos definidos en el metamodelo de pruebas. Al objeto de definir las relaciones de trazabilidad entre metamodelos, tenemos las siguientes interrelaciones: • La Metaclass Escenario está relacionada con la Metaclass SmartContract del metamodelo de smart contract. • La Metaclass CasoPrueba está relacionada con la Metaclass Function del metamodelo de smart contract. • La Metaclass DatoCasoPrueba está relacionada con la Metaclass Dato del metamodelo de smart contract. • La Metaclass PasoCasoPrueba está relacionada con la Metaclass Paso del metamodelo de smart contract. • La Metaclass ReglaCasoPrueba está relacionada con la Metaclass Regla del metamodelo de smart contract. IV.4. Resumen del Capítulo Este Capítulo recoge la parte conceptual de nuestra propuesta de solución para el proceso sistemático de generación de pruebas funcionales, a partir de las especificaciones de los requisitos y de comportamiento de los smart contract. En concreto, a lo largo del presente Capítulo, se ha definido un metamodelo para representar los smart contracts, un metamodelo para representar las pruebas funcionales. Y, tras esto, se ha establecido un lenguaje específico