CAPÍTULO V

Pruebas al Prototipo

5.1 Pruebas de integración

Las pruebas de integración se llevaron a cabo usando la herramienta de integración

continua llamada Travis, para lo cual se agregó un proyecto nuevo y se especificó que se
utilizaría el lenguaje Go.

Al especificar el lenguaje, Travis automáticamente crea una máquina virtual, clona el

proyecto desde el sistema manejador de versiones, el cual fue Github en este caso, y crea
las variables de entorno necesarias, tales como “GOROOT” y “GOPATH”.

Finalmente Travis corre todas las pruebas unitarias que hay en el proyecto mediante el
comando “go test –v ./…”. En dicho comando las palabras “go test” significan que se
compilara el código del proyecto y luego se correrán las pruebas de los archivos con
terminación “_test.go”. La bandera “-v” significa que se imprimirá una descripción extendida
de cada prueba. Y por último “./…” significa que las pruebas se buscarán de forma iterativa
en todo el proyecto.

5.2 Pruebas de tensión

Para medir la velocidad de ejecución se utilizó el paquete testing de Go el cual nos

permite conocer la velocidad de ejecución de un proceso al escribir pruebas de tensión
conocidas como benchmarks.

Tal y como Dave Cheney menciona, escribir benchmarks es una excelente manera de
comunicar una mejora en el rendimiento o una regresión de un modo reproducible [13].

22
5.3 Pruebas de operación

Se crearon diversas pruebas para comprobar que la librería cumpliera con el objetivo
para el cual fue diseñada. Debido a que se trata de una librería, se crearon varios escenarios
para la prueba de la misma, tales como: accesos a una base de datos, utilización de
arquitecturas en capas y utilización de objetos globales. Asimismo se verificó que las
validaciones para el archivo de configuración funcionaran de manera correcta.

5.4 Pruebas de usabilidad

Se diseñaron diversas pruebas para verificar que la interfaz del objeto principal fuera
fácil de entender y tuviera las funciones necesarias para que el usuario programador pueda
comenzar a utilizarla de manera fácil e intuitiva.

23
CAPÍTULO VI
Análisis de Resultados

6.1 Tratamiento estadístico que se aplicó a la información recolectada

El objetivo del uso de Inyección de Dependencias en un proyecto tiene como objetivo

el aumentar la mantenibilidad, la cual es muy difícil de medir debido a que depende de varios
factores, algunos de los cuales son muy subjetivos.

Existen algunos estudios como el realizado por Ekaterina Razina y David Janzen [14]
que mencionan que el mantenimiento del software consume alrededor del 70% del ciclo de
vida del mismo. Igualmente mencionan que algunos estudios [10, 11] muestran que módulos
pequeños, desacoplados y con una alta cohesión conllevan un incremento en la
mantenibilidad.

En este mismo estudio se midieron dos factores basados en la investigación de Briand

et al. [18]: cohesión y acoplamiento.

El acoplamiento es definido como el grado de interdependencia entre las partes de un

diseño [17]. Para esta se utilizaron dos medidas:

 Acoplamiento entre objetos (CBO). Se refiere al número de clases a la cual una clase
en particular esta acoplada.

 Respuesta por clase (RFC). Es un conjunto de métodos que pueden ejecutarse

potencialmente en respuesta a un mensaje recibido por un objeto de la clase.

La cohesión es el grado de similitud de los métodos [12, 13]. También podemos decir que
es el grado en el cual cada parte del módulo está asociada con la otra [14].

Lamentablemente dicho estudio no pudo comprobar la hipótesis planteada de que la

Inyección de Dependencias reduce significativamente las dependencias en módulos de
24
software. Sin embargo durante el mismo se encontró una tendencia de un menor
acoplamiento en aquellos módulos con un porcentaje mayor de Inyección de Dependencias
(mayor al 10%).

6.2 Descripción de las gráficas, tablas, dibujos, figuras, etc., obtenida del tratamiento
aplicado a la información recolectada.

Figura 6 Proyectos con mayor %DI

Regresando al proyecto realizado por Ekaterina Razina y David Janzen [14], en la

tabla anterior se muestran los proyectos que registraron el número más bajo de CBO
promedio y en donde se puede observar, que la mayoría tiene un porcentaje de Inyección de
Dependencias (%DI) mayor al 10%.

25
CAPÍTULO VII
Conclusiones

7.1 Discusión

El propósito de esta investigación es el desarrollo de una librería open source que

permita la Inyección de Dependencias en el lenguaje Go. Para lograr lo anterior se procedió
a hacer una investigación acerca de los conceptos necesarios tales como inversión de
control (IoC) y el mismo concepto de Inyección de Dependencias DI.

Como se mencionó en el capítulo 6, es muy difícil medir en qué grado la Inyección de

Dependencias ayuda a un proyecto a ser más flexible al cambio y por ende, mas mantenible.
Por ejemplo, se puede usar la Inyección de Dependencias pero eso no garantiza que el resto
del código este desacoplado, o incluso que los objetos que están siendo inyectados lo estén.

Lo anterior esta fuera del alcance de este proyecto, cuyo propósito es solo la creación
de dicha librería y no observa la eficacia de la misma. Por lo tanto no se observa el grado en
que esta librería ayuda a crear código más mantenible, si ayuda a reducir las líneas de
código o que tanto ayuda a reducir el tiempo de desarrollo de un proyecto.

Como usuario de frameworks que permiten la Inyección de Dependencias, puedo decir

que en mi opinión, este mecanismo ayuda a crear código más flexible y, en el caso de los
que proporcionan la opción de utilizar un archivo de configuración externo, permiten crear
código que es más fácil de probar al ser capaces de cambiar el comportamiento del sistema
sin tener que recompilar el código fuente.

26
7.2 Cumplimientos de los objetivos

7.2.1 Estudiar el estado del arte del contexto del proyecto

Se procedió a revisar varios documentos del tema que incluían la teoría detrás de la
Inyección de Dependencias así como investigaciones acerca de la influencia de la misma en
el código de un proyecto.

Igualmente fueron revisados documentos acerca de librerías y frameworks ya

existentes para Inyección de Dependencias tales como Spring para verificar la manera en
que llevan a cabo dicho proceso.

7.2.2 Definir los el contexto y los escenarios del proyecto

El único escenario detectado en el cual se utilizaría el proyecto es en el cual se

requeriría de una herramienta que permita la Inyección de Dependencias para crear código
más flexible y que permita modificar la configuración mediante un archivo externo.

7.2.3 Analizar y definir los requerimientos del proyecto

Después del análisis de requerimientos se determinaron las partes necesarias para

crear un contenedor de Inyección de Dependencias, los archivos de configuración
necesarios, así como las herramientas externas que facilitarían el desarrollo tales como Git y
Gihub para el manejo de versiones y alojamiento del proyecto respectivamente y Travis para
la integración continua del proyecto.

7.2.4 Diseñar e implementar el proyecto

Se detectaron los módulos necesarios para el funcionamiento de la librería, los cuales

son: El manejador de contextos, contexto, inyector y el mapa de tipos. Adicionalmente se
crearon dos estructuras que servirán de base para contenedor para contener los datos
obtenidos del archivo de configuración.

7.2.5 Pruebas y análisis funcional

En el desarrollo del proyecto fueron utilizadas dos tipos de pruebas: pruebas unitarias,
para probar cada parte del código y pruebas de integración, para probar todos los módulos y
componentes del proyecto a la vez.
27
7.2.6 Medición del impacto del proyecto

No se realizaron medidas del impacto de la librería en un proyecto de software debido

a que es muy difícil por cuestiones que son muy subjetivas tal como se menciona en el
capítulo 6. Sin embargo se menciona el resultado de un trabajo al respecto [14].

7.3 Documentación del proyecto

La documentación de manejo de la librería así como de los métodos que esta expone
para uso de los usuarios programadores se encuentra directamente en el repositorio de
Github el cual se encuentra en la url https://github.com/cone/digo para facilitar el acceso a la
misma.

7.4 Cumplimiento de la hipótesis

Podemos decir que la hipótesis se cumplió satisfactoriamente dado que la librería fue
creada y probada exitosamente.

7.5 La importancia de los resultados obtenidos

Ahora que existe una librería para la Inyección de Dependencias en el lenguaje Go,
los proyectos de software podrán ser construidos de manera que tengan una mayor
flexibilidad y puedan ser probados más fácilmente.

7.6 Las posibles aplicaciones

La librería puede ser usada en cualquier proyecto de software construido con el

lenguaje Go para obtener un código más flexible y por ende, más mantenible.

7.7 Las limitaciones de la investigación

Esta investigación se limitó solo al desarrollo de la librería y pruebas de la misma en

cuanto a su correcto funcionamiento. No se incluyó como parte de esta investigación, en qué
medida ayudaría a un proyecto de software a ser más mantenible, debido a que es muy difícil
medir lo anterior.

28
7.8 Recomendaciones para continuar con la investigación en lo futuro

Se recomienda hacer una investigación más profunda acerca de la usabilidad de dicha

librería en arquitecturas como la clean architecture [19] la cual se basa en diferentes capas
de software.

29
Referencias

[1] The Go Programming Language. Consultado en Mayo 21, 2015, de https://golang.org

[2] Álvarez Cecilio (2014). ¿Que es Spring Framework?. Recuperado de:

http://www.genbetadev.com/frameworks/que-es-spring-framework

[3] Introducing JSON. Consultado en Mayo 21, 2015, de http://json.org/

[4] Test and Deploy with Confidence. Consultado en Mayo 21, 2015, de https://travis-ci.org/

[5] E. Gamma, R. Helm, R. Johnson, and J. Vlissides (1995). Design patterns: Elements of
reusable object-oriented software. Reading, Mass.: Addison-Wesley.

[6] Meyer Bertrand (1988). Object Oriented Software Construction. Reading, Mass.: Prentice
Hall.

[7] M. Seemann. (2011). Dependency Injection in .Net. Recuperado de:

http://www.manning.com/seemann/MEAP_Seemann_01.pdf

[8] S. Chacon and B. Straub (2010, August 2). Pro Git. Recuperado de:
http://labs.kernelconcepts.de/downloads/books/Pro%20Git%20-%20Scott%20Chacon.pdf

[9] S. Chacon and B. Straub. (2010, August 2). Pro Git. Recuperado de: http://git-
scm.com/book/en/v2/GitHub-Account-Setup-and-Configuration

[10] M. Fowler. (2006, May 1). Continuous Integration. Recuperado de:

http://www.martinfowler.com/articles/continuousIntegration.html

[11] Build Better Software Faster. Consultado en Mayo 21, 2015, de

http://www.pivotaltracker.com/

[12] R. Johnson and B. Foote. (1988, June/July). Designing Reusable Classes. Recuperado
de: http://www.laputan.org/drc/drc.html

[13] D. Cheney. (2013, June 30). How to write benchmarks in go. Recuperado de:
http://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go

[14] E. Razina and D. Janzen. (2007, November 19-21). Effects of dependency injection on
maintainability. Recuperado de:
http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=1035&context=csse_fac

[15] E. Arisholm. Dynamic coupling measures for object oriented software. IEEE Symposium
on Software Metrics, 30(8), 2002, 33-34.

30
 Referencias (continuación …)

[16] C. Rajaraman and M.R. Lyu. Reliability and maintainability related software coupling
metrics in C++ programs. In Third International Symposium on Software Reliability, North
Carolina, USA, 1992, 303-311.

[17] S. R. Chidamber and C. F. Kemerer. A metrics suite for object oriented design. IEEE
Transactions on Software Engineering, 20(6), 1994, 476-493.

[18] L. Briand, J. Daly, and J. Wust. A unified framework for coupling measurement in object-
oriented systems. IEEE Transactions on Software Engineering, 24(1), 1999, 91-121.

[19] R. Martin. (2012, Aug13). The Clean Architecture. Recuperado de:

http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

31