View
3
Download
0
Category
Preview:
Citation preview
Sistema de Recuperación de Decisiones de Diseño de Arquitectura de Software sobre Proyectos
Públicos Basados en Microservicios
Juan Carlos Paz Holguín
Adrián David Peña López
Trabajo de Grado presentado para optar al título de Magister en Ingeniería de Software
Director: Msc. Fernando Barraza
Universidad San Buenaventura Cali
Facultad de Ingeniería
Maestría en Ingeniería de Software
Cali, Colombia
2017
II
Referencia/Reference
Estilo/Style:
APA 6th ed. (2017)
Paz, J., & Peña, A. (2017). Sistema de Recuperación de Decisiones de Diseño de
Arquitectura de Software sobre Proyectos Públicos Basados en
Microservicios (Trabajo de grado Maestría en Ingeniería de software).
Universidad de San Buenaventura Colombia, Facultad de Ingeniería, Cali.
Maestría en Ingeniería de Software, Cohorte V
Bibliotecas Universidad de San Buenaventura
• Biblioteca Universidad de San Buenaventura - Cali.
• Biblioteca Fray Alberto Montealegre OFM - Bogotá.
• Biblioteca Fray Arturo Calle Restrepo OFM- Medellín, Bello, Armenia, Ibagué.
• Biblioteca Central Fray Antonio de Marchena – Cartagena.
Universidad de San Buenaventura Colombia
Universidad de San Buenaventura Colombia - http://www.usb.edu.co/
Cali -http://www.usbcali.edu.co
Bogotá - http://www.usbbog.edu.co
Medellín - http://www.usbmed.edu.co
Cartagena - http://www.usbctg.edu.co
Editorial Bonaventuriana - http://www.editorialbonaventuriana.usb.edu.co/
Revistas - http://revistas.usb.edu.co/
Biblioteca Digital (Repositorio)
http://bibliotecadigital.usb.edu.co
III
Tabla de Contenido
1. INTRODUCCIÒN .................................................................................................................................... 1
1.1 Intereses de la Investigación ............................................................................................................... 1
1.2 Justificación del tema objeto de estudios ............................................................................................ 1
1.3 Objetivos de la Investigación .............................................................................................................. 2
1.3.1 Objetivo General: ......................................................................................................................... 2
1.3.2 Objetivos Específicos: .................................................................................................................. 2
1.4 Organización del documento .............................................................................................................. 3
2. FUNDAMENTOS TEÓRICOS ................................................................................................................ 4
2.1 Gestión de Conocimiento Arquitectónico (AKM): ............................................................................. 4
2.2 Decisiones de Diseño de Arquitectura (ADD) .................................................................................... 4
2.3 Modelos de Decisiones de Arquitectura de Software ....................................................................... 13
2.4 Decisiones Alojadas en Repositorios Públicos (GitHub) .................................................................. 14
2.5 Microservicios ................................................................................................................................... 14
3. PROCESO METODOLÓGICO ............................................................................................................. 17
3.1 Modelo de Decisiones Propuesto ...................................................................................................... 17
3.1.1 Tipos de Decisiones ................................................................................................................... 17
3.1.2 Modelos de Decisiones .............................................................................................................. 18
3.1.3 Criterios de Selección. ............................................................................................................... 20
3.1.4 Selección del Modelo. ................................................................................................................ 20
3.1.5 Modelo de Decisiones Propuesto. .............................................................................................. 23
3.2 Diseño del Sistema ............................................................................................................................ 24
3.2.1 Diagrama de Motivación ............................................................................................................ 24
3.2.2 Diseño de Solución con Enfoque de Arquitectura Empresarial. ................................................ 26
3.2.3 Arquitectura de Referencia ........................................................................................................ 28
3.2.4 Arquitectura de Solución. .......................................................................................................... 29
3.3 Implementación de la Herramienta ................................................................................................... 37
3.3.1 API Rest. .................................................................................................................................... 37
IV
3.3.2 Artefactos Recuperados. ............................................................................................................ 37
3.3.3 API GitHub. ............................................................................................................................... 38
3.3.4 API Maven. ................................................................................................................................ 39
3.3.5 Dimensión de Arquitectura. ....................................................................................................... 40
3.4 Evaluación......................................................................................................................................... 44
3.4.1 Relevancia. ................................................................................................................................. 44
3.4.2 Juicio de Expertos. ..................................................................................................................... 45
3.4.3 Consultas Formuladas. ............................................................................................................... 47
3.4.4 Medidas de evaluación. .............................................................................................................. 48
3.4.5 Instrumentos de evaluación. ....................................................................................................... 49
3.4.6 Resultados obtenidos.................................................................................................................. 51
3.4.7 Análisis de Resultados. .............................................................................................................. 66
4. CONCLUSIONES .................................................................................................................................. 69
5. TRABAJOS FUTUROS ......................................................................................................................... 71
6. REFERENCIAS BIBLIOGRÀFICAS .................................................................................................... 72
V
Lista de Ilustraciones
Ilustración 1. Posible Máquina de Estados para una Decisión…………………………….……..8
Ilustraciòn 2. Ejemplo de Decisiones de Diseño……………………..…………………….……21
Ilustración 3. Modelo de Decisiones Propuesto……………………………………………..…..23
Ilustración 4: Diagrama de Motivación…………………………………………………….…....25
Ilustración 5. Diseño de Solución con Enfoque de Arquitectura Empresarial……………….….27
Ilustración 6. Arquitectura de referencia de Sistema de recuperación de datos de API Rest
GITHUB…………………………………………………………………………………………28
Ilustración 7. Presentación Primaria - Componentes y Relaciones de la solución de Recuperación
de Decisiones de Diseño de Arquitectura- Microservicios……………………………………....29
Ilustración 8. Diagrama de Secuencia del Sistema…………………………………………...….35
Ilustración 9. Diagrama de Secuencia del Comportamiento del Proceso de Consulta de las
decisiones de Diseño de Arquitectura……………………………………………………………36
Ilustración 10. Ejemplo de contenido de un archivo POM……..………………….…………….38
Ilustración 11. Ejemplo de contenido de API Maven..……………………………..…………....39
Ilustración 12. Ejemplo de relaciones entre artefactos en un POM del Repositorio A………….41
Ilustración 13. Ejemplo de las Decisiones Alojadas en 2 Repositorios..…………..……….……42
Ilustración 14. Conjunto de Documentos Recuperados………………………………………….48
Ilustración 15. Gráfica de Precisión y Recall Interpolada para la Consulta C1………………….53
Ilustración 16. Gráfica de F-score para la Consulta C1………………………………………….54
Ilustración 17. Gráfica de Precisión y Recall Interpolada para la Consulta C2………………….56
Ilustración 18. Gráfica F-Score y Recall para la Consulta C2…..……………………………….57
Ilustración 19. Gráfica de Precisión y Recall Interpolada para la Consulta C3………………….59
VI
Ilustración 20. Gráfica de F-score para la Consulta C3…………………………………….……60
Ilustración 21. Gráfica de Precisión y Recall Interpolada para la Consulta C4…………….……62
Ilustración 22. Gráfica de F-score para la Consulta C4………………………………………….63
Ilustración 23. Gráfica de Precisión y Recall Interpolada para la Consulta C5………………….65
Ilustración 24. Gráfica de F-score para la Consulta C5………………………………………….66
VII
Lista de Tablas
Pág.
Tabla 1. Cuadro Comparativo de Modelos de Decisiones de Diseño de Arquitectura…………..19
Tabla 2. Criterios de Decisión…………………………………………………………………....22
Tabla 3. Elementos de la Presentación Primaria…………………………………………………30
Tabla 4. Puntos de Variación……………………………………………………………………31
Tabla 5. Tabla de Decisiones de Arquitectura………………………………………………..….32
Tabla 6. Ejemplo de Ítems Resultantes para la Consulta de "Cloud"……………………………43
Tabla 7. Consultas formuladas……………...………………………………………………..…..47
Tabla 8. Instrumentos de evaluación………..…...…………………………………………..…..50
Tabla 9. Ejemplos de Instrumentos de evaluación …………………………………………..…..51
Tabla 10. Resultados Evaluación Consulta C1…..…………………………………………..…..52
Tabla 11. Resultados Evaluación Consulta C2……..……………………………...…………….55
Tabla 12. Resultados Evaluación Consulta C3…..………………………………………....……58
Tabla 13. Resultados Evaluación Consulta C4..…………………………………..……………..61
Tabla 14. Resultados Evaluación Consulta C5…..………………………………………..……..64
Tabla 15. Resultados Consolidados de la Evaluación…………………………………...………66
1
1. INTRODUCCIÒN
1.1 Intereses de la Investigación
Los arquitectos de TI cumplen un papel muy importante dentro de las organizaciones, son
responsables de tomar decisiones que impactan intrínsecamente el futuro tecnológico de las
compañías. Además, considerando los objetivos estratégicos de las organizaciones y las nuevas
tecnologías disponibles deben ser capaces de conceptualizar nuevos entornos que lleven a las
compañías a ser cada vez más competitivas. Estas decisiones muchas veces se ven limitadas a la
mera experiencia del arquitecto que algunas veces es nula cuando se trata de soluciones con
tecnologías emergentes, o por la experiencia que logre capturar de otros arquitectos con los que
puedan interactuar. Muchas de estas experiencias corresponden a implementaciones de
soluciones de proyectos que están alojados en repositorios públicos en internet.
La presente investigación busca diseñar un sistema de recuperación de decisiones
arquitectónicas que permita a los arquitectos acceder a las decisiones plasmadas por otros
arquitectos para el desarrollo de proyectos alojados en repositorios de internet. De esta manera,
se apoya el proceso de toma de decisiones en las organizaciones de manera acertada y además se
brinda la oportunidad a arquitectos emergentes de que puedan entregar soluciones respaldadas
por la comunidad de arquitectos en el mundo.
1.2 Justificación del tema objeto de estudios
Cuando surgen nuevas tendencias para soluciones de TI, los arquitectos se enfrentan al
problema de diseñar soluciones que aborden dichas tendencias pero que, como se trata de
conocimiento nuevo, variado, disperso y extenso en los cuales ellos no tienen experiencia, una
2
herramienta como esta puede apoyar y servir de punto de partida para la toma de decisiones de
diseño arquitectónico tanto para arquitectos con experiencia como para arquitectos junior. Este
conocimiento tácito muchas veces se ve “evaporizado” ya que no se documenta y permanece
oculto en la mente del arquitecto.
Precisamente esta investigación pretende cubrir esta brecha planteando y dejando el
conocimiento arquitectónico de manera explícita y accesible para cualquier tipo de arquitecto
inclusive desarrolladores que requiera tomar algún tipo de decisión de diseño en su organización.
1.3 Objetivos de la Investigación
1.3.1 Objetivo General:
Diseñar un sistema de recuperación de decisiones de diseño de arquitectura de software
sobre proyectos públicos basados en microservicios.
1.3.2 Objetivos Específicos:
• Realizar un benchmarking sobre modelo de decisiones de arquitectura de software y
seleccionar el más apropiado para el sistema propuesto
• Diseñar una herramienta para alimentar un repositorio de decisiones de diseño de
arquitectura basado en el modelo previamente seleccionado.
• Implementar la herramienta seleccionada que apoye el proceso de consulta de decisiones
de diseño alojadas en los repositorios.
• Realizar la validación de las decisiones de diseño recuperadas del repositorio basándose
en técnicas de evaluación de sistemas de recuperación.
3
1.4 Organización del documento
El presente trabajo está dividido en cuatro capítulos: Los fundamentos teóricos, el
desarrollo metodológico, las conclusiones y finalmente los trabajos futuros.
En el primer capítulo se describen los diferentes conceptos y procesos relacionados a la
problemática planteada: Gestión de conocimiento arquitectónico, Modelos de decisiones de
diseño, Sistemas de recuperación y microservicios.
El siguiente capítulo describe el proceso metodológico de la investigación presentándolo de la
siguiente manera: La selección del modelo, el diseño de la solución, la implementación, y por
último la evaluación del sistema de recuperación.
Finalmente, los últimos dos capítulos presentan las conclusiones del desarrollo de la
investigación y los trabajos futuros a realizar.
4
2. FUNDAMENTOS TEÓRICOS
En este capítulo se expondrán las teorías y conceptos que fundamentan el desarrollo de esta
investigación.
Se da inicio con el concepto de Gestión de conocimiento arquitectónico, pasando luego por las
diferentes teorías expuestas por algunos autores sobre las decisiones de diseño de arquitectura,
para luego mencionar los modelos de decisiones de arquitectura de software relevantes para la
investigación, así como, las decisiones alojadas en repositorios públicos, para finalizar con el
concepto de los microservicios.
2.1 Gestión de Conocimiento Arquitectónico (AKM):
La gestión de conocimiento arquitectónico (AKM) busca proponer modelos, enfoques,
frameworks y herramientas para apoyar las actividades involucradas en los procesos de
arquitecturas de sistemas como lo son: el análisis, la implementación, la documentación, la
evaluación, la descripción de arquitecturas y la recuperación entre otros. AKM comprende
enfoques para capturar, representar, reusar y más recientemente, compartir el conocimiento
arquitectónico. Fowler (2014)
(Conocimiento Arquitectónico = Diseño arquitectónico + Decisiones de Diseño Arquitectónico).
2.2 Decisiones de Diseño de Arquitectura (ADD)
A medida que los sistemas software han ido creciendo en complejidad, se ha hecho
imprescindible la necesidad de aislar los detalles de implementación para poder prestar atención
al comportamiento e interacción de los elementos que integran el sistema y poder diseñar
sistemas que posean las propiedades deseadas. (González, 2014).
5
De manera abstracta, la arquitectura de software implica la descripción de los elementos
de los que se compone el sistema, las interacciones entre esos elementos, los patrones que guían
su composición y las restricciones en esos patrones (Shaw y Garlan, 1996).
Desde la aparición del término arquitectura de software en los años noventa, se han propuesto
más de 150 definiciones (Clements et al. 2011). La más aceptada es la propuesta por Bass et al.
(1998):
“La arquitectura de un programa o sistema computacional es la estructura o estructuras del
sistema, que comprende los componentes software, sus propiedades visibles desde el exterior y
las relaciones entre ellos”. (Bass, 1998)
Esta definición va en línea con la adoptada en el estándar ISO/IEC/IEEE para la
descripción de arquitecturas ISO/IEC/IEEE 42010:2011 Systems and Software Engineering –
Architecture description (ISO 2011) que sustituye a la ISO1471:2000 y que define el término
como:
“La arquitectura son los conceptos fundamentales o propiedades del sistema en su ambiente
expresada a través de sus elementos, relaciones, los principios de su diseño y evolución”. (ISO,
2011)
Lo que aparece como denominador común en las distintas definiciones, es que la
arquitectura software se compone de elementos, conexiones o relaciones entre ellos y
propiedades relevantes.
Según Clements (2011), la arquitectura software de sistema es una entidad compleja que
no puede ser descrita de una forma simple utilizando una representación mono-dimensional. Es
por esto que documentar una arquitectura consiste en representar las vistas relevantes y añadir
documentación que involucre a más de una vista.
6
El número y nombre de las vistas necesarias para la representación de una arquitectura
software es un tema muy controvertido y en el que no se ha logrado un consenso (González,
2014). Una de las representaciones más conocidas es la representación 4 +1 (Kruchten, 1995),
que aboga por describir la arquitectura mediante 5 vistas: la vista lógica, la vista de desarrollo, la
vista de proceso, la vista física y la vista de escenarios. El estándar ISO/IEC/IEEE 42010:2011
(ISO 2011), propone que el número de vistas y su naturaleza se definan en función de las
características del sistema a desarrollar.
Por otro lado, Jan Bosch (2004, 2005) declaró que "no vemos una arquitectura de
software como un conjunto de componentes y conectores, sino más bien como la composición de
un conjunto de decisiones de diseño arquitectónico". Asegurando que la falta de representación
de la lógica de primera clase en el diseño de los modelos de vista de arquitectura ocasiona la
necesidad de incluir decisiones de arquitectura que deben ser incorporados dentro de la
documentación de una arquitectura tradicional.
Para Kruchten (2009) existen varios beneficios para usar las razones de diseño en la
arquitectura como un medio para lograr explicar por qué se hace una elección de diseño en
particular o para saber qué alternativas de diseño han sido evaluadas anteriormente para así
lograr elecciones optimas de diseño.
Dichos beneficios, se pueden lograr a mediano y largo plazo porque documentar el diseño
justifica la necesidad de procesos de recuperación de la arquitectura, debido a que se consigue
posteriormente recuperar las decisiones de arquitectura cuando el diseño, la documentación o
incluso los creadores de la arquitectura ya no estén disponibles. En otros casos, se hace necesario
debido a que la evolución natural de un software obliga a que las decisiones anteriores sean
reemplazadas por unas nuevas. Por lo tanto, mantener y gestionar este conocimiento
7
arquitectónico requiere una atención continua para así poder mantener los cambios en el código y
el diseño alineados con las decisiones, y lograr de esta manera usarlos para colmar la brecha de
arquitectura del software. (Kruchten, op. cit.)
Las decisiones de diseño son entonces un subconjunto del conocimiento arquitectónico
(AK) que se produce durante el desarrollo de la arquitectura. La mayor parte del conocimiento
tácito que permanece oculto en la mente de los arquitectos debe ser explícito y transferible en
una forma útil para su uso posterior, facilitando la ejecución de procesos de toma de decisiones
distribuidos y colectivos. (Kruchten, 2009)
Autores como Jan Bosch (2004), Kruchten (2004), Lago y van Vliet (2006) realizaron
diferentes aportes sobre la importancia de las decisiones de diseño arquitectónico, introduciendo
una plantilla más detallada para documentar las decisiones de diseño, en particular haciendo
hincapié en las relaciones entre las decisiones de diseño y entre las decisiones de diseño y otros
artefactos.
Posteriormente, Tang (2005) Dueñas y Capilla (2005, 2007) generan cada uno diferentes
tipos de atributos de diseño y aunque con variaciones entre ellos se logró en 2006 conciliar todas
las opiniones en el llamado Taller SHARK.
Dentro de los atributos de una decisión de diseño arquitectónico Kruchten (2004- 2006)
señala los siguientes:
• Epítome (o la propia Decisión): dentro de este atributo se realiza una breve declaración
textual de la decisión de diseño, en unas pocas palabras o una línea. Este texto sirve para
resumir las decisiones, enumerarlas, etiquetarlas en diagramas, etc.
8
• Justificación: en este atributo se realiza una explicación textual del "por qué" de la
decisión, su justificación. Se debe tener cuidado de no simplemente parafrasear o repetir
información capturada en otros atributos, sino para agregar valor.
• Alcance: algunas decisiones pueden tener un alcance limitado, en el tiempo, en las
organizaciones, o en el diseño y la implementación. Por defecto, (si no se documenta) la
decisión es universal. El alcance podría delimitar la parte de un ciclo de vida, o una parte
de la organización a la que se aplica la decisión.
• Estado: al igual que los informes de problemas o el código, las decisiones de diseño
evolucionan de una manera que puede ser descrita por una máquina de estado (Imagen 1):
Ilustración 2. Posible Máquina de Estados para una Decisión.
Fuente: Kruchten (2004).
Esta máquina de estados está compuesta por: una Idea, Provisional (Escenarios “Qué pasa
si”), Decidido (Posición actual del arquitecto), Aprobado (Decisión aprobada por una revisión o
9
consejo), Desafiado (Decisión que fue aprobada pero que puede volver a ser puesta a probación o
entrar a estado provisional o rechazada), Rechazado (Decisión que no se cumple en el sistema
actual) y Obsoleta (Similar al rechazado pero esta decisión se ha convertido en discutible o
irrelevante) Kruchten (ob. cit.).
A continuación, se presentan la definición de los aspectos que intervienen en los estados
de una decisión de diseño arquitectónico:
• Autor, Sello de Tiempo, Historia: la persona que tomó la decisión y cuándo.
Idealmente, se debe recopilar la historia de los cambios en una decisión de diseño. Los
cambios estatales son importantes, pero también lo son los cambios en la formulación y
el alcance, especialmente con las revisiones arquitectónicas incrementales.
• Categorías: una decisión de diseño puede pertenecer a una o más categorías. La lista de
categorías está abierta. Las categorías son útiles para consultas y para crear y explorar
conjuntos de decisiones de diseño que están asociados con preocupaciones específicas o
atributos de calidad.
• Costo: algunas decisiones de diseño tienen un costo asociado.
• Riesgo: es importante documentar debido a la exposición - una combinación de factores
de impacto y probabilidad - este es el riesgo asociado con tomar una decisión en
particular.
• Decisiones relacionadas: la decisión A "está relacionada con" la decisión B de
cualquiera de maneras como las restricciones, prohibiciones, habilitantes, subsistemas,
conflictos, anulación, limitada, restrictivas, entre otras.
10
Por otro lado, en la investigación sobre las decisiones de diseño arquitectónico de Boer,
Farenhorst, Lago, Vliet, Clere & Jansen (2007) y Tyree y Akerman (2005), típicamente se
consideran cuatro aspectos de las decisiones: el tema de la decisión, la elección, las alternativas
que se consideran y la justificación (a veces formalizada como clasificación) de la decisión.
Existen diferentes niveles de abstracción de las decisiones arquitectónicas. Como se
describe por de Boer (2007), las decisiones a menudo se relacionan entre sí, y esta relación suele
formar una estructura tipo árbol la cual se organiza desde la más abstracta hasta la más concreta
(las decisiones dan lugar a nuevos temas de decisión).
Para Boer (ob. cit.) en general se pueden distinguir tres niveles de decisiones:
• Decisiones de Alto Nivel: son aquellas que afectan a todo el producto, aunque no
necesariamente son siempre las decisiones que se debaten o se piensan más. A menudo,
las personas que no están involucradas en la realización del proyecto (Por ejemplo, los
arquitectos de gestión o de empresa) afectan mucho a estas decisiones. Se resalta que
cambiar estas decisiones suele tener un enorme impacto.
• Decisiones de Nivel Medio: las decisiones de nivel medio implican la selección de
componentes o marcos específicos, o describen cómo se correlacionan componentes
específicos entre sí de acuerdo con patrones arquitectónicos específicos. Estas decisiones
se discuten a menudo, donde la arquitectura y el desarrollo son evaluados, cambiados y
desechados según sea necesario. Tienen un alto impacto en las propiedades (no
funcionales) del producto y son relativamente costosos de cambiar.
• Decisiones de Nivel de Realización: las decisiones de nivel de realización implican la
estructura del código, la ubicación de responsabilidades específicas (por ejemplo,
11
patrones de diseño) o el uso de API específicas. Estas decisiones son relativamente
fáciles de cambiar y tienen un impacto relativamente bajo en las propiedades del sistema.
Dichas investigaciones finalmente concluyen que las decisiones arquitectónicas más
difíciles de tomar son las decisiones de nivel medio (Van der Ven & Bosh, 2013), por las
siguientes razones: a) estas decisiones tienen un alto impacto sobre las propiedades funcionales y
no funcionales de la sistema; b) cambian constantemente, especialmente en comparación con las
decisiones de alto nivel que sólo cambian cuando se rehace el sistema; c) son costosos de
cambiar debido al impacto en el sistema; d) porque los nuevos componentes y la versión se crean
constantemente, Es difícil mantenerse informado acerca de todas las alternativas pertinentes,
tienen resultados impredecibles hasta que se implementan en el sistema.
Finalmente se desea representar el conocimiento arquitectónico porque se desea obtener
el control intelectual sobre la enorme complejidad del sistema sofisticado y asegurar la
continuidad, permitiendo que estos grandes sistemas evolucionen, y se mantengan más
efectivamente y transferir este conocimiento a otros.
Esto con el fin de lograr analizar y evaluar arquitecturas, implementarlas, evolucionarlas,
evaluar algunas de sus cualidades, apoyar actividades de planificación, presupuestación o
adquisición, debido a que cuanto más se deje implícito este conocimiento arquitectónico, más
difíciles o arriesgadas serán estas actividades. Además, también lograr tener la capacidad de
abstraer un conocimiento arquitectónico más genérico que el conocimiento colectivo en un
dominio dado o con tecnologías dadas. (Kruchten, 2009)
Sin olvidar al final como lo anota Kruchten (2009) que este conocimiento es una
combinación de a) El diseño arquitectónico, genérico, traído adentro usando arquitectos expertos,
educación, marco, métodos, y estándares. B) Diseño arquitectónico, para el sistema en
12
desarrollo, expresado mediante una combinación de las anotaciones y herramientas apropiadas,
adaptadas a las preocupaciones de las partes involucradas (puntos de vista). Son modelos del
sistema. C) Decisiones arquitectónicas, para el sistema en desarrollo, con sus complejas
interdependencias y rastreo hacia arriba a los requisitos, contexto y restricciones, y rastreo
downstream hasta el diseño, e incluso la implementación.
En la Taxonomía arquitectural de decisiones de diseño Kruchten (2004) menciona que las
decisiones de diseño arquitectónico no desempeñan todas las mismas funciones en el proceso de
diseño arquitectónico. Algunas están estrechamente acopladas al diseño mismo, y pueden
atravesarse directamente de un elemento (por ejemplo, una clase, un proceso, un sistema de
paquetes, una interfaz) en el subdesarrollo del sistema; otras decisiones son propiedades o
restricciones generales que imponemos al sistema, que los conjuntos de elementos deben
satisfacer y, finalmente, algunos están vinculados a los ambientes políticos, sociológicos y
culturales generales del desarrollo o despliegue y menciona cuatro clases de decisiones:
• Decisiones Existentes: en la implementación de sistemas ya diseñados o implementados
se encuentran decisiones existentes que satisfacen requerimientos funcionales o
requerimientos no funcionales que se capturan para poyar otras alternativas
• Prohibiciones o Decisiones de Inexistentes: es lo contrario de una decisión existente,
indicando que algún elemento no aparecerá en el diseño o la implementación. Las
decisiones de prohibición se hacen a menudo cuando se eliminan gradualmente las
posibles alternativas.
• Decisiones de Propiedad: Una decisión de propiedad establece un rasgo duradero,
general o la calidad del sistema. decisiones de propiedad pueden ser reglas de diseño o
13
directrices (cuando se expresa positivamente) o restricciones de diseño (cuando se
expresa negativamente),
• Decisiones Ejecutivas: Estas son las decisiones que no se relacionan directamente con
los elementos de diseño o sus cualidades, sino que son impulsadas más por el entorno
empresarial (financiero) y afectan el proceso de desarrollo (metodológico), las personas
(educación y formación), la organización y, a una amplia gama de opciones de
tecnologías y herramientas.
2.3 Modelos de Decisiones de Arquitectura de Software
Existen diferentes esfuerzos de los investigadores para generar modelos y herramientas
relacionados a la captura, administración y publicación de las decisiones de diseño de
arquitectura (ADD) (Shahin &Liang, 2009) almacenando el conocimiento arquitectónico (AK)
Uno de los principales problemas en las decisiones de arquitectura es la evaporación del
conocimiento de dichas decisiones de diseño y alternativas de decisión de una solución de
software tal y como lo señalan Capilla y Jansen (2016). Debido a esto se plantea la necesidad de
tomar diferentes modelos y ontologías de referencias para soportar las decisiones de diseño y que
estas puedan ser recuperadas y consultadas a futuro.
Capilla y Jansen (2016) estudian nueve modelos seleccionados por Shahin, Liang, Reza
Khayyambashi (2009) donde comparan cada uno de los modelos y se evidencia las similitudes en
conceptos e igualmente diferencias en términos entre los modelos, para la comparación se
separan en dos tipos elementos principales (Major Elements) y elemento sin consenso (Minor
Elements) a continuación el listado de los nombres de los modelos seleccionados para este
estudio:
14
• Tyree Decision Template es modelo propuesto por Tyree y Akerman (2005) y está
orientado a SOA
• Kruchten’s Ontology (Kruchten, 2004)
• Core Model (Boer, Farenhorst, Lago, Vliet & Clerc, 2007).
• Pattern-based Model Although. Harrison, Avgeriou & Zdun (2007).
• Service-Oriented Architecture Decision Model (Zimmermann, Koehler & Leymann,
2006)
• Archium Model (Jansen & Bosch, 2005)
• Architecture Design Decision Support System Model
• AREL (Tang, Han & Vasa, 2009)
• DAMSAK (Babar, Gorton & Kitchenham, 2006).
2.4 Decisiones Alojadas en Repositorios Públicos (GitHub)
Tal como lo menciona Loeliger (2009) GitHub es un sitio de alojamiento de proyectos de
software que basa su funcionamiento en el sistema de gestión de configuración GIT para el
control de versiones, muy usado para proyectos públicos, y al ser una plataforma colaborativa es
altamente utilizada por los desarrolladores.
Lo que lo hace interesante a este repositorio es que expone información técnica o de
desarrollo de los de los proyectos por medio de un API Rest como lo relaciona Gousios y
Spinellis (2013).
2.5 Microservicios
Las arquitecturas livianas emergentes como arquitectura de microservicios surgen de las
experiencias de un estilo de arquitectura orientada a servicios SOA, las características como el
15
desacoplamiento de responsabilidades a los componentes de software con el benéfico de ser
desplegados y probados de forma independientes generan una mayor autonomía y reutilización
y están siendo muy adoptadas en las empresas de tecnología con alto tráfico como Netflix,
Amazon y LinkedIn Como lo menciona Thones, Johannes (2015).
Uno de los primeros trabajos escritos sobre microservicios fue publicado en 2015 por Sam
Newman generando gran cantidad de discusiones de arquitectura de microservicios donde
también se ve identificando nuevos términos de las prácticas de desarrollo de software como
DevOps, Aseguramiento de Calidad Ágil, integración continua, entrega continúa destacando el
alto desempeño que ofrece este estilo arquitectónico James Lewis and Martin Fowler (2014),
Datos de Trafico en Internet Norteamérica y Latinoamérica ofrecidos por la compañía Sandvine
en su último informe de tráfico global de internet (Tang, Han & Vasa, 2009)
• Netflix representó el 35.2% del tráfico en las redes fijas norteamericanas. Si bien este fue
un modesto descenso del 37,1% del tráfico que representó hace seis meses, este cambio
es probablemente el resultado de las mejoras de Netflix para comprimir mejor su
videoteca. Incluso con estas mejoras en la eficiencia de transmisión, el porcentaje de
tráfico de Netflix en las redes fijas en América Latina aumentó de 6.6% a 8.3%.
• Amazon Video es ahora la tercera aplicación clasificada (desde el octavo de hace un año)
en América del Norte, lo que representa el 4,3% del tráfico fijo. Sling TV ahora aparece
entre las 20 aplicaciones más importantes en la mayoría de las redes estadounidenses,
pero aún representa menos del 1% del tráfico.
• El streaming de audio y video ahora representa el 71% del tráfico vespertino en las redes
de acceso fijo de Norteamérica. Sandvine espera que esta cifra alcance el 80% en 2020.
16
• Cloud Storage (Dropbox, iCloud, Google Drive, etc.) ha superado a Filesharing como la
fuente más grande de tráfico en sentido ascendente durante el período de pico en las redes
de acceso fijo norteamericanas. BitTorrent ahora representa menos del 5% del tráfico
diario total en la región.
• La incorporación de llamadas de video y voz está impulsando el crecimiento de las
aplicaciones de comunicaciones en redes móviles en América Latina y América del
Norte. En América Latina, el porcentaje de tráfico de WhatsApp es ahora del 7,4%, más
del triple de lo que era hace dos años.
• En América Latina, Facebook y Google representan más del 70% del tráfico móvil total
en la región, frente al 60% reportado el año pasado.
• Más del 60% del tráfico móvil en América Latina y América del Norte está ahora cifrado
y Sandvine predice que algunas redes superarán el 80% este año.
El informe presentado muestra el tráfico de internet y las compañías que lideran dicho tráfico
demostrando que las nuevas técnicas tienden a ser adoptadas por equipos más hábiles. Estos
equipos son referentes para equipos que quieren mejorara sus desarrollos enfrentándose a nuevos
desafíos donde finalmente tendrán que tomar decisiones de diseño de arquitectura.
Se evidencia que el estilo microservicio es una tendencia interesante y con muchos retos para los
arquitectos, por lo que se plantea como un escenario de validación propicio para la presente
investigación.
17
3. PROCESO METODOLÓGICO
En esta sección se presenta el desarrollo metodológico para el diseño del sistema de
recuperación. Primero se detalla el modelo de decisiones propuesto, luego se plantea el diseño de
la solución, posterior a ello se describe la implementación del sistema y por último se presenta la
evaluación del mismo.
3.1 Modelo de Decisiones Propuesto
3.1.1 Tipos de Decisiones
El “Rational Unified Process” (RUP) define la arquitectura de software como el conjunto
de decisiones significativas a cerca de la organización de los sistemas de software: la selección
de los elementos de estructura e interfaces con que se compone el sistema. En este orden de ideas
se definen las decisiones como el “core” de toda arquitectura de software.
Dichas decisiones se pueden encontrar en elementos de diseño, documentación e inclusive en el
código fuente de los proyectos de software que pueden estar alojados en repositorios públicos.
Para determinar el modelo de decisiones a utilizar en el sistema de recuperación de decisiones se
plantea la siguiente pregunta:
¿Qué tipo de decisiones de diseño se pueden encontrar en repositorios públicos?
Según Kruchten (2004), existen tres tipos de decisiones de diseño:
• Decisiones de propiedad
• Decisiones ejecutivas
• Decisiones existentes
18
Las decisiones de propiedad están más relacionadas a reglas de diseño, restricciones de
diseño y líneas guías. Un ejemplo de ellas sería: Todas las clases relacionadas a persistencia son
definidas en la capa # 2.
Las decisiones ejecutivas están más dirigidas a restricciones de políticas que afectan el
proceso de desarrollo. Por ejemplo, una decisión de este tipo sería: Todos los controles de
cambios deben ser aprobados por el comité de Arquitectura.
Las decisiones existentes son aquellas que se pueden evidenciar en elementos/artefactos
de diseño o implementación y que tienen que ver con la forma como se crean los subsistemas,
componentes y capas de la arquitectura y la manera como estos interactúan juntos para proveer
funcionalidad o satisfacer algún requisito no funcional (atributo de calidad). Ejemplo de ellas
sería: La comunicación entre clases usa Servicios REST.
Estas últimas son las decisiones soportadas por el modelo propuesto.
3.1.2 Modelos de Decisiones
La mayoría de los modelos de decisiones presentan ciertos elementos comunes que varían
en cuanto a terminología y algunos profundizan en ciertos elementos más que otros. Las
diferencias se marcan es por las herramientas que soportan dichos modelos; algunas ofrecen
diferentes funcionalidades como trazabilidad y análisis de impacto, mientras que otras ofrecen
capacidades para el trabajo colaborativo, por ejemplo.
En la Tabla 1 se presentan nueve (9) modelos de decisiones, que son los más usados en la
industria según Capilla y Jansen (2016), y se comparan con respecto a los elementos y
capacidades que ofrecen. Los elementos mayores corresponden a elementos comunes entre los
modelos y que básicamente solo cambian en cuanto a terminología. Los elementos menores son
elementos diferenciadores entre un modelo y otro.
19
Tabla 1. Cuadro Comparativo de Modelos de Decisiones de Diseño de Arquitectura
Fuente: Capilla y Jansen (2016)
20
3.1.3 Criterios de Selección.
Ya que la mayoría de los modelos presentan características muy similares, se busca un
modelo que permita mapear la mayoría de elementos que estén presentes en las decisiones
alojadas en los repositorios públicos, a la vez que soporte una arquitectura extensible a futuras
investigaciones.
Los siguientes son los criterios de decisión tenidos en cuenta:
• Completitud: la completitud es el grado en el que los datos asociados con una entidad
tienen valores para todos los atributos esperados e instancias de entidades relacionadas en
un contexto de uso específico. En este caso, la completitud corresponde a la cantidad de
elementos que se pueden mapear en dicho modelo.
• Compresibilidad: la compresibilidad es el grado en el que los datos tienen atributos que
permiten ser leídos e interpretados por los usuarios y son expresados utilizando lenguajes,
símbolos y unidades apropiados en un contexto de uso específico.
• Flexibilidad: la flexibilidad es el grado en el que los datos tienen atributos que permiten
ser modificados o adaptados según la necesidad que se tenga en un contexto de uso
específico.
3.1.4 Selección del Modelo.
La ontología de Kruchten es el único modelo no estático que permite extender sus
elementos (y las relaciones entre los elementos) según sea la necesidad. Se preselecciona dicha
ontología y se compara contra el modelo de Archium.
21
A continuación, se plantea un ejemplo de dos decisiones presentes en un repositorio público,
todo esto con el fin de identificar los elementos susceptibles de ser parte del modelo de
decisiones propuesto.
Ilustraciòn 2. Ejemplo de Decisiones de Diseño
Fuente: Elaboración propia
22
En la decisión 1, se logra evidenciar que el repositorio “waitme8888/spring-security”
tomó la decisión de usar la librería Spring Security JWT para resolver un requisito de
codificación / decodificación de JSON Web Tokens en el mismo repositorio; es decir, en el
mismo proyecto, se decidió utilizar también la librería OAuth2 para un asunto de seguridad.
Tomando como base este ejemplo, se identifican los siguientes elementos de decisión:
• Autor: el nombre del repositorio, en este caso waitme8888/spring-security
• Resumen: el nombre de las librerías usadas por el autor, en este caso “Spring Security
JWT Library” y “OAuth For Spring Security”
• Justificación: la descripción de las librerías usadas en el repositorio
• Categoría: la categoría de las decisiones, en este caso la categoría sería “Security”
• Relación: ambas decisiones están relacionadas entre sí ya que pertenecen al mismo
repositorio.
Teniendo en cuenta estos cinco (5) elementos y los criterios de decisión, se realiza la
comparación entre los dos (2) modelos preseleccionados obteniendo los siguientes resultados:
Tabla 2: Criterios de Decisión
Fuente: Elaboración propia.
Se selecciona la Ontología de Kruchten como resultado de la comparación de los dos modelos.
23
3.1.5 Modelo de Decisiones Propuesto.
A continuación, se presenta un Modelo de Decisiones Propuesto, que se toma como
referencia reflejado en el siguiente esquema:
Ilustración 3. Modelo de Decisiones Propuesto
Fuente: Elaboración propia
- Autor: Es el arquitecto que tomó la decisión. Corresponde al nombre del repositorio de
GitHub.
- Decisión: Son librerías usadas por los arquitectos en sus repositorios. Tienen un nombre
(Resume) y una descripción (Rational). Está información la encontramos en los
repositorios de Maven.
- Concerns: Toda decisión es tomada para satisfacer un interés de arquitecto (categoría).
Estos intereses o preocupaciones para el caso de microservicios pueden ser, por ejemplo:
Seguridad, Elasticidad, Rendimiento.
24
- Related to: las decisiones pertenecientes a un mismo repositorio pueden estar
relacionadas entre sí.
3.2 Diseño del Sistema
En la siguiente sección se detalla el diseño de la herramienta. Se partió de un enfoque de
arquitectura empresarial descrito por Josey, Hofmman & Rouse (2013) que sirviera de driver
para conectar el diseño de la solución con los requerimientos de los arquitectos. Este enfoque de
arquitectura es ampliamente usado en metodologías de referencia como lo es TOGAF (The Open
Group Architecture Framework)
3.2.1 Diagrama de Motivación
Este diagrama ilustra las razones que motivan a diseñar este tipo de sistema. En él se
encuentran elementos como drivers, hallazgos, objetivos y metas. Un Arquitecto que desee
diseñar una solución de microservicios, por ejemplo, espera “reducir la evaporización del
conocimiento” (driver) que se ve impactada por la “Gestión deficiente del conocimiento”
(hallazgo) lo que plantea la necesidad de “disponer de información oportuna para decisiones de
diseño de microservicios” (objetivo) que lleva a la meta de “implementar una herramienta de
consulta de decisiones en los repositorios” de proyectos ya implementados.
26
3.2.2 Diseño de Solución con Enfoque de Arquitectura Empresarial.
Una vez definidas las motivaciones, se procede a diseñar una propuesta que vaya acorde a
esas motivaciones partiendo de una arquitectura base a una arquitectura objetivo (la arquitectura
de solución propuesta) pero que apunte a las metas previamente identificadas, todo esto para
suplir el vacío (gap) que precisamente resuelve el Sistema de Recuperación propuesto. (Ver
Ilustración 5).
27
Ilustración 5. Diseño de Solución con Enfoque de Arquitectura Empresarial
Fuente: Elaboración propia
28
3.2.3 Arquitectura de Referencia
Contiene un conjunto de mejores prácticas arquitectónicas de las cuales se puede referenciar y
reutilizar para una arquitectura se solución en un dominio en particular; en este caso una
referencia para una solución involucrando APIs de repositorios públicos como GITHUB.
Como lo demuestra Gousios y Spinellis (2013, p. 5) en su proyecto GHTorrent en la Ilustración 6
la interacción del API Rest por medio de componentes crawler que recuperan datos de GitHub
pasando por una cola de mensajes y persistidos para su posterior consulta.
Ilustración 6. Arquitectura de referencia de Sistema de recuperación de datos de API Rest
GITHUB
Fuente: Gousios y Spinellis (2013, p. 5)
Los atributos de calidad para la arquitectura antes mencionada por la cual se hace referencia para
la solución propuesta de recuperación de decisiones de diseño se enfocan en la interoperabilidad
y Rendimiento por el gran volumen de información como se justifica en la sección 3.2.5.
29
3.2.4 Arquitectura de Solución.
Ilustración 7. Presentación Primaria - Componentes y Relaciones de la solución de Recuperación de Decisiones de Diseño de
Arquitectura- Microservicios
Fuente: Elaboración propia
cmp Component
Recuperación de Decisiones Diseño de Arquitectura de Software - Microservicios
Recuperación GitHub
GitHub API getData
(RetrievalBot)
REST /
JSON
Almacenamiento
- datosJSON
Maven API
Recuperación Maven
getInfoFramework
Almacenamiento
- InfoFrameworkIndexado
Consulta de Arquitectos de proyectos de
software UIConsulta de
Terminos de
Microservicios
Almacenamiento -
Modelo de
Decisiones de
Diseño (BD)
MicroserviciosMicroservicios
Preprocesamiento
«abstraction»«abstraction»
30
El diagrama de la (Ilustración 6) representa las capas, componentes y relaciones que participan
en la solución implementada, para la arquitectura de solución se estudian algunas arquitecturas
de referencia que utilizan recuperación de información e interactúa directamente con la API Rest
de GitHub como es el caso de GHTorrent project de Gousios y Spinellis (2013, p. 5). En la tabla
3, se describen cada uno de sus elementos.
Tabla 3. Elementos de la Presentación Primaria
Nombre del Componente Descripción del Componente
GitHub API
Este componente representa API Rest del repositorio de código
fuente de proyectos de software de GITHUB, poderosa herramienta
que expone GitHub para la integración con otros sistemas de
información.
GetData()
Este componente representa el conjunto de elementos que se utiliza
para integración con el API Rest y posterior recuperación de los
proyectos públicos que contienen decisiones de diseño de
arquitectura ya implantadas y se evidencia en los archivos de
configuración de los gestores de dependencias.
Este componente crawler se ejecuta a diario con una periodicidad
seleccionada aproximada 24 horas y recupera proyectos como una
tarea programada.
Github.Microservicios
Este componente representa una abstracción con la cual se
segmenta la solución orientando los resultados recuperados por
GetData a términos y conceptos de microservicios.
Almacenamiento datos JSON
Este componente representa los datos recuperados posterior al
consumo del API GitHub en notación JSON
Almacenamiento en Modelo de Decisiones
de Diseño de Arquitectura
Este componente representa un modelo de base de datos diseñado
con base en la ontología Kruchten’s donde se alojan las decisiones
de diseño de arquitectura de software para su posterior consulta.
Indexado Este componente representa la indexación documentos recuperados
de la combinación entre lo recuperado de API Rest Maven y API
Rest GitHub utilizando la herramienta Lucen de Apache.
Preprocesamiento Este componente realiza el preprocesamiento textual de la consulta
antes de ser ejecutada.
31
GetInfoFrameWork Este componente representa el conjunto de elementos que se utiliza
para integración con el API Rest Maven y posterior recuperación de
la información de los framework o dependencia.
Este componente crawler se ejecuta a diario con una periodicidad
seleccionada aproximada 24 horas y recupera información de
dependencias como una tarea programada.
Maven.Microservicios
Este componente representa una abstracción con la cual se
segmenta la solución orientando los resultados recuperados por
GetInfoFrameWork a términos y conceptos de microservicios
Almacenamiento datos InfoFrameWork Este componente representa los datos recuperados posterior al
consumo del API Maven en notación JSON
Maven API
Este componente representa API Rest del gestor de dependencias
Maven, poderosa herramienta que expone GitHub para la
integración con otros sistemas de información.
Consulta de Arquitectos de Proyectos
Software UI
Este componente Representa una aplicación web Fontend que
consulta las decisiones recuperadas partiendo de los archivos
indexados y consultando el detalle de lo encontrado en el modelo
de BD donde están alojadas las decisiones de diseño de
arquitectura.
Fuente: Elaboración propia
La tabla 4 muestra los puntos de variación posibles en el diseño y se cuenta con el
mecanismo de variación que el arquitecto ha elegido como lo explica (Clements, Bachmann Len
Bass, Garlan, Ivers, Little, Merson, Nord & Stafford, 2010, Sesion 6.4.4)
Tabla 4. Puntos de Variación.
Punto de Variación Elemento o Relación
Afectada
Variantes Condiciones Momento de
Asociación
Funcionalidades
procedimientos,
operaciones, datos
Componente APIs
Creación o
modificación de
nuevas
funcionalidades
Funcionalidades
repetitivas en los
servicios,
funcionalidades con
grado alto de
reutilización,
funcionalidades no
En tiempo de
diseño y desarrollo.
32
dependientes del
negocio.
Mecanismo de
almacenamiento de
la información de
trazabilidad y
auditoria.
Logging and
Auditing;
Mail;
Logs;
Database
Mail, logs,
database.
Mejor manejo de la
información
almacenar la
trazabilidad en las
bases de datos, los
logs impactan
menos el
rendimiento y para
el envió de errores o
alertas por
comportamientos
anormales se usa el
mail.
Ejecución
Mecanismo de
almacenamiento en
BD
Base de Datos
SQLite
Base de Datos Base de datos ligera
con un rendimiento
alto en tiempo de
respuestas
Ejecución
Fuente: Elaboración propia.
3.2.5 Justificación
A continuación, se establece la tabla de decisiones arquitecturales tomas por cada uno de los
atributos de calidad de la arquitectura que afectan el sistema.
Tabla 5. Tabla de Decisiones de Arquitectura.
Atributo de Calidad Afectado
(Característica / Sub-
característica)
Necesidad Decisión Arquitectural
Interoperabilidad
Proveer un mecanismo de
intercambio donde se
recupere fuentes de
proyectos de desarrollo de
software de repositorios de
código públicos
Se decide utilizar API Rest de GitHub debido
a que es un repositorio público con alta
demanda en el mercado donde existen
proyectos de software de los cuales se puede
recuperar su código fuente que contiene
33
Proveer un mecanismo de
intercambio donde se
recupere información de
las dependencias o
framework
decisiones de diseño arquitectural ya
implantados.
La comunicación es por HTTP Rest
facilitando la comunicación entre
componentes y es la que ofrece GITHUB para
integración
Se decide utilizar API Rest de mvnrepository
debido a que es un repositorio remoto que
contiene una colección de dependencias de
diferentes tipos, también se decide utilizar los
archivos de configuración (pom.xml) de los
proyectos recuperado para identificar las
dependencias asociadas a microservicios que
son decisiones de diseño que en la
implantación soluciona un problema
identificado utilizando java
La comunicación es por HTTP Rest
facilitando la comunicación entre
componentes.
Rendimiento
Se hace necesario
mantener un buen
rendimiento en la
comunicación entre los
componentes
Se decide utilizar notación JSON para la
mensajería entre los componentes APIs y
Recuperación Get (se debe establecer los
contratos de cada servicio swagger)
Fuente: Elaboración propia
34
3.2.6 Diagrama de Comportamiento.
La Ilustración 7 muestra el comportamiento entre los componentes : Indexado por medio del
componente getInfoFramework obtiene los documentos asociados a microservicios del API
Maven los cuales son indexados con la herramienta de Lucene de apache para una posterior
consulta, de igual forma y apoyado del componente de getData se obtienen los documentos del
API GitHub los cuales son indexados, posteriormente se combinan los documentos generando
datos de decisiones de diseño que finalmente se almacenan en la bases de datos.
El diagrama de secuencia de la Ilustración 8, se muestra el comportamiento de los componentes
y la forma en que los arquitectos recuperan las decisiones de diseño de arquitectura para apoyar
sus propias decisiones en proyectos de software asociados a microservicios. Los arquitectos
ingresan un término (o varios términos) a buscar utilizando el componente web que
posteriormente consulta en los documentos previamente indexados que a su vez son consultados
en la base de datos que almacena las decisiones de diseño de arquitectura para ofrecer un mayor
detalle de la información de las decisiones que finalmente se muestran a los arquitectos.
35
Ilustración 8. Diagrama de Secuencia del Sistema
Fuente: Elaboración propia
sd Secuencia Model
Maven API GitHub APIIndexado :Almacenamiento -
Modelo de
Decisiones de
Diseño (BD)
A
alt Proceso de Indexado-crawler
Almacenar Decision de arquitectura ()
Consulta Pom Proyectos GITHUB
(Lista IdFrameWork)
Lista IdFrameWork()
Ubicar Doc Termino MicroServicio()
Ubicacion Proyectos GITHUB - JSON
Decision ()
36
Ilustración 9. Diagrama de Secuencia del Comportamiento del Proceso de Consulta de las decisiones de Diseño de Arquitectura
Fuente: Elaboración propia
sd Component Model
Arquitecto Software
:Consulta de
Arquitectos de
proyectos de
software UI
:Almacenamiento
-Modelo de
Decisiones de
Diseño (BD)
A
Indexado
alt Consulta Decision del Modelo de BD
Decision de arquitectura - Info de Proyecto de Repositorio GITHUB()
Decision de arquitectura - Info de Proyecto de Repositorio GITHUB()
Consulta Informacion detallada()
Concer : Termino Microservicio ()
Consulta Archivos Indexado()
37
3.3 Implementación de la Herramienta
Una vez definida la arquitectura de solución y el modelo de decisiones propuesto, se
prosigue a implementar un prototipo basado en esta arquitectura que sirva de herramienta de
consulta para el arquitecto en materia de decisiones de diseño arquitectónico sobre
microservicios.
A continuación, se describen los APIs utilizados para la conexión a los repositorios
públicos, los artefactos recuperados, la implantación de los componentes de indexación y
consulta, y la implementación de la Dimensión de Arquitectura utilizada para ponderar los
documentos arrojados por la consulta.
3.3.1 API Rest.
La mayoría de los repositorios públicos en Internet disponen de un API REST para
realizar operaciones de consulta sobre sus datos. REST (en inglés Representational State
Transfer) es un estilo de arquitectura de software que brinda la posibilidad de intercambiar
información entre sistemas distribuidos a través de peticiones HTTP y respuestas en cualquier
formato como XML o JSON.
Para la implementación del sistema propuesto se utiliza el API Rest como mecanismo de
acceso a la información de los repositorios públicos.
3.3.2 Artefactos Recuperados.
Dado el modelo de decisiones propuesto en la sección 3.1, se plantea la necesidad de
recuperar en el repositorio aquellos artefactos que sirvan de soporte de información para el
modelo propuesto. Este es el caso del archivo POM (Project Object Model) que es un archivo
38
XML que contiene información de los proyectos y los detalles de configuración utilizados para
construir el proyecto. Este artefacto contiene información rica en arquitectura ya que define los
componentes utilizados para soportar las funcionalidades de los proyectos, además de las
relaciones de dependencia dentro de los mismos artefactos. Un ejemplo del contenido de un
archivo POM se puede ver en la Ilustración 10.
Ilustración 10. Ejemplo de contenido de un archivo POM.
Fuente: Elaboración propia
Las librerías relacionadas en los archivos POM corresponden al elemento Resumen
perteneciente al modelo de decisiones propuesto.
3.3.3 API GitHub.
GitHub es un sitio de alojamiento de proyectos de software que basa su funcionamiento
en el sistema de gestión de configuración Git para el control de versiones como lo menciona
Loeliger (2009), y es muy usado para proyectos públicos; es una plataforma colaborativa usada
para desarrolladores. Lo que hace interesante a este repositorio es que expone información
técnica o de desarrollo de proyectos por medio de un API Rest como menciona (Georgios
Gousios and Diomidis Spinellis 2013).
39
El propietario de la cuenta de GitHub corresponde al elemento Autor perteneciente al
modelo de decisiones propuesto, es decir, es el arquitecto que toma las decisiones alojadas en el
repositorio.
3.3.4 API Maven.
Maven es una herramienta de gestión de proyectos que utiliza los archivos POM como
base de su funcionamiento. Las librerías relacionadas en las dependencias en los POM de los
proyectos alojados en GitHub están disponibles en un repositorio central de Maven. Maven
ofrece un API para recuperar información alojada en su repositorio central. La ilustración 11
muestra un ejemplo de tipo de contenido que se puede recuperar a través del API de Maven.
Ilustración 11. Ejemplo de contenido de API Maven.
Fuente: Elaboración propia
40
Las descripciones de las librerías alojadas en el repositorio central de Maven
corresponden a la Justificación de las decisiones de diseño del modelo de decisiones propuesto
en esta investigación.
3.3.5 Dimensión de Arquitectura.
Dado que la propuesta de esta investigación no consiste en diseñar un sistema
convencional de recuperación de información textual, sino en diseñar un sistema de recuperación
de conocimiento arquitectónico, se hace necesario encontrar un mecanismo que permita validar
la información recuperada de tal manera que sea aportante para el arquitecto.
Autores como Munaiah, N. (2016), Kroh, S. (2016), Cabrey, C. (2016), and Nagappan,
M. (2016), describen ocho (8) dimensiones de la ingeniería de software que pueden estar
inmersas en el código fuente de un proyecto de software; una de ellas, la “Dimensión de
Arquitectura”, que se calcula en base a la organización del código.
Tomando como base la anterior investigación, se propone implementar la dimensión de
arquitectura como elemento diferenciador y validador de las decisiones arrojadas por el sistema
de recuperación de manera que pueda ser utilizada como factor de ponderación de los ítems
resultantes.
La fórmula propuesta para el cálculo de la dimensión de arquitectura es la siguiente:
𝐴 = 𝐶𝑎𝑛𝑡𝑖𝑑𝑎𝑑 𝑑𝑒 𝑑𝑒𝑐𝑖𝑠𝑖𝑜𝑛𝑒𝑠 𝑟𝑒𝑐𝑢𝑝𝑒𝑟𝑎𝑑𝑎𝑠 𝑒𝑛 𝑢𝑛 𝑟𝑒𝑝𝑜𝑠𝑖𝑡𝑜𝑟𝑖𝑜
𝑇𝑜𝑡𝑎𝑙 𝑑𝑒 𝑑𝑒𝑐𝑖𝑠𝑖𝑜𝑛𝑒𝑠 𝑟𝑒𝑐𝑢𝑝𝑒𝑟𝑎𝑑𝑎𝑠 ∗ 100
Este índice califica el nivel de arquitectura de un repositorio con base en el número de
decisiones de diseño que tiene alojado dicho repositorio. Entre más decisiones tenga, mayor será
el índice de arquitectura y mayor será el interés que pueda llegar a tener un arquitecto sobre este
repositorio.
41
La (Ilustración 11) muestra un ejemplo de un archivo POM recuperado de un repositorio
A de GitHub y las 5 dependencias que lo componen, 4 de ellas del framework de “spring.boot”
que es un framework de microservicios.
Ilustración 12. Ejemplo de relaciones entre artefactos en un POM del Repositorio A.
Fuente: Elaboración propia.
42
En la (Ilustración 12) se muestra un grafo de las cuatro (4) decisiones posiblemente recuperadas
del repositorio A y un repositorio B que podría también alojar decisiones que hayan sido
tomadas en el repositorio B.
Ilustración 13. Ejemplo de las Decisiones Alojadas en 2 Repositorios
Fuente: Elaboración propia
43
Si la cantidad de decisiones recuperada fuera 100 y tomando como base el ejemplo de la
Ilustración 12 en donde se evidencian 4 decisiones para el repositorio A y 1 decisión para el
repositorio B, el cálculo de la dimensión de arquitectura A para el repositorio A y B sería la
siguiente:
𝐴𝑟𝑒𝑝𝑜 𝐴 = 4
100 ∗ 100 = 4% 𝐴𝑟𝑒𝑝𝑜 𝐵 =
1
100 ∗ 100 = 1%
Si se realizara una consulta sobre un interés que tenga que ver con “cloud”, y el Sistema
arrojara la decisión D4 como resultado, el repositorio A debería aparecer de primero en la lista
de ítems resultantes ya que posee un mayor índice de arquitectura y sería más interesante para el
arquitecto como se ve en la tabla 6.
Tabla 6. Ejemplo de Ítems Resultantes para la Consulta de "Cloud"
Repositorio A (%) Decisión
A 4 Starter Cloud Connectors
B 1 Starter Cloud Connectors
Fuente: Elaboración propia.
La implementación logró mostrar los resultados representándolos en el modelo de decisiones
propuesto y además mostrar el cálculo de la de la dimensión de arquitectura como índice de
ponderación de los documentos resultantes.
44
3.4 Evaluación
La etapa final en la creación de un Sistema de Recuperación de Información es la
Evaluación. En esta se busca valorar la efectividad de los resultados arrojados por el sistema; es
decir, conocer en qué medida la respuesta es satisfactoria a la demanda del usuario.
A continuación, se presentan algunas definiciones de conceptos inherentes al proceso de
evaluación, seguido de los instrumentos de evaluación y el análisis de los resultados obtenidos.
3.4.1 Relevancia.
Según el Diccionario de la Lengua Española (DRAE), relevancia significa “cualidad o
condición de relevante, importancia, significación”, y relevante es definido como “importante o
significativo”. Así, un documento será relevante cuando el contenido del mismo posea alguna
significación o importancia en relación con la pregunta realizada por el usuario, es decir, con su
necesidad de información. El cálculo de la relevancia es clave en toda evaluación de un sistema
de recuperación.
Para calcular la relevancia, lo más habitual es establecer valores binarios: un documento
es relevante, es decir, sirve como respuesta a nuestra pregunta cuando su valor es igual 1 o no
relevante si su valor es igual a 0.
Muchas veces establecer la relevancia de un documento para una pregunta determinada resulta
difícil y los especialistas no se ponen de acuerdo; por ello, es conveniente que los juicios los
haga un grupo de expertos y de ser posible sus integrantes sea un número impar.
Para la evaluación del sistema se tuvo en cuenta el concepto de cinco arquitectos expertos
que calificaron la relevancia de los resultados entregados por el sistema dada una necesidad de
información.
45
3.4.2 Juicio de Expertos.
Los expertos seleccionados corresponden a arquitectos que cumplen con los siguientes
criterios:
• Arquitectos expertos en la materia, profesionales con amplia experiencia en el diseño de
soluciones de arquitectura de software (más de 8 años).
• Arquitectos activos, que actualmente estén desempeñando roles de arquitectura en sus
organizaciones (Arquitectos de software, Arquitectos de TI, Arquitectos de integraciones,
Arquitectos de negocio, Arquitectos de datos, Arquitectos empresariales, Arquitectos de
soluciones).
• Arquitectos con amplio recorrido académico y fundamentos teóricos (Especialistas,
Magisters).
A continuación, el perfil de los cinco arquitectos:
PERFIL ARQUITECTO A
Empresa Vortexbird
http://vortexbird.com/
Cali – Valle del Cauca
Cargo Arquitecto de Soluciones
Experiencia 15 años
Perfil Ingeniero de Sistemas, Magíster en Ingeniería de Software, con experiencia
liderando proyectos de desarrollo de software y siendo arquitecto de soluciones
de TI.
46
PERFIL ARQUITECTO B
Empresa Instituto de Desarrollo Urbano
https://www.idu.gov.co/
Bogotá D.C.
Cargo Arquitecto Empresarial
Experiencia 20 años
Perfil Ingeniero de Sistemas, Especialista en Arquitectura Empresarial de Negocio,
con más de 6 años de experiencia en proyectos de Desarrollo e implementación
de Software, para proyectos cliente/servidor, web, trabajando como líder de
grupos de soporte y desarrollo, proyectos de desarrollo de software con casas
de software.
PERFIL ARQUITECTO C
Empresa Instituto de desarrollo urbano IDU
https://www.idu.gov.co/
Bogotá D.C.
Cargo Arquitecto de Software
Experiencia 20 años
Perfil Ingeniero de Sistemas, Magíster en Gestión de Informática y
Telecomunicaciones, con experiencia liderando proyectos de desarrollo de
software y siendo arquitecto de soluciones de TI.
PERFIL ARQUITECTO D
Empresa Departamento de Estadística Nacional (DANE)
http://www.dane.gov.co/
Bogotá D.C.
Cargo CTO
Experiencia 10 años
Perfil Ingeniero de Sistemas, Especialista en Gerencia de Proyecto Cursando
Master, experiencia en desarrollo web, backend y BD
47
PERFIL ARQUITECTO E
Empresa Lead IS Consulting
Cali – Valle del Cauca
Cargo CTO
Experiencia 8 años
Perfil Ingeniero de Sistemas y Telemática, Especialista en Procesos para el Desarrollo
de Software y Magíster en Ingeniería de Software
CTO and co-founder of lead IS consulting, Educator de DevHack , Co-
organizer Google Developer Group Cali
3.4.3 Consultas Formuladas.
Dado que el escenario de validación del sistema son proyectos que tengan que ver con
soluciones orientadas a microservicios, se plantearon cinco preguntas teniendo en cuenta los
intereses que podrían llegar a tener los arquitectos a la hora de diseñar soluciones de este estilo
de arquitectura.
Tabla 7. Consultas formuladas
Código Consulta Concern
C1 Data Access Persistencia
C2 Cloud deployment Cloud
C3 Service config Autonomía
C4 Building microservices Building
C5 Manager services Monitoring
Fuente: Elaboración propia.
48
3.4.4 Medidas de evaluación.
Ilustración 14. Conjunto de Documentos Recuperados
Fuente: Elaboración propia
a) Precisión
La precisión mide el porcentaje de documentos recuperados que resultan relevantes con el
tema de la pregunta y su cálculo es simple: se divide el total de documentos relevantes
recuperados entre el total de documentos recuperados (Ver ilustración 8).
𝑃 =𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 í𝑡𝑒𝑚𝑠 𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡𝑒𝑠 𝑟𝑒𝑐𝑢𝑝𝑒𝑟𝑎𝑑𝑜𝑠
𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 í𝑡𝑒𝑚𝑠 𝑟𝑒𝑐𝑢𝑝𝑒𝑟𝑎𝑑𝑜𝑠
b) Recall
El recall o exhaustividad o sensibilidad es la proporción de documentos relevantes
recuperados, del total de los documentos que son relevantes en la base de datos,
independientemente de que éstos, se recuperen o no. Mientras que la precisión se puede
49
determinar, la exhaustividad no, ya que para calcularla se necesita conocer de antemano el
número de documentos relevantes.
𝑅 =𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 í𝑡𝑒𝑚𝑠 𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡𝑒𝑠 𝑟𝑒𝑐𝑢𝑝𝑒𝑟𝑎𝑑𝑜𝑠
𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 í𝑡𝑒𝑚𝑠 𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡𝑒𝑠 𝑒𝑛 𝑙𝑎 𝑐𝑜𝑙𝑒𝑐𝑐𝑖ó𝑛
Nota: Debido a que el cálculo del recall requiere calificar la relevancia de todos los ítems de la
colección, para efectos de la evaluación inferimos un valor de exhaustividad de 1,0. Además, la
Precisión y el Recall son inversamente proporcionales, por lo que, si se desea un valor alto para
uno, se castiga el valor del otro. Los arquitectos entrevistados manifestaron preferir un sistema
preciso antes que un sistema exhaustivo.
c) F-score
El valor F, F-score o medida F, es la media armónica que combina los valores de precisión y
recall de manera que quede un único valor ponderado. Este valor mide el rendimiento real del
sistema de recuperación. Su fórmula es la siguiente:
𝐹 = 2 ∗ 𝑃 ∗ 𝑅
𝑃 + 𝑅
3.4.5 Instrumentos de evaluación.
Teniendo en cuenta las diversas consultas formuladas expuestas en la sección 3.4.3. se hace
entrega al grupo de expertos un conjunto de registros "datasets" arrojados por el prototipo de
solución implementado, con el fin de que estos realicen el proceso de evaluación.
Los dataset entregados al grupo de expertos esta compuestos por las siguientes columnas:
50
Tabla 8. Instrumentos de evaluación
Columna Descripción
Artifactid Identificador de dependencia utilizado en el
archivo pom con el que se relaciona su
información en detalle
Nombre Nombre de la dependencia
Descripción Descripción de la dependencia que orienta
la decisión de diseño recuperada
Repositorio Autor del repositorio consultado / nombre
del repositorio
Artifact URL URL o ruta del repositorio publico
GITHUB que cuenta con decisiones de
diseño de arquitectura
Arquitectura Dimensión de arquitectura que muestra el
porcentaje del nivel de arquitectura de la
decisión recuperada ver sección 3.3.5
Concern Termino de interés en la decisión
recuperada
Relevancia Espacio para el diligenciamiento por el
grupo de experto para afirmar si la decisión
recuperada es relevante, es decir, sirve
como respuesta a nuestra consulta
formulada cuando su valor es igual 1 o no
relevante si su valor es igual a 0.
Fuente: Elaboración propia.
A continuación, un ejemplo de un registro de una decisión recuperada por el prototipo de
solución implementado:
51
Tabla 9. Ejemplo Instrumentos de evaluación
Columna Descripción
Artifactid spring-boot-starter-data-ldap
Name Spring Boot Data LDAP Starter
Descripción Starter for using Spring Data LDAP
Repositorio ravisuthar/spring-data
Artifact URL https://github.com/ravisuthar/spring-
data/blob/f5ce82eae2709dacac6ce3366ea23aefc1fd6a2a/demo/pom.xml
Arquitectura 1%
Concern Persistence
Relevancia 1
Fuente: Elaboración propia.
3.4.6 Resultados obtenidos.
A continuación, los resultados de las evaluaciones hechas por los expertos para cada una de las
consultas y las gráficas de las medidas de Precisión, Recall y F-score.
Las tablas corresponden a los resultados de las evaluaciones hechas por los cinco arquitectos
expertos sobre los diez documentos más relevantes arrojados por el sistema con las cinco
consultas formuladas en la sección 3.4.3, en donde los arquitectos evaluaron cada documento
como relevante (1) o no relevante (0). Se utiliza la moda como medida para lograr determinar la
relevancia final de cada documento. Si la mayoría de los arquitectos califican un documento
como relevante (1), entonces la relevancia final de dicho documento será uno (1), de lo contrario
será cero (0).
52
La gráfica de precisión contra recall nos permite observar como fue el comportamiento de la
precisión en la medida en que se iban recuperando cada uno de los documentos hasta llegar al
valor máximo de exhaustividad (recall). La precisión nos define que tan pertinentes son los
documentos que nos devuelve el sistema.
La gráfica de la medida-F nos permite conocer el valor real de rendimiento retornando un valor
único ponderado (media armónica) de la precisión y el recall.
Para está evaluación se recuperaron 2010 decisiones los repositorios de GitHub y Maven.
Los resultados se analizan en la sección 3.4.6.
La Tabla 10 muestra los resultados de la evaluación de la consulta C1 (Data Access). Los
resultados muestran un valor final de precisión del 100% y de F-score del 100%
Tabla 10. Resultados Evaluación Consulta C1
A1 A2 A3 A4 A5 M C A P R F-s
D1 1 1 1 0 0 1 1 1 1,00 0,10 0,18
D2 1 1 1 0 0 1 2 2 1,00 0,20 0,33
D3 1 1 1 0 0 1 3 3 1,00 0,30 0,46
D4 0 1 1 1 1 1 4 4 1,00 0,40 0,57
D5 0 1 1 1 1 1 5 5 1,00 0,50 0,67
D6 1 1 1 0 1 1 6 6 1,00 0,60 0,75
D7 0 0 1 1 1 1 7 7 1,00 0,70 0,82
D8 1 0 1 0 1 1 8 8 1,00 0,80 0,89
D9 0 1 1 0 1 1 9 9 1,00 0,90 0,95
D10 1 1 1 1 1 1 10 10 1,00 1,00 1,00
Total 6 8 10 4 7 10
An: Arquitecto enésimo (n=1…5)
Dn: Documento enésimo (n=1…10)
M: Moda
C: Contador de documentos
A: Variable auxiliar para el cálculo de P y R
P: Precisión
R: Recall
F-s: F-score
Fuente: Elaboración propia.
53
La Ilustración 15 muestra el comportamiento de precisión obtenido en la evaluación de la
consulta C1 (Data Access). En la gráfica se observa un comportamiento ideal para la precisión.
Ilustración 15. Gráfica de Precisión y Recall Interpolada para la Consulta C1
Fuente: Elaboración propia.
La Ilustración 16 muestra el comportamiento de F-score obtenido en la evaluación de la consulta
C1 (Data Access). En la gráfica se observa un comportamiento ideal de F-score.
0,00
0,20
0,40
0,60
0,80
1,00
1,20
0,00 0,20 0,40 0,60 0,80 1,00 1,20
Pre
cisi
on
Recall
C1
54
Ilustración 16. Gráfica de F-score para la Consulta C1
Fuente: Elaboración propia.
La Tabla 11 muestra los resultados de la evaluación de la consulta C2 (Cloud deployment). Los
resultados muestran un valor final de precisión del 80% y de F-score del 89%.
0,00
0,20
0,40
0,60
0,80
1,00
1,20
0,00 0,20 0,40 0,60 0,80 1,00 1,20
F-Sc
ore
Recall
C1
55
Tabla 11. Resultados Evaluación Consulta C2
A1 A2 A3 A4 A5 M C A P R F-s
D1 1 1 0 1 1 1 1 1 1,00 0,13 0,22
D2 1 1 1 1 1 1 2 2 1,00 0,25 0,40
D3 1 0 1 1 1 1 3 3 1,00 0,38 0,55
D4 1 1 1 1 1 1 4 4 1,00 0,50 0,67
D5 1 1 0 0 1 1 5 5 1,00 0,63 0,77
D6 1 0 0 0 1 0 6 5 0,83 0,63 0,71
D7 1 0 0 0 1 0 7 5 0,71 0,63 0,67
D8 1 1 0 0 1 1 8 6 0,75 0,75 0,75
D9 1 1 0 0 1 1 9 7 0,78 0,88 0,82
D10 1 1 0 0 1 1 10 8 0,80 1,00 0,89
Total 10 7 3 4 10 8
An: Arquitecto enésimo (n=1…5)
Dn: Documento enésimo (n=1…10)
M: Moda
C: Contador de documentos
A: Variable auxiliar para el cálculo de P y R
P: Precisión
R: Recall
F-s: F-score
Fuente: Elaboración propia.
La Ilustración 17 muestra el comportamiento de precisión obtenido en la evaluación de la
consulta C2 (Cloud deployment). Nótese que al retornar el documento 6, la precisión empezó a
descender.
56
Ilustración 17. Gráfica de Precisión y Recall Interpolada para la Consulta C2
Fuente: Elaboración propia.
La Ilustración 18 muestra el comportamiento de F-score obtenido en la evaluación de la consulta
C2 (Cloud deployment). Nótese que, a pesar de la decaída en la precisión, el rendimiento logra
mantenerse.
57
Ilustración 18. Gráfica F-Score para la Consulta C2
Fuente: Elaboración propia.
La Tabla 12 muestra los resultados de la evaluación de la consulta C3 (Service config). Los
resultados muestran un valor final de precisión del 80% y de F-score del 89%.
58
Tabla 12. Resultados Evaluación Consulta C3
A1 A2 A3 A4 A5 M C A P R F-s
D1 1 1 0 1 1 1 1 1 1,00 0,13 0,22
D2 1 1 0 0 1 1 2 2 1,00 0,25 0,40
D3 1 1 1 1 1 1 3 3 1,00 0,38 0,55
D4 0 1 1 1 1 1 4 4 1,00 0,50 0,67
D5 0 0 0 1 1 0 5 4 0,80 0,50 0,62
D6 0 1 0 0 0 0 6 4 0,67 0,50 0,57
D7 1 1 0 1 0 1 7 5 0,71 0,63 0,67
D8 1 1 0 1 1 1 8 6 0,75 0,75 0,75
D9 0 1 0 1 1 1 9 7 0,78 0,88 0,82
D10 1 1 1 0 1 1 10 8 0,80 1,00 0,89
Total 6 9 3 7 8 8
An: Arquitecto enésimo (n=1…5)
Dn: Documento enésimo (n=1…10)
M: Moda
C: Contador de documentos
A: Variable auxiliar para el cálculo de P y R
P: Precisión
R: Recall
F-s: F-score
Fuente: Elaboración propia. Los resultados muestran un valor final de precisión del 80% y de F-score del 89%
La Ilustración 19 muestra el comportamiento de Precision obtenido en la evaluación de la
consulta C3 (Service config). Nótese que al retornar el documento 5 la precisión empezó a
descender.
59
Ilustración 19. Gráfica de Precisión y Recall Interpolada para la Consulta C3
Fuente: Elaboración propia.
La Ilustración 20 muestra el comportamiento de F-score obtenido en la evaluación de la consulta
C3 (Service config). Nótese que, a pesar de la decaída en la precisión, el rendimiento logra
mantenerse.
60
Ilustración 20. Gráfica de F-score para la Consulta C3
Fuente: Elaboración propia.
La Tabla 13 muestra los resultados de la evaluación de la consulta C4 (Building microservices).
Los resultados muestran un valor final de precisión del 60% y de F-score del 75%.
61
Tabla 13. Resultados Evaluación Consulta C4
A1 A2 A3 A4 A5 M C A P R F-s
D1 1 1 1 1 0 1 1 1 1,00 0,17 0,29
D2 1 1 1 1 0 1 2 2 1,00 0,33 0,50
D3 0 0 0 0 1 0 3 2 0,67 0,33 0,44
D4 1 1 0 1 1 1 4 3 0,75 0,50 0,60
D5 0 0 0 0 1 0 5 3 0,60 0,50 0,55
D6 1 1 1 1 1 1 6 4 0,67 0,67 0,67
D7 1 1 1 1 1 1 7 5 0,71 0,83 0,77
D8 0 0 0 0 1 0 8 5 0,63 0,83 0,71
D9 0 0 0 1 1 0 9 5 0,56 0,83 0,67
D10 1 0 0 1 1 1 10 6 0,60 1,00 0,75
Total 6 5 4 7 8 6
An: Arquitecto enésimo (n=1…5)
Dn: Documento enésimo (n=1…10)
M: Moda
C: Contador de documentos
A: Variable auxiliar para el cálculo de P y R
P: Precisión
R: Recall
F-s: F-score
Fuente: Elaboración propia.
La Ilustración 21 muestra el comportamiento de Precision obtenido en la evaluación de la
consulta C4 (Building microservices). Nótese la precisión no uniforme.
62
Ilustración 21. Gráfica de Precisión y Recall Interpolada para la Consulta C4
Fuente: Elaboración propia.
La Ilustración 22 muestra el comportamiento de F-score obtenido en la evaluación de la consulta
C4 (Building microservices). Nótese que, el rendimiento no es constante.
63
Ilustración 22. Gráfica de F-score para la Consulta C4
Fuente: Elaboración propia.
La Tabla 14 muestra los resultados de la evaluación de la consulta C5 (Manager services). Los
resultados muestran un valor final de precisión del 90% y de F-score del 95%
64
Tabla 14. Resultados Evaluación Consulta C5
A1 A2 A3 A4 A5 M C A P R F-s
D1 1 1 1 1 0 1 1 1 1,00 0,11 0,20
D2 1 1 1 1 0 1 2 2 1,00 0,22 0,36
D3 1 0 1 0 0 0 3 2 0,67 0,22 0,33
D4 1 0 1 1 0 1 4 3 0,75 0,33 0,46
D5 1 1 1 0 0 1 5 4 0,80 0,44 0,57
D6 1 1 1 1 1 1 6 5 0,83 0,56 0,67
D7 1 1 1 1 1 1 7 6 0,86 0,67 0,75
D8 1 1 1 0 1 1 8 7 0,88 0,78 0,82
D9 1 1 0 1 1 1 9 8 0,89 0,89 0,89
D10 1 1 0 1 1 1 10 9 0,90 1,00 0,95
10 8 8 7 5 9
An: Arquitecto enésimo (n=1…5)
Dn: Documento enésimo (n=1…10)
M: Moda
C: Contador de documentos
A: Variable auxiliar para el cálculo de P y R
P: Precisión
R: Recall
F-s: F-score
Fuente: Elaboración propia.
La Ilustración 23 muestra el comportamiento de Precisión obtenido en la evaluación de la
consulta C4 (Manager services). Nótese que al retornar el documento 3 la precisión empezó a
descender.
65
Ilustración 23. Gráfica de Precisión y Recall Interpolada para la Consulta C5
Fuente: Elaboración propia.
La Ilustración 24 muestra el comportamiento de F-score obtenido en la evaluación de la consulta
C5 (Manager services). Nótese que, el rendimiento casi perfecto.
0,00
0,20
0,40
0,60
0,80
1,00
1,20
0,00 0,20 0,40 0,60 0,80 1,00 1,20
Pre
cisi
on
Recall
C5
66
Ilustración 23. Gráfica de F-score para la Consulta C5
Fuente: Elaboración propia.
3.4.7 Análisis de Resultados.
A continuación, se relacionan los resultados consolidados de las medidas de Precisión y
Recall, y la medida F para cada una de las consultas. El promedio determina el rendimiento real
del Sistema.
Tabla 15. Resultados Consolidados de la Evaluación
C1 C2 C3 C4 C5 Media
Precisión 1,00 0,80 0,80 0,60 0,90 0,82
Recall 1,00 1,00 1,00 1,00 1,00 1,00
F-score 1,00 0,89 0,89 0,75 0,95 0,90
Fuente: Elaboración propia
67
Como primera aproximación a la evaluación se tomó con mayor importancia el valor de la
precisión frente al cálculo de la exhaustividad. Este dio un valor real de 0.82, lo cual es bastante
aceptable. Incrementando el número de las consultas (y por ende de las evaluaciones) se podría
llegar a un promedio más fino.
Cabe resaltar que las gráficas de Precisión, Recall y F-score de la Consulta C1 corresponden a
gráficas ideales, deseadas en todo sistema de recuperación. Esto se dio porque la mayoría de los
arquitectos coincidieron en calificar los diez documentos resultantes como relevantes. En la
inspección que se realizó sobre estos repositorios se encontró que en ellos se implementaban
diferentes formas de solucionar los problemas de persistencia que se pueden presentar en
proyectos de microservicios. Esto pudo influenciar (a favor) la calificación de los arquitectos.
La evaluación de la consulta C5 presenta un comportamiento muy similar a los resultados de la
consulta C1.
Los resultados obtenidos de la evaluación de las consultas C2 y C3 tuvieron comportamientos
bastante aceptables (rendimiento del 0,89). Se evidenció que, en los repositorios recuperados
para esta consulta, la decisión de utilizar la librería “spring-boot-starter-cloud-connectors” para
la conexión a servicios de la nube era bastante recurrente. Además, esta consulta retornó el
proyecto con mayor nivel de arquitectura (Arquitectura = 1.09%), es decir, el repositorio con
más decisiones de diseño arquitectónico tomadas para soluciones de microservicios de las 2010
decisiones recuperadas para la evaluación.
Los resultados más “pobres” corresponden a la consulta C4, para un rendimiento del 75%. En
esta evaluación se encontraron muchas decisiones que a pesar que fueron tomadas, nunca fueron
ejecutadas. Es decir, en la inspección de los repositorios no se encontró en el código fuente
evidencias de su utilización. Esto es una oportunidad de mejora que se podría tener en cuenta
para investigaciones futuras en aras de mejorar la confiabilidad del Sistema.
Se comprobó que efectivamente los repositorios con mejor “ranking”, los de mayor nivel de
arquitectura, fueron los proyectos mejor calificados por los arquitectos. Esto demuestra la
68
asertividad y efectividad en la utilización de dicho índice (dimensión de arquitectura) como
medida de ponderación de los resultados retornados por el sistema.
Como resultado final se encuentra que el Sistema presenta un rendimiento final del 90%. Los
resultados satisfacen en gran manera los intereses de los arquitectos. Las consultas planteadas
sobre asuntos de microservicios (persistencia, cloud, monitoreo, autonomía y construcción)
arrojaron proyectos reales con gran nivel de arquitectura que pueden ser muy útiles para apoyar
las decisiones futuras de los arquitectos y servir de base para sus implementaciones, cumpliendo
de esta manera el objetivo de la presente investigación.
69
4. CONCLUSIONES
Las decisiones de diseño arquitectónico son los elementos que conforman la arquitectura de un
Sistema. Dichas decisiones son tomadas por los arquitectos de TI basados en su conocimiento y
experiencia, que en muchos casos es poca cuando se trata de tecnologías emergentes como
microservicios. Nuestra investigación nos permitió evidenciar la existencia de decisiones de
diseño en repositorios de proyectos públicos que pueden ser recuperadas para apoyar las futuras
decisiones de diseño de los arquitectos de TI.
Este trabajo permite comparar diferentes modelos de decisiones para seleccionar el que más se
ajuste a los tipos de decisiones que se pueden recuperar en un repositorio público mediante un
sistema de recuperación de información.
Del mismo modo, con la perspectiva de Arquitectura Empresarial se logró construir un diseño de
arquitectura de solución que fuera acorde a las necesidades del arquitecto, es decir, que el diseño
se pudiera conectar con los requisitos del usuario, a través de elementos motivacionales como
“Meta”, “Principio” y “Requerimiento”; cubriendo de esta manera las brechas encontradas desde
el planteamiento de una arquitectura base hasta el diseño de la arquitectura objetivo.
Además, el diseño del sistema de recuperación planteado mostró un alto grado de
interoperabilidad con diferentes APIs (Rest) expuestos por repositorios públicos para acceder a la
información disponible en ellos por medio de componentes de captura de información (Crawler).
A pesar que en el sistema desarrollado se implementó un componente para captura de
información en el dominio microservicios, el diseño de arquitectura propuesto permite ser
70
extendido a otros dominios, lo que potencia su uso en otros contextos de tecnologías y técnicas
de desarrollo de software.
Cabe resaltar que el índice de arquitectura propuesto para este proyecto demostró un alto nivel de
asertividad y efectividad, ya que los repositorios con mayor nivel de arquitectura fueron los
mejor calificados por parte de los arquitectos. Esto muestra la relación que existe entre la
Arquitectura y los Sistema de Recuperación de Información que busca nuestra investigación,
permitiendo lograr un nuevo y mayor grado de aplicabilidad y usabilidad sobre los sistemas de
recuperación convencionales.
Por otro lado, la subjetividad es un problema que está siempre presente a la hora de medir el
rendimiento de todo sistema de recuperación. Esto se intentó reducir, escogiendo un grupo de
arquitectos con perfiles más o menos homogéneos, con experiencias laborales y académica
cercanas.
Por último, se concluye que se dan por cumplidos los objetivos propuestos por la investigación,
que permitieron diseñar un sistema de recuperación de información arquitectónica aprovechando
las experiencias tácitas inherentes en los proyectos alojados en repositorios públicos, todo esto
con el fin de apoyar a los arquitectos para la toma de decisiones oportuna en el proceso de diseño
de soluciones.
De la misma manera, resaltar que gracias a la guía recibida por cada uno de los docentes de la
Maestría en Ingeniería de Software se afianzaron y fortalecieron algunos conocimientos previos
y se generaron nuevos aprendizajes que han logrado un crecimiento profesional, debido a que se
cuenta con nuevas herramientas que permiten afrontar los retos futuros desde una óptica
diferente.
71
5. TRABAJOS FUTUROS
Este sistema diseñado tiene conectores (clientes) para acceder a los repositorios de GitHub y el
repositorio central de Maven, sin embargo, sería interesante minar de alguna manera contenido
no estructurado como el ofrecido por plataformas como “Stack Overflow”, ya que son sistemas
ampliamente utilizados por las comunidades de arquitectos y desarrolladores en el mundo y
podrían tener información valiosísima susceptible de ser recuperada.
Del mismo modo el componente de Microservicios es un componente que puede ser extendido a
otro tipo de soluciones de TI como por ejemplo a DevOps, que es una nueva tendencia que busca
mejorar la rapidez organizacional gracias a un conjunto de filosofías, herramientas y practicas
inherentes al proceso de desarrollo, para de esta manera encontrar otro tipo de decisiones en los
repositorios que no sean meramente tecnológicas.
A pesar de que el documento POM de los repositorios recuperados son artefactos que evidencian
rica información arquitectónica de los proyectos, vale la pena revisar otros tipos de artefactos (y
sus relaciones) que estén presentes en el código fuente expuesto de dichos proyectos, todo esto
con el fin de extender el modelo de decisiones a la representación de otro tipo de información.
72
6. REFERENCIAS BIBLIOGRÀFICAS
Boer, R.C., Farenhorst, R., Lago, P., Vliet , H. v., Clerc, V., and Jansen, A (2007). Architectural
knowledge: Getting to the Core. In the Quality of Software-Architectures (QoSA), 197-21.
Bosch, J. (2004). Software architecture: The next step. In: Oquendo, F., Warboys, B., Morrison,
R. (eds.) Software Architecture, First European Workshop (EWSA), pp. 194–199.
Springer, Heidelberg, LNCS 3047.
Capilla R., Jansen, A., Tang A., Avgeriou P., Babar Muhammad, A. (2016). 10 years of Software
Architecture Knowledge Management: Practice and Future.
Capilla, R., Nava, F. y Dueñas, J.C. (2007). Modeling and documenting the evolution of
architectural design decisions. In: 2nd Workshop on Sharing and Reusing architectural
Knowledge – Architecture, rationale, and Design Intent (SHARK/ADI), 9.
Clements, P., Garlan, D., Bass, L., Stafford, J. (2011). "Documenting software architectures: views
and beyond" 2nd Editio. Pearson Education.
David R. Cheriton School of Computer Science, University of Waterloo, 200 University Avenue
West, Waterloo, Ontario, Canada N2L 3G18
Dueñas, J.C., Capilla, R. (2005). The decision view of software architecture. In: Morison, R.,
Oquendo, F. (2ª ed.) 2nd European Workshop on Software Architecture. Pisa, Italy
Georgios Gousios and Diomidis Spinellis (2013). GHTorrent:Github’sDatafromaFirehose
Department of Management Science and Technology Athens University of Economics and
Business Athens, Greece
González, J (2014). Derivación, Evaluación y Mejora de la Calidad de Arquitecturas Software en
el Desarrollo de Líneas de Producto Software Dirigido por Modelos. Universitat Politècnica
de València (UPV). Valencia. España.
Harrison, N.B., Avgeriou, P., and Zdun, U. (2007). IEEE Software, 24(4), 38-45.
ISO (2011). "ISO / IEC / IEEE 42010:2011 Systems and software engineering".
Jansen, A., Bosch, J. (2005). Software architecture as a set of architectural design decisions. In:
Proceedings of the 5th IEEE/IFIP Working Conference on Software Architecture (WICSA),
IEEE Computer Society 109-119.
J. Loeliger (Jun 2009),Versioncontrol with Git:PowerfulToolsandTechniques for Collaborative
Software Development. Sebastopol, CA: O’Reilly Media.
73
Josey, A. Hofmman, P, Rouse, M. (2013). TOGAF, V.9.1, Van Harren Publishing. Reino Unido.
Jansen, A., and Bosch, J. (2005), Software Architecture as a Set of Architectural Design Decisions,
Proceedings of 5th Working IEEE/IFIP Conference on Software Architecture (WICSA),
109-120.
Kruchten, P., Lago, P., van Vliet, H. (2004) Building up and Reasoning about Architectural
Knowledge. In: C. Hofmeister, I. Crnkovic, R. Reussner (eds.) Quality of Software
Architectures,Proceedings 2nd International Conference, LNCS.
Kruchten, P. (1995). "Architectural Blueprints — The “ 4 + 1 ” View Model of Software
Architecture". IEEE Software, 12(11), 42-50
Kruchten, P. (2004). An Ontology of Architectural Design Deciions in Software-Intensive Systems.
In: 2nd Groningen Workshop on Software Variability Management. Groningen, The
Netherlands.
Kruchten, P. (2004). An Ontology of Architectural Design Deciions in Software-Intensive Systems.
In: 2nd Groningen Workshop on Software Variability Management. Groningen, The
Netherlands.
Kruchten, P., Lago, P., van Vliet, H. (2006). Building up and Reasoning about Architectural
Knowledge. In: C. Hofmeister, I. Crnkovic, R. Reussner (eds.) Quality of Software Architectures,
Proceedings 2nd International Conference, LNCS, 4214, 43-58.
Kruchten, P., Lago, P., van Vliet, H. (2006). Building up and Reasoning about Architectural
Knowledge. In: C. Hofmeister, I. Crnkovic, R. Reussner (eds.) Quality of Software
Architectures, Proceedings. 2nd International Conference, LNCS, 4214, 43-58.
Kruchten, P (2009), Software Architecture knowledge management. Springer. New York.
Shaw, M., Garlan, D. (1996). "Software Architecture: Perspectives on an Emerging
Discipline". Prentice Hall, Upper Saddle River: New Jersey, USA.
Kruchten, P., An Ontology of Architectural Design Decisions in Software-Intensive Systems,
Proceedings 2nd Groningen Workshop on Software Variability Management, Groningen,
pages 109-119, 2004.
M. Shahin, P. Liang, and M.R. Khayyambashi, A Survey of Architectural Design Decision Models
and Tools, Technical Report SBU-RUG-2009-SL-01, Sheikh Bahaei University &
University of Groningen, 2009.
74
Mojtaba Shahin, Peng Liang, Mohammad Reza Khayyambashi (2009). A Survey of Architectural
Design Decision Models and Tools.
Tang, A., Han, J., and Vasa, R. (2009). Software Architecture Design Reasoning: A Case for
Improves Methodology Support. IEEE Software, 26(2), 43-49.
Nuthan Munaiah, Steven Kroh, Craig Cabrey, and Meiyappan Nagappan (2016)
Curating GitHub for Engineered Software1 Projects Department of Software Engineering,
Rochester Institute of Technology, 134 Lomb5 Memorial Drive, Rochester, NY, USA
146236
O'Reilly Media, (2015). Building Microservices. (1a ed.). Microservices Architecture Enables
DevOps: An Experience Report on Migration to a Cloud-Native Architecture
Paul Clements Felix Bachmann Len Bass David Garlan James Ivers Reed Little Paulo Merson
Robert Nord Judith Stafford 2010 Documenting Software Architectures Views and Beyond
- Addison Wesley – SEI
Sandvine 2016 global-internet-phenomena-report-latin-america-and-north-america
Tang, A., Babar, A.M., Gorton, I., Han, J. (2005). A Survey of the Use and Documentation of
Architecture Design Rationale. In: Proceedings 5th Working IEEE/IFIP Conference on
Software Architecture (WICSA5), pp. 89–98. IEEE Computer Society.
Tyree, J. & Akerman, A. (2005) Architecture Decisions: Demystifying Architecture. IEEE Softw,
22 (2), 19-27
Thones, J. (2015). Microservices Software engineering –IEEE Computer Society - Patterns of
Enterprise Application Architecture (1a ed.) by Martin Fowler (Author).
Van der Ven, J. S. & Bosch, J. (2013) Architecture Decisions: Who, How and When?. In: To be
published in: ASA, Agile Software Architectures.
Recommended