un enfoque para visualizar oportunidades de refactoring en

Un Enfoque para Visualizar Oportunidades de Refactoring en Aplicaciones SOA

TRABAJO FINAL DE LA CARRERA INGENIERÍA DE SISTEMAS

Director: Dr. Guillermo Rodríguez

Co-Director: Dr. Alfredo Teyseyre

Alumnos: Emanuel Fernández, Martín Vizzolini

Tandil, 2016

Indice

Índice de Ilustraciones ................................ 6

Índice de Tablas ................................ 10

Resumen ................................ 12

1 Introducción ................................ 14

1.1 Cuál es la motivación detrás de este enfoque? ................................ 15

1.2 Solución Propuesta ................................ 16

1.3 Objetivos a cumplir con la realización del enfoque propuesto ................................ 16

1.4 Esquema general del presente documento ................................ 17

2 Marco Teórico ................................ 18

2.1 Arquitectura Orientada a Servicios (SOA) ................................ 18

2.1.1 Orígenes de SOA ................................ 19

2.1.2 Problemas que se intentan resolver con SOA ................................ 22

2.1.3 Definición de un Servicio dentro de SOA ................................ 22

2.1.3.1 SOAP Simple Object Access Protocol ................................ 25

2.2 Especificación de documentos WSDL ................................ 25

2.2.1 Estructura de un documento WSDL ................................ 26

2.2.2 Extensibilidad del lenguaje y binding ................................ 31

2.2.3 Antipatrones en WSDLs ................................ 31

2.3 Refactorización ................................ 36

2.3.1 Por qué se debe refactorizar el código? ................................ 36

2.3.2 Puntos que necesitan refactorización ................................ 37

2.3.3 Refactorización utilizando técnicas de IA ................................ 38

2.4 Clusters y técnicas de clustering ................................ 39

2.4.1 Métodos de Particionamiento ................................ 40

2.4.1.1 Kmeans ................................ 40

2.4.1.2 ExpectationMaximization (EM) ................................ 43

2.4.2 Algoritmos jerárquicos ................................ 44

2.5 Visualización de datos ................................ 47

2.5.1 Edge Bundles (Radial layout) ................................ 48

2.5.2 Tree layout ................................ 49

2.5.3 Layout mixto ................................ 49

Conclusiones ................................ 50

3 Trabajos Relacionados ................................ 52

3.1 Resaltadores de sintaxis ................................ 52

2

3.2 Visualizador de WSDL ................................ 54

3.3 WSDL Analyzer ................................ 57

3.4 SoapUI Pro WSDL Refactoring ................................ 61

3.5 Antipattern detector ................................ 62

3.6

Enfoques de clusterización con técnicas de minería de datos aplicados a

servicios web ................................ 63

3.6.1 Web service clustering using text mining techniques ................................ 63

3.6.2 Efficiently Finding Web Services Using a Clustering Semantic Approach ................................ 64

3.6.3 Clustering WSDL Documents to Bootstrap the Discovery of Web Services ................................ 65

3.6.4 Similarity Search for Web Services ................................ 66

3.7 Semantic clustering: Identifying topics in source code ................................ 66

3.8 Comparación de los trabajos relacionados ................................ 67

Conclusiones ................................ 71

4

Enfoque para Visualizar Oportunidades de Refactoring en Aplicaciones

SOA ................................ 72

4.1 Descripción del enfoque ................................ 72

4.1.1 Opciones de similitud mínima y máxima total de clusters ................................ 74

4.1.2 Panel de opciones ................................ 74

4.1.2.1 Botón More Info ................................ 76

4.1.2.2 Botón Show <nombre del archivo>.wsdl ................................ 78

4.1.3 Panel principal ................................ 79

4.1.4 Menú ................................ 79

4.1.5 Panel de algoritmos de agrupamiento ................................ 80

4.1.6 Gráficos del Panel principal ................................ 80

Conclusiones ................................ 82

5 Diseño e implementación ................................ 84

5.1 Requerimientos funcionales ................................ 84

5.2 Tecnologías utilizadas ................................ 85

5.3 Diseño del enfoque propuesto ................................ 86

5.3.1 Arquitectura del sistema ................................ 86

Vista estática del servidor ................................ 86

Vista dinámica del servidor ................................ 87

Escenario de calidad 1 ................................ 88



5.3.2 Diseño Detallado ................................ 92

Componente Apdetector ................................ 92

Componente ServiceClusterer ................................ 92

3

Componente ModelViewController ................................ 94

Conclusiones ................................ 95

6 Resultados experimentales ................................ 96

6.1 Técnicas de validación de clusters ................................ 96

6.1.1 Enfoque no supervisado ................................ 96

6.2 Presentación de las evaluaciones realizadas al enfoque no supervisado ................................ 98

6.3 Presentación del primer caso de estudio ................................ 98

6.3.1

Ejecución de los diferentes algoritmos de clustering para el primer caso

de estudio ................................ 99

6.3.1.1 Ejecución algoritmo jerárquico ................................ 99

6.3.1.2 Ejecución algoritmo KMeans ................................ 100

6.3.1.2.1 Análisis del gráfico Rotate Cluster Layout ................................ 101

6.3.1.3 Ejecución algoritmo Expectation Maximization ................................ 102

6.3.1.3.1 Análisis del gráfico Rotate Cluster Layout ................................ 103

6.3.1.4 Conclusiones ................................ 104

6.3.2 Antipatterns para el primer caso de estudio ................................ 105

6.4 Presentación del segundo caso de estudio ................................ 106

6.4.2

Ejecución de los diferentes algoritmos de clustering para el segundo caso

de estudio ................................ 107

6.4.2.1 Ejecución algoritmo jerárquico ................................ 108

6.4.2.2 Ejecución del algoritmo KMeans ................................ 108

6.4.2.3 Ejecución del algoritmo Expectation Maximization ................................ 109

6.4.2.5 Conclusiones ................................ 109

6.4.4 Antipatterns para el segundo caso de estudio ................................ 110

6.5 Comparación resultados manuales vs no supervisados ................................ 111

6.5.1 Descripción del enfoque manual utilizado ................................ 111

6.5.1.1 Criterio de refactorización utilizado en el enfoque manual ................................ 111

6.5.1.2 Oportunidades de refactoring encontradas utilizando el enfoque manual ................................ 111

6.5.1.3 Resultados obtenidos utilizado el enfoque manual ................................ 115

6.5.2

Comparación de oportunidades de refactoring detectadas en cada

enfoque ................................ 116

Conclusiones ................................ 120

7 Conclusiones y Trabajos Futuros ................................ 122

7.1 Conclusiones ................................ 122

7.2 Ventajas de la herramienta ................................ 123

7.3 Limitaciones de la herramienta y trabajos futuros ................................ 123

Bibliografía ................................ 126

4

Índice de Ilustraciones Figura 2.1: Esquema general arquitectura SOA ...................................... 18

Figura 2.2: Evolución de las arquitecturas en el tiempo ...................................... 19

Figura 2.3: Colaboraciones en SOA ...................................... 21

Figura 2.4: Vista de capas de las tecnologías utilizadas en servicios web ...................................... 23

Figura 2.5: Estructura de un documento con formato WSDL ...................................... 26

Figura 2.6: Segmento de t ypes ...................................... 27

Figura 2.7: Segmento de message ...................................... 27

Figura 2.8: Segmento de portType ...................................... 28

Figura 2.9: Patrones de operación en WSDL ...................................... 29

Figura 2.10: Segmento de binding ...................................... 29

Figura 2.11: Segmento de service ...................................... 30

Figura 2.12: estado inicial del algoritmo k means ...................................... 41

Figura 2.13: paso 2 del algoritmo k means ...................................... 41

Figura 2.14: paso 3 del algoritmo kmeans ...................................... 41

Figura 2.15: Convergencia del algoritmo kmeans ...................................... 42

Figura 2.16: EM paso 1 ...................................... 43

Figura 2.17: EM paso 2 ...................................... 43

Figura 2.18: EM paso 3 ...................................... 44

Figura 2.19: EM paso 4. Convergencia ...................................... 44

Figura 2.20: Edge bundle ...................................... 48

Figura 2.21: Tree layout ...................................... 49

Figura 2.22: radial cluster layout (Layout mixto) ...................................... 50

Figura 3.1: Visualización de un contrato WSDL en Eclipse con WTP ...................................... 53

Figura 3.2: Visualización de un contrato WSDL Editor en Eclipse con

WTP ...................................... 54

Figura 3.3: Visualización de un contrato WSDL en Vanek 1er porción ...................................... 55

Figura 3.4: Visualización de un contrato WSDL en Vanek 2da porción ...................................... 56

Figura 3.5: Visualización de un contrato WSDL en Vanek 3er porción ...................................... 56

Figura 3.6: Visualización de un contrato WSDL en WA. Información

general ...................................... 58

Figura 3.7: Visualización de un contrato WSDL en WA. Reporte general ...................................... 58

Figura 3.8: Visualización de un contrato WSDL en WA. Namespaces ...................................... 58

Figura 3.9: Visualización de un contrato WSDL en WA. Reporte de las

versiones ...................................... 59

6

Figura 3.10: Visualización de un contrato WSDL en WA. Schemas

referenciados ...................................... 59

Figura 3.11: Visualización de un contrato WSDL en WA. PortTypes ...................................... 59

Figura 3.12: Visualización de un contrato WSDL en WA. Bindings ...................................... 60

Figura 3.13: Visualización de un contrato WSDL en WA. Servicios ...................................... 60

Figura 3.14: Esquemático de Clustering WSDL Documents to Bootstrap

the Discovery of Web Services ...................................... 65

Figura 3.15: Mapa de distribución de los clusters semánticos sobre la

estructura de paquetes del programa JEdit ...................................... 67

Figura 4.1: Diagrama general de la arquitectura ...................................... 73

Figura 4.2: MockUp de la aplicación ...................................... 73

Figura 4.3: Opciones de similitud y total de clusters ...................................... 74

Figura 4.4: Panel de opciones (Files activado) ...................................... 75

Figura 4.5: Panel de opciones (Files activado) con archivos importados ...................................... 75

Figura 4.6: Información general del servicio ...................................... 75

Figura 4.7: Servicios definidos en el contrato ...................................... 75

Figura 4.8: Anti patrones detectados en un contrato ...................................... 75

Figura 4.9: Anti patrones detectados vs soluciones propuestas ...................................... 76

Figura 4.10: Estadísticas de anti patrones en un contrato ...................................... 76

Figura 4.11: Popup para el botón more info, sección input ...................................... 77

Figura 4.12: Popup para el botón More Info, sección output ...................................... 78

Figura 4.13: Popup para el botón More Info, sección output ...................................... 79

Figura 4.14: Panel principal ...................................... 79

Figura 4.15 : Gráficos soportados por la aplicación ...................................... 80

Figura 4.16 Inverted Radial Layout ...................................... 81

Figura 4.17 Bundle Layout ...................................... 81

Figura 4.18 Tree Layout ...................................... 81

Figura 4.19 Rotate Cluster Layout ...................................... 81

Figura 4.20 : Collapse Tree Layout ...................................... 82

Figura 5.1: Diagrama general de la arquitectura. ...................................... 86

Figura 5.2: Diagrama de componentes ...................................... 87

Figura 5.3: Use case map Escenario de calidad 1 ...................................... 89



Figura 5.6: diseño detallado Ap detector app ...................................... 92

Figura 5.7: diseño detallado ServiceClusterer app ...................................... 93

Figura 5.8: diseño detallado ModelViewController ...................................... 94

Figura 6.1: Diagrama de distancias inter e intra cluster ...................................... 97

7

Figura 6.2: Caso de estudio 1, cantidad de líneas de código ...................................... 99

Figura 6.3: Caso de estudio 1 Rotate Cluster Layout K Means con 17 clusters ...................................... 102

Figura 6.4: Caso de estudio 1 Rotate Cluster Layout EM con 17 clusters ...................................... 103

Figura 6.5: Caso de estudio 1, cantidad de Antipatrones detectados y

soluciones propuestas ...................................... 105

Figura 6.6: Caso de estudio 1, porcentaje de cada antipatrón detectado ...................................... 105

Figura 6.7: Caso de estudio 2, cantidad de líneas de código ...................................... 107

Figura 6.8: Caso de estudio 2, cantidad de Antipatrones detectados y

soluciones propuestas ...................................... 110

Figura 6.9: Caso de estudio 2, porcentaje de cada antipatrón detectado ...................................... 110

8

Índice de tablas

Tabla 2.1: Comparación componentes vs servicios web ..................................... 24

Tabla 2.2: Ventajas y desventajas del algoritmo k means ..................................... 42

Tabla 3.1: Escala de evaluación de las características de las

herramientas ..................................... 68

Tabla 3.2: comparativa de las herramientas mencionadas con las

respectivas características ponderadas ..................................... 68

Tabla 6.1: Cantidad de clusters calculados por el algoritmo

jerárquico ..................................... 100

Tabla 6.2: Métricas calculadas para el algoritmo jerárquico

utilizando RStudio ..................................... 100

Tabla 6.3: Métricas calculadas para el algoritmo K Means ..................................... 100

Tabla 6.4: Métricas calculadas para el algoritmo KMeans

utilizando RStudio ..................................... 101

Tabla 6.5: Métricas calculadas para el algoritmo

ExpectationMaximization ..................................... 102

Tabla 6.6: Comparativa de métricas calculadas ..................................... 104


jerárquico ..................................... 108

Tabla 6.8: Métricas para el algoritmo jerárquico utilizando R

Studio ..................................... 108


KMeans ..................................... 108

Tabla 6.10: Métricas calculadas para el algoritmo K Means con R

Studio ..................................... 109

Tabla 6.11: Cantidad de clusters calculados por el algoritmo EM ..................................... 109

Tabla 6.12: Comparativa de métricas calculadas ..................................... 109

Tabla 6.13: lista de refactorizaciones por semántica ..................................... 115

Tabla 6.14: Duración del proceso de refactorización divido en

etapas ..................................... 115

Tabla 6.15: Oportunidades de refactorización, enfoque

automático ..................................... 119

Tabla 6.16: Comparación resultados manual vs no supervisado ..................................... 120

10

Resumen

El rápido avance de las tecnologías informáticas, junto con la necesidad de crear sistemas accesibles por usuarios y a su vez por otros sistemas, fomentó el desarrollo de aplicaciones con una arquitectura orientada a servicios. Dicha arquitectura otorga, entre varias cosas, la facilidad y la flexibilidad a la integración con sistemas ya existentes y también la agilidad de adaptarse a la demanda y a los rápidos cambios en las reglas de negocio. La necesidad de actualizar, mantener y refactorizar sistemas ya existentes se ve fuertemente impulsada gracias al mencionado avance tecnológico y a los rápidos cambios en las reglas de negocio, lo cual a su vez, genera la necesidad de refactorizar sistemas ya existentes.

En el presente trabajo, en primer instancia se introduce un enfoque para detectar de forma automática, oportunidades de refactoring en aplicaciones con arquitectura orientada a servicios. Para ello se plantean dos perspectivas generales, por un lado la utilización de técnicas de minería de datos para sugerir potenciales refactorizaciones de los contratos que describen los servicios del sistema y por el otro la detección de antipatrones en la definición de dichos contratos.

Luego de discutir los fundamentos de las dos perspectivas descritas anteriormente, se detalla el proceso de diseño e implementación de una herramienta web para la detección de oportunidades de refactorización haciendo especial énfasis en la visualización de las mismas. Se incluyeron técnicas de visualización como por ejemplo “Bundle Layouts”, “Inverted Radial Layout” entre otras, las cuales favorecen la rápida detección de relaciones entre los servicios web descritos en los contratos analizados por la herramienta. Finalmente se agregaronmódulos para visualizar los contratos WSDL analizados y también para la fácil visualización, interpretación y posterior corrección de los antipatrones.

Para validar el enfoque propuesto, primeramente se tomaron dos sistemas existentes y se analizaron las definiciones de los contratos para cada servicio provisto en ambos sistemas. Se describen las oportunidades de refactorización encontradas haciendo especial hincapié en el tiempo que llevó realizar dicho análisis y también se detallan los antipatrones detectados en la definición de los contratos de cada servicio. Finalmente se realizó la comparación del relevamiento y búsqueda manual de oportunidades de refactorización contra los resultados arrojados por el enfoque aquí propuesto haciendo énfasis en la cantidad y la calidad de oportunidades de refactorización encontradas por la técnica manual contra la técnica automatizada y el tiempo que se tomó para llevar a cabo cada enfoque.

12

1. Introducción

Actualmente, en la industria del software es muy común encontrar sistemas implementados con el paradigma de Computación Orientados a Servicios, de sus siglas en inglés SOC. Estos sistemas se construyen en base al estilo arquitectónico denominado ServiceOriented Architecture (SOA). Las soluciones SOA han sido creadas para satisfacer los objetivos de negocio, los cuales incluyen facilidad y flexibilidad de integración con sistemas legados, alineación directa a los procesos de negocio reduciendo costos de implementación, innovación de servicios a clientes y una adaptación ágil ante cambios incluyendo reacción temprana ante la competitividad, entre otros. Estas son algunas de las razones por las cuales los sistemas SOA son tan comunes a la hora de producir soluciones de software. Técnicamente, en un contexto SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayoría de las definiciones de SOA identifican la utilización de servicios web empleando SOAP (Simple Object 1

Access Protocol) y WSDL en su implementación. Es decir que simplemente los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios los solicitan llamándolos a través de la Web utilizando dichos procedimientos. La manera de definir estas relaciones es a través de WSDL Web Service Description Language [Bartolini, 2008].

WSDL es entonces, un lenguaje de interfaz de descripción basado en XML (Extensible Markup Language), que se utiliza para describir la funcionalidad ofrecida por un servicio web. Una descripción WSDL de un servicio web provee una descripción interpretable por una computadora de cómo el servicio se puede llamar, qué parámetros espera y qué estructura de datos devuelve como respuesta, entre otras características. Es decir que, a través de una descripción en WSDL, es posible definir las diferentes relaciones entre servicios web, así como también, la jerarquía de los mismos. Un programa cliente que se conecta a un servicio web puede leer el WSDL para determinar qué funciones están disponibles en el servidor. Los tipos de datos especiales se incluyen en el archivo WSDL en forma de XML. El cliente puede usar SOAP para hacer la llamada a una de las funciones listadas en el WSDL.

1 Es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Se detallará el tema en el capítulo 2.

14

Finalmente, las aplicaciones SOA como cualquier otra aplicación de software, requieren mantenimiento por parte de los desarrolladores lo cual contribuye fuertemente a la evolución del sistema. Parte de este mantenimiento consiste en el refactoring (o refactorización) de código.

1.1 Cuál es la motivación detrás de este enfoque?

Cuando se está analizando un sistema de software previamente desarrollado, o cuando se está desarrollando uno nuevo, es común encontrar o diagramar cambios en el sistema debido a que no se seguían buenas prácticas, no se había notado el uso de antipatrones, se pretendemigrar a otra tecnología o simplemente el sistema se estaba quedando obsoleto y las prácticas de diseño y desarrollo han evolucionado permitiendo practicar la refactorización.

La refactorización de software entonces, es el proceso de reestructurar código existente de un sistema sin cambiar su comportamiento para el exterior, es decir, sin modificar la funcionalidad que le aporta al usuario final. Es una práctica que se utiliza constantemente en el ciclo de vida de una aplicación. La refactorización mejora los atributos de calidad no funcionales de software tales como la legibilidad del código, decrementa la complejidad y esto mejora sumantenibilidad [Fowler, 2002].

Se quiere refactorizar un sistema SOA utilizando y analizando los contratosWSDL que posee el mismo. Los archivos de WSDL suelen ser extensos y requieren de una lectura muy meticulosa, ya que se basan en XML, lo cual puede ser arduo, tedioso y conducir a no distinguir posibles oportunidades de refactoring o más preocupante aún, no detectar errores en la arquitectura y código del sistema producto de haber utilizado antipatrones. En este contexto, existen técnicas de clustering y visualización que apuntan a solucionar o aliviar la problemática mencionada anteriormente, y de esta manera, facilitar la tarea de los desarrolladores a la hora de detectar oportunidades para refactoring. Dichas técnicas se abordarán en próximos capítulos.

Los algoritmos de clustering identifican de forma automática agrupaciones o clusters de elementos de acuerdo a unamedida de similitud entre ellos. Representar los datos mediante una serie de clusters, conduce a la pérdida de detalles, pero consigue la simplificación de los mismos. En cuanto a las estrategias de visualización de WSDL, las estrategias actuales no están preparadas para manejar las diferentes relaciones entre los datos asociados llevando así a una posible confusión visual, ineficiente, y en muchos casos, inentendible.

Habiendo observado y analizado en particular servicios webs descritos en el lenguajeWSDL, se hizo imperante la necesidad de poder visualizar el gran caudal de información que se puede obtener o deducir de un conjunto de archivos WSDL, obviamente describiendo varios servicios web necesarios o utilizados por alguna aplicación SOA.

Por último y no menos importante, se ha tenido la necesidad demigrar aplicaciones construidas en tecnologías casi obsoletas o sin soporte hace varios años, hacia una tecnología actual o emergente. Aquí surge el problema de poder ver y analizar la arquitectura del sistema enfocándose en los servicios web. Existen herramientas con las cuales se pueden obtener la descripción de los servicios web en lenguaje WSDL, pero lo que está más acotado es la

15

generación de información a partir de dichos servicios en una manera más gráfica y cognitiva potenciando así la migración o el refactoring realizado por los programadores.

1.2 Solución Propuesta

Se realizó una investigación y se concluyó que actualmente existen escasas alternativas para asistir a los desarrolladores de software para detectar oportunidades de refactoring o simplemente obtener información de un conjunto de WSDL que especifican un sistema con arquitectura SOA. Esto motivó a plantear la construcción de una herramienta que tome como punto de partida los archivos WSDL y pueda brindar como salida un conjunto de gráficos y diagramas, que enriquezcan la información que se obtiene de los archivosWSDL, demanera de poder potenciar el uso de los mismos no sólo mediante la utilización de los WSDL a través de software, sino también como información para sustentar la toma de decisiones, por ejemplo, a la hora de refactorizar, extender el sistema existente o migrar el mismo a otra plataforma.

1.3 Objetivos a cumplir con la realización del enfoque propuesto

El objetivo principal es proponer un enfoque de visualización de software basado en aprendizaje no supervisado para asistir a los arquitectos/desarrolladores de software en la detección de oportunidades de refactoring en aplicaciones SOA ya que se analizan los contratos descritos en WSDL de la aplicaciones a evaluar con el fin de proponer algunamejora si hay lugar para ello, de manera de asistir el diseño de dichos contratos para que luego se pueda proceder con su implementación y lograr un producto final más robusto y mejor diseñado. Se pretende lograr una herramienta web, capaz de tomar como entrada diferentes archivos en formato WSDL, ya sea de un sistema completo o de un subconjunto de servicios web del sistema, realizar un análisis y proveer así de distintos gráficos mostrando los datos que se sustrajeron de las relaciones y jerarquías de los diferentes servicios definidos en los archivos.

La herramienta será capaz de graficar, entre otras cosas, relaciones entre los diferentes servicios web a través de una estrategia de visualización basada en relaciones de estos servicios y la abstracción jerárquica de los mismos.

Cabe destacar que los antipatrones que se pretenden detectar son aquellos a los que se podría llamar evidentes, es decir aquellos que pueden ser detectados sólo con analizar el contenido sintáctico o estructural de los WSDL [Rodríguez, 2010]. Los antipatrones que se pueden denominar no evidentes, es decir aquellos de los cuales se necesita además un análisis semántico no serán abordados por nuestro enfoque, dejando así la posibilidad a una futura extensión o mejora del mismo.

Se utilizará el enfoque implementado y desarrollado por integrantes delISISTAN, el cual detecta

antipatrones en WSDL. Los antipatrones muestran formas de enfrentarse a problemas con consecuencias negativas conocidas. Se basan en la idea de que puede resultar más fácil detectar a priori fallos en el desarrollo del proyecto, o descartar las alternativas incorrectas para ayudar a la elección de una mejor alternativa.

16

1.4 Esquema general del presente documento

El resto del informe está organizado de la siguiente manera. En el capítulo 2 se realiza la introducción al marco teórico necesario para comprender el enfoque del presente trabajo, el cual comprende los temas de Arquitectura Orientada a Servicios, Protocolo de comunicación SOAP, lenguaje de descripción de servicios web WSDL, clusters y técnicas de clustering, refactoring y visualización de datos. En el capítulo 3 se detallan, analizan y clasifican los trabajos relacionados. En el capítulo 4 se presenta el enfoque del trabajo, su descripción y un ejemplo base para complementar la explicación del enfoque. En el capítulo 5 se detalla el diseño arquitectónico, la implementación y la información que presenta la herramienta. En el capítulo 6 se presentan resultados experimentales, descripción de las métricas a utilizar y la evaluación de casos concretos. Finalmente en el capítulo 7 además de las conclusiones se detallan ventajas y desventajas del enfoque, limitaciones y trabajos futuros que se puedan realizar.

17

2. Marco Teórico

Previamente se mencionaron conceptos utilizados en el desarrollo de software como servicios web, SOA, clusters y clustering, la especificación de servicios webs en formato WSDL, etc. A continuación se abordará el marco teórico de cada concepto necesario para comprender la relación entre ellos y también su relación con el enfoque de la propuesta.

2.1 Arquitectura Orientada a Servicios (SOA)

La Arquitectura Orientada a Servicios es un paradigma de arquitectura para diseñar y desarrollar sistemas distribuidos. Las soluciones SOA han sido creadas para satisfacer los objetivos de negocio los cuales incluyen en la facilidad y la flexibilidad de integración con sistemas legados ó existentes, alineación directa a los procesos de negocio reduciendo costos de implementación, innovación de servicios a clientes y una adaptación ágil ante cambios. Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios.

Figura 2.1: Esquema general arquitectura SOA.

En la figura 2.1 se puede ver el esquema general de la arquitectura SOA donde se sigue el paradigma de descubrir, publicar, linkear e invocar. La idea es consultar un registro de servicios donde se listan todos los servicios existentes y tomar los servicios deseados demanera de que el

18

consumidor conectándose al proveedor mediante las interfaces provistas por los contratos, utilice los servicios deseados.

2.1.1 Orígenes de SOA

Los sistemas IT han evolucionado exponencialmente, lo cual se ha transmitido en un crecimiento de la complejidad del software de las empresas. Las tecnologías tradicionales han alcanzado su límite de capacidad y en las empresas cada vez se pide una respuesta más rápida a los requerimientos de negocio, reducciones de costos y a la integración de nuevos patrones y de nuevos clientes. Las organizaciones de IT han buscado diferentes implementaciones, modelos de software, antes de llegar a desarrollar SOA. En los años 80 aparecieron los modelos orientados a objetos, en los 90 aparecieron los modelos basados en componentes y en la actualidad han aparecido los modelos orientados a servicios. La figura 2.2 simplifica y muestra de unamanera gráfica la evolución cronológica de las arquitecturas desde sus fases iniciales de arquitecturas monolíticas hasta la actualidad.

Figura 2.2: Evolución de las arquitecturas en el tiempo.

Aunque la arquitectura orientada a servicios no es un concepto nuevo, fue descrita por primera vez por Gartner (una compañía de investigación de USA.) en 1996, se ha visto aumentada su aparición en la actualidad, en gran medida por el aumento de uso de servicios web [Channabasavaiah et al, 2004].

Generalmente los servicios webs tienden a ser desasociados, con funcionalidad flexible, independientes del ambiente. Cada servicio implementa al menos una acción, como por ejemplo

19

la solicitud en línea para la creación de una cuenta, la solicitud para obtener el estado de dicha cuenta, etc. Dentro de una SOA, el uso de servicios define protocolos que describen cómo los servicios analizan los mensajes y los pasan, utilizando la descripción en la metadata. Esta no sólo describe las características de los servicios, sino también los datos que utiliza. Los programadores han hecho un amplio uso de XML en SOA para estructurar los datos que se envuelven en una descripción casi exhaustiva del contenedor. Análogamente, el Web Services Description Language (WSDL, abordado en 2.2) típicamente describe los propios servicios, mientras SOAP (originalmente Simple Object Access Protocol) o REST (Representational State Transfer) describen los protocolos de comunicación. SOA depende de los datos y los servicios que se describen en los metadatos que deben cumplir con los dos siguientes criterios:

1. Lametadata debe proporcionarse en una forma en que los sistemas de software puedan utilizarla para configurar dinámicamente el descubrimiento y la incorporación de los servicios ya definidos, y también para mantener la coherencia y la integridad de los mismos. Por ejemplo, la metadata podría ser utilizada por otras aplicaciones, como un catálogo, para realizar el descubrimiento automático de servicios sin necesidad de modificar el contrato funcional del mismo.

2. Lametadata se debe proporcionar en una forma que los diseñadores de sistemas puedan entender y manejar de una manera razonable y sin demasiadas complicaciones.

El objetivo de SOA es permitir a los usuarios combinar grandes porciones de funcionalidad para formar aplicaciones adhoc construidas casi en su totalidad de los servicios de software existentes. Cuanto mayores sean las porciones anteriormente mencionadas, menor será la cantidad de interfaces necesarias para implementar cualquier conjunto de funcionalidad. Sin embargo, porciones con gran funcionalidad pueden no poseer una granularidad suficiente para su reutilización. Además, cada interfaz trae consigo una cierta cantidad de sobrecarga debido al procesamiento que realiza, por lo que la elección de la granularidad de los servicios influye directamente en la performance de los mismos [Channabasavaiah et al, 2003].

SOA como arquitectura se basa en la orientación a servicios como principio fundamental del diseño. Si un servicio presenta una interfaz simple que abstrae la complejidad subyacente permite a los usuarios acceder y consumir de los servicios independientes sin conocimiento de la implementación de la plataforma de los servicios.

Las colaboraciones en SOA, diagramadas en lafigura 2.3, siguen el paradigma descubrir, linkear e invocar, donde un consumidor de servicios realiza la localización dinámica de un servicio consultando el registro de servicios para hallar uno que cumpla con un determinado criterio. Si el servicio existe, el registro proporciona al consumidor la interfaz de contrato y la dirección del servicio proveedor. El siguiente diagrama ilustra las entidades (roles, operaciones y artefactos) en una arquitectura orientada a servicios donde estas colaboran.

20

Figura 2.3: Colaboraciones en SOA.

Cada entidad puede tomar uno de los tres roles posibles correspondientes a consumidor,

proveedor y/o registro:

Un consumidor de servicios es una aplicación, unmódulo de software u otro servicio que demanda la funcionalidad proporcionada por un servicio, y la ejecuta de acuerdo a un contrato de interfaz.

Un proveedor de servicios es una entidad accesible a través de la red que acepta y ejecuta consultas de consumidores, y publica sus servicios y su contrato de interfaces en el registro de servicios para que el consumidor de servicios pueda descubrir y acceder al servicio.

Un registro de servicios es el encargado de hacer posible el descubrimiento de servicios, conteniendo un repositorio de servicios disponibles y permitiendo visualizar las interfaces de los proveedores de servicios a los consumidores interesados.

Las operaciones que pueden llevar a cabo las entidades son:

Publicar: Para poder acceder a un servicio se debe publicar su descripción para que un consumidor pueda descubrirlo e invocarlo.

Descubrir: Un consumidor de servicios localiza un servicio que cumpla con un cierto criterio consultando el registro de servicios.

Linkear e Invocar: Una vez obtenida la descripción de un servicio por parte de un consumidor, éste lo invoca haciendo uso de la información presente en la descripción del servicio.

Finalmente, los artefactos en una arquitectura orientada a servicios son:

Servicio. Un servicio que está disponible para el uso a través de una interfaz publicada y que permite ser invocado por un consumidor de servicios.

Descripción de servicio. Una descripción de servicio especifica la forma en que un consumidor de servicio interactúa con el proveedor de servicio, especificando el formato

21

de consultas y respuestas desde el servicio. Esta descripción también puede especificar el conjunto de precondiciones, postcondiciones y/o niveles de calidad de servicio (QoS).

2.1.2 Problemas que se intentan resolver con SOA

Las organizaciones de IT han buscado diferentes implementaciones antes de llegar a desarrollar SOA y los problemas básicos con lo que se han encontrado y los que las implementaciones SOA

tratan de resolver son [Lemahieu, 2001]:

Complejidad: Los entornos son complejos. Las obligaciones de cumplir los presupuestos y la eficiencia de operación hacen necesario una reutilización de los sistemas, más que un reemplazo de éstos. El fácil y barato acceso a Internet ha hecho posible la constante creación de nuevos modelos de negocio que se han de evaluar para seguir el ritmo de la competencia. El crecimiento por fusión y adquisición están a la orden del día y por ello es necesario que las organizaciones IT, aplicaciones e infraestructuras se integren y absorban. A esta complejidad se le suma las soluciones punto a punto que lo hacen todavía más complicado, con lo que es necesario desarrollar un entorno heterogéneo en el que se utilicen todo tipo de hardware, sistemas operativos, lenguajes, tipos de datos, etc.

Programación redundante y no reutilizable: las aplicaciones igual que las empresas se van desarrollando a partir de fusiones y adquisiciones, lo cual hace que se tenga que trabajar con aplicaciones redundantes o aplicaciones con funciones que no son fácilmente reutilizables. Si cada unidad de negocio se desarrolla independientemente, a la hora de actualizar o de introducir los nuevos productos y servicios, la redundancia hace que aumenten los costos y el tiempo necesario para introducir los cambios en cada parte afectada.

Interfaces múltiples : Si se tiene que interconectar N sistemas existentes se necesitan N(N1) interfaces para hacer posible esta realización, con lo que si se quiere introducir un nuevo sistema se deberá crear documentación, testear y mantener 2N nuevas interfaces.

2.1.3 Definición de un Servicio dentro de SOA

Las siglas SOA provienen del inglés Service Oriented Architecture. Es unmodelo de arquitectura que es caracterizado por su procedimiento para crear y utilizar diversos procesos que son parte de un sistema informático, reunidos en forma de servicios. Estos configuran un determinado Proceso de Negocio (Un proceso de negocio se puede ver como un conjunto estructurado de tareas, que contribuyen colectivamente a lograr los objetivos de una organización). Entonces se puede definir a un servicio como un paquete funcional de software al cual se puede acceder a través de una infraestructura de red. Los servicios son autónomos, autocontenidos y no se puede tener control, ni autoridad sobre ellos. Un ejemplo de servicio es, dentro de un entorno de negocio, una transacción simple (como obtener la cuota de stock ó conseguir las direcciones de los clientes, etc.), una transacción de negocio más compleja (calendario de entregas, cobertura de ventas, etc.) o servicios de sistema (autenticación de usuario, mensaje de conexión, etc.). Las funciones de negocio desde el punto de vista de aplicación no son funciones de sistema, y son atómicas (aunque estén formadas por funciones más pequeñas, se considera como un paquete

22

indivisible). Las transacciones de negocio tienen que implementarse como una composición de funciones de bajo nivel transparentes al que las llama. Por último los servicios de sistema son funciones genéricas que pueden ser abstraídas fuera de la plataforma particular, comoMicrosoft Windows o Linux por ejemplo.

La riqueza funcional de las aplicaciones está dada según el nivel de granularidad. La granularidad es entonces, la capacidad de descomponer las aplicaciones de negocio en servicios, lo cual tiene implicaciones prácticas, no es sólo un proceso de abstracción. Los servicios pueden ser de baja granularidad o funciones complejas de alta granularidad (finegrained ó coarsegrained respectivamente) [Channabasavaiah et al, 2004]. Generalmente, los servicios son funciones coarsegrained ya que suelen ser el resultado de ejecutar varias operaciones finegrained; por ejemplo, “abrir una cuenta” está compuesto por “identificar al usuario” y “crear una cuenta nueva”, etc. Esta es la manera de desarrollar un entorno de aplicaciones basadas en componentes, donde los servicios se definen como un conjunto de componentes reusables que pueden ser usados para la construcción de nuevas aplicaciones, o para integrar los recursos de software ya existentes.

Es importante tener en consideración cómo se utilizan estos términos y no confundirlos. Web Services engloba varias tecnologías, incluyendo XML, SOAP, WSDL, UDDI, etc. los cuales permiten construir soluciones de programación para mensajes específicos y para problemas de integración de aplicaciones.

En cambio SOA es una arquitectura de aplicación en la cual todas las funciones están definidas como servicios independientes con interfaces invocables que pueden ser llamados en secuencias bien definidas para formar los procesos de negocio.

En SOA la clave está en la interfaz puesto que define los parámetros requeridos y la naturaleza del resultado. Esto significa que define la naturaleza del servicio y no la tecnología utilizada. Esta función permite realizar dos de los puntos críticos: los servicios son realmente independientes y pueden ser manejados.

A continuación se presenta una vista de capas de las tecnologías a la izquierda, junto con las opciones más utilizadas a la hora de definir servicios web a la derecha. Como se puede ver en la figura 2.4, funcionalmente un servicio web se puede dividir en cinco capas aunque cabe aclarar que se agregan nuevos elementos continuamente.

Figura 2.4: Vista de capas de las tecnologías utilizadas en servicios web.

23

La primera capa es la de red, básicamente el protocolo de comunicación de los servicios web, usualmente se utiliza el protocolo de comunicación TCP/IP. La segunda capa es la capa de transporte, en este caso se define el protocolo de transporte de los datos, la opciónmás utilizada es HTTP. La tercer capa de empaquetamiento, comprende el proceso de empaquetar los datos con la información de protocolos necesaria antes de que comience su tránsito por la red, la tecnología más utilizada es el protocolo SOAP que se detalla más adelante. La cuarta capa de descripción, comprende la tecnología con la cual se describe el servicio web para que sea accesible por los consumidores, la tecnología más utilizada es la del lenguajeWSDL. Finalmente la quinta capa, de descubrimiento, describe la tecnología que se utiliza a la hora de registrar y buscar servicios en la web, la tecnología más utilizada en este caso es la UDDI . 2

Finalmente se puede realizar una comparación entre componentes de software orientado a objetos con servicios web como se ve en la tabla 2.1 a continuación:

Componentes Servicios Web

Los componentes de software son reusables Los servicios web son reusables

Para ser utilizado un componente debe:

1. Ser empaquetado para ser distribuido en una aplicación más grande.

2. Ser compatible con los frameworks utilizados para construir el sistema.

Para ser utilizado un servicio web debe:

1. Ser publicado en la web.

Los componentes pueden ser vendidos y por ejemplo cobrarse por cada deployment del componente.

Los servicios web también pueden ser vendidos, y cobrar en relación al número de llamadas que se realiza al servicio.

Existen muchos frameworks de componentes para construir sistemas distribuidos (J2EE, DCOM, .NET, CORBA, etc.) pero no son compatibles entre ellos mismos.

Los servicios web se pueden componer y ser utilizados en sistemas más grandes, a diferencia de los componentes, estos no necesitan ser descargados e instalados por el cliente para utilizarlos.

Tabla 2.1: Comparación componentes vs servicios web.

2 "UDDI Universal Description, Discovery and Integration": Es un registro basado en XML, crossplatform, donde empresas a nivel mundial pueden registrarse en internet y un mecanismo para registrar y localizar servicios web y definir como los servicios o aplicaciones de software interactúan mediante la internet. UDDI esta patrocinado por OASIS (Organization for the Advancement of Structured Information Standard). Cuando se descubre un servicio con UDDI, se accede al servicio mediante un registro centralizado el cual establece la conexión.

24

2.1.3.1 SOAP Simple Object Access Protocol

SOAP es una especificación de un protocolo para el intercambio de información estructurada utilizado en la implementación de servicios web. Está basado en XML, el cual utiliza para dar formato a los mensajes, y depende de otro protocolo en la capa de aplicación, para la negociación y transmisión de dichos mensajes.

SOAP consiste de tres partes:

1. envelope, que define la estructura del mensaje y cómo va a ser procesado.

2. Un conjunto de reglas para expresar instancias de datatypes definidos por la aplicación.

3. Una convención para representar llamadas a procedimientos y respuestas de los mismos.

El protocolo SOAP posee tres grandes características:

1. Extensibilidad, por ejemplo security y WSRouting se encuentran en la extensiones que están siendo desarrolladas actualmente.

2. Neutralidad, SOAP puede operar sobre cualquier protocolo en la capa de aplicación, como por ejemplo HTTP, SMTP, TCP, UDP o JMS.

3. Independencia, SOAP es compatible con cualquier paradigma de programación.

2.2 Especificación de documentos WSDL

WSDL, Web Services Description Language, es un formato de archivos basado enXML que se utiliza para describir Servicios Web que utilizan SOAP. Actualmente la W3C (World Wide Web Consortium, es un consorcio internacional que produce recomendaciones para laWorld Wide Web.) recomienda la versión 2.0.

WSDL describe la interfaz pública a los servicios web, está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo. Las operaciones y mensajes que soporta se describen en abstracto y se linkean después al protocolo concreto de red y al formato del mensaje. La especificación WSDL es ampliable, de modo que se pueden describir los puntos finales independientemente de los formatos demensaje o de los protocolos de red que se utilicen para comunicarse. De este modo, las empresas pueden poner a disposición de sus serviciosWeb

25

http://es.wikipedia.org/wiki/XML

los documentos WSDL mediante UDDI, WSIL o divulgando los URL a su WSDL mediante 3

correo electrónico o sitios Web.

2.2.1 Estructura de un documento WSDL

Un documento WSDL no es más que un documento XML que describe ciertas características propias de un servicio web, así como su localización y aquellos parámetros y métodos que soporta. Se define el contrato para poder consumir de los servicios requeridos.

Un documento WSDL define un servicio web utilizando a tal fin elementos XML, como:

<portType> para las operaciones que proporciona el servicio web. <message> para los mensajes que utiliza el servicio web. <types> para los tipos de datos que utiliza el servicio web. <binding> para los protocolos de comunicaciones que utiliza el servicio web. <service> para los servicios y su mapeo con su respectivo puerto.

Un documento WSDL tiene una estructura semejante a la observada en la Figura 2.5:

Figura 2.5: Estructura de un documento con formato WSDL.

Elemento type

Mediante el elemento<types>, se definen los tipos de datos utilizados en el servicio web. Para ello, WSDL prefiere XSD como tipo del sistema. Naturalmente los tipos de datos pueden ser un tipo de datos primitivo, como pueden serintostring, y de unamanera similar, se pueden definir objetos complejos, como por ejemplo un objetoTradePriceRequest, un elemento bursátil con su

3 Web Services Inspection Language (WSIL): es un mecanismo para descubrir servicios, es una alternativa a UDDI pero también lo complementa. WSIL permite ir directamente al proveedor del servicio y pedir consumir del servicio que provee.

26

valor, que posee los campos tickerSimbol, y price, que corresponden al nombre del elemento bursátil y su valor actual respectivamente. En lafigura 2.6 se detalla una versión reducida del fragmento WSDL para el ejemplo mencionado anteriormente.

Figura 2.6: Segmento de types.

El atributo name es único entre todos los types definidos dentro del WSDL, un elemento es nombrado e identificado mediante el atributo name.

Elemento message

Mediante el elemento<message>se definen los tipos de datos que se utilizan en una operación. Cada mensaje puede tener una o varias partes,<part>, y cada parte puede considerarse como si fuera los parámetros que se pasan en la llamada a una función en programación clásica (RPC) o un método en programación orientada a objetos. Se puede ver un ejemplo en la Figura 2.7.

Figura 2.7: Segmento de message.

27

El atributo namees único entre todos losmessagesdefinidos dentro del WSDL, un elemento message es nombrado e identificado mediante el atributo name.

Mensajes concretos vs abstractos:

La definición de un mensaje siempre se considera que es una definición abstracta del contenido

del mensaje. El binding del mensaje describe cómo el contenido abstracto es mapeado a la forma concreta. Sin embargo, en algunos casos, la definición abstracta puede coincidir con la representación concreta de una manera muy aproximada o coincidir exactamente para uno o más bindings, de manera tal que el/los binding/s proveerá/n muy poca información o directamente no proveerá nada de información. Sin embargo, otro binding de la misma definición del mensaje podrá requerir extensiva información de mapeo. Por esta razón, no se podrá determinar “cuán abstracto” el mensaje es realmente hasta que el binding es inspeccionado.

Elemento portType

<portType>es el elemento XML de WSDL que define el servicio web, así como las operaciones posibles mediante dicho servicio y los mensajes vinculados. <portType>cumple una función análoga a la de una función de biblioteca en programación clásica o a la de una clase en programación orientada a objetos. Se puede ver un ejemplo en la Figura 2.8.

Figura 2.8: Segmento de portType.

El atributonamees único entre todos los port types definidos dentro delWSDL, una operación es nombrada e identificada mediante el atributo name.

WSDL soporta cuatro primitivas de transmisión (ilustradas en la figura 2.9):

1. Oneway: el servicio recibe un mensaje. 2. Requestresponse: el servicio recibe un mensaje y envía un mensaje relacionado al

mensaje anteriormente recibido (respuesta). 3. SolicitResponse: el servicio envía un mensaje y recibe un mensaje relacionado al

mensaje enviado anteriormente. 4. Notification: el servicio envía un mensaje.

28

Figura 2.9: Patrones de operación en WSDL

Elemento binding

<binding>define el formato del mensaje y el protocolo para cada uno de los puerto. Se puede definir cualquier cantidad de bindings para un portTypeen particular. Se puede observar un ejemplo en la Figura 2.10.

Figura 2.10: Segmento de binding.

29

El atributo name es único entre todos los bindings definidos dentro del WSDL, binding es nombrado e identificado mediante el atributo name.

Cabe destacar que existen varias maneras de relacionar un servicio con el protocolo SOAP, dependiendo del estilo de binding con el que se cuenta. Por ejemplo, se cuentan con dos estilos de binding para el protocolo SOAP: RPC (remote procedure call) y Document y a su vez cada modelo de estilo de binding tiene un modelo de codificación, los cuales pueden ser encoded (codificado) o literal. Lo cual da como resultado cuatro estilos de binding:

1. RPC/Encoded 2. RPC/Literal 3. Document/Encoded 4. Document/Literal

La ventaja de utilizar el estilo de modelo Document es que se puede estructurar el cuerpo del mensaje SOAP de cualquier forma que desee, siempre y cuando el contenido del cuerpo del mensaje SOAP es cualquier instancia XML arbitraria. El estilo de Document también se conoce como el estilo orientado amensajes. Sin embargo, con un estilo demodelo RPC, la estructura del cuerpo de la petición SOAP debe contener tanto el nombre de la operación y el conjunto de parámetros del método. El estilo demodelo RPC asume una estructura específica de la instancia XML contenido en el cuerpo del mensaje.

Cuando se utiliza un modelo de codificación literal, el contenido del cuerpo debe ajustarse a una estructura XMLschema definido por el usuario (XSD). La ventaja es doble. Por un lado, se puede validar el cuerpo del mensaje con el esquema XML definido por el usuario, y por otra parte, también se puede transformar el mensaje utilizando un lenguaje de transformación como XSLT.

Con un modelo de uso encoded (SOAP), el mensaje tiene que usar tipos de datos XSD, pero la estructura del mensaje no necesita ajustarse a cualquier esquema XML definido por el usuario. Esto hace que sea difícil para validar el cuerpo del mensaje o utilizar XSLT transformaciones basadas en el cuerpo del mensaje.

Elemento service

Por último, <service>: Conjunto de puertos y dirección de los mismos. Esta parte final hace referencia a lo aportado por las secciones anteriores. Se puede ver un ejemplo en la Figura 2.11.

Figura 2.11: Segmento de service.

30

El atributo namees único entre todos losservicesdefinidos dentro del WSDL, un elemento service es nombrado e identificado mediante el atributo name.

Un elemento portno debe especificar más de un address, como así tampoco no debe especificar otra información de binging más que la que se especifica en el elemento address.

Para resumir entonces, en el ejemplo ilustrado se define un servicio web al que se lo accede o

consume mediante la url: http://example.com/GetLastTradePrice. Éste necesita un

input en formato soap y devuelve como output otra salida en formato soap. Estos mensajes son

los llamadosGetLastTradePriceInputyGetLastTradePriceOutputrespectivamente. A su

vez estos mensajes están conformados por un elemento cada uno, TradePriceRequesty

TradePrice que a su vez tienen un campo cada uno, string y float respectivamente.

2.2.2 Extensibilidad del lenguaje y binding

En WSDL, el término binding se refiere al proceso de asociar un protocolo o un formato de datos con una entidad abstracta como puede ser un message, operation, o portType.

WSDL permite a los elementos representar una tecnología específica (referidos aquí como elementos de extensibilidad) bajo varios elementos definidos por WSDL. Estos puntos de extensibilidad son típicamente utilizados para especificar información de binding para un formato de mensaje o un protocolo en particular, pero no están limitados a tal uso solamente. Los elementos de extensibilidad deben utilizar un namespace de XML diferente al de su respectivo WSDL. Estos elementos son comúnmente utilizados para especificar tecnologías específicas de binding. Para distinguir si la tecnología específica del binding es requerida o es opcional, los elementos de extensibilidad pueden tener el atributo wsdl:requiredde tipo booleano, por defecto el valor para este atributo es falso.

2.2.3 Antipatrones en WSDLs

Uno de los principales problemas que se pueden encontrar en los archivos WSDL es su “descubribilidad”. Como se mencionó anteriormente, el registro UDDI trabaja también como motor de búsqueda para los servicios web. Alternativamente, existen otros motores de búsqueda de servicios web que proveen interfaces basadas en procesamiento de texto, que obviamente dependen de la calidad del contrato especificado en los WSDL. El objetivo entonces es mejorar la efectividad de los registros sintácticos. Una posible solución es detectar las prácticas comunes que reducen la información sintáctica dentro de un documentoWSDL, definir soluciones que se deshagan de los problemas introducidos a los WSDL por el uso de las mencionadas prácticas. Por último se pueden clasificar dichas prácticas y sus soluciones mediante la forma de un catálogo antipatrones [Rodríguez, 2012].

Los antipatrones en WSDL se pueden agrupar en tres grandes grupos, documentación, representación y diseño. Los nombres casi explican por sí mismos a cada grupo; el grupo de documentación comprende aquellos antipatrones que afectan la documentación del WSDL, como los comentarios o los nombres de las operaciones. El grupo de representación tiene en

31

cuenta cómo se representan los datos dentro del WSDL, es decir la coherencia de los mismos. Por último el grupo de diseño comprende aquellos que afectan el diseño de los servicios en el WSDL [Rodríguez, 2012].

A continuación se presentan y detallan los antipatrones de los archivosWSDL, con sus síntomas, la manera en que se manifiesta, es decir cómo se puede descubrir el antipatrón, los problemas que aporta a la “descubribilidad” del WSDL y cómo solucionarlo.

Documentation: Inappropriate or lack of documentation. Ambiguous names.

Representation: Redundant data models Whatever types.

Design: Redundant porttypes. Low cohesive operation in the same porttype. Empty messages. Enclosed data model. Undercover fault messages within standard messages.

Inappropriate or lack of documentation (Documentación inapropiada o falta de ella)

Síntomas Ocurre cuando un documento WSDL no tiene comentarios o los comentarios no son representativos o son demasiado complejos de comprender.

Manifestación No es inmediatamente aparente, se debe analizar semánticamente el contenido de los comentarios.

Problemas No describe ni aporta palabras relacionadas a la funcionalidad del servicio que debe documentar.

Solución Crear comentarios concisos y ubicarlos en lugar correcto dentro de los documentos WSDL.

32

Ambiguous Names (Nombres ambigüos)

Síntomas Ocurre cuando nombres ambiguos o sin significado son utilizados para denotar los principales elementos de un documento WSDL.

Manifestación No es inmediatamente aparente, se deben analizar semánticamente los nombres utilizados.

Problemas Reduce el número de palabras relevantes e introduce palabras irrelevantes al documento WSDL.

Solución Renombrar nombres ambiguos o sin significado a nombres más representativos.

Redundant data models (Data models redundantes)

Síntomas Ocurre cuando coexisten varios datatypes para representar objetos del dominio de aplicación dentro de un mismo documento WSDL.

Manifestación Es evidente.

Problemas Introduce palabras irrelevantes e influencia su importancia.

Solución Agrupar datatypes redundantes dentro de un nuevo datatype.

Whatever types (Tipos cualquiera)

Síntomas Ocurre cuando un datatype especial es utilizado para representar cualquier objeto del dominio de aplicación.


Problemas Reduce el número de palabras relevantes e introduce irrelevantes.

Solución Reemplazar dichos tipos con datatypes que representan a los objetos de una manera adecuada.

Redundant porttypes (Porttypes redundantes)

Síntomas Ocurre cuando diferentes porttypes ofrecen el mismo conjunto de operaciones. Frecuentemente los publishers redefinen un porttype por cada tecnología de comunicación soportada por la aplicación.


Problemas Influencia la importancia de las palabras.

Solución Agrupar los porttypes redundantes dentro de un nuevo porttype.

33

Low cohesive operation in the same porttype (Baja cohesividad en el mismo porttype)

Síntomas Ocurre cuando algunos porttypes tienen una cohesión débil, en su mayoría debido a que los publishers incluyen operaciones para monitorear el estado del servicio dentro de un porttype que provee las funcionalidades ofrecidas.

Manifestación No es inmediatamente evidente.


Solución Migrar las operaciones que poseen baja cohesión y colocarlas dentro de un porttype nuevo. Repetir dicha operación hasta que no hayan porttypes con niveles bajos de cohesión.

Empty messages (Mensajes vacíos)

Síntomas Ocurre cuando se utilizan mensajes vacíos en operaciones que no producen ninguna salida o no reciben ninguna entrada.



Solución Eliminar los mensajes vacíos y las definiciones de datatypes sin contenido.

Enclosed data model (Data models encapsulados)

Síntomas Ocurre cuando las definiciones de los datatypes utilizadas para el intercambio de información son ubicadas dentro del documento WSDL en lugar de ubicarlos en documentos XSD por separado.


Problemas Reduce el número de palabras relevantes e introduce palabras irrelevantes al documento WSDL.

Solución Reubicar las definiciones de los datatypes a documentos schema individuales.

34

Undercover fault messages within standardmessages (Mensajes de fallo encubiertos dentro de mensajes estándar)

Síntomas Ocurre cuando mensajes de salida son utilizados para notificar errores en el servicio.

Manifestación Presente en la implementación del servicio.


Solución Utilizar mensajes de fallo provistos por los documentos WSDL para informar errores.

35

2.3 Refactorización

Como se mencionó en el capítulo anterior, pueden existir antipatrones en los contratosWSDLs los cuales deben ser detectados en el caso de existir y solucionados. No sólo existen antipatrones en contratos WSDLs sino que también pueden existir servicios duplicados, o que pueden ser mejor agrupados en un mismo contrato WSDL de una manera más intuitiva, como por ejemplo una agrupación semántica. Una técnica que facilita la detección de antipatrones o problemas en el código es la técnica de refactorización.

La refactorización de código es el proceso de cambiar sistemas de software de manera tal que dicho cambio no altera el comportamiento del sistema pero mejora la estructura interna del proyecto. Es una manera disciplinada de limpiar, purificar, el código de manera de minimizar las chances de introducir errores (conocidos como bugs). Cuándo se está refactorizando un sistema en esencia se está mejorando el diseño del código luego de que se haya escrito.

Actualmente en la industria de software se pretende diseñar y luego escribir el código. Un buen diseño es fundamental para comenzar, y después su codificación. Con el correr del tiempo el código se modificará y la integridad del sistema, su estructura de acuerdo con ese diseño previamente creado se irá desvaneciendo gradualmente. El código vá cambiando desde un punto de vista de ingeniería hacia un punto de vista de hacking [Fowler, 2002].

La refactorización es la práctica opuesta. Con las técnicas de refactorización se pueden tomar sistemas con un mal diseño, incluso sistemas con caos en la estructura interna de su código y se los puede convertir en sistemas bien diseñados. En cada paso se mueve un campo de una clase a otra, quitar fragmentos de código de un método para crear su propio método, y subir o bajar porciones de código en la jerarquía de clases. Aún así los efectos acumulativos de estos pequeños cambios pueden mejorar radicalmente el diseño [Fowler, 2002].

2.3.1 Por qué se debe refactorizar el código?

La refactorización no soluciona todos los problemas en el mundo del software, pero es una herramienta con gran valor que ayuda a tener el sistema en buena forma. La refactorización es una herramienta que puede, y debe, ser utilizada para diferentes propósitos.

La refactorización mejora el diseño del Software

Sin la refactorización el diseño de software se deteriora. Mientras que los programadores cambian el código para cumplir con metas cortas, o cambios que son realizados sin tener la comprensión total del diseño arquitectónico, el código pierde su estructura original. Se torna más difícil ver el diseño leyendo el código. La refactorización se puede ver como poner el código en el lugar en el que debería estar, se remueven porciones que no están en el lugar adecuado. La pérdida de estructura tiene un efecto acumulativo, mientras seamás difícil de ver el diseño en el código, más difícil será de preservar de manera que causará el deterioro más rápidamente. La

36

refactorización ayuda a mantener el código en forma y evitar el problema mencionado anteriormente.

El códigomal escrito, desde el punto de vista de su diseño, usualmente requiere demás líneas de código que las necesarias, ya que usualmente hace literalmente lo mismo en varias porciones del programa. Entonces, un aspecto importante a la hora de mejorar el diseño, es eliminar código duplicado. La principal importancia de esto es que afecta a futuras modificaciones, dado que mientras más código exista, será naturalmente más difícil de modificar.

La refactorización hace al Software más fácil de comprender

Cuando un programador está escribiendo código, no necesariamente lo hace con la idea en mente de que dicho código, probablemente sea modificado en algunos meses por otro programador. El problema aparece cuando se está tratando de hacer funcionar el código de la manera deseada, no se está pensando en ese próximo programador que luego modificará el código. La refactorización ayuda a hacer el código más legible. Cuando se está leyendo el código para estudiarlo, la refactorización ayuda a llegar a niveles más altos de compresión del sistema. Si no se hiciera, estos detalles se perderían.

La refactorización ayuda a encontrar errores en el software (bugs)

Al ayudar a comprender el código, también favorece la detección de bugs. Existen programadores que pueden leer grandes porciones de software y detectar bugs rápidamente. Dado que la granmayoría de programadores no puede hacer esto, la refactorización se considera una buena práctica para detectar bugs por parte de los programadores, ya que al ayudar a comprender el código de una manera más detallada y profunda, los bugs resultanmás fáciles de encontrar.

La refactorización hace al software más mantenible

En los puntos anteriores se describieron algunos beneficios que se obtienen al refactorizar código. La refactorización y la mantenibilidad están fuertemente relacionadas, un código que ha sido refactorizado y/o es refactorizado periódicamente es probablemente más mantenible que un código que aún no lo fue. La razón es simple, con el proceso de refactoring se intentan agregar atributos de calidad al diseño y al código tales como extensibilidad, entendibilidad, etc. gracias a los cuales la mantenibilidad del sistema se ve afectada positivamente.

2.3.2 Puntos que necesitan refactorización

Existen muchas maneras de comenzar a buscar código que necesita refactorización, que tiene ‘mal olor’ . Los puntos del código a verificar van desde chequear por código duplicado, métodos 4

o funciones largas, clases con muchas líneas de código, lista de parámetros muy extensa, hasta

4 ‘Mal olor’ o code smell: En programación, el ‘mal olor’ en el código es síntoma de un posible problema o que indica un problema más profundo en el programa. Algunos ejemplos son: Código duplicado, métodos o clases largas, demasiados parámetros, etc.

37

por ejemplo, remover lo que se conoce como middle man. Este último se encuentra cuando luego de mucho tiempo de desarrollo, puede que una clase esté delegando funcionalidad a métodos de otra clase, motivo por el cual se recomienda remover almiddle man(hombre del medio) y realizar las invocaciones a la clase que en realidad ejecuta la rutina deseada [Fowler, 2002].

De todas maneras, este trabajo está centrado en dar soporte al desarrollador o arquitecto para refactorizar aplicaciones SOA mediante la detección de antipatrones en el sistema, analizando los contratos WSDL del mismo, los cuales se mencionan en la sección 2.2.3.

2.3.3 Refactorización utilizando técnicas de IA

La refactorización no se lleva a la práctica tanto como se desearía. Esto es debido a múltiples razones, incluyendo management, por ejemplo: “Se necesitan agregar funcionalidades paraX proceso y la refactorización no contribuye directamente con ellos” y técnicas, como por ejemplo: “La refactorización puede romper una propiedad sutil del sistema, lo cual es muy peligroso”. Existen varias herramientas para solventar algunos de estos problemas, en su mayoría automatizando el proceso o aplicando una refactorización que un ingeniero determinó que era apropiada. De todas maneras, el motivo por el cuál no se aplica refactoring que más motiva el presente trabajo es la dificultad existente a la hora de encontrar o detectar oportunidades de refactorización. La utilización de técnicas de IA para detectar estas oportunidades es de vital importancia a la hora de sustentar la toma de decisiones en la refactorización de código. Existen varios estudios [Dong et al, 2004][Kuhn et al, 2007][Liu, Wong, 2009][Jiangang et al, 2008][Elgazzar et al, 2010] que proponen técnicas de IA para mejorar la descubribilidad de servicios web, para clusterizar etc. En la siguiente sección se detallarán técnicas de IA para clusterizar servicios web por alguna similitud, generando así clusters de servicios web similares, los cuales deberán ser analizados por los desarrolladores/arquitectos para determinar si la refactorización de esos servicios es factible.

38

2.4 Clusters y técnicas de clustering

De todas las técnicas de Inteligencia Artificial existentes, se abordará la técnica de clustering debido a que es un métodono supervisado para agrupar elementos de un conjunto cuando no existen categorías de dichos elementos predefinidas. Los métodosno supervisados en machine learning son aquellos que tratan de encontrar una estructura que está oculta en los datos que no fueron previamente categorizados [Marakas, 2002]. Entonces se toma el método de clustering ya que los servicios webs en las aplicaciones SOA no están categorizados a la hora de consumir los datos presentes en los contratos WSDL, se necesita obtener dicha estructura oculta.

El análisis de clustering en sí no es un algoritmo específico, más bien es la tarea general que hay que resolver. Se puede lograr por diversos algoritmos que difieren significativamente en su noción de lo que constituye un clúster y cómo encontrarlo de manera eficiente. Nociones populares de grupos incluyen grupos con pequeñas distancias entre los miembros del clúster, áreas densas del espacio de datos, intervalos ó distribuciones estadísticas particulares. Por lo tanto el Clustering puede definirse como un problema de optimización multiobjetivo. La configuración del algoritmo de agrupamiento y de parámetros apropiados (incluidos los valores tales como la función de distancia de usar, un umbral de densidad o el número de grupos esperados) dependen del conjunto de datos individuales y el uso de los resultados previstos. El análisis de clustering como tal, no es una tarea automática, sino un proceso iterativo de descubrimiento de conocimiento o la optimización multiobjetivo interactiva a base de prueba y error. A menudo será necesario modificar los parámetros de preprocesamiento y modelo de datos hasta que el resultado alcance las propiedades deseadas.

Existen muchos modelos de clustering en la actualidad, los cuales tienen en cuenta diferentes características de los elementos del conjunto a la hora de agruparlos, tanto del tipo de datos disponibles como del propósito de la aplicación.

Si se utiliza el análisis de clustering como una herramienta descriptiva o exploratoria, es posible que se prueben distintos algoritmos sobre los mismos datos con el fin de ver cuál es el método que mejor se ajusta al problema. Un buen modelo de clustering debe identificar clusters que sean tanto compactos como separados entre sí, es decir, que tengan alta similaridad intracluster y baja similaridad intercluster. Un buen modelo debe descubrir todos o casi todos los patrones ocultos en los datos, se puede deducir entonces que la calidad del modelo de clustering depende casi directamente de la medida de similitud aplicada a los elementos.

Se puede dividir a los modelos en dos grandes grupos, aquellos que pertenecen al grupo dehard clustering son los que consideran que cada objeto pertenece a un cluster o no, no permiten incertidumbre acerca de la membresía de una instancia a cada cluster en un conjunto de clusters. Por otro lado, los métodos que pertenecen alsoft clustering (también conocido como fuzzy clustering) son aquellos que consideran que cada objeto pertenece a cada cluster en cierto grado, asignan probabilidades de pertenencia de una instancia a más de un cluster.

39

A continuación se detallan los diferentes enfoques de técnicas de clustering que fueron utilizados en el presente trabajo.

2.4.1 Métodos de Particionamiento

Los métodos de particionamiento (centroidbased clustering) construyen una partición de n objetos del conjunto de datosD en un conjunto dek clusters, siendok≤n . Dado un determinado k,se intenta encontrar una partición dek clusters que optimice el criterio de particionamiento. Clasifica a los datos en k grupos que satisfacen los siguientes requisitos:

• Cada grupo debe contener, al menos, un elemento.

• Cada elemento debe pertenecer únicamente a un grupo.

Dadok, el número de particiones que se deben construir, los métodos particionales realizan una partición inicial. A continuación, utilizan una técnica iterativa de recolocación que intenta mejorar la partición moviendo los objetos de un grupo a otro.

El criterio general para decidir si una partición es buena es que los objetos pertenecientes al mismo cluster estén cerca mientras que los objetos pertenecientes a los clusters restantes están lejos de ellos.

Existen varios métodos de particionamiento, algunos ejemplos son:

Kmeans ExpectationMaximization Algoritmos jerárquicos.

2.4.1.1 Kmeans

Formalmente, dado un conjunto de observaciones (x1, x2, … , xn) donde cada observación es un vector real de dimensión D, kmeans apunta a particionar lasnobservaciones enkconjuntos, donde k<= n, y S = S1, S2,..., Sk con el fin de minimizar la suma de los cuadrados dentro de cada grupo:

donde i es la media de puntos en Siμ

En la práctica, dado un k número de clusters y el conjunto de datos n, se debe elegir arbitrariamentekobjetos como centros iniciales de clusters, llamados semillas y luego iterar los siguientes pasos:

40

Asignar o reasignar cada objeto al cluster con el cual el objeto seamás similar, basándose en el valor medio de los objetos del cluster.

Actualizar los valores medios del cluster, los centroides propiamente dichos. Es decir, calcular el valor medio de los objetos para cada cluster.

Finalmente cuando no se producen más cambios se considera que se ha llegado a la convergencia y es el punto de corte del algoritmo.

Un enfoque más visual del algoritmo kmeans se presenta a continuación, en las figuras se puede ver de manera gráfico el efecto de cada paso ejecutado por el algoritmo.

En la figura 2.12 se pueden observar k centroides iniciales (en este caso k=3).

Figura 2.12: estado inicial del algoritmo kmeans.

En la figura 2.13 se pueden observar k clusters son creados mediante la asociación de cada observación con el grupo más cercano. Aquí las particiones representan eldiagrama de voronoi generado por los grupos. 5

En la figura 2.14 se puede ver como se recalcula el centroide de cada cluster.

Figura 2.13: paso 2 del algoritmo kmeans.

Figura 2.14: paso 3 del algoritmo kmeans.

Los pasos 2 y 3 se repiten hasta que se llega a la convergencia, como se ve en la figura 2.15.

5El diagrama de Voronoi es una construcción de teoría de grafos en la que se crean las regiones conmenor distancia a

ciertos puntos. se genera a partir de las mediatrices de los puntos.

41

Figura 2.15: Convergencia del algoritmo kmeans.

Cálculo del valor de k

Kmeans requiere de antemano la especificación de la cantidad de clusters. Particularmente, el valor de k influencia la estructura de los grupos en el algoritmo kmeans de una manera muy fuerte. Un valor dek grande generará clusters más juntos y densos. Por lo tanto, la selección del valor dek no es trivial [Berkhin, 2006]. Para abordar este problema, el enfoque propuesto en el presente trabajo propone utilizar elsilhouette coefficient[Rousseeuw, 1987].Este es unamedida de la cohesión y la separación de los clusters, y está basado en la diferencia entre la distancia promedio a puntos en el cluster más cercano y a puntos en el mismo cluster. El valor de k seleccionado es el que posee el mayor promedio del silhouette coefficient.

A continuación en la tabla 2.2, se muestran ventajas y desventajas del algoritmo kmeans.

Ventajas Desventajas

Entre los algoritmos de particionamiento es eficiente.

Se necesita conocer el valor de k al momento de comenzar con el algoritmo.

Su implementación es sencilla. Es sensible al ruido.

El resultado puede variar dependiendo de las semillas escogidas al comienzo.

Algunas semillas pueden resultar en una tasa de convergencia menor.

La selección de semillas se puede basar en heurísticas o resultados obtenidos por otros métodos.

Tabla 2.2: Ventajas y desventajas del algoritmo kmeans.

42

2.4.1.2 ExpectationMaximization (EM)

EM es un método de optimización iterativo para estimar parámetros desconocidos , dada la Θ

medición de datos U. Sin embargo, no se conocen los valores de variables ocultas J, que deben ser descubiertos. En particular, se pretende maximizar la probabilidad a posteriori de los parámetros dados los datos U, marginando sobre las variables ocultas J:Θ

La intuición detrás de EM es antigua: se alternan entre la estimación de la incógnita Θ y las variables ocultas J. Esta idea se conoce desde hace mucho tiempo. Sin embargo, en lugar de encontrar el mejor J∈ J dado una Θ estimación en cada iteración, EM calcula una distribución a través de J espacio [Dempster et al, 1977].

La iteración en EM alterna entre calcular pasos de esperanza (E), la cual crea una función de esperanza del logaritmo natural de la función de probabilidad evaluada utilizando los actuales valores estimados para los parámetros J y un paso de maximización (M), el cual computa parámetros maximizando la esperanza del logaritmo natural calculado en el paso E. Estas estimaciones de los parámetros J son utilizados para comenzar el paso E siguiente, y así se repite el proceso.

A continuación, en las figuras 2.16 a 2.19 se presenta la resolución gráfica de una agrupación de datos utilizando EM.

Figura 2.16: EM paso 1. Figura 2.17: EM paso 2.

43

Figura 2.18: EM paso 3. Figura 2.19: EM paso 4. Convergencia.

2.4.2 Algoritmos jerárquicos

Los algoritmos jerárquicos son una familia de métodos que difieren por la manera en que las distancias son computadas. Los algoritmos jerárquicos se basan en la idea central de que los objetos están relacionados a los objetos más cercanos a estos que a los más alejados.

Estos algoritmos conectan objetos para formar clusters basados en su distancia, un cluster puede ser descrito en gran medida por la distancia máxima necesaria para conectar partes del clúster. A diferentes distancias, formarán diferentes clusters que pueden ser representados utilizando un árbol binario o dendrograma lo que explica que el nombre común de "agrupación 6

jerárquica" proviene de que estos algoritmos no proporcionan una única partición del conjunto de datos, sino que proporcionan una extensa jerarquía de grupos que se unen entre sí a ciertas distancias. En un dendrograma, el eje y marca la distancia a la que los grupos se fusionan, mientras que los objetos se colocan a lo largo del eje x de tal manera que los grupos no se mezclan.

Las diferentes estrategias para los algoritmos jerárquicos generalmente se pueden agrupar de la siguiente manera:

Aglomerativas (bottomup): Este es un acercamiento ascendente: cada observación comienza en su propio grupo, y los pares de grupos son mezclados mientras uno sube en la jerarquía. (Ej. AGNES, Agglomerative Nesting).

6 Un dendrograma es un tipo de representación gráfica o diagramade datos en formade árbol que organiza los datos en subcategorías que se van dividiendo en otros hasta llegar al nivel de detalle deseado. Este tipo de representación permite apreciar claramente las relaciones de agrupación entre los datos e incluso entre grupos de ellos aunqueno las relaciones de similaridad o cercanía entre categorías.

44

Divisivas (topdown): Este es un acercamiento descendente: todas las observaciones comienzan en un grupo, y se realizan divisiones mientras uno baja en la jerarquía. (Ej. DIANA, Divisive Analysis)

Los métodos jerárquicos presentan un pequeño inconveniente y es que una vez que un paso se realiza (unión o división de datos), este no puede deshacerse. Esta falta de flexibilidad es tanto la clave de su éxito, ya que arroja un tiempo de computación muy bajo, como su mayor problema puesto que no es capaz de corregir errores.

Al momento de decidir cuáles grupos deberían ser combinados (para aglomerativo), o cuando un grupo debería ser dividido (para divisivo), se requiere de una medida de disimilitud entre conjuntos de observaciones.

En la mayoría de los métodos de agrupamiento jerárquico, esto se logra mediante el uso de una métrica apropiada (una medida de distancia entre pares de observaciones), y un criterio de enlace el cual especifica la disimilitud de conjuntos como una función de las distancias entre pares de observaciones de los conjuntos.

Métricas

La elección de una métrica apropiada va a influir en la forma de los clusters, debido a que algunos elementos estarán más cerca unos entre otros de acuerdo una distancia y más alejados teniendo en cuenta otra distancia diferente. Por ejemplo, en un espacio bidimensional, la distancia entre el punto (1,0) y el origen, es decir el (0,0) siempre será 1 de acuerdo con las normas usuales, pero la distancia entre el punto (1,1) y el origen (0,0) puede ser 2 según la distancia Manhattan, de acuerdo con la distancia Euclidiana o 1 de acuerdo a la distancia √2

máxima.

Las métricas más utilizadas en los algoritmos jerárquicos se presentan a continuación:

Distancia Euclidiana:

Distancia Euclidiana Cuadrada:

Distancia Manhattan:

Distancia Máxima:

45

Distancia de Mahalanobis: (S es la matriz de covarianza)

Criterios de Enlace

Como se mencionó anteriormente, especifica la disimilitud de conjuntos como una función de

las distancias entre pares de observaciones de los conjuntos. Algunos de los criterios de enlace

entre dos conjuntos de observaciones A y B frecuentemente usados son:

Agrupamiento de máximo o completo enlace:

Agrupamiento de mínimo o simple enlace:

Agrupamiento de enlace media o promedio, o UPGMA:

Agrupamiento de mínima energía:

Donde d es la métrica escogida.

46

2.5 Visualización de datos

La idea de proponer agrupaciones de servicios en clusters para realizar una refactorización de un sistema SOA es la de solucionar posibles problemas en el código y aumentar sumantenibilidad. Al realizar una herramienta que busca y genera posibles oportunidades de refactorización en dichas aplicaciones se debe idear una manera de presentar estas oportunidades, de manera de que sea fácil e intuitivo para el desarrollador o arquitecto interpretar los resultados arrojados por la misma. Para ello se estudiaron diferentes técnicas de visualización de datos con la idea de utilizar las más adecuadas. A continuación se desarrolla el concepto de visualización de datos y las técnicas de visualización utilizadas en el presente trabajo.

Gershon define visualización de la siguiente manera: Visualización es más que un método de computación. Visualización es el proceso de transformar información a una forma visual, permitiendo a los usuarios observar dicha información. La presentación visual resultante permite al científico o ingeniero percibir visualmente características que están ocultas en los datos, pero que son, de todas maneras, necesarios para la exploración y análisis de datos [Diehl, 2007].

Hoy en día, las computadoras se han convertido en una importante herramienta para crear diversos tipos de visualizaciones de datos, como así también, han ayudado al ser humano a comprender fenómenos complejos, brindando un gran aporte a la evolución del conocimiento.

El principal propósito de la visualización es dar una visión global y abstracta de un conjunto de datos. La comunicación de la información a través de imágenes ayuda a comprender las relaciones, causas y dependencias que se pueden encontrar entre las grandes masas abstractas de información que se generan en los procesos científicos, sociales y particularmente los computacionales.

La visualización de datos cuenta con varias ventajas:

Ayuda en la toma de decisiones acertadas. Cuando se cuenta con un gran volumen de datos se consigue un panorama más amplio y una mejor interpretación de la información.

La visualización y transformación de la información es lo que permite y sustenta la toma de decisiones informadas.

Mejora el análisis de datos adhoc, las visualizaciones de datos avanzadas respaldan un análisis profundo y complejo lo cual permite visualizar resultados del procesamiento de la información. De esta manera se puede obtener el análisis adecuado para una situación concreta.

Como principal desventaja se puede plantear la siguiente:

Al presentar datos ya procesados, se puede perder potencial información al no procesar dichos datos de una manera adecuada.

47

Los conceptos de visualización que se detallarán en el presente informe están relacionados con la visualización de clusters y servicios web demanera de facilitar la comprensión de las posibles refactorizaciones que se encuentren utilizando el enfoque propuesto en el presente trabajo.

2.5.1 Edge Bundles (Radial layout)

En muchas técnicas de visualización, eledge (o borde) es una importante primitiva visual para la codificación de los datos. Por ejemplo, los edges puede codificar datos relacionales en gráficas y datos multidimensionales en plots de coordenadas paralelas. Sin embargo, las visualizaciones a menudo sufren de desorden visual cuando el número de elementos de datos aumenta. El desorden visual causado por millones de bordes no sólo afecta a la calidad estética de la representación, pero también hace que sea difícil la obtención de información de la visualización [Zhou et al, 2013].

Recientemente,edge bundles (o agrupaciones de bordes) se ha convertido en una técnica común de reducción de desorden en la investigación de la visualización de la información. En edge bundles, los bordes similares se deforman y se agrupan en haz, lo que proporciona una visión abstracta y ordenada de la visualización original, la cual contaba con ruido si se quiere, ya que estaba desordenada [Zhou et al, 2013].

Existen varios enfoques sobre cómo implementar edge bundles, en este abstracto sólo se abordará el enfoque de edge bundlesradiales, los cuales resultan de gran utilidad a la hora de relacionar edges y a su vez generar una especie de separación o distinción visual de grupos de edges. En la figura 2.20 se muestra un ejemplo de edge bundles en un layout circular. En el gráfico se muestran redes de enfermedades originadas por similaridad genética.

Figura 2.20: Edge bundle.

De todos modos, cabe destacar que la utilización de la presente técnica de visualización se puede mapear también a clusters y servicios webs que se encuentren en cada cluster, de manera de poder agrupar por algún criterio los anteriormente mencionados servicios web en edges, los

48

cuales a su vez se mapean a clusters computacionales donde se encuentran deployados los servicios.

2.5.2 Tree layout

El tree layout, o disposición de árbol, se utiliza para visualizar información jerárquica. Cada elemento del árbol o ítem se denomina branch (rama) ó nodo. A su vez, cada nodo puede tener asociado un subárbol, generando así la estructura jerárquica que se desea representar en la visualización. A un nodo que no tiene asociado ningún subárbol se lo denomina nodo hoja.

Las vistas de árbol se ven a menudo en aplicaciones como por ejemplo administradores de archivos, donde permiten al usuario navegar por los directorios del sistema de archivos. Se pueden utilizar para presentar datos jerárquicos, como un documento XML. En la figura 2.21 se ve un ejemplo de un tree layout representando la estructura de archivos de una computadora.

Figura 2.21: Tree layout.

Como en el caso de la técnica de visualización anterior, también se puede utilizartree layout para mapear clusters y servicios webs que se encuentren en cada cluster. En este caso se los mapea de manera de poder agrupar los servicios web por algún criterio ensubárboles, los cuales a su vez se mapean a clusters computacionales donde se encuentran deployados los servicios, y cada nodo hoja representa un servicio web.

2.5.3 Layout mixto

De las técnicas de visualización que se mencionan en los dos puntos anteriores se puede construir una visualización mixta, que puede potenciar las bondades deledge bundle junto con

49

la capacidad de discriminar de una manera muy visual las posibles divisiones entre los grupos de elementos que están siendo graficados.

En la figura 2.22 se muestra el layoutradial cluster,enel cual se pueden ver las operaciones de una clase agrupadas por similitud en la funcionalidad ofrecida por dichos métodos.

Figura 2.22: radial cluster layout (Layout mixto).

Como se puede observar en la figura anterior, elradial cluster layout se puede utilizar también para representar clusters con operaciones de la mismamanera que los casos anteriores. Es decir que se pueden representar servicios web que están deployados en cada cluster. La idea principal es similar a la de utilizaredge bundles, cada servicio web se mapea a unedge y además de ser agrupados en los clusters correspondientes, se crean nodos intermedios que representan dichos clusters de manera de que estos existan gráficamente en el diagrama y no sean una mera agrupación de la cual se deba agregar un factor de interpretación. Los clusters existen de una manera tangible en el diagrama.

Conclusiones

En este capítulo se realizó un análisis de los conceptos más importantes que se utilizan en el desarrollo del presente trabajo. Se analizó la historia y evolución de los sistemas informáticos

50

con arquitecturas orientadas a servicios, por otro lado se analizó el proceso por el cual se definen y consumen los servicios que brindan dichos sistemas, junto con las tecnologías más utilizadas y los principales problemas que se encuentran a la hora de definir servicios con estas tecnologías.

Por otro lado se hace mención a la importancia de la refactorización como técnica de mantención y evolución de los sistemas de software y se presenta la necesidad que el presente trabajo pretende solucionar.

Finalmente se introducen los conceptos de clusterización en data mining junto con sus diferentes algoritmos y resultados también se introduce el concepto de visualización de datos y sus ventajas a la hora de analizar información. Estos conceptos son pilares para la comprensión del trabajo.

51

3. Trabajos Relacionados

Como se puede deducir de la sección 2.2, especificación de archivos WSDL, la tarea de leer e interpretar un contrato de una aplicación SOA definido en un formato basado en XML puede llegar a ser una tarea un poco difícil y engorrosa y más preocupante aún, propensa a cometer errores. Es por ello que se crean herramientas para facilitar la visualización de archivos WSDL con el objetivo de que los desarrolladores puedan leer, analizar y entender el contrato en cuestión más rápidamente.

Aunque el objetivo de este trabajo es dar soporte a la toma de decisiones a la hora de refactorizar una aplicación SOA existente, también cabe destacar que en la actualidad se utilizan herramientas que pueden generar el contrato automáticamente dado su código, es decir que siguen una metodología de desarrollo codefirst. Estos casos solamente aplican a la hora de crear un sistema o agregar funcionalidad a uno existente. Dichas herramientas no son demasiado útiles a la hora de la refactorización del sistema.

A continuación se analizarán las diferentes categorías donde actualmente existen diferentes alternativas para facilitar la interacción de los desarrolladores con los contratos WSDL y facilitando de alguna manera el proceso de refactoring en algunos casos y en otro caso en particular, asistiendo de manera explícita en dicho proceso.

3.1 Resaltadores de sintaxis

En primera instancia se pueden ver los resaltadores de sintaxis que poseen la mayoría de los IDEs. En el caso de Eclipse, una de las herramientas más utilizadas con este fin es Web Tool Platform , más conocida comoWTP. Cabe destacar queWTP no es sólo un resaltador de sintaxis 7

para archivos basados en XML, sino que también es una suite muy poderosa para desarrollar aplicaciones web.

En lafigura 3.1 se puede ver un ejemplo de un contratoWSDL visualizado en Eclipse, utilizando la herramienta WTP. El contrato es del buscador Bing perteneciente a la compañía Microsoft.

7 http://eclipse.org/webtools/

52

Figura 3.1: Visualización de un contrato WSDL en Eclipse con WTP.

Cómo se puede ver en la figura 3.1, esta porción de la herramienta no ofrece demasiados beneficios para potenciar el desarrollo de aplicaciones. Elementos como type, name, minOccurs,maxOccurstienen diferente color que sus respectivos valores demanera de facilitar la lectura y su edición así como también cada tag del archivo wsdl tiene un color diferente al de los elementos anteriormente mencionados. Se puede observar sobre el margen izquierdo el número de línea del archivo y en el caso de tags que contengan más tags como hijos en la estructura WSDL, un pequeño signo para agrupar el tag y ocultar su contenido de manera de poder eliminar ‘ruido’ de la ventana de edición.

El tiempo de adaptación a comprender rápidamente de que se está definiendo en el archivo WSDL es bastante largo y el proceso es tedioso. Por otro lado, si el contrato no es sencillo, y posee tipos de datos compuestos o los servicios requieren de parámetros de entrada y/o de salida, el panorama no es muy alentador para el desarrollador. Es costoso ver y encontrar atributos y sus valores, sin importar que tengan diferente color. Tampoco se pueden visualizar de una manera intuitiva las relaciones entre dos o más servicios, si dichas relaciones existieran. Esto requiere de un análisis bastante exhaustivo por parte del desarrollador para determinar si existe alguna relación. Por último y nomenos importante, la idea de encontrar un antipatrón de WSDL (mencionados en la sección 2.2.3) utilizando este tipo de herramientas solamente, requiere tener los conocimientos de comprender todos los antipatrones en primer lugar, y luego revisar el contrato adhoc en busca de ellos.

Por otro lado, con el objetivo demitigar esta complicaciónmencionada anteriormente que sufre el programador a la hora de crear/editar contratos WSDL con esta herramienta, se ha provisto

53

al desarrollador con una serie de cuadros de entrada, de manera de poder crear/editar el contrato de una manera visual de manera de definir cada porción del contrato.

A continuación, en la figura 3.2, se da una breve muestra de cómo se ve el editor visual de contratos WSDL.

Figura 3.2: Visualización de un contrato WSDL Editor en Eclipse con WTP.

Como se puede ver en la figura anterior, la edición del contrato WSDL es simple dado que sólo se necesita hacer click en la porción del contrato amodificar y realizar dichamodificación. En el panel derecho se pueden ver las diferentes secciones del contrato WSDL, como bindings

portTypes, messages etc.

Si se sabe qué porción del contratoWSDL se requiere editar, la operación suele ser sencilla, pero por otro lado, no se brinda soporte al desarrollador a la hora de encontrar y mitigar antipatrones, no se da soporte al refactoring de aplicaciones SOA, no se cuenta con ninguna métrica a la hora de analizar el sistema. Esta herramienta sólo debe ser utilizada a la hora de realizar cambios en los contratos WSDL.

3.2 Visualizador de WSDL

Otro enfoque diferente para complementar con los mencionados en la sección anterior son los visualizadores de WSDL. Estos presentan la información que se puede obtener de un archivo WSDL con un previo preprocesamiento, el cual hace que por ejemplo encontrar variables, ver sus tipos, analizar losporttypes, sea un menos engorroso que leer todo elWSDL o tener que utilizar una herramienta de búsqueda provista por el IDE de desarrollo. Un ejemplo de visualizadores de WSDL, en este caso web (una de sus ventajas es que es multiplataforma) es el creado por Tomi Vanek . Vanek dice que los contratos en WSDL tienen su lógica constructiva, 8

8 http://tomi.vanek.sk/index.php?page=wsdlviewer

54

pero que de todas maneras son difíciles de leer por personas noprogramadores, como puede ser el ejemplo de los stakeholders. El objetivo a la hora de crear esta herramienta fue ayudar al análisis de la interfaz del servicio WSDL, colaborando con el análisis del negocio de las aplicaciones.

A continuación también se utilizará como ejemplo el servicio del contrato es del buscador Bing. En lafigura 3.3 se ve la primer porción de información que arroja la herramienta de Vanek: el nombre del servicio, los namespaces utilizados en el WSDL, el puerto y sus características.

Figura 3.3: Visualización de un contrato WSDL en Vanek 1er porción.

En la figura 3.4 se puede ver el segundo bloque de información, correspondiente a las operaciones del contrato. Aquí, por cada operación se puede ver el port type, el estilo de binding, es decir si esRCPódocument, el tipo de primitiva de transmisión óoperation type, es decir, si es oneway, requestresponse, solicitresponse ó notification. Se define también la acción SOAP, y el input y output (en caso de que la primitiva cuente con ellos) junto con la descripción si el mensaje es literal o encoded. Por último se pueden ver los parámetros requeridos o devueltos, dependiendo de si es parámetro de entrada o de salida, que tiene el servicio, por defecto el parámetro es requerido, en caso de ser opcional se detalla con la palabra optional, y luego se detalla su tipo (int, string, etc). A fines ilustrativos sólo se muestran algunos parámetros de entrada del servicio, ya que sonmuchos. Para visualizar el contenido completo del servicio se aconseja navegar al sitio de Vanek e ingresar el WSDL 9

9 http://api.search.live.net/search.wsdl

55

http://api.search.live.net/search.wsdl

Figura 3.4: Visualización de un contrato WSDL en Vanek 2da porción.

Finalmente en la figura 3.5 se presenta el último bloque de información presentado por la herramienta de Vanek, el contrato WSDL se muestra en su totalidad, en un conveniente bloque con formato XML, resaltando la sintaxis del lenguaje. Cabe destacar también que a modo ilustrativo se presenta sólo una pequeña porción del archivo WSDL ya que su contenido es muy extenso. Para visualizar el contenido completo del contrato se aconseja navegar al sitio de Vanek e ingresar el WSDL ó navegar directamente a la URL mencionada anteriormente. 10

Figura 3.5: Visualización de un contrato WSDL en Vanek 3er porción.

10 http://api.search.live.net/search.wsdl

56

http://api.search.live.net/search.wsdl

Debido al enfoque que Vanek le dió a su herramienta, sus ventajas son bastante claras, facilita la comprensión de la interfaz del servicio, describiendo el tipo de protocolo utilizado, el tipo de operaciones, los parámetros de entrada y de salida etc. El resaltador de sintaxis utilizado no es tan bueno como el utilizado en WTP en Eclipse, pero de todas maneras también facilita la lectura de la sintaxis WSDL. Un detalle a remarcar es que los puertos y las operaciones detallados en las primeras secciones tienen links que llevan a la porción del contrato WSDL facilitando su acceso y también su comprensión.

De todas maneras, si se quiere utilizar esta herramienta para dar soporte al refactoring de aplicaciones SOA todavía hay lugar a mejoras. No se cuenta con un detector de antipatrones de WSDL, así como tampoco se puede editar el contenido del contratoWSDL. Por último no cuenta con ningún tipo de métricas asociadas a los servicios o el contrato, es solamente un visualizador de WSDLs.

3.3 WSDL Analyzer

WSDL Analyzer (WA) abarca varias cuestiones respecto de los contratos WSDL, es una 11

herramienta bastante más útil que las analizadas anteriormente a la hora de refactorizar una aplicación SOA y también cuenta con varias funcionalidades más. Por otro lado,WSDL Analyzer es una aplicación web, brindando de esta manera un soporte multiplataforma, y como condición más restrictiva el contar con acceso a internet de manera de poder utilizar esta aplicación.

Las funcionalidades que se encuentran en el WA son:

Análisis de la estructura del contrato WSDL. Análisis de los schemas embebidos e importados en el contrato WSDL. Chequeos en busca de inconsistencias. Visualización del contrato WSDL en una manera más amigable al usuario. Creación de un reporte de validación del contrato WSDL.

Por otro lado, el WA también ofrece una herramienta de comparación de versiones de los contratos WSDL, es decir lo que comúnmente es llamado“diff” en la industria del software. Se puede ver y distinguir cuáles elementos fueron agregados, modificados o eliminados y también favorece a la comprensión de cómo afectarán los cambios realizados en el contrato a la aplicación SOA.

En el caso del contrato WSDL del buscador Bing, perteneciente a Microsoft, la información presentada por el WA es la siguiente:

En lafigura 3.6 se puede ver el nombre del contrato WSDL junto con las versiones que fueron subidas al servidor del WA, de esta manera se puede utilizar la herramienta de comparación con las diferentes versiones.

11 https://www.wsdlanalyzer.com/

57

https://www.wsdl-analyzer.com/

Figura 3.6: Visualización de un contrato WSDL en WA. Información general.

En la figura 3.7 se puede ver un reporte de la información general que provee el WA. La validación de la sintaxis WSDL, un puntaje otorgado por la herramienta (no hay información disponible que describa cuales son los criterios a la hora de dar puntajes) y por último los errores, advertencias y sugerencias que encontró WA en el contrato. También se agrega la opción de visualizar un reporte detallado de las métricas donde se especifica cada validación aplicada al contratado WSDL y su resultado.

Figura 3.7: Visualización de un contrato WSDL en WA. Reporte general.

En la figura 3.8 se muestran los namespaces que se encuentran en el contrato analizado por WA. También se chequea que los objetos tengan nombres comparándolos con el formato válido.

Figura 3.8: Visualización de un contrato WSDL en WA. Namespaces.

58

En la figura 3.9 se ve la sección donde se hacen los reportes de cada versión subida al WA del contrato WSDL. Se hace una aclaración donde dice que es recomendado documentar en el contrato WSDL.

Figura 3.9: Visualización de un contrato WSDL en WA. Reporte de las versiones.

En la figura 3.10 se ven los schemas referenciados por el contrato WSDL junto con una tabla donde especifica si existe algún error, advertencia o sugerencias por parte de WA para cada schema referenciado por el contrato.

Figura 3.10: Visualización de un contrato WSDL en WA. Schemas referenciados.

En la figura 3.11 se encuentran losportTypesdel contrato WSDL, junto con una tabla donde especifica los parámetros de entrada, la salida y si existen errores para cada operación definida dentro del contrato. Finalmente se validan las operaciones y los nombres de las operaciones.

Figura 3.11: Visualización de un contrato WSDL en WA. PortTypes.

59

En lafigura 3.12 se detallan los bindings del contrato. Cada binding cuenta con una tabla donde se especifica el tipo de protocolo utilizado, el portType, el estilo y si existe alguna póliza. Finalmente se valida si el estilo es respetado o no.

Figura 3.12: Visualización de un contrato WSDL en WA. Bindings.

Por último en lafigura 3.13 se muestran los servicios que están definidos en el contratoWSDL. Una tabla describe los puertos del servicio donde se pueden encontrar el nombre, la ubicación del servicio y su documentación. Se valida el nombre de los puertos para cada servicio y por último se hacen sugerencias si corresponde en el caso. Para el contrato analizado se hace la observación de que una de las ubicaciones del servicio divulga información acerca de la tecnología utilizada en el servicio SOA.

Figura 3.13: Visualización de un contrato WSDL en WA. Servicios.

El WA es una herramienta que favorece la comparación de versiones de los contratosWSDL. Sus tests están más enfocados hacia validar la estructura del contrato y sus partes individuales, como losportTypes, estilos de bindings, etc. Por otro lado, ofrece una navegación y acceso a las diferentes partes del contrato WSDL muy buena, su interfaz es realmente simple y concisa, fácil

60

de utilizar y casi no requiere de rampup . Quizás pueda llegar a ser muy útil a la hora de 12

validar el resultado del contrato ya refactorizado y luego compararlo con su versión anterior.

De todas maneras, si se quiere utilizar esta herramienta para dar soporte al refactoring de aplicaciones SOA todavía hay lugar a mejoras. No se cuenta con un detector de antipatrones de WSDL, así como tampoco se puede editar el contenido del contrato WSDL.

3.4 SoapUI Pro WSDL Refactoring

La herramienta SoapUI es una aplicación opensource utilizada para testear aplicaciones SOA y también representational state transfer REST . Su funcionalidad abarca inspección de 13

servicios web, invocación, desarrollo, simulación y mocking, testing funcional y testing de carga. Además de las funcionalidades mencionadas anteriormente, SoapUI cuenta con una funcionalidad para realizar refactoring . Al actualizar o refactorizar un contrato WSDL, los 14

cambios en los contratos subyacentes pueden requerir cambios a todos los mensajes relacionados con una cierta modificación, por ejemplo, si un elemento se ha cambiado el nombre o movido. También, pueden necesitar ser actualizado expresiones XPath en afirmaciones, traslados y ampliaciones de propiedad, etc., para hacer referencia correctamente los elementos actualizados.

La funcionalidad de Refactorizar un contrato WSDL en SoapUI Pro apunta a facilitar enormemente este proceso de actualización, proporcionando un asistente que le permite al usuario asignar elementos de mensaje viejos a los nuevos, lo que resulta en el contenido del mensaje y las expresiones XPath actualizadas automáticamente. El usuario siempre tiene la 15

posibilidad de anular o descartar los cambios creados por SoapUI durante el proceso, asegurando que el resultado final sea el correcto.

Una vez que el contrato se encuentra importado a la herramienta, la refactorización soportada por SoapUI se puede resumir en el siguiente flujo:

1. Refactorizar las operaciones. 2. Refactorizar los mensajes. 3. Actualizar los XPath de los tests.

A continuación se mencionan algunos detalles de la utilización de la herramienta para refactorizar un contrato WSDL.

12 Rampup: Tiempo requerido para la comprensión total de la herramienta que se está utilizando.

13 REST es un conjunto coordinadode restricciones aplicadas al diseño de componentes en un sistemadehipermedia distribuida que puede conducir a una arquitectura más performante y mantenible

14 http://www.soapui.org/soapandwsdl/wsdlrefactoring.html

15 Xpath: identifica unívocamente un elemento en un archivo basado en lenguaje XML.

61

http://www.soapui.org/soap-and-wsdl/wsdl-refactoring.html

Refactorizar las operaciones

Se brinda la capacidad de mapear operaciones viejas a las nuevas en caso de ser necesario, es decir que previamente se debió hacer referencia a las dos versiones del contrato, la versión original y la versión parcialmente refactorizada. Se permite asociar operaciones viejas con las nuevas o desasociar en caso de ser necesario.

Refactorizar los mensajes

Luego de refactorizar las operaciones, actualizar elnamespace, reorganizar elementos o cambiar un elemento a un atributo o viceversa se realizan demanera automática y también se permite su verificación manual de una manera similar a la mencionada en la sección anterior. Los elementos y atributos restantes que no fueron actualizados automáticamente se los permite asociar de manera manual.

Actualizar los XPath de los tests

Aquí se muestran todas las actualizaciones a los XPath que se han realizado de manera automática y se le pide al usuario la validación manual de manera de que la versión resultante del contrato ya refactorizado sea la deseada. Los XPath que no se pudieron actualizar automáticamente se los resalta en color rojo ayudando al usuario a identificar posibles conflictos.

Los beneficios como se pueden ver del flujo descrito anteriormente, son el soporte al usuario a la hora de la refactorización de contratos WSDL a la hora de mantener la integridad en todo el sistema. Es una herramienta muy útil a la hora de realizar la refactorización.

Esta herramienta es paga, quizás se pueda considerar como un punto en contra. Por otro lado, SoapUI es útil cuando ya se ha refactorizado alguna porción del contrato WSDL y se desea mantener integridad, pero no aporta ningún beneficio en cuanto a encontrar y fundamentar que porción del contrato WSDL se debe refactorizar. Por ejemplo nomuestra antipatronesWSDL en los contratos analizados/refactorizados.

3.5 Antipattern detector

La detección de un antipatrón está fuertemente relacionada con la forma en que se manifiesta. Un antipatrón es evidente si se puede detectar sólo mediante el análisis de la estructura, o la sintaxis del documento WSDL. No inmediatamente evidente significa que la detección del antipatrón no sólo requiere de un análisis sintáctico sino también de un análisis semántico. Por último, antipatrones presentes en la ejecución del servicio no pueden mostrarse en el documento WSDL, por lo que se requiere la ejecución del servicio asociado para la detección de antipatrones.

62

Con respecto a la detección de antipatrones evidentes, Antipattern detector , desarrollada por 16

investigadores del ISISTAN, ha definido, implementado y evaluado varios algoritmos basadosen sintaxis escritos en Java. Los resultados preliminares de la medición de la precisión de estos algoritmos fueron alentadores. Al mismo tiempo, la detección de antipatrones no inmediatamente evidente presenta varios retos.

Para el antipatrón de detección de operaciones con cohesión baja en el mismo portType, los creadores del Antipattern detector están investigando una heurística basada en algoritmos de clasificación de aprendizaje automáticos. La idea es utilizar un clasificador automático para deducir el dominio de cada operación dentro de un portType y, a su vez, comprobar si los dominios deducidos son similares. Una de las dificultades que han encontrado es que la exactitud de tal clasificador se mejora si está entrenado previamente. Esto implica que las heurísticas necesitan como entrada una colección de documentosWSDL, cuyas operaciones han sido clasificadas correctamente.

En cuanto a la detección de nombres ambiguos y comentarios inapropiados, se está evaluando una heurística que combina una base de datos léxica electrónica y un analizador de lenguaje natural. El objetivo es analizar si los documentos WSDL siguen las convenciones tales como la longitud de los nombres de las partes debe ser entre 3 y 15 caracteres, los nombres de operación deben estar en la forma: <verbo> "+" <nombre>, nombres compuestos deben ser escritos de acuerdo con las notaciones comunes , etc. [Rodríguez, 2013].

Actualmente la herramienta se utiliza por consola, soportada en Linux yWindows, lo cual puede ser mejorado. Por otro lado, es una aplicación cien por ciento dedicada a encontrar antipatrones en contratos WSDL y ofrecer una manera de eliminar estos antipatrones favoreciendo así la detectabilidad del servicio.

3.6 Enfoques de clusterización con técnicas de minería de datos aplicados a servicios web

A continuación se presentan varios trabajos que utilizan técnicas de minería de datos para formar clusters de servicios web y obtener varios beneficios como por ejemplo facilitar su búsqueda utilizando un motor de búsqueda web.

3.6.1 Web service clustering using text mining techniques

Este trabajo [Liu, Wong, 2009] propone técnicas para recolectar, descubrir e integrar automáticamente características relacionadas a un conjunto de clusters y archivos WSDL y convertirlos en grupos de servicios naturalmente organizados. El conjunto de archivosWSDL se obtiene realizando una petición a algún motor de búsqueda, como puede ser Google, basado en que el tipo de archivo debe contener la extensión “.wsdl”. Luego se minan diferentes tipos de características de los contratos WSDL:content,context,service host yservice name. Luego de

16 https://sites.google.com/site/easysoc/home/antipatternsdetector

63

https://sites.google.com/site/easysoc/home/anti-patterns-detector

haber obtenido las palabras que describen las características mencionadas anteriormente de cada servicio web se separan las palabras de contenido de las palabras de funcionalidad. Seguidamente se estima la frecuencia de las palabras utilizando un conteo por página y finalmente se aplica un reconocimiento de términos especiales de clustering. Aquí se agrupan los clusters mediante algoritmos de clustering.

Luego de un análisis intensivo del enfoque aquí propuesto se llegó a la conclusión de que clusterizar servicios web en grupos con similares funcionalidad pueden reducir abruptamente el espacio de búsqueda para una tarea de un descubridor de servicios. Por otro lado se brinda la capacidad de dar servicios redundantes, es decir, en el caso de que uno de los servicios no está accesible, se puede consumir de un servicio con similar funcionalidad. Cabe destacar que para que esta técnica tenga mejores resultados, se debe contar con una buena documentación acerca del servicio en cuestión, de manera de poder clasificarlo correctamente.

3.6.2 Efficiently Finding Web Services Using a Clustering Semantic Approach

Este trabajo [Jiangang et al, 2008] propone encontrar de manera eficiente servicios web utilizando un enfoque de clustering semántico. La eficiencia de esta propuesta depende directamente de la calidad de la descripción que se brinda en el contratoWSDL. Se presenta un nuevo enfoque para encontrar demanera eficiente servicios web. Dada una consulta, primero se filtran los servicios web cuyo contenido no es compatible con la consulta del usuario a través de un algoritmo de agrupamiento, para adquirir un conjunto de datos inicial con los cuales se trabajará a continuación. El siguiente paso el enfoque de análisis probabilístico de semántica latente (PLSA de sus siglas en inglés) se aplica al conjunto de datos de trabajo, que se agrupan adicionalmente en un número finito de grupos semánticamente relacionados. En esta fase, se utiliza un enfoque PLSA para capturar los conceptos semánticos ocultos detrás de las palabras de una consulta y los anuncios en los servicios. Este método es llamado CPLSA (Clustering PLSA).

En términos generales, el método CPLSA combina el análisis sintáctico con un enfoque semántico de clustering, que se basa en mecanismos actualmente dominantes de descubrimiento y descripción de servicios web utilizando UDDI y WSDL. Las contribuciones clave en este trabajo son las siguientes:

1 Un novedoso enfoque de descubrimiento de servicios a través de la combinación la técnica de palabras claves y la semántica extraída de la descripción de los servicios.

2 Descripción del experimento preliminar para evaluar la eficacia del enfoque aquí propuesto, y los resultados mostrando mejoras sobre la exhaustividad (recall) y la precisión (precision). 17 18

17 Se trata de la proporción de material relevante recuperado, es decir, del total de los documentos que son relevantes en la base de datos, independientemente de si se recuperan o no.

64

El enfoque CPLSA se basa en la asumpción de que la eficiencia en encontrar servicios puede ser mejorada si los datos irrelevantes son eliminados de antemano, de manera de ejecutar el algoritmo de extracción de semántica posteriormente.

3.6.3 Clustering WSDL Documents to Bootstrap the Discovery of Web Services

Este trabajo [Elgazzar et al, 2010] propone utilizar cinco características claves extraídas de los contratos WSDL con el objetivo de clusterizar servicios web basándose en su funcionalidad. Con un enfoque similar a los dos trabajos presentados anteriormente se pretende extraer características de los contratos WSDL que describen el comportamiento y la semántica del servicio web, la diferencia es que este enfoque se centra en los elementos content, types, messages, ports y el nombre del servicio web que se extraen del WSDL. A continuación en la figura 3.14 se muestra un diagrama esquemático de cómo funciona el enfoque propuesto.

Figura 3.14: Esquemático de Clustering WSDL Documents to Bootstrap the Discovery of Web Services.

Se propone crear un web crawler, es decir un algoritmo que recorre constantemente la web en búsqueda de servicios web. En cuanto dicho algoritmo encuentra alguno, se le aplica el algoritmo de extracción de semántica y comportamiento y se procede a clusterizar el servicio web encontrado, de manera que cuando el usuario está buscando servicios web, la búsqueda se realiza sobre la base de datos de servicios clusterizados.

Los resultados que se han obtenido en las pruebas preliminares parecen ser alentadores, y lo que es mejor aún es que este enfoque puede ser integrado en motores de búsqueda existentes para mejorar la calidad de descubrimiento de servicios web ayudando a identificar de una manera más exacta los servicios web relevantes para el usuario.

18 Se trata de la fracción de material recuperado que es relevante a la búsqueda realizada.

65

3.6.4 Similarity Search for Web Services

Este trabajo [Dong et al, 2004], conocido también como Woogle, propone un buscador de servicios web que soporte la búsqueda por similitud, es decir operaciones que utilicen input o output similares, aquellas que se componen con un servicio dado, etc.

Se propone la utilización de un conjunto de funcionalidades que se consideran básicas para un motor de búsqueda, también se propone el uso de un algoritmo para la búsqueda por similitud, éste combina varias fuentes de evidencia para determinar la similitud. En particular se considera la similitud textual entre descripciones de operaciones de servicios web como así también la similitud de la descripción de los servicios web en su totalidad, por otro lado también se busca similitud entre los nombres de los parámetros de las operaciones. El factor principal del algoritmo aquí propuesto es la utilización de una técnica que crea clusters de los nombres de parámetros que son mapeados a conceptos semánticamente significativos. Mediante la comparación de los conceptos a los que los parámetros de entrada o salida de una operación pertenecen se puede determinar una medida de similitud.

Finalmente, se describe una evaluación experimental de más de 1500 operaciones de servicios web, la cual arroja resultados con alta precisión y exhaustividad (recall) comparado con las búsquedas por palabras claves únicamente.

3.7 Semantic clustering: Identifying topics in source code

El trabajo propuesto por Kuhn et al., 2007 sugiere el uso de técnicas de recuperación de la información para explotar la lingüística en el código fuente, como pueden ser nombres de variables y comentarios. Se introduce el clustering semántico, un técnica basada en Indexación Semántica Latente (LSI) y en clustering para agrupar artefactos de código (clases, paquetes, métodos, etc) que utilizan un vocabulario similar. A estos grupos se los llama clusters semánticos y se interpretan comotópicos lingüísticos que revelan la intención del código, la idea es soportar de alguna manera la rápida comprensión del sistema por parte de los desarrolladores. Se comparan los temas, se identifican los enlaces entre ellos, se provee de etiquetas obtenidas automáticamente y se utiliza una visualización para ilustrar cómo se distribuyen en el sistema. A continuación en la figura 3.15 se muestra el mapa de distribución de los clusters semánticos sobre la estructura de paquetes del programa JEdit.

66

Figura 3.15: Mapa de distribución de los clusters semánticos sobre la estructura de paquetes del programa JEdit.

Cada color representa una porción de semántica diferente la cual se distribuye en los paquetes que forman el programa JEdit, lo ideal sería que cada paquete tenga un sólo color, es decir que la semántica está distribuida por paquetes.

Los resultados arrojados por este trabajo muestran que la mayoría de lostópicos lingüísticos se relacionan con conceptos de la aplicación o con componentes arquitectónicos. Usualmente, el enfoque de este trabajo particiona el sistema en uno (o a veces dos) clusters que son específicos al dominio y hasta una docena de clusters que son independientes al dominio.

3.8 Comparación de los trabajos relacionados

En base a los trabajos anteriormente citados y comentados, se puede ver que existen muchas herramientas que pueden ayudar o dar sustento en la toma de decisiones a los desarrolladores de aplicaciones SOA a la hora de realizar refactoring a las mismas. A continuación se presentarán las características analizadas en cada trabajo a la hora de utilizarlos para hacer refactoring.

Usabilidad [Usabilidad]: Indica el grado de dificultad de interacción que posee la herramienta para el usuario con respecto a su utilización.

Claridad de la salida [Claridad]: Indica la claridad de los datos de salida, con qué facilidad se pueden interpretar.

Análisis de los contratos WSDL [Análisis]: Indica el grado de análisis que se puede realizar con la herramienta dados los contratos WSDL.

Detección de antipatrones [Antipatrones]: Indica el grado de detección de antipatrones que se puede realizar con la herramienta.

Detección de oportunidades de refactorización [Refactoring]: Indica el grado de detección de oportunidades de refactoring que posee la herramienta y si realiza el refactoring sobre el código.

67

Clusterización [Clustering]:Muestra el grado de clusterización que soporta la herramienta y si se pueden seleccionar diferentes tipos de clusterización.

Cada una de las características anteriormente detalladas será evaluada utilizando la escala que se puede ver en la tabla 3.1.

Excelente Muy Bueno Bueno Regular Malo

Tabla 3.1: Escala de evaluación de las características de las herramientas

A continuación, se mostrará en la tabla 3.2 la comparativa de las herramientas mencionadas con las respectivas características ponderadas.

Usabilidad Claridad Análisis

Resaltadores de sintaxis

Una vez instalado el código se resalta automáticamente.

El código es fácilmente legible.

No se realiza ningún análisis de código, salvo resaltar la sintaxis.

Visualizador de WSDL

Importar el archivo WSDL es el único paso para utilizar la

herramienta.

No se resaltan las directivas clave de los contratos WSDL y el

resaltador de sintaxis no es bueno.

No se realiza ningún análisis de código, se

resaltan las características del contrato WSDL.

WSDL Analyzer

Solamente se debe importar el archivo.

Se ofrecen varios diagramas de la

información recopilada del contrato WSDL.

Se realiza un análisis de un WSDL seleccionado a

la vez y se permite comparación con

versiones anteriores.

SoapUI Pro

68

Solamente se debe importar el archivo WSDL o el

proyecto.

No ofrece demasiada información en su salida.

No se realiza demasiado análisis. Sí se pueden explorar y ejercitar las

operaciones.

Antipattern detector

Mediante CLI.

La salida ofrecida es mediante la misma CLI por la cual se invoca.

Analiza todos los WSDL pasados por parámetro en

búsqueda de los antipatrones en WSDL.

Enfoques de clusterización para servicios

Web

Solamente abarca servicios webs publicados pero no se encontraron ejemplos de su

interfaz.

No se encontraron ejemplos de los outpus brindados por estos

trabajos.

Se hacen análisis profundos a la hora de clusterizar los servicios

webs.

Semantic clustering para código fuente

No se encontró ejemplos de su interfaz, pero aplica para cualquier código fuente.

Clusteriza código por su semántica y se lo grafica

por cluster.

Analiza la semántica del código en cuestión para formar clusters por

semántica.

Antipatrones Refactoring Clustering

Resaltadores de sintaxis

No se realiza ninguna búsqueda de antipatrones

para servicios web.

No se sugiere refactoring alguno.

No se realiza ningún análisis para clusterizar.

Visualizador de WSDL

No se realiza ninguna

No se sugiere refactoring

No se realiza ningún

69

búsqueda de antipatrones para servicios web.

alguno. análisis para clusterizar.

WSDL Analyzer


para servicios web.

No se sugiere refactoring alguno.


SoapUI Pro


para servicios web.

El refactoring es automático aunque necesita input y aceptación del programador.


Antipattern detector

Encuentra los antipatrones detectables con análisis de

WSDLs.

Sugiere soluciones para eliminar los antipatrones

encontrados.


Enfoques de clusterización para servicios

Web


para servicios web.

Se puede deducir el refactoring de algún

servicio dado el resultado de la búsqueda.

Se clusteriza utilizando algoritmos

predeterminados, no se puede seleccionar el

algoritmo.

Semantic clustering para código fuente


para servicios web.

No se remarcan las oportunidades de

refactorización, aunque se pueden deducir de los

resultados.

Se clusteriza utilizando algoritmos

predeterminados, no se puede seleccionar el

algoritmo.

Tabla 3.2: comparativa de las herramientas mencionadas con las respectivas características ponderadas

70

Las observaciones que se pueden hacer de la tabla 3.2 son en cuanto a la funcionalidad provista por cada herramienta analizada. La usabilidad resulta muy buena en la mayoría de las ellas. La claridad de su salida, output, varía dependiendo de la herramienta. Aquellas que se utilizan principalmente para facilitar la visualización de las diferentes partes o secciones de los contratos y los resaltadores de sintaxis tienen una salida relativamente buena. En el caso deldetector de antipatrones la salida no es considerada buena ya que solamente es texto. Si se tiene en cuenta el análisis realizado por la herramienta, eldetector de antipatrones junto con losEnfoques de clusterización para servicios Web y Semantic clustering para código fuente realizan un muy análisis de los contratos. En cuanto al análisis de antipatrones, solamente una herramienta de las aquí enunciadas lo soporta y obviamente es eldetector de antipatrones. Si se tiene en cuenta la refactorización como métrica, solamente dos casos de los analizados aportan grandes beneficios, SoapUI y el detector de antipatrones, en el primero El refactoring es automático aunque necesita input y aceptación del programador y en el segundo se sugieren soluciones estandares para eliminar los antipatrones detectados. Por último y no menos importante, la métrica clustering demostró ser buena en dos casos de los analizados, Enfoques de clusterización para servicios Web y Semantic clustering para código fuente.

Conclusiones

Los trabajos analizados (excepto el Antipattern detector) son herramientas que no se utilizan puramente para la refactorización de aplicaciones SOA, debido a esto se tuvieron que tener en cuenta ciertas características a la hora de evaluar dichas herramientas. Existe un amplio espectro de aplicaciones para trabajar con contratosWSDL, desde resaltadores de sintaxis hasta herramientas que clusterizan los servicios web por semántica.

Cabe destacar que elAntipattern detector sí es una herramienta creada para la refactorización de servicios web. Está desarrollada por investigadores del ISISTAN y es utilizada por el enfoque presentado en éste trabajo. También se le agregó un módulo de visualización, para dar soporte via web, permitiendo así una fácil utilización y visualización de la información aportada. Las diferentes herramientas aquí presentadas realizan diferentes análisis a los contratosWSDL (ó al código fuente de la aplicación si la funcionalidad es soportada). Por un lado se analizan antipatrones, y por otro se trata de agrupar los servicios utilizando diferentes criterios, semánticos en su mayoría. No se cuenta con una herramienta que cuente con ambas funcionalidades.

Finalmente, a la hora de clusterizar los servicios web, las herramientas que dan soporte a esta funcionalidad no permiten la selección de diferentes criterios de agrupamiento ó algoritmos de clustering.

71

4. Enfoque para Visualizar Oportunidades de Refactoring en Aplicaciones SOA

En este capítulo se describe la funcionalidad provista por el enfoque para la visualización de oportunidades de refactoring. Al mismo tiempo, se detalla la usabilidad de cada elemento del sistema para una mejor utilización de la herramienta.

4.1 Descripción del enfoque

El marco teórico de los conceptos utilizados en la realización del presente enfoque se detallaron en el capítulo 2. Por otro lado, en el capítulo 3 se presentaron herramientas que pueden asistir de alguna manera en la tarea de refactorización de un sistema SOA.

En el presente capítulo se describe el enfoque propuesto en conjunto con la herramienta creada para asistir en el proceso de refactorización de aplicaciones SOA. El objetivo principal es un enfoque de visualización de software basado en aprendizaje no supervisado para asistir a los arquitectos/desarrolladores de software en la detección de oportunidades de refactoring en aplicaciones SOA, analizando los contratos WSDL de la aplicaciones a evaluar con el fin de si hay lugar para mejoras, proponerlas de manera visual.

Se creó una herramienta web, que como entrada recibe los diferentes contratosWSDL (tanto del sistema completo o de un subconjunto de servicios web) que realiza un análisis y provee de distintos gráficos mostrando los datos que se sustrajeron de las relaciones y jerarquías de los diferentes servicios definidos en los contratos. Se presentan las relaciones entre los diferentes servicios web a través de una estrategia de visualización basada en relaciones de estos servicios y la abstracción jerárquica de los mismos. Como complemento, el enfoque permite identificar antipatrones en la arquitectura de servicios web y poder presentar una potencial solución ante este antipatrón en particular.

La aplicación realizada en el presente trabajo está basada fundamentalmente en la arquitectura clienteservidor (la cuál se abordará con más detalle en el próximo capítulo) como se puede ver en la figura 4.1, por un lado se ejecuta la generación de los datos a presentar que se obtuvieron a través de algoritmos de clustering y análisis de datos relacionales; y el por otro el ambiente donde se muestra la representación de esos datos generados por medio de una herramientaWeb interactiva que permite al usuario la posibilidad de generar sus propios gráficos de análisis.

72

Figura 4.1: Diagrama general de la arquitectura.

La herramienta cuenta con varias secciones que se irán detallando a lo largo de este capítulo junto con su funcionalidad. En la figura 4.2 se muestra un mockup de la aplicación donde se pueden ver en distintos colores las secciones generales de la UI: el Menú, Panel de opciones y Panel principal. Por otro lado semuestran los botones de navegación en azul y el botón Generate que ejecuta los algoritmos de agrupamiento y finalmente se muestra en forma de lista en cada panel la información que se muestra dependiendo del botón de navegación utilizado. A continuación se detalla cada elemento del mockup con su funcionalidad asociada.

Figura 4.2: MockUp de la aplicación.

73

4.1.1 Opciones de similitud mínima y máxima total de clusters

Figura 4.3: Opciones de similitud y total de clusters.

En la figura 4.3 se pueden observar las opciones de similitud que se utilizarán para comparar los elementos a la hora de ejecutar los algoritmos de clustering. El campo “Bottom Simil” se utiliza para cuantificar la similitud mínima entre los elementos y el campo “Top Simil” se utiliza para cuantificar la similitud máxima entre dos elementos. El campo #Clusters es utilizado en algoritmo Kmeans ya que este requiere la cantidad K de antemano (número de clusters).

4.1.2 Panel de opciones

En el panel de opciones, el cual se encuentra sobre el lado izquierdo de la aplicación, se muestran tres diferentes solapas o botones:

1. Files: Aquí se le permite al usuario seleccionar los archivos WSDL a ingresar al sistema con el objetivo de analizar las posibles oportunidades de refactoring. Una vez ingresado los archivos WSDL se pueden quitar los existentes o agregar nuevos.

2. Info: En esta sección se muestra la información obtenida de los WSDL.

3. Stats: En esta sección se muestran datos estadísticos de los contratos analizados.

En la figura 4.4 se muestra el panel de opciones con el botón de Files activado. En la figura 4.5 se muestra el mismo panel con archivos WSDL importados y seleccionados.

Para importar archivos WSDL al sistema y analizarlos, se debe hacer click enAdd y seleccionar los archivos WSDL que se deseen importar. A partir de aquí se tienen los archivos WSDL importados pero además se debe seleccionar de la lista de archivos ya importados, cuáles se van a analizar (se pueden analizar, todos, sólo un archivo o un grupo de ellos). Una vez seleccionados los archivos WSDL se procede a seleccionar el algoritmo de clustering (sección 4.1.3) y el diagrama de clustering para presentar la salida del sistema (sección 4.1.4). Por último se debe hacer click en el botón Generate para ejecutar los algoritmos con los archivos WSDL seleccionados anteriormente.

74

Figura 4.4: Panel de opciones (Files activado). Figura 4.5: Panel de opciones (Files activado) con

archivos importados.

En las figuras 4.6 , 4.7 y 4.8 se muestran las diferentes secciones del botón Info.

Figura 4.6: Información general del servicio Figura 4.7: Servicios definidos en el contrato

Figura 4.8: Anti patrones detectados en un contrato

Para que la información esté visible en la aplicación se debe seleccionar un servicio haciendo click en su nombre en alguno de los diagramas o gráficos presentados en el panel principal. El nombre del archivo, y el nombre del servicio seleccionado. En la figura 4.6 se muestra la

75

información principal del contrato WSDL seleccionado. En la figura 4.7 se muestran los servicios que se encuentran en el contrato WSDL seleccionado. Por último en la figura 4.8 se muestran los anti patrones detectados en el contrato seleccionado, y también cuando se hace click sobre el antipatrón se muestra la información relacionada con éste, una breve descripción del antipatrón encontrado y una sugerencia para eliminar el antipatrón del contrato WSDL, en caso de tener una solución recomendada.

En las figuras 4.9 y 4.10 se muestran las diferentes secciones del botón Stats.

Figura 4.9: Anti patrones detectados vs soluciones propuestas.

Figura 4.10: Estadísticas de anti patrones en un contrato.

Las estadísticas proporcionadas por la aplicación comprenden los antipatrones detectados en el/los contrato/s analizado/s. Se muestra el total de anti patrones detectados vs la cantidad de soluciones propuestas, de modo de poder analizar la cantidad de soluciones que se proponen en base al volumen de anti patrones encontrados y también el porcentaje de anti patrones detectado por contrato.

De la figura 4.6 se desprenden dos funcionalidades provistas por la aplicación las cuales pueden observar ser ejecutada mediante dos botones:

1. More Info

2. Show <nombre del archivo>.wsdl

A continuación se detalla la información presentada mediante el uso de los botones anteriormente mencionados.

4.1.2.1 Botón More Info

El botón more info abre un popup con información obtenida del contratoWSDL que está siendo

seleccionado en ese momento. Entre la información presentada por el popup se encuentran los

76

mensajes de entrada y salida de los servicios detallados en el contrato y su tipo. Si es un tipo compuesto se muestran todos los tipos hasta llegar a un primitivo (int, string, etc.).

A continuación en la figura 4.11 se muestra el popup para un contrato elegido, con la solapa de input activa.

Figura 4.11: Popup para el botón more info, sección input.

Se puede ver que se listan cada tipo de entrada para el servicio, en el caso particular de la figura

es TraerClavesAsociadasSoapIn y a su vez se listan los parámetros para cada tipo de entrada, donde se detalla el número de parámetros, el nombre, el tipo y un detalle acerca de si el parámetro es opcional, obligatorio o un arreglo de algún tipo. Análogamente, se presenta información para la salida del servicio en la solapa output. En la figura 4.12 se puede ver el detalle de la información visible, cuyo formato es el mismo que el de la solapa input.

77

Figura 4.12: Popup para el botón More Info, sección output.

Como se ve en la figura anterior, el tipo de dato del output del servicio

TraerClavesAsociadasSoapOut es un tipo de datos compuesto, de manera que se detalla debajo, en forma de acordeón, todos los tipos compuestos involucrados con el servicio anteriormente mencionado.

4.1.2.2 Botón Show <nombre del archivo>.wsdl

Una vez seleccionado un contrato WSDL en el gráfico del panel principal, cuando se accede a la

información acerca de dicho contrato, haciendo click en el botón Show <nombre del archivo>.wsdl visible en la figura 4.6 , existe la posibilidad de ver el código del archivo WSDL donde se detalla el mismo. A continuación se muestra una captura de pantalla del popup donde se muestra el código del contrato WSDL, ver figura 4.13

78

Figura 4.13: Popup para el botón More Info, sección output.

4.1.3 Panel principal

En el panel principal se muestran los diferentes diagramas con las diferentes técnicas de

visualización utilizadas en el enfoque. Por otro lado también se encuentran las opciones de los algoritmos de agrupamiento de clusters soportados por la herramienta. En la figura 4.14 se muestra el panel en su estado inicial, es decir cuando no hay ningún diagrama cargado.

Figura 4.14: Panel principal

En este panel se encontrarán los diferentes diagramas con los resultados de haber analizado los WSDL provistos a la herramienta, así como también la selección del algoritmo de agrupamiento: Hierarchical,kmeans oExpectation Maximization (EM). El botón generate que se utiliza para refrescar los diagramas en caso de haber cambiado el conjunto de archivos WSDL a evaluar y finalmente un slider con la tensión, solamente utilizada en el gráfico de edge bundle.

4.1.4 Menú

En la barra de Menú, en el sector derecho se pueden ver las opciones Home y Graphics. En el

caso de Home la única funcionalidad que ofrece es resetear la vista de la aplicación a la vista inicial, donde no se presenta ningún diagrama en el panel principal.

79

En el caso del dropdown Graphics, se presentan todos los diagramas soportados por la aplicación, las opciones son las que se presentan en la figura 4.15

Figura 4.15 : Gráficos soportados por la aplicación.

Para utilizar los diferentes gráficos, es requisito haber ingresado a la aplicación los contratos

WSDL a analizar. Una vez realizada dicha tarea, se procede a seleccionar un tipo de gráfico o diagrama de la opción Graphics y se debe hacer click en el botón Generate del panel principal.

Una vez generadas las estructuras, no es necesario volver a generar los gráficos, sólo basta con seleccionar el gráfico deseado del dropdownGraphics y el diagrama visible en el panel principal será actualizado con el gráfico elegido. Cabe destacar que si se desea agregar o quitar contratos WSDL del análisis ó se quiere utilizar un nuevo algoritmo de ordenamiento de clusters, el proceso de generar las estructuras (escogiendo los contratosWSDL/algoritmo de ordenamiento, y haciendo click en el botón Generate) deberá ser ejecutado nuevamente.

4.1.5 Panel de algoritmos de agrupamiento

En la primera sección del panel principal, figura 4.14, se pueden ver los radio buttons asociados

a cada algoritmo de agrupamiento soportado por la aplicación. Los algoritmos soportados son tres, una agrupación jerárquica, kmeans y por último Expectation Maximization.

4.1.6 Gráficos del Panel principal

Los gráficos o diagramas presentados en el panel principal se corresponden con los del menú

Graphics. La idea principal es presentar de una manera gráfica el agrupamiento sugerido por el algoritmo escogido, los cuales se detallaron en la sección anterior, de modo de separar visualmente los posibles clusters con los servicios web que debe contener cada nodo del cluster.

A continuación, en las siguientes figuras (4.16, 4.17, 4.18, 4.19 y 4.20) se muestran ejemplos de los gráficos que son soportados en la aplicación. Como se mencionó anteriormente, cuando se hace click sobre cualquier servicio web que se muestra en el gráfico que se está visualizando, la

80

información de dicho servicio web se presenta en el panel de opciones, solapainfo (figura 4.5, 4.6 y 4.7).

Figura 4.16 Inverted Radial Layout:

Figura 4.17 Bundle Layout:

Figura 4.18 Tree Layout:

Figura 4.19 Rotate Cluster Layout:

81

Figura 4.20 : Collapse Tree Layout

Como se puede ver, todos los gráficos ofrecen un agrupamiento de servicios web los cuales deben incluirse en los diferentes nodos del cluster. En el caso de la figura 4.16 y 4.17, el agrupamiento es visual, se pueden ver los diferentes grupos separados. En los casos restantes la agrupación es más tangible, en la figura 4.18 y 4.19 se pueden ver los nodos a crear, los cuales tienen un número. En la figura 4.20, se pueden ver los nodos a crear así como también se puede expandirlos y mostrar los servicios web que deben ser incluidos en dichos nodos, o de ocultarlos.

En los gráficos presentados anteriormente se puede ver el agrupamiento que se obtiene luego de haber aplicado el algoritmo de clustering seleccionado. Se muestra de una manera visual la similitud de los servicios web sugiriendo a los desarrolladores/arquitectos de la aplicación SOA evaluada, que puede haber alguna oportunidad de refactorización en cada cluster generado.

Conclusiones

En este capítulo se describió el enfoque de la herramienta, realizando una pequeña introducción al trabajo realizado y cada sección que conforman al mismo. Se describió la funcionalidad del menú, cada opción a la hora de introducir contratos WSDL y seleccionarlos para ejecutar el algoritmo de clusterización y de manera similar se describieron las opciones a la hora de configurar y seleccionar los diferentes algoritmos que tiene el sistema. Asimismo se describen las posibilidades de visualizar los contratos WSDL y sus diferentes campos, ambas opciones consisten de popups en la herramienta de manera de no entorpecer la navegación y de facilitar su uso. Finalmente se detallaron los gráficos que se muestran como salida del sistema en los cuales se ven los clusters y también las métricas que se tomaron tanto de cada contrato WSDL como del conjunto de contratos WSDL analizados.

82

5. Diseño e implementación

En este capítulo se describirán el diseño y la implementación del enfoque propuesto. Inicialmente, se realizará una introducción detallando los requerimientos funcionales y las tecnologías empleadas; luego se describirá el diseño del sistema desde el punto de vista arquitectónico por medio de vistas estáticas y dinámicas. Finalmente se analizará el enfoque por medio del diseño detallado de los distintos componentes que forman parte del sistema.

5.1 Requerimientos funcionales

El desarrollo del presente trabajo se basó en una serie de requerimientos funcionales sobre los cuales se realizaron el diseño y la implementación del enfoque propuesto. Los requerimientos fueron:

Desarrollar un ambiente donde se puedan visualizar oportunidades de refactoring de una manera gráfica e intuitiva.

Permitir seleccionar al usuario contratos WSDL a ser analizados. Permitir seleccionar qué contratos WSDL serán analizados y brindar posibilidad de

agregar o eliminar contratos al grupo de contratos importados. Permitir seleccionar al usuario más de un algoritmo de agrupamiento o clusterización

para el mismo conjunto de contratos WSDL. Señalar antipatrones en los contratos WSDL. Sugerir soluciones a los antipatrones encontrados. Mostrar de una manera gráfica la cantidad de antipatrones encontrados y la cantidad de

soluciones propuestas. Permitir al usuario seleccionar varios gráficos donde se puedan apreciar visualmente los

grupos o clusters formados como resultado de ejecutar los algoritmos. Desarrollar una interfaz sencilla demanera que el usuario pueda acceder fácilmente a las

funcionalidades más relevantes del sistema. Permitir la posibilidad de navegar los contratos WSDL que fueron analizados con un

resaltador de sintaxis que facilite su lectura. Permitir la utilización del sistema sin necesidad de instalar software local.

84

5.2 Tecnologías utilizadas

En esta sección se describirán las tecnologías adoptadas para la realización del sistema. Una de las primeras decisiones tomadas fue el ambiente de desarrollo. Como se requería no instalar ningún software para utilizar el sistema se optó por crear una aplicación con plataforma web donde los usuarios podrán importar sus WSDL y realizar las operaciones correspondientes. Como tecnología web principal se utiliza Ruby on Rails (RoR) v 2.1 ya que se basa en la 19

arquitectura Model View Controller (MVC), la cual aporta muchos beneficios a la hora de realizar una aplicación web. Por otro lado RoR cuenta con muchos componentes creados por la comunidad de esta herramienta, lo cual brinda un punto extra a la hora de decidir qué plataforma utilizar.

Para el front end de la aplicación se utilizó el framework UI llamado Bootstrap , el cuál fue 20

creado por la famosa compañía Twitter. Dicho framework facilita la maquetación de la aplicación web, no sólo agregando estilos sino que además brindamuchas funcionalidades como la creación de tabs, menús, y en general funcionalidades básicas con Javascript. También se utilizaron dos bibliotecas de Javascript, una llamada jQuery con la cual, además de realizar 21

funciones de UI también se lleva a cabo un parseo de los archivos WSDL seleccionados por el usuario y se arman los paneles de información presentados al usuario y la otra biblioteca responsable de la renderización de los gráficos llamada D3 , herramienta útil a la hora de 22

responder a cambios en nuestros datos y actualizar de manera muy fácil y transparente.

Se utilizaron dos aplicaciones web escritas en Java, la primera es la mencionada en el capítulo de trabajos relacionados, Antipattern detector, realizada por integrantes del ISISTAN. Cabe destacar que a esta aplicación se le agregó un wrapper para que pueda ser ejecutada como una aplicación web, aunque de todas maneras es tratada en este trabajo como una caja negra. La segunda aplicación web también está escrita utilizando Java, la cuál se la denomina Service Clusterer. A la hora de crear los proyectos para realizar los cambios pertinentes en la aplicación Service Clusterer se utilizó Maven.

Las dos soluciones Web integradas en la herramienta fueron acopladas utilizandoSpringBoot. Se decidió por esta herramienta ya que como ambos componentes son accesibles a través de servicios Web, SpringBoot, además de incorporar todas las soluciones web del framework, cuenta además con un servidor embebido lo cual facilita la configuración y publicación de servicios a través de un servidor Tomcat.

Para el análisis y comparación de resultados a través de métricas se utilizó la herramienta IDE RStudio, en el caso particular para el cálculo de las distancias inter e intra cluster, otorgando así las soluciones y las distancias para el algoritmo de clusterización jerárquica basados en la matriz de distancias de la herramienta.

19 http://www.rubyonrails.org/ 20 http://www.getbootstrap.com/ 21 https://www.jquery.com/ 22 http://d3js.org/

85

5.3 Diseño del enfoque propuesto

En esta sección se explicará cómo fue el desarrollo del enfoque propuesto. En primer lugar, se mostrará la arquitectura de la aplicación y, posteriormente, se desarrollará el diseño detallado del enfoque. Ambas secciones cuentan con diagramas que serán de ayuda para comprender las decisiones tomadas.

5.3.1 Arquitectura del sistema

Se propone la utilización de una arquitectura cliente servidor (Figura 5.1), debido a que uno de los requisitos fue que el usuario no debería instalar ningún tipo de software a la hora de utilizar la aplicación demodo que se decidió crear una aplicación web. La especificación del componente cliente se abordará más adelante en el informe pero con menos detalle, ya que dicho componente se mapea directamente al navegador web (browser) que utiliza el usuario a la hora de acceder a la aplicación creada.

Figura 5.1: Diagrama general de la arquitectura.

En la sección de arquitectura se realizará una descripción de la misma junto con sus principales características. En primer lugar, se mostrará una vista estática del servidor donde se verán los distintos componentes que forman parte del mismo, y luego se mostrará la interacción entre los componentes mediante una vista dinámica.

Vista estática del servidor

A continuación, en la figura 5.2 se muestra el diagrama de componentes del servidor del sistema propuesto en el presente trabajo.

Analizando el diagrama de componentes presentado en la figura 5.2 se puede ver la estructura deModel View Controller que ofrece Ruby on Rails, y luego los dos componentes encargados de realizar el análisis y clusterización de los contratos wsdl.

Por un lado el componente ServiceClusterer se encarga de realizar las clusterizaciones utilizando el algoritmo de clustering seleccionado en la UI, y devolviendo como resultado los

86

clusters de servicios en formato JSON. El componente View se encarga de la creación de las páginas en formato HTML que son renderizadas por el componente Cliente, es decir el navegador web del usuario y este procede a la presentación de dichos datos renderizando los diagramas correspondientes utilizando las librerías D3 y jQuery, incluidas por el componente View.

Por otro lado el componente Apdetector es el encargado de detectar los antipatrones en los contratos WSDL y de devolver al componente Controller dicha información junto con las potenciales soluciones a lo antipatrones observados, en el caso que hubiera alguno.

Figura 5.2: Diagrama de componentes.

Vista dinámica del Servidor

A continuación, se analizarán distintos escenarios donde puede apreciarse la interacción dinámica de los componentes arquitectónicos.

87

Escenario de calidad 1

Nota: Se omite la generación del request por parte del cliente especificando solamente el flujo de datos en el servidor con el objetivo de simplificar el escenario de calidad.

Un usuario importa archivos WSDL y genera un gráfico Inverted Radial Layout utilizando el algoritmo de agrupamiento kmeans para visualizar las oportunidades de refactorización.

Atributo de Calidad: Usabilidad. Fuente de Estímulo: El usuario. Estímulo: importa archivos WSDL y genera un gráfico Inverted Radial Layout. Ambiente / Entorno: Tiempo de ejecución. Componente / Artefacto: Sistema. Medida de Respuesta: visualización de las oportunidades de refactorización satisfactoriamente. Respuesta: Gráfico Inverted Radial Layout de los clusters generados por el algoritmo kmeans junto con la información de cuantos antipatrones tienen todos los servicios analizados. En el Use Case Map que semuestra en la figura 5.3 se puede observar el hilo de ejecución que se crean cuando el usuario quiere generar un gráfico de agrupamiento de servicios web, en este caso el Inverted Radial Layout. El flujo se inicia en el componente Controller, este toma los archivos o contratos wsdl importados por el usuario y se procede a obtener las estructuras en formato JSON que devuelve el componenteServiceClusterer que representa la agrupación de los servicios web utilizando el algoritmo seleccionado cumpliendo con la responsabilidad de “Clusterizar los WSDL utilizando kmeans” (en este caso). A su vez el componenteApdetector detecta los antipatrones y propone las soluciones a los antipatrones detectados. Ambos resultados son recibidos por el componente Controller, el cual luego selecciona la vista pertinente (en este caso la vista deInverted Radial Layout) y se comunica con el componente Model para almacenar los datos recién obtenidos y para notificar a la vista de los cambios, de manera que se comunica con el componente View. Cabe destacar que al haber simplificado el flujo de acción al ámbito del servidor solamente, se podría mencionar que los datos son finalmente renderizados en el componenteClient, que es el navegador web del usuario.

88

Figura 5.3: Use case map Escenario de calidad 1.


Luego de generado el escenario de calidad 1, el usuario selecciona una operación del gráfico Inverted Radial Layout,selecciona el tabInfo y hace click en el botónmore info, desplegando un popup con información acerca del contrato WSDL que contiene la operación seleccionada.

Atributo de Calidad: Usabilidad. Fuente de Estímulo: El usuario. Estímulo: Seleccionar una operación del gráfico Inverted Radial Layout, seleccionar el tab Info y hacer click en el botón more info. Ambiente / Entorno: Tiempo de ejecución. Componente / Artefacto: Sistema.

89

Medida de Respuesta: Visualización satisfactoria del Popup con la información acerca del contrato wsdl. Respuesta: Popup con la información acerca del contrato wsdl. En el Use Case Map que se muestra en la figura 5.4 se puede observar que el hilo de ejecución existe solamente en el componente Client ya que no se consideró necesario cargar al servidor con funcionalidad que puede ser fácilmente ejecutada por el componenteClient(El navegador web del usuario). El parseo y análisis de los contratos WSDL se realiza utilizando bibliotecas de javascript las cuales como se mencionó anteriormente, son ejecutadas en el navegador web.



Nota: Se omite la generación del request por parte del cliente especificando solamente el flujo de datos en el servidor con el objetivo de simplificar el escenario de calidad.

Luego de haber importado los archivos WSDL y haber generado un gráfico Inverted Radial Layout habiendo utilizado el algoritmo de agrupamiento kmeans, el usuario deselecciona algunos archivos WSDL y genera un nuevo gráfico Inverted Radial Layout utilizando el algoritmo de agrupamiento Expectation Maximization (EM) para visualizar las oportunidades de refactorización con el nuevo conjunto de WSDL.

Atributo de Calidad: Usabilidad. Fuente de Estímulo: El usuario. Estímulo: deselecciona algunos archivos WSDL y genera un gráfico Inverted Radial Layout. Ambiente / Entorno: Tiempo de ejecución. Componente / Artefacto: Sistema. Medida de Respuesta: visualización de las oportunidades de refactorización

90

satisfactoriamente. Respuesta: Gráfico Inverted Radial Layout de los clusters generados por el algoritmo EM junto con la información de cuántos antipatrones tienen todos los servicios analizados.

En el Use Case Map que semuestra en la figura 5.5 se puede observar que el hilo de ejecución es exactamente el mismo que el del escenario de calidad 1. La variación aquí es la selección de un conjunto diferente de WSDLs y el algoritmo que ejecuta el componenteServiceClusterer para agrupar dichos servicios. Como se puede deducir de la especificación del escenario 1 y del escenario 3, cada vez que se quiera generar un diagrama con un conjunto de WSDLs diferente al generado, o con un algoritmo diferente al del utilizado para el diagrama ya generado, se debe repetir el proceso de generación de clusters y antipatrones.

Cabe destacar también que al haber simplificado el flujo de acción al ámbito del servidor

solamente, se podría mencionar que los datos son finalmente renderizados en el componente Client, que es el navegador web del usuario.


91

5.3.2 Diseño Detallado

El proyecto ha sido organizado en 3 componentes de acuerdo a las funcionalidades:Apdetector, ServiceClustereryModelViewController. A continuación se hará una breve descripción de cada componente que conforma el sistema.Apdetector contiene todas las clases que se encargan de detectar y ofrecer posibles soluciones a algunos de los antipatrones que se pueden encontrar en los contratos WSDL. El componenteServiceClusterer contiene las clases encargadas de ejecutar los algoritmos de agrupamiento para los contratos WSDL seleccionados. Finalmente, el componenteModelViewController es el nexo entre el usuario y las funcionalidades provistas por el sistema, las clases contenidas en este componente se encargan de realizar las comunicaciones con los otros dos componentes y de crear y renderizar la información que se le presenta al usuario.

En las próximas secciones se detallarán las clases de cada uno de los componentes con sus respectivos diagramas de clases.

Componente Apdetector

Este componente corresponde a un archivo .jar, los cuales se utilizan típicamente para incluir clases java y sus respectivas dependencias demanera de empaquetar la aplicación facilitando su distribución. Como se mencionó anteriormente, esta aplicación fue desarrollada por integrantes del ISISTAN, demanera que en el presente trabajo se tomó como una caja negra, es decir que no se desarrolló ni analizó el código del componente.

La única tarea que se realizó sobre dicho componente fue la de agregarle un wrapper, un envoltorio, de manera de poder consumir los servicios de la aplicación utilizando un servidor web que provee Spring.

Figura 5.6: diseño detallado Apdetector app

Se puede observar que lo único que hace el componente Apdetector es agregar los mecanismos de comunicación para retornar los resultados a la UI en formato Json y haciendo uso de la herramienta de detección de patrones a través de una llamada a la librería.

Componente ServiceClusterer

De manera similar al anterior componente, el ServiceClusterer fue tomado de la biblioteca de software del ISISTAN, a diferencia del componente anteriormente mencionado, aquí también se le agregó el wrapper para consumir los servicios utilizando el servidor web de Spring, pero también se realizó un refactoring de la aplicación para poder proveer las estrategias de

92

clusterización tanto para Kmeans y EM. A diferencia del componente Apdetector, el componenteServiceClusterer cuenta con funcionalidad agregada para el propósito del presente trabajo. La funcionalidad inicial era la de ejecutar un algoritmo de clusterización jerárquica propio, es decir que el algoritmo está codificado sin utilizar dependencias algunas. A dicha funcionalidad se le agregó la posibilidad de ejecutar dos algoritmos de clusterización adicionales, Kmeans y EM utilizando unas librerías de la herramienta WEKA. Para ello se utilizó un patrón de diseño Strategy para definir qué estrategia de clusterización utilizar dependiendo de los parametros establecidos en la UI por parte del usuario. Esta estrategia permitirá poder agregar cualquier otro tipo de algoritmo de clusterización a la herramienta en un futuro, de manera de con sólo crear la clase del nuevo algoritmo e incluirla como implementación del patrón diseño basta para habilitar la posibilidad de ejecutar otro algoritmo.

Figura 5.7: diseño detallado ServiceClusterer app

Aquí se observa en detalle cuál fue la refactorización utilizada mostrando las nuevas clases que implementan los nuevos algoritmos de clusterización, también los resultados son enviados a la UI en formato Json incluyendo también las validaciones y las métricas de los mismos.

93

Componente ModelViewController

En cuanto al componente UI, la arquitectura respeta el flujo del framework Ruby on Rails que fue elegido para el desarrollo, se explicará brevemente cada uno de sus componentes principales.

View: Encargado de renderizar lo que el usuario ve, HTML, CSS, XML, Javascript, JSON. Aquí también se crean los gráficos necesarios para mostrar los resultados provistos por el controlador a través de librerías JavaScripts.

Model: Aquí se encuentran las clases de Ruby encargadas de validar datos, almacenamiento, lógica de negocio. Poco utilizado para el propósito del presente trabajo, únicamente para almacenar variables globales de la aplicación.

Controller: Encargado de la comunicación con las aplicaciones Apdetector y ServiceClusterer a través de servicios web que luego son enviados a la vista.

Browser(Navegador web): Aquí se producen las llamadas del usuario que luego serán mapeadas en requests específicas en el controlador utilizando el componente “Rails Routes”.

Figura 5.8: diseño detallado ModelViewController

94

Conclusiones

En este capítulo se describió el diseño y la implementación de nuestro enfoque. En primer lugar se realizó un listado de los requerimientos funcionales que debía cumplir la herramienta, donde sin entrar en detalles más específicos, se puede ver que el objetivo funcional principal es la visualización de oportunidades de refactorización. Luego se realizó la descripción de las tecnologías empleadas, donde se explicó el ambiente de desarrollo. Explicar los requerimientos funcionales y la tecnología empleada, sirvió para entender mejor las decisiones tomadas en la arquitectura y el diseño detallado del enfoque donde se pudieron ver los distintos componentes que contiene el sistema, con sus responsabilidades, sus interfaces y el diseño detallado de cada uno de ellos. También se mostraron diferentes vistas dinámicas para que se pueda comprender mejor cómo se comporta cada componente ejemplificando algunos escenarios de calidad.

95

6. Resultados experimentales

En este capítulo se describirán las técnicas de validación que serán utilizadas para analizar los resultados experimentales de la herramienta construida. Asimismo se evaluarán dos sistemas y se detallarán los resultados obtenidos, y por último se discutirán tiempos de acción sobre los sistemas, es decir un enfoque enteramente manual contra un enfoque nosupervisado.

6.1 Técnicas de validación de clusters

Existen diferentes métodos de validación, dependiendo del tipo de cluster y de las características de los datos. Éstas consisten en validar el análisis del clustering realizado, evaluando los resultados obtenidos.

La evaluación de los clusters es importante y debe ser parte de cualquier análisis de clusters. Una de las motivaciones es que casi todos los algoritmos de clustering encontrarán clusters en el conjunto de datos, aún cuando este conjunto no contenga clusters naturales en su estructura. Para evaluar el desempeño de los diferentes algoritmos de clustering, se utilizanmétricas de un enfoque no supervisado: basado en métricas que utilizan la información proporcionada a los algoritmos de agrupamiento (es decir, métricas internas).

6.1.1 Enfoque no supervisado

A continuación se detallan los criterios de evaluación para el enfoque no supervisado.

Basado en los algoritmos utilizados en el trabajo de tesis, en el enfoque seguido, el punto de partida para el análisis y validación será la del enfoque no supervisado, debido a que la técnica de machine learning que se utiliza en el presente trabajo es la de clusterización, la cual es un método no supervisado.

Las medidas nosupervisadas de la validez de un cluster a menudo se dividen en dos clases: medida de cohesión de los clusters (compacto, denso), que determina lo cercanos que están los objetos dentro del cluster, y la medida de separación (aislamiento), que determina lo distinto y bien separado que está un cluster con respecto a los otros.

96

Para evaluar la cualidad de los algoritmos propuestos, dos medidas serán analizadas: diámetros intraclusters y distancias interclusters. Se intentará defender que un aprendizaje no supervisado es una propuesta efectiva para detectar oportunidades de refactoring.

6.1.1.1 Diámetros ‘intraclusters’

Es definido como el promedio de similitud entre los elementos de cada cluster. El objetivo es minimizar esta distancia.

donde Ci representa el cluster i, K es la cantidad de clusters y mi es la cantidad de elementos pertenecientes al cluster i

6.1.1.2 Distancias ‘interclusters’

Es definido como el promedio de similitud entre los elementos dentro de cada clúster y el resto de los elementos en el conjunto de datos. El objetivo es maximizar esta distancia.

dondeci representa el elemento central (centroide) del clusteri, ycj representa el centroide del cluster j y K es la cantidad de clusters.

Figura 6.1: Diagrama de distancias inter e intra cluster.

97

En la figura 6.1 se puede ver gráficamente el concepto de cadamétrica y su objetivo. Los clusters están bien definidos cuando su diámetro intracluster es minimizado y su distancia intercluster es maximizada.

6.2 Presentación de las evaluaciones realizadas al enfoque no supervisado

En el caso de la utilización del enfoque no supervisado se hará hincapié en los valores introducidos como entrada de los diferentes algoritmos de clusterización. Para realizar dicha evaluación se deberá tomar el conjunto entero de contratos wsdl y aplicarle el algoritmo de clusterización, teniendo en cuenta la cantidad de clusters resultantes para el algoritmo jerárquico, y las métricas mencionadas en el punto anterior: distancias inter e intra clusters. Por último se analizará el error que arrojan los diferentes algoritmos. Dicha métrica es provista por la herramientawekay calcula el error a la hora de clasificar un elemento, en este caso servicios web, dentro de un conjunto de elementos.

A la hora de comparar resultados arrojados por los diferentes algoritmos que posee el sistema, se debe establecer un criterio de comparación de antemano para decidir qué algoritmo se comporta mejor que el resto para el caso de estudio en cuestión. Existen muchas maneras de comparar la calidad del modelo obtenido, una de las más utilizadas es el criterio de Schwarz [Schwarz, 1978], pero a modo explicativo en el presente trabajo se decidió utilizar el mejor resultado global en cuanto a los valores de las métricas anteriormente mencionadas, es decir que se buscará un balance en el error y las distancias inter e intra cluster, tratando deminimizar lo más posible el error y el diámetro intracluster y tratando demaximizar la distancia intercluster con el motivo de obtener los clusters mejor definidos posibles.

Cabe destacar, que como se ha mencionado en capítulos anteriores, el algoritmo jerárquico utilizado por el presente trabajo está desarrollado por integrantes del ISISTAN y fue tomado de la biblioteca de software de dicha institución, de manera que es muy costoso en magnitud de tiempo agregar soporte para detallar las mediciones que se requieren para el análisis de resultados, motivo por el cual se decidió integrar la herramienta RStudio como semencionó en el capítulo anterior.

6.3 Presentación del primer caso de estudio

Este caso de estudio cuenta con 32 contratos wsdl, en los cuales a su vez se distribuyen las 37 operaciones totales con las que cuenta el sistema.

El sistema cuenta con un total de 5032 líneas de código en contratos wsdl, y un promedio de 157 líneas por contrato. A continuación, en la figura 6.2 se pueden ver los diferentes contratos con sus respectivas cantidades de líneas de código.

98

Figura 6.2: Caso de estudio 1, cantidad de líneas de código.

Luego de seleccionar e importar todos los contratos wsdl en el sistema, se ejecutaron los diferentes algoritmos con diferentes parámetros. A continuación se detallan los resultados obtenidos.

6.3.1 Ejecución de los diferentes algoritmos de clustering para el primer caso de estudio

A continuación se detallarán los tres algoritmos utilizados en el presente trabajo para realizar las tareas de clusterización. También se presentarán los valores de las métricas mencionadas en el punto 6.2 asociadas a la ejecución de cada algoritmo, y por último se realizará una conclusión de los resultados obtenidos.

6.3.1.1 Ejecución algoritmo jerárquico

El algoritmo jerárquico que se utilizó en el presente trabajo tiene dos parámetros de entrada, bottom y top similitud, los cuales corresponden a valores utilizados por el algoritmo a la hora de decidir si un elemento pertenece o no a un determinado cluster. Cuando se cuantifica la similitud que tienen dos elementos que están siendo comparados entre sí utilizando una lógica previamente definida por los autores originales del código, se verifica que dicho resultado debe estar comprendido en el rango definido por los valores de bottom y top similitud para pertenecer al cluster en cuestión. En caso contrario ambos elementos pertenecen a diferentes clusters. En este caso los elementos que se comparan son las operaciones de los contratosWSDL junto con su tipo de datos, portypes y messages.

99

Bottom Simil Top Simil #Clusters

40 60 11

30 70 13

20 80 17

1 100 18

Tabla 6.1: Cantidad de clusters calculados por el algoritmo jerárquico.

Como se puede apreciar en la tabla 6.1, los resultados arrojados por el algoritmo jerárquico establecen que a medida que se aumenta la resolución entre bottom y top similitud la cantidad de clusters aumenta, dejando un resultado de 11 clusters comomínimo y comomáximo un total de 18 cuando las tuplas de valores bottom y top son (40, 60) y (1, 100) respectivamente.

Luego de haber ejecutado el algoritmo jerárquico y haber obtenido las cantidades de clusters para cada caso, se estableció utilizar el valor de top y bottom simil de 20 y 80 respectivamente, ya que es el último par de valores donde la cantidad de clusters cambia considerablemente. Si se sigue aumentando la diferencia entre top y bottom no se obtienen grandes cambios en la cantidad de clusters.

Con la utilización de la herramienta RStudio se calcularon las distancias inter e intra clusters para el caso con 17 clusters, los resultados se muestran a continuación en la tabla 6.2.

# Clusters InterCluster IntraCluster

17 23.5187 1.4054

Tabla 6.2: Métricas calculadas para el algoritmo jerárquico utilizando RStudio.

6.3.1.2 Ejecución algoritmo KMeans

La ejecución del algoritmo KMeans sólo ofrece un parámetro de entrada y es la cantidad de clusters en las que se agruparán los elementos. Ya que el algoritmo jerárquico resultó con 17 clusters, se decidió tomar el mismo valor para obtener valores comparables del comportamiento del algoritmo KMeans.

# Clusters InterCluster IntraCluster Error

17 20.8323 2.4268 207.0141

Tabla 6.3: Métricas calculadas para el algoritmo KMeans.

Luego para complementar los valores obtenidos utilizando la herramienta desarrollada, se calcularon los valores de las métricas inter e intra cluster para el algoritmo aquí analizado utilizando la herramienta RStudio. Los resultados se presentan a continuación en la tabla 6.4.

100

Cada técnica de clusterización tiene diferentes maneras de calcular el error a la hora de establecer si un elemento pertenece o no a un cluster. El error para un elemento es entonces, la distancia de dicho elemento al cluster más cercano. Para el algoritmo KMeans la técnica más común para calcular el error es la siguiente:

Para calcular la suma de los errores cuadrados, SSE de sus siglas en inglés, se eleva al cuadrado la distancia de los elementos al cluster más cercano y se suma:

x es un elemento en el cluster Ciymi es el punto representativo para el cluster Ci. Demanera que dados dos clusters se puede elegir a cuál de los dos clusters pertenece un elemento en particular. Por último, unamanera fácil de disminuir el valor del error (SSE) es la de aumentar el valor deK (la cantidad de clusters), aunque una buena clusterización con un K pequeño puede tener un error menor a una clusterización mala con un alto valor para K.


17 21.67501 2.243242

Tabla 6.4: Métricas calculadas para el algoritmo KMeans con RStudio.

6.3.1.2.1 Análisis del gráfico Rotate Cluster Layout

En la figura 6.3 se puede observar el gráfico generado por la aplicación para el primer caso de estudio, ejecutando el algoritmo kmeans con una entrada de 17 clusters. A primera vista se puede ver que el conjunto de clusters es efectivamente de 17, y se puede observar también cuales son las operaciones que forman parte de cada cluster. La numeración va desde 2 hasta 18 dado que el elemento 1 se considera el sistema completo.

Analizando los clusters 16 y 17, se puede ver que la semántica de las operaciones está fuertemente asociada. Todas las operaciones pertenecientes a ambos clusters brindan servicios de búsqueda de datos. Analizando más en profundidad parece evidente que en realidad son operaciones de filtrado de datos, ya que los nombres son del tipo “BuscoX...”, es decir búsqueda por algún criterio. Si se observa el clúster número 10, se puede encontrar una operación con el nombre de BusquedaApoderado, se podría afirmar que dado que no es un criterio de filtrado y en realidad es un servicio de búsqueda el algoritmo lo ha asociado a otro cluster, aunque ésto es sólo un supuesto, se necesita de un análisis posterior del código para determinar si efectivamente es conveniente esta clusterización.

Por otro lado, analizando los clusters 4, 5, 6, 7 y 8 se puede observar que existen solo 2 operaciones en cada cluster, excepto en el cluster 6 donde solamente se encuentra 1 operación y la semántica aparente de cada operación está relacionada con la obtención de datos, de modo que habría que analizar más profundamente si efectivamente es conveniente crear 8 servicios

101

web con 2 operaciones cada uno de obtención de datos, agrupar todos las operaciones de obtención de datos en 1 solo servicio web, ó determinar algún otro criterio de refactorización.

Figura 6.3: Caso de estudio 1 Rotate Cluster Layout KMeans con 17 clusters.

6.3.1.3 Ejecución algoritmo Expectation Maximization

De un modo similar al algoritmoKMeans, a la hora de ejecutar el algoritmo de clusterización Expectation Maximization (EM) también ofrece sólo un parámetro de entrada y es la cantidad de clusters en las que se agruparán los elementos. Con el objetivo de poder comparar los resultados arrojados por cada algoritmo aquí también se respetan la cantidad de clusters arrojada por el algoritmo jerárquico.


17 21.5614 2.5200 175.7681

Tabla 6.5: Métricas calculadas para el algoritmo ExpectationMaximization.

102

En la tabla 6.5 se pueden ver las métricas que arrojó la ejecución del algoritmo EM para una cantidad de clusters de 17.

6.3.1.3.1 Análisis del gráfico Rotate Cluster Layout

En la figura 6.4 se puede ver el gráfico resultante de correr el algoritmoEM con una entrada de 17 clusters, los cuales se pueden ver en los diferentes grupos generados en el diagrama.

Figura 6.4: Caso de estudio 1 Rotate Cluster Layout EM con 17 clusters.

Analizando los clusters 15 y 16, se puede ver que como en el caso deKMeans, la semántica de las operaciones está fuertemente asociada, todas las pertenecientes a ambos clusters brindan servicios de búsqueda de datos. Una situación similar se dá en los clusters 11, 12, 13 y 14 dado que las operaciones pertenecientes a dichos clusters están asociadas en una semántica de obtención de datos de un aparente servicio externo. Cabe destacarse que la operación BuesquedaApoderadodel clúster 12 podría hallarse allí por un error del algoritmo dado que su semántica parece no estar en línea con las otras operaciones, por lo que habría que analizar el tipo de datos que utiliza la operación, ya que podría ser el mismo que las que utilizan el resto de operaciones en el grupo de clusters previamente mencionado.

103

Finalmente se puede observar el mismo problema aparente con el que contaba el caso de KMeans analizado anteriormente, donde la semántica de obtención de datos se distribuye en operaciones en los clusters 4, 5, 6, 7, 8 y 9. Por último, en el cluster 2 y 4 se pueden ver operaciones que parecen no estar del todo asociadas al resto (AltaRelaciones y ListarPersxDoc respectivamente), aunque también en este caso habría que corroborar los tipos de datos utilizados en las operaciones del cluster.

6.3.1.4 Conclusiones

Luego de haber ejecutado los algoritmos con los mismos parámetros de entrada se pueden ver diferencias en las métricas arrojadas y obviamente en los resultados que se obtendrán utilizando las salidas particulares de los algoritmos.

Analizando las distancias inter e intra clusters obtenidas se puede ver que el algoritmo jerárquico tiene la menor distancia intercluster, lo cual es beneficioso a la hora de clusterizar elementos. En la tabla 6.6 se pueden ver los resultados obtenidos.

Inter Cluster (aplicación)

Inter Cluster (RStudio)

Intra Cluster (aplicación)

Intra Cluster (RStudio)

Error (aplicación)

Jerárquico 23.51875 1.405454

KMeans 20.8323 21.6750 2.4268 2.2432 207.0141

EM 21.5614 2.5200 175.7681

Tabla 6.6: Comparativa de métricas calculadas.

El algoritmo jerárquico cuenta con una distancia intercluster de 23.51875, el algoritmo KMeans cuenta con 20.8323 utilizando las métricas provistas por la herramienta (ó 21.6750, métrica provista por la herramienta RStudio, se puede ver que las métricas no difieren demasiado entre sí). Y por último el algoritmo EM arrojó una distancia intercluster de 21.5614. Como se puede ver la mayor distancia intercluster la tiene el algoritmo de EM.

Analizando la métrica de distancia intracluster los resultados dan que el algoritmojerárquico para 17 clusters cuenta con una distancia de 1.405454, el algoritmo KMeans cuenta con una distancia de 2.4268 (ó 2.243242, métrica provista por la herramientaRStudio, también se puede ver que las métricas no difieren demasiado entre sí). Y por último el algoritmo EM cuenta con una distancia intracluster de 2.52. La menor distancia intercluster se obtiene en el algoritmo Jerárquico.

Se podría concluir que a la hora de cuantificar los resultados obtenidos, ningún algoritmo se destacó más que otro, lo cual deja a criterio del usuario qué algoritmo utilizar. En este caso puntual se podría decidir utilizar el algoritmo jerárquico ya que es el que mejor resultados globales ha arrojado, aunque como se mencionó anteriormente dichos resultados no

104

corresponden directamente al algoritmo ejecutado por la aplicación sino que corresponden a los resultados arrojados por la herramienta RStudio.

Cabe destacar que la métrica de error que brinda la herramienta RStudio no utiliza el mismo algoritmo que se utilizó en las métricas hasta aquí obtenidas, de modo tal que se ignora. Por otro lado debido a que el algoritmo jerárquico que se utilizó en el presente trabajo fue creado por otros alumnos de la carrera, agregar una funcionalidad para que las métricas sean calculadas de forma automática es muy costoso en calidad de tiempo y beneficio, motivo por el cual se decidió utilizar RStudio a modo comparativo.

El algoritmo KMeans fue ejecutado con la herramienta RStudio con los mismos sets de contratos WSDL solamente a modo comparativo, se decidió no realizar la misma comparación con el algoritmo EM dado que no es relevante al enfoque del trabajo presentado.

6.3.2 Antipatterns para el primer caso de estudio

Para el presente caso de estudio la herramienta ha encontrado algunos de los antipatrones que fueron mencionados en el capítulo 2. A continuación se puede ver la discriminación de los antipatrones, el total de antipatrones detectados y el total de soluciones que se sugieren:

"Enclosed data model" 37 "Empty messages" 32 "Whatever types" 32

"Ambiguous names" 215 "Redundant data models" 1

"Low cohesive operations in the same porttype" 1 "Redundant porttypes" 48

El total de antipatrones detectados fue de 366 y el total de soluciones propuestas 300.

Figura 6.5: Caso de estudio 1, cantidad de Antipatrones detectados y soluciones propuestas

Figura 6.6: Caso de estudio 1, porcentaje de cada antipatrón detectado.

105

En las figuras 6.5 y 6.6 se pueden observar la cantidad de antipatrones detectados en el caso de estudio 1 junto con las soluciones propuestas y el porcentaje de cada antipatrón detectado respectivamente.

6.4 Presentación del segundo caso de estudio

Este caso de estudio cuenta con 211 contratos wsdl, en los cuales a su vez se distribuyen las 259 operaciones totales con las que cuenta el sistema, un promedio de ~1.2 servicios por contrato WSDL.

106

Figura 6.7: Caso de estudio 2, cantidad de líneas de código.

El sistema cuenta con un total de 38701 líneas de código en contratos wsdl, y un promedio de ~183,42 líneas por contrato. A continuación, en la figura 6.7 se pueden ver los diferentes contratos con sus respectivas cantidades de líneas de código.

6.4.2 Ejecución de los diferentes algoritmos de clustering para el segundo caso de estudio

Del mismo modo que para el primer caso de estudio, a continuación se detallarán los tres algoritmos utilizados para realizar las tareas de clusterización. También se presentarán los

107

valores de las métricas mencionadas en el punto 6.2 asociadas a la ejecución de cada algoritmo, y también se realizará una conclusión de los resultados obtenidos.

6.4.2.1 Ejecución algoritmo jerárquico

A continuación se presentan los resultados obtenidos de las diferentes ejecuciones del algoritmo jerárquico.

Bottom Simil Top Simil #Clusters

40 60 17

30 70 24

20 80 32

Tabla 6.7: Cantidad de clusters calculados por el algoritmo jerárquico

Como se puede apreciar en la tabla 6.7, los resultados arrojados por el algoritmo jerárquico establecen que la cantidad de clusters es de 32 utilizando el mismo par de valores bottom y top simil que para el caso de estudio anterior.

Aquí nuevamente se ha utilizado la herramientaRStudio para calcular las distancias inter e intra cluster que arroja el algoritmo jerárquico para el conjunto WSDL en análisis y dando como resultado 32 clusters. En la tabla 6.8 se presentan los resultados del RStudio.


32 15.01825 3.132723

Tabla 6.8: Métricas para el algoritmo jerárquico utilizando RStudio.

6.4.2.2 Ejecución del algoritmo KMeans

De manera similar al punto 6.3.1.2, se tomó la misma cantidad de clusters arrojados por el algoritmo jerárquico como entrada del algoritmo KMeans. En la tabla 6.9 se pueden ver los resultados.


32 14.6942 3.0853 1774.5102

Tabla 6.9: Cantidad de clusters calculados por el algoritmo KMeans

Similarmente al primer caso de estudio, para complementar los valores obtenidos se calcularon las métricas inter e intra cluster para el algoritmo aquí analizado utilizando la herramienta RStudio. Los resultados se presentan a continuación en la tabla 6.10.

108


32 13.5323 3.5283

Tabla 6.10: Métricas calculadas para el algoritmo KMeans con RStudio.

6.4.2.3 Ejecución del algoritmo Expectation Maximization

Del mismo modo que en el punto anterior, se tomaron los resultados arrojados por el algoritmo jerárquico como entrada del algoritmo EM. Los resultados se presentan a continuación en la tabla 6.11.


32 15.0936 3.1728 1809.5051

Tabla 6.11: Cantidad de clusters calculados por el algoritmo EM.

6.4.2.5 Conclusiones

De la misma manera que en el caso de estudio anterior, se presentan las comparativas de los resultados obtenidos en la tabla 6.12.

Inter Cluster (aplicación)

Inter Cluster (RStudio)

Intra Cluster (aplicación)

Intra Cluster (RStudio)

Error (aplicación)

Jerárquico 15.01825 3.132723

KMeans 14.6942 13.5323 3.0853 3.5282 1774.5102

EM 15.0936 3.1728 1809.5051

Tabla 6.12: Comparativa de métricas calculadas.

Como se puede ver en la tabla 6.12 la distancia inter cluster para el algoritmojerárquico es de 15.01825, mientras que para el algoritmo KMeans dicha distancia es de 14.6942 (ó 13.5323, métrica provista por la herramienta RStudio, se puede ver que las métricas no difieren demasiado entre sí). Finalmente la distancia inter cluster para el algoritmoEM es de 15.0936. Como se viene haciendo hincapié, la distancia inter cluster debe ser maximizada, demodo que el algoritmo que arroja un mejor resultado es el de EM.

Para la métrica intra cluster el algoritmo jerárquico arrojó un resultado de 3.132723. El algoritmo KMeans para dicha métrica arrojó 3.0853 (ó 3.5283, métrica provista por la herramientaRStudio, donde se puede ver que los valores no difieren demasiado entre sí). Y por último la distancia intra cluster para el algoritmoEM es de 3.1728. El algoritmo que demuestra mejor desempeño con la configuración planteada es aquel que minimiza la distancia intra cluster, y en el caso puntual de este caso de estudio el algoritmo es elKMeans si se toman los

109

valores de la aplicación, aunque si se toman los valores de la herramientaRStudio el algoritmo que arroja menor distancia intra cluster es el jerárquico.

De nuevo aquí se podría concluir que a la hora de cuantificar los resultados obtenidos, ningún algoritmo se destacó más que otro. En el caso puntual del presente caso de estudio se podría decidir utilizar el algoritmo Kmeans ya que es el que arrojó mejor resultados globales.

Por último, mencionar que las mismas notas acerca de las métricas calculadas y los resultados “” visibles en la tabla 6.12, son debido a las mismas razones presentadas en los comentarios sobre la tabla 6.6 en el punto 6.3.1.4 del presente capítulo.

6.4.4 Antipatterns para el segundo caso de estudio

De manera similar al caso de estudio anterior, se utilizó la herramienta desarrollada para conocer los antipatrones presentes en el segundo caso de estudio. Los antipatrones y sus ocurrencias son detallados a continuación junto con la cantidad total de antipatrones encontrados y las soluciones propuestas:

"Enclosed data model" 211"Empty messages" 211"Whatever types" 211

"Ambiguous names" 2708 "Redundant data models" 22

"Low cohesive operations in the same porttype" 22 "Redundant porttypes" 633

El total de antipatrones es de 3807 para los cuales propone solución para 3657 antipatrones.

Figura 6.8: Caso de estudio 2, cantidad de Antipatrones detectados y soluciones propuestas

Figura 6.9: Caso de estudio 2, porcentaje de cada antipatrón detectado.

En las figuras 6.8 y 6.9 se pueden observar la cantidad de antipatrones detectados en el segundo caso de estudio junto con las soluciones propuestas y el porcentaje de cada antipatrón detectado respectivamente.

110

6.5 Comparación resultados manuales vs no supervisados

En conjunto con el análisis del segundo caso de estudio luego de haber utilizado la herramienta desarrollada, se realizó un trabajo en paralelo para poder comparar un caso práctico de refactorización automatizado contra un caso de refactorización manual.

A continuación se detallarán factores claves a la hora de la búsqueda de oportunidades de refactoring utilizando un enfoque manual y se compararan las oportunidades encontradas por ambos enfoques y también se comparará el tiempo total invertido para ello.

Es importante mencionar que en el caso de la refactorización manual, el desarrollador encargado de realizarla construyó un pequeño servicio web de manera de poder importar contratos WSDL luego de haberles realizado modificaciones y especificar la semántica de un servicio a extraer del contrato, pudiendo así generar como salida un nuevo contrato WSDL con todos los servicios extraídos.

6.5.1 Descripción del enfoque manual utilizado

A continuación se hará una breve descripción de puntos claves que definen el enfoque manual utilizado en este experimento. Se detallará el criterio de refactorización a la hora de buscar las oportunidades, qué oportunidades se encontraron y por último los resultados obtenidos luego de refactorizar las oportunidades encontradas haciendo especial hincapié en el tiempo consumido por el proceso de refactorización.

6.5.1.1 Criterio de refactorización utilizado en el enfoque manual

En primer instancia se hizo un relevamiento de todos los contratos wsdls a refactorizar detectando oportunidades de refactorización como por ejemplo el uso de los mismos tipos de datos por dos o más servicios y también se intentó buscar servicios con funcionalidad repetida.

Luego se decidió agrupar o clusterizar los servicios que comparten las oportunidades de refactorización mencionadas anteriormente junto con los servicios que comparten una misma semántica. Es decir que por ejemplo se agruparon los servicios que dan Alta a entidades, se agruparon los que dan Baja a entidades y los que modifican dichas entidades. El resultado de este agrupamiento resulta en tres contratosWSDL: darAlta.wsdl, darBaja.wsdl y modificar.wsdl que abarcan todas las altas bajas y modificaciones respectivamente que se nombraron anteriormente.

6.5.1.2 Oportunidades de refactoring encontradas utilizando el enfoque manual

A continuación en la tabla 6.13 se detalla la lista de refactorizaciones por semántica, incluyendo los contratos wsdl refactorizados por semántica y la cantidad de LOC antes y después de la refactorización. La columna #S representa la cantidad de servicios refactorizados.

111

Nuevo Servicio Servicios Refactorizados #S LOC Antes

LOC Después

darAlta 23 1. AbmArchivoAcreedores 2. AbmArchivoClientes 3. AbmArchivoCreditosRecibosInterrumpidos 4. AbmArchivoProveedores 5. AbmArchivoRecibos 6. AbmArchivoVendedores 7. AbmArticulos 8. AbmChequesEnCartera 9. AbmChequesRechazados 10. AbmClientesGestionJudicial 11. AbmComisiones 12. AbmComprasSinInventario 13. AbmCondiciones 14. AbmConsultaArchivoTelefono 15. AbmFletes 16. AbmMensajesClientes 17. AbmOtrosDeudores 18. AbmPedidos 19. AbuInterdepositos 20. AltasYBajasDevolucionBolsas 21. AltasYBajasTalonariosRecibosProvisoriosEnviados 22. AltasyBajasRecibosProvisoriosAnulados 23. BajaChequesEndosadosNoRechazados 24. BajaIngresosYAjustesStock 25. BajaLibroOrdenesPago 26. CajaIngresosYEgresos 27. ModificacionesArrastreCaja 28. ModificacionesComisiones

28 8838 2708

darBaja1 2221

modificacion1 2242

Anulador 1. AnulacionEntregaMercaderiaSinFacturaConPedido 2. AnulacionFacturasMercaderiaNoEntregada 3. AnulacionRecibos 4. AnulacionRemitosMercaderiaEntregada

4 683 554

ArmadorDeArchivos 1. ArmaRegistroRetenciones 2. ArmadoArchivosComunicacionCartaPorteRecibidas 3. ArmadoCitiCompras 4. ArmadoSicorePercepcionesIngresosBrutos 5. ArmadoSicoreRetenciones 6. ArmadoSicoreRetencionesIngresosBrutos 7. GeneraArchivoDgiMoliendaTerceros

7 1066 808

ControladorDeRecibos

1. ControlNumeracionRecibos 2. ControlRecibosProvisoriosEnviadosRecibidos 3. ControlRecibosProvisoriosRecibidos

4 452 363

ControladorDeRecibosSalidaExcel

1. ControlRecibosProvisoriosEnviadosRecibidosSalidaExcel 2. ControlRecibosProvisoriosRecibidosSalidaExcel

2 310 263

CreadorNotasCreditoDebito

1. NotaDeCreditoSinRemitoConPedidos 2. NotasDebitoChequesRechazados

2 422 375

23 darAlta, darBaja y modificación surgen de los servicios que tienen las operaciones de alta baja y modificación de datos, es decir que los nuevos servicios (darAlta, darBaja y modificación) agrupan cada operación para todos los servicios.

112

EmisorDeDocumentos 1. EmisionCartasPorte 2. EmisionConFacturaDeCredito 3. EmisionManualCreditosCobranza 4. EmisionOrdenesPagoYComprobantesRetenciones 5. EmisionRecibos 6. EmisionRecibosCobroDeudores

6 1194 976

EntregadorDeMercaderia

1. EntregaMercaderiaSinFacturaConPedido 2. EntregaMercaderiaSinFacturaConPedidoParaExportacio

n 3. EntregaMercaderiaSinFacturaNiPedido

3 610 399

Facturador 1. FacturacionManualFletes 2. FacturacionMercaderiaYaEntregada 3. FacturacionPedidos 4. FacturacionPedidosSinEntregaMercaderia 5. FacturacionPedidosSinEntregaMercaderiaExportacion 6. FacturacionSinPedidos 7. FacturacionSinPedidosConceptosVariosExportacion 8. FacturacionSinPedidosMercaderiaAEntregar

8 1527 1193

ImpresorDeDocumentos 1. ImpresionArchivoTelefono 2. ImpresionCarteraInterdepositos 3. ImpresionCuentasOtrosDeudores 4. ImpresionFacturaCredito 5. ImpresionLibroBancos 6. ImpresionLibroCartasPorteEmitidas 7. ImpresionLibroOrdenesPago 8. ImpresionTotalesMovimientosStockMensual 9. ImpresorCarteraDocumentosACobrar 10. ImpresorPreciosPromedios 11. ImpresorPreciosPromediosTrigo

11 1754 1328

Limpiador 1. LimpiaMercaderiaAEntregarDonaciones.wsdl 2. LimpiezaCuentasCorrientes.wsdl 3. LimpiezaEstadisticas.wsdl 4. LimpiezaKardex.wsdl 5. LimpiezaLibroCompras.wsdl 6. LimpiezaLibroIva.wsdl 7. LimpiezaLibroRecibos.wsdl

7 934 679

ListadorCaja 1. ListaContabilizaBorraCaja 2. ListadoCajaOrdenMayor

2 307 262

ListadorCheques 1. ChequesAFechaPorZonaMes 2. ListadoChequesRechazados 3. ListaHischeq 4. ListadoChequesRecibidos

4 686 555

ListadorClientes 1. InformeClientesParaSecretariaComercio 2. InformeClientesParaSecretariaComercioHarina000 3. ListadorArchivoClientes 4. ListadorArchivoClientesMonotributistas

4 616 484

ListadorCobranzas 1. CobranzaClientesPorZona 2. CobranzaPorZonaMes 3. ListadoHistoriaCobranzas 4. ListadoTotalesCobranzaMensual

4 607 477

113

ListadorCuentas 1. CuentasCorrientesAcreedoresPorPantalla 2. CuentasCorrientesPorPantalla 3. CuentasCorrientesProveedoresPorPantalla 4. CuentasCorrientesVendedoresPorPantalla 5. CuentasEnGestionJudicialPorPantalla 6. CuentasOtrosDeudoresPorPantalla 7. ListadorCuentaCorrienteBolsas 8. ListadorCuentasAcreedores 9. ListadorCuentasCorrientes 10. ListadorCuentasCorrientesEnGestionJudicial 11. ListadorCuentasProveedores 12. ListadorCuentasVendedores

12 2104 1604

ListadorDeudas 1. DeudasPorPantalla 2. DeudoresQueExcedenTope 3. ListaDeudasND30 4. ListadorDeudas 5. ListadorDeudasChequesRechazados 6. ListadorDeudasChequesRechazadosCartaConvalidando 7. ListadorDeudasChequesRechazadosCartaReclamo 8. ListadorDeudasParaVendedor 9. ListadorDeudasUnCliente

10 1527 1058

ListadorEstadisticas 1. ListadorEstadisticas 2. ListadorEstadisticasSegunCondicionIva

2 299 253

ListadorFormatoExcel 1. ArmadoListadosSubsidiosSalidaExcel 2. BalanceCuentaDeudasYCuentaCorrienteSalidaExcel 3. BalanceMovimientosCuentasProveedoresAcreedoresSal

idaExcel 4. BalanceSaldosClientesSalidaExcel 5. CruceTotalesMovimientoMercaderiasSalidaExcel 6. DescuentosConcedidosPorZonasMesSalidaExcel 7. ExcelParaInformeOnca 8. ExcelParaSubsidios 9. ImpresionArchivoTelefonoSalidaExcel 10. LibroVentasPorImputacionAPedidoSalidaExcel 11. ListaMayorSalidaExcel 12. ListaSaldosPedidosSalidaExcel 13. ListaSituacionTrigoUnaFechaSalidaExcel 14. ListadoChequesRecibidosSalidaExcel 15. ListadoComisionesPorVendedorMesSalidaExcel 16. ListadoDeudoresGestionJudicialPorZonaMesSalidaExcel 17. ListadoDeudoresPorVentasZonaMesSalidaExcel 18. ListadoFacturadoClienteEntreFechasAPedidoSalidaExcel 19. ListadoLibroIvaComprasEnlaceExcel 20. ListadoVeintePrimerosDeudoresAcreedoresProveedore

sSalidaExcel 21. ListadorCuentasAcreedoresSalidaExcel 22. ListadorDeudasChequesRechazadosSalidaExcel 23. ListadorDeudasParaVendedorSalidaExcel 24. ListadorLibroIvaSalidaExcel 25. ListadorLibroIvaSalidaExcelVariosPeriodos 26. ListadorNotasDebitoCreditoCerealSalidaExcel 27. MercaderiaAEntregarPorZonaSalidaExcel 28. PedidosPendientesPorZonaSalidaExcel 29. TalonariosEntregadosSalidaExcel 30. VentasPorZonaSubproductoMesSalidaExcel 31. VentasPorZonaSubproductoMesSalidaExcelDetalle

31 4923 3647

114

ListadorIngresosEgresos 1. ListadoCajaOrdenIngresosEgresos 2. ListadoCajaOrdenIngresosYEgresos

2 309 155

ListadorLibroIva 1. ListadoLibroIvaCompras 2. ListadoLibroIvaComprasDeProveedor 3. ListadoTotalesLibroIvaCompras 4. ListadorLibroIva 5. ListadorLibroIvaEntreFechas 6. ListadorPercepcionesLibroIva

6 1005 788

ListadorMercaderia 1. ConsultaListaMercaderiaAEntregar 2. MercaderiaAEntregarPorZona

2 320 274

ListadorMovimientos 1. BusquedaMovimientosRepetidosMercaderiaAEntregar 2. ListadorMovimientosCuentasAcreedoresPorVencimient

o 3. MovimientoCliente

3 490 401

ManejadorDeCreditos 1. CreditosPorDevoluciones 2. DebitosCreditosVarios 3. DebitosCreditosCompraCereal

3 606 459

ObtenerBalanceCuentas 1. BalanceCuentaDeudasYCuentaCorriente 2. BalanceCuentasCorrientesGestionJudicial 3. BalanceDeudasCuentasCorrientes 4. BalanceEntreCuentasCorrientesYArrastreSaldos

4 578 449

ObtenerBalanceMovimientos

1. BalanceMovimientosCuentasCorrientes 2. BalanceMovimientosCuentasProveedoresAcreedores

2 296 251

ObtenerBalanceSaldos 1. BalanceSaldosAcreedoresProveedores 2. BalanceSaldosClientes

2 316 258

TOTAL - 231 32779 25484

Tabla 6.13: lista de refactorizaciones por semántica

6.5.1.3 Resultados obtenidos utilizado el enfoque manual

Se obtuvieron un total de 29 clusters que en promedio contienen alrededor de 8 operaciones cada uno. En la Tabla 6.14 se puede ver el tiempo que tomó todo el proceso de refactorización dividido en las etapas relevantes del mismo.

Etapa Duración

Relevamiento de los servicios web existentes y agrupamiento por semántica. 6:50 horas.

Creación del servicio web. 8:30 horas.

Creación de los nuevos contratos WSDL. 17:40 horas.

Total 33 horas.

Tabla 6.14: Duración del proceso de refactorización divido en etapas.

115

Como se puede observar en la Tabla 6.14, el proceso de refactorización tomó 33 horas netas, de las cuales 6:50 horas fueron dedicadas al relevamiento de los servicios web existentes en búsqueda de oportunidades de refactorización. Este número es importante ya que con la utilización del enfoque propuesto en el presente trabajo se espera reducir la cantidad de horas invertidas en dicho punto dramáticamente.

Por último, cabe destacar que el desarrollador a cargo del enfoque manual no encontró posibilidad de refactorización en 28 servicios web, los cuales quedaron en su estado original. Esto se debió a que la semántica de éstos servicios web no encajaba de manera lógica en los clusters formados por el desarrollador a la hora de buscar las oportunidades de refactorización.

6.5.2 Comparación de oportunidades de refactoring detectadas en cada enfoque

Respetando los resultados arrojados en el caso de estudio 2, a la hora de ejecutar el algoritmo KMeans con una entrada de 32 clusters para respetar los valores obtenidos en el caso de estudio 2. Dichos resultados serán utilizados para realizar una comparación entre ambos enfoques.

A continuación en la tabla 6.15 se detallarán las oportunidades de refactoring que se detectaron utilizando el enfoque automático.

#CL Servicios #CL Servicios 1 ObtenerListadoChequesRecibidosSalidaExcel 7 EmitirCartaPorte ObtenerListadoChequesRecibidos ObtenerListadoPagado ObtenerListadoChequesRechazados ObtenerListadoDuplicadosOrdenesPago

2 AltaCompraSinInventario ObtenerListadoDeudores ComplementarRecibos ObtenerListadoNotasDebitoCredito EmitirRecibos EndosarCheque ObtenerListadoCarteraDocumentosACobrar ObtenerListadoOnca

3 BajaCompraSinInventario ObtenerListadoSubsidios ObtenerBalanceEntreCuentasCorrientesYArrastreSaldos ArmarSicoreRetenciones ObtenerListadoCobranzasPorZona ObtenerListadoHarinaVendida BajaAcreedor ObtenerListadoDescuentos

BajaTelefono ObtenerListadoDeudoresGestionJudicialPorZonaMesSalidaExcel

AltaComision ArmarListadosSubsidios BajaProveedor GenerarListadoCheques ObtenerListadoTelefonos LiquidarOrdenPago ObtenerListadoTalonariosEntregados ObtenerListadoLibroCartasPorteEmitidas VerificarCuit ObtenerListadoLibroOrdenesPago AltaMensaje AcoplarASicore

116

ModificacionMensaje EmitirOrdenPagoYComprobanteRetencion BajaMensaje ArmarSicorePercepcionesIngresosBrutos ControlarRecibosProvisorios ObtenerListadoPercepcionesLibroIva ObtenerInformeClientes ArmarRegistroRetenciones ObtenerListadoSaldosPedidos ObtenerListadoRecibos DarBajaCheque ObtenerListadoNuevoLibroIva VerificarEstadoArchivoFacturacion ControlarSecuenciaLibroIva ObtenerBalanceDeudasCuentasCorrientes ControlarNumeracionRecibos VerificarPadronIngresosBrutos RealizarDeposito ConvertirPadronIngresosBrutos 8 CruzarTotalesMovimientos

ObtenerListadoMayor ObtenerListadoVentasPorZonaSubproductoMesSalidaExcelDetalle

ObtenerListadoDeudoresPorVentasZonaMesSalidaExcel ObtenerListadoMovimientosCliente ObtenerListadoComisionesPorVendedorMesSalidaExcel

ObtenerListadoVentasPorZonaSubproductoMesSalidaExcel

GenerarArchivoDgi ObtenerListadoMercaderiaAEntregar LimpiarLibroCompras 9 AltaAcreedor AltaReciboProvisorio ModificacionAcreedor BajaReciboProvisorio AltaProveedor AltaTalonario ModificacionProveedor BajaTalonario AltaCaja AltaDevolucionBolsa ModificacionCaja BajaDevolucionBolsa 10 AltaCreditoReciboInterrumpido BajaCaja ModificacionCreditoReciboInterrumpido ObtenerListadoMovimientosRepetidosMercaderiaAEntregar BajaCreditoReciboInterrumpido ObtenerListadoVentasPorZona AltaRecibo BajaOrdenPago ModificacionRecibo ArmarArchivosComunicacion BajaRecibo AltaVendedores 11 AltaTelefono ModificacionVendedores ModificacionTelefono BajaVendedores ConsultaTelefono AcreditarComision 12 ObtenerListadoClientes LimpiarMercaderiaAEntregarDonaciones ObtenerBalanceSaldosClientesSalidaExcel ObtenerListaContabilizaBorraCaja ObtenerListadoProveedores LiquidarComisionVendedores ObtenerListadoAcreedores LimpiarLibroRecibos ObtenerBalanceSaldosClientes LimpiarLibroIva ObtenerBalanceSaldosAcreedoresProveedores LimpiarKardex 13 ObtenerBalanceMayorProveedoresPorCodigoProveedor

117

LimpiarEstadisticas 14 EntregarMercaderia LimpiarCuentasCorrientes FacturarPedido ObtenerBalanceLibroIva RealizarNotaCredito AltaInterdeposito AnularMercaderia UtilizacionInterdeposito DevolverPedido BajaInterdeposito EmitirConFacturaDeCredito BajaPedidos 15 ObtenerListadoDeudasChequesRechazados AltaFlete TransferirImporte

ModificacionFlete ObtenerListadoDeudasChequesRechazadosCartaReclamo

BajaFlete ObtenerListadoDeudas AltaCondicion ObtenerListadoCuentasOtrosDeudores ModificacionCondicion ObtenerListadoCuentasEnGestionJudicial

BajaCondicion 16 ObtenerBalanceMovimientosCuentasAcreedoresProvee

doresSalidaExcel

BajaCliente ObtenerBalanceMovimientosCuentasAcreedoresProveedores

AltaCheque ObtenerBalanceMovimientosCuentasCorrientes ModificacionCheque 17 RealizarCredito BajaCheque EmitirCreditosCobranza AltaArticulo RealizarNotaDebito ModificacionArticulo 18 ObtenerListadoMovimientos BajaArticulo ObtenerListadoCuentasVendedores BajaOtroDeudor ObtenerListadoCuentasCorrientesVendedores BajaIngreso ObtenerListadoCuentasCorrientesProveedores AnularRecibo ObtenerListadoCuentasCorrientesAcreedores

AnularRemito 19 ObtenerBalanceCuentaDeudasYCuentaCorrienteSalida

AExcel 4 ModificarComision

ObtenerBalanceCuentaDeudasYCuentaCorrienteSalidaExcel

ModificarArrastreCaja ObtenerBalanceCuentaDeudasYCuentaCorriente 5 AnalizarSituacionZonasDeVenta 20 FacturarFlete ObtenerListadoLibroIva 21 ObtenerPedidosPendientes ObtenerListadoFacturacion ObtenerListadoPedidosPendientes ObtenerListadoSituacionTrigo 22 ObtenerListadoCuentasAcreedores ObtenerBalanceArchivosDiarios ObtenerListadoCuentasCorrientes ImprimirCarteraInterdepositos ObtenerListadoCuentasCorrientesEnGestionJudicial ObtenerListadoTotalesCobranzaMensual ObtenerListadoCuentaCorrienteBolsas ObtenerListadoHischeq ObtenerListadoCuentasProveedores ObtenerBalanceCuentasCorrientesGestionJudicial

23 ObtenerListadoIngresosEgresos

118

ObtenerListadoHistoriaCobranzas ObtenerListadoLibroBancos ObtenerListadoTotalesMovimientosStockMensual ObtenerListadoCajaOrdenMayor ObtenerListadoUnidadesEntregadasPorZona 24 ObtenerDetalleRetencionesOrdenesPago ObtenerListaKardex 25 ObtenerListadoTotalesLibroIva

6 ObtenerListadoLibroComprasPorImputacion 26 ObtenerListadoEstadisticas ObtenerListadoLibroVentasPorImputacion ObtenerListadoPreciosPromedios

29 AltaCliente 27 ObtenerListadoFacturaCredito ModificacionCliente AnularFactura AltaOtroDeudor 28 AltaPedidos ModificacionOtroDeudor ModificacionPedidos

30 ContarBolsas 31 AjustarStock

32 ArmarCitiCompras

Tabla 6.15: Oportunidades de refactorización, enfoque automático.

A primera vista las similitudes que se pueden encontrar entre los resultados del enfoque automático y los del enfoque manual son muy pocas. En el primer cluster del enfoque automático se pueden ver 3 operaciones que comparten tipos de datos: ObtenerListadoChequesRecibidosSalidaExcel, ObtenerListadoChequesRecibidos y ObtenerListadoChequesRechazados. La semántica de los servicios parece ser similar, pero los tipos de datos de datos de todos ellos son compartidos en su mayoría. Es decir que el cluster 1 comparte algunos servicios del cluster “ListadorDeCheques” del enfoque manual.

En el cluster 3 del enfoque automático se pueden encontrar en su mayoría servicios del estilo alta baja o modificación, lo cual puede ser comparado con los tres servicios del enfoquemanual darAlta, darBaja y Modificiación. Aunque cabe destacar que en el enfoque manual se decidió agrupar cada servicio en un servicio diferente mientras que en el enfoque automático se agruparon en el mismo servicio.

Otra de las similitudes se puede encontrar en el cluster número 22 del enfoque automático en donde se agrupan cinco operaciones en las cuales se listan cuentas. Estas cinco operaciones se pueden encontrar agrupadas en el servicioListadorCuentasdel enfoquemanual, junto con otras operaciones.

Por otro lado en el cluster 8 del enfoque automático se agruparon los servicios CruzarTotalesMovimientos , ObtenerListadoVentasPorZonaSubproductoMesSalidaExcel ObtenerListadoVentasPorZonaSubproductoMesSalidaExcelDetalle entre otros, los cuales comparten el tipo de datos utilizado en el servicio. En el enfoque manual ninguno de los 3 servicios fue refactorizado debido a que el desarrollador no encontró dichas oportunidades. Aquí se ve una razón clara de cómo el presente sistema puede ayudar a encontrar oportunidades de refactoring que el humano no pudo encontrar.

119

A continuación en la tabla 6.16 se muestra el total de tiempo consumido en la detección de oportunidades de refactoring manual vs el tiempo del enfoque aquí propuesto, la cantidad de clusters resultantes en cada enfoque, las operaciones analizadas y el promedio de operaciones por clusters luego de haber analizado el total de contratos WSDL.

Manual No supervisado

Tiempo de detección 6:50 horas. (410 minutos) ~5 minutos

Clusters resultantes 29 clusters 32 clusters

Operaciones con oportunidad de refactoring

175 operaciones 201 operaciones

Operaciones por cluster ~8 operaciones ~6 operaciones

Tabla 6.16: Comparación resultados manual vs nosupervisado.

Como se puede ver en la tabla 6.16, el total de tiempo invertido en cada enfoque es extremadamente diferente, el enfoquemanual demandó un total de 410minutos mientras que el no supervisado demandó de alrededor de 5 minutos para sugerir oportunidades de refactorización.

Por otro lado la cantidad de clusters resultantes no varía demasiado, 29 clusters del enfoque manual contra 32 clusters del enfoque no supervisado, lo que dan como resultado alrededor de 8 operaciones por cluster en el enfoque manual vs 6 en el no supervisado.

Finalmente las operaciones analizadas con oportunidades de refactoring en el enfoque no supervisado son mayores que en el enfoque manual, lo que sugiere que el enfoque no supervisado ofrece oportunidades que el ser humano no puede encontrar, como ya semencionó anteriormente.

Conclusiones

En el presente capítulo se analizaron los resultados de ambos enfoques, manual y no supervisado. En primer lugar se realizaron comparaciones utilizando el enfoque no supervisado seleccionando los diferentes algoritmos soportados por el mismo, variando los parámetros de entrada con el objetivo de encontrar el mejor agrupamiento de servicios teniendo en cuenta el criterio establecido. En segundo lugar se presentaron los resultados del experimento donde se buscaron manualmente oportunidades de refactoring en el segundo caso de estudio. Finalmente se realizó la comparación de los resultados obtenidos en ambos enfoques.

Si bien elenfoqueno supervisado es muchomás rápido que elenfoquemanual, el primero no es cien por ciento preciso de la mismamanera que el enfoquemanual tampoco. Ninguna de las dos soluciones brinda un resultado perfecto, por lo que ambos enfoques se deberían aplicar en conjunto a la hora de refactorizar un sistema basado en arquitectura SOA, teniendo en cuenta que quizás sería más fácil y rápido utilizar el enfoque no supervisado y luego seguir buscando

120

oportunidades de refactorización manualmente, aunque cabe destacarse también que si los resultados del enfoque no supervisado son analizados antes de realizar el relevamiento de las oportunidades de refactoring de manera manual, estos pueden influir, “contaminar” quizás, a la hora de analizar y encontrar las potenciales oportunidades.

121

7. Conclusiones y Trabajos Futuros

En este capítulo, se hará una descripción de las conclusiones a las que se llegaron, se detallarán las limitaciones observadas en la herramienta y su utilización, y por último se propondrán trabajos futuros que se pueden realizar luego de hacer un análisis experimental y teórico de la herramienta presentada.

7.1 Conclusiones

En este trabajo se logró utilizar gran parte de los conocimientos adquiridos durante el curso de la carrera para realizar el diseño y la construcción de una herramienta web con el objetivo de explorar y encontrar oportunidades de refactorización de contratos WSDL en aplicaciones basadas en arquitectura SOA.

El enfoque presentado integra satisfactoriamente varias herramientas para cumplir con el objetivo principal de la detección de oportunidades de refactoring. Se presentan las oportunidades de refactorización en grupos de contratos WSDL en los que se ha encontrado alguna similitud a modo de gráficos. Asimismo, el enfoque presentado detecta y ofrece soluciones para los antipatrones presentes en los contratos WSDL que se analizan. La herramienta también cuenta con una amplia cantidad de opciones a la hora de seleccionar algoritmos de clusterización, los diagramas para visualizar los resultados y un visualizador de contratos WSDL, entre otras características.

También se realizaron dos experimentos para demostrar los resultados obtenidos con la

utilización de la herramienta y uno de ellos se comparó con su contraparte manual, a modo de comparar no solo los resultados obtenidos en base a las oportunidades de refactorización sino que también se realizó una comparación en base al tiempo requerido por cada enfoque (manual vs automático), concluyendo con resultados muy positivos en el caso de la utilización de la herramienta.

Hay que volver a hacer especial hincapié en que el enfoque no supervisado aquí propuesto no otorga una solución perfecta, sino que más bien resalta oportunidades de refactorización que el ojo humano tiende a pasar por alto cuando la cantidad de contratos WSDL a analizar es relativamente grande.

122

Como se discutió en capítulos anteriores, no existen muchos trabajos que soporten la búsqueda de oportunidades de refactorización de aplicaciones SOA utilizando enfoques no supervisados, de modo que los trabajos a futuro y las mejoras propuestas son sólo la punta del iceberg.

7.2 Ventajas de la herramienta

La herramienta se construyó teniendo en cuenta el requerimiento de la facilidad de su utilización. Se trató de lograr una interfaz gráfica concisa y orientada a la usabilidad y legibilidad a la hora de mostrar los resultados. La interfaz es de fácil utilización e intuitiva y los resultados se muestran de una manera de agilizar la interpretación de los mismos haciendo uso de diagramas previamente analizados para lograr dicho fin. Por otro lado, la herramienta es una aplicación web, de modo que no requiere de instalación y la interacción con la misma requiere solo de acceso a internet (una vez desplegada en los servidores).

Se brindan cinco diferentes tipos de diagramas para la presentación de resultados, dejando al usuario un amplio abanico de posibilidades para visualizar las oportunidades de refactorización y los diferentes clusters que se armaron utilizando alguno de tres los diferentes algoritmos que soporta el sistema.

Por otro lado, se presentan algunas estadísticas en conjunto con los resultados y también se presentan los diferentes antipatrones de contratosWDSL que se encontraron durante el análisis y la etapa de clusterización. Cabe destacar que se sugieren soluciones abstractas a cada antipatrón detectado por la herramienta.

Por último y no así menos importante hay que destacar dos puntos fundamentales. El primero es el tiempo en el que la herramienta devuelve los resultados, que puede variar de algunos segundos hasta algunos minutos dependiendo de cuántos contratos WSDL se requieran analizar. Como se puede ver, además de sustentar la toma de decisiones a la hora de la refactorización también se aporta una ventaja con respecto al tiempo que se invierte para detectar las oportunidades. En cuestión de minutos el desarrollador puede importar los contratos y visualizar las oportunidades para, por último, decidir si la refactorización es factible o no (dependiendo de sus propios criterios). Como segundo punto se puede tomar la posibilidad de encontrar oportunidades de refactorización que un ser humano encuentra difícil de detectar, sobre todo cuando el conjunto de archivos WSDL a relevar es de una gran cantidad.

7.3 Limitaciones de la herramienta y trabajos futuros

A continuación se detallarán puntos en los cuales la herramienta, y el enfoque propuesto demuestran algunas limitaciones, y también se propondrán soluciones a las limitaciones encontradas.

123

Posibilidad de edición de los contratos WSDL:

Los contratos WSDL son tratados de una manera estática en la versión actual de la herramienta propuesta. De aquí surge la posibilidad de evaluar el agregado de una nueva funcionalidad a la herramienta, permitiendo al usuario poder realizar cambios sobre los contratos WSDL sin la necesidad de tener que editarlos localmente y volver a subirlos al servidor para realizar los análisis correspondientes.

De la misma manera se podrían aplicar soluciones semiautomatizadas a los contratosWSDL en cuanto a la ocurrencia de los antipatrones. Así se propone el agregado de un nuevo caso de uso para permitir al usuario poder ver los antipatrones y solucionarlos de manera automática en el caso que lo permita o presentar una ventana de edición con el cursor en la sección donde se detecta el antipatrón para que el usuario decida cómo solucionarlo.

Refactorización:

Actualmente la herramienta brinda oportunidades de refactorización, las cuales requieren del análisis de uno o varios gráficos en los cuales se presenta la clusterización resultante de ejecutar algún algoritmo de clustering soportado. Se propone agregar en versiones posteriores de la herramienta un algoritmo que realice la refactorización de los servicios de manera automática, dando como resultado nuevos contratos WSDL teniendo en cuenta la posibilidad de la interacción con el usuario a la hora de nombrar los nuevos servicios webs o sus operaciones por ejemplo.

Agregar soporte a otros algoritmos de clusterización:

Como se presentó en el capítulo 5 (Diseño del sistema), se utilizó el patrón de diseñoStrategy para facilitar el agregado y soporte de nuevos algoritmos de clusterización. De manera que se propone el agregado de más algoritmos de clusterización que soporta WEKA ya que se han integrado los algoritmos de dicha herramienta.

Agrupación por semántica:

Como se demostró en el capítulo anterior, la herramienta posee algunas limitaciones a la hora de asociar operaciones teniendo en cuenta diferentes criterios, como por ejemplo la utilización de la semántica de las operaciones y/o servicios. Utilizar un enfoque de agrupamiento por semántica parece tener sentido a la hora de refactorizar servicios web debido a que, por ejemplo, el sistema que está siendo refactorizado puede tener mucho tiempo en construcción, lo cual contribuye a la posibilidad de que los servicios y sus operaciones no estén agrupados utilizando ningún criterio (como es la situación de algunos servicios y sus operaciones en el 2do caso de estudio presentado en este trabajo). Esto puede ocurrir de la misma manera en proyectos en los cuales existen muchos programadores y no hay una comunicación efectiva entre ellos a la hora de crear servicios, agregar operaciones o incluso realizar modificaciones al sistema en cuestión. El agrupamiento por semántica resulta natural a la hora de organizar/asignar operaciones a servicios web de manera que son fáciles e intuitivas de encontrar para los desarrolladores del

124

sistema o incluso para otros desarrolladores que quieren utilizar los servicios del sistema en cuestión.

La mejora propuesta es incluir técnicas de agrupamiento que analicen y utilicen la semántica de las operaciones, de modo de ofrecer otras oportunidades de refactorización que la herramienta actualmente no ofrece. Una alternativa sería explotar con técnicas de minería de texto los comentarios de los mensajes y documentación de las operaciones.

125

Bibliografía

[Bartolini, 2008] Cesare Bartolini, Antonia Bertolino, Eda Marchetti and Andrea Polini, 2008, Towards AutomatedWSDLBased Testing of Web Services, Lecture Notes in Computer Science, volúmen 5364, pp 524529.

[Berkhin, 2006] Berkhin, Pavel (2006) ‘A Survey of Clustering Data Mining Techniques’, Grouping multidimensional data. pp 2571.

[Channabasavaiah et al, 2003] Kishore Channabasavaiah, Kerrie Holley and Edward Tuggle, Jr., IBM Software Group, “Migrating to a serviceoriented architecture”, white paper, Dec 2003

[Channabasavaiah et al, 2004] Kishore Channabasavaiah and Kerrie Holley, IBM Global Services, and Edward M. Tuggle, Jr., IBM Software Group, “On demand operating environment solutions: Migrating to a serviceoriented architecture”, white paper, April 2004.

[Dempster et al, 1977] A. P. Dempster; N. M. Laird; D. B. Rubin (1977) ‘Maximum Likelihood from Incomplete Data via the EM Algorithm’ in Journal of the Royal Statistical Society. Series B (Methodological), Vol. 39, No. 1, pp. 138.

[Diehl, 2007] Software Visualization. Visualizing the Structure, Behaviour, and Evolution of Software. Stephan Diehl. 2007

[Dong et al, 2004] X. Dong, A. Halevy, J. Madhavan, E. Nemes, J. Zhang, “Similarity Search for Web Services”, In: VLDB. pp 372383. Morgan Kaufmann, San Francisco (2004).

[Elgazzar et al, 2010] Elgazzar, Khalid and Hassan, Ahmed E. and Martin, Patrick. (2010) ‘Clustering WSDL Documents to Bootstrap the Discovery of Web Services’, Proceedings of the 2010 IEEE International Conference onWeb Services. pp 147154.

[Fowler, 2002] Martin Fowler, Kent Beck, John Brant, William Opdike, Don Roberts. Refactoring Improving the Design of Existing Code. AddisonWesley, 2002.

[Holten, 2006] Danny Holten. Hierarchical Edge Bundles: Visualization of Adjacency Relations in Hierarchical Data. IEEE Transactions on visualization and computer graphics, Vol. 12, No. 5, September/October 2006 pp 741748.

[Jiangang et al, 2008] Ma, Jiangang and Zhang, Yanchun and He, Jing. (2008) ‘Efficiently Finding Web Services Using a Clustering Semantic Approach’, WWW 2008, No. 5, pp 18.

[Kuhn et al, 2007] Adrian Kuhn and Stéphane Ducasse and Tudor Girba. Semantic Clustering: Identifying Topics in Source Code. Information & Software Technology, vol 49, N0. 3, 2007 pp 230243.

[Lemahieu, 2001] W. Lemahieu, 2001, Web Service description, advertising and discovery: WSDL and Beyond, 2001. In J. Vandenbulcke and M. Snoeck (eds.), New Directions in Software Engineering, Leuven University Press, 2001.

126

[Liu, Wong, 2009] Liu, W. and Wong, W. (2009) ‘Web service clustering using text mining techniques’, Int. J. AgentOriented Software Engineering, Vol. 3, No. 1, pp.6–26.

[Marakas, 2002] George M. Marakas. eStudy Guide for Modern Data Warehousing, Mining, and Visualization: Core Concepts. Prentice Hall; 1 edition, December 2, 2002.

[Rodríguez, 2010] “Improving Web Service descriptions for effective service discovery” J.M. Rodríguez, M. Crasso, A. Zunino and M. Campo. Volume 75, Issue 11, 1 November 2010, pp 1001–1021.

[Rodríguez, 2012] "Best Practices for Describing, Consuming, and Discovering Web Services: A Comprehensive Toolset" J.M. Rodríguez, M. Crasso, C. Mateos and A. Zunino. Software: Practice and Experience. 2012. In Press. WileyBlackwell (Thomson SCI, IF JCR2011=0.573)

[Rodríguez, 2013] JUAN MANUEL RODRIGUEZ; MARCO CRASSO; ALEJANDRO ZUNINO An approach for Web Service discoverability antipatterns detection (Indexed SCI, IF JCR2012=0.2) JOURNAL OFWEB ENGINEERING; Lugar: Paramus, NJ; Año: 2013 vol. 12 p. 107 134

[Rousseeuw, 1987] Rousseeuw, Peter (1987) ‘Silhouettes: A Graphical Aid to the Interpretation and Validation of Cluster Analysis’, J. Comput. Appl. Math. Vol. 20, No 1, pp 5365.

[Schwarz, 1978] Gideon Schwarz (1978) ‘Estimating the dimensions of a model’, The annals of statistics, Vol 6, No. 2, pp. 461464.

[Thanh, 2003] Thanh, T., N., Wehrens, R. y Widen, L. M. C. KNN DensityBased Clustering for High Dimensional Multispectral Images. Segunda GRSS/ISPRS Joint Workshop on Remote Sensing and Data Fusion over Urban Areas, URBAN 3002, Berlin (2003).

[Vázquez, 2005] Vázquez, F. D., Sánchez, J. S. and Pla, F. A stochastic approach to Wilson’s editing algorithm. Pattern Recognition and Image Analysis, LNCS, Springer Verlag, 3523, 35 – 42 (2005).

[Vázquez, 2008] Vázquez, F. D. Tésis Doctoral. Universidad Jaume I, Castellón, España, 2008.

[Zhou et al, 2013] Hong Zhou , Panpan Xu, Xiaoru Yuan , and Huamin Qu. Edge Bundling in Information Visualization, April 2013. Tsinghua Science and Technology. Vol. 18, No. 2, pp 145156.

127