Sistema de Recuperación de Decisiones de Diseño de ...

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

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

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

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 18. Gráfica F-Score y Recall para la Consulta C2…..……………………………….57


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




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


- 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.

25

Ilustración 4. Diagrama de Motivación


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


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


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.


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


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)


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


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


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.


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.


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.


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


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


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.

http://vortexbird.com/

46

PERFIL ARQUITECTO B

Empresa Instituto de Desarrollo Urbano

https://www.idu.gov.co/

Bogotá D.C.

Cargo Arquitecto Empresarial


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


Bogotá D.C.

Cargo Arquitecto de Software


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


Perfil Ingeniero de Sistemas, Especialista en Gerencia de Proyecto Cursando

Master, experiencia en desarrollo web, backend y BD



http://www.dane.gov.co/

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


48

3.4.4 Medidas de evaluación.

Ilustración 14. Conjunto de Documentos Recuperados


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.


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


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


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


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


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



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



M: Moda



P: Precisión

R: Recall

F-s: F-score


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




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


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



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



M: Moda



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




C3 (Service config). Nótese que, a pesar de la decaída en la precisión, el rendimiento logra

mantenerse.

60



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



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



M: Moda



P: Precisión

R: Recall

F-s: F-score


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




C4 (Building microservices). Nótese que, el rendimiento no es constante.

63



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



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



M: Moda



P: Precisión

R: Recall

F-s: F-score


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




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



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


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.

Sistema de Recuperación de Decisiones de Diseño de ...

Documents

Transcript of Sistema de Recuperación de Decisiones de Diseño de ...