Trabajos Relacionados
3.3 Técnicas de visualización
Dado que uno de los propósitos de este trabajo es proponer una mejora de visualización para la herramienta JSpIRIT, en esta sección se destacan algunas técnicas de visualización desarrolladas aplicadas a la evolución de los sistemas en general y en algunos casos particularmente a los code smells. Algunos de estos approaches provienen de fuentes investigativas mientras que otros se encuentran implementados en herramientas comerciales. (a) “In the small” (b) “In the large” Figura 3.2: Técnicas de visualización de D’Ambros y Lanza. 11 https://www.intooitus.com/products/incode
D’Ambros y Lanza [9] presentan visualizaciones para analizar la evolución de un sistema basadas en sus diferentes versiones. Los autores presentan dos grupos de visualizaciones i) “in the large”, y ii) “in the small”. La primera se enfoca en identificar cambios y diferentes commits a una clase usando figuras de tiempo discretas (Figura 3.2a). Mientras que la última se enfoca en encontrar bugs en las clases y analizar el tamaño y la complejidad de las clases (Figura 3.2b). Por ejemplo, la vista de la Figura 3.2a puede ayudar a identificar las clases que sufrieron más cambios mientras que la vista en la Figura 3.2b puede ayudar a identificar clases largas y complejas como las “God Classes”. Los mismos autores proponen una técnica de visualización para calcular acoplamiento entre módulos, correlación entre clases y complejidad de clases [48].
Figura 3.3: Matriz de evolución.
Lanza [49] propone el uso de una matriz de evolución para visualizar los cambios de las clases a lo largo de la historia de un sistema. Cada celda de la matriz contiene una versión específica de una clase. Una clase es visualizada como un rectángulo donde el ancho y alto son definidos en base a métricas (ej.
cantidad de métodos y cantidad de variables de instancia). Este trabajo también propone una categorización de las clases visualizadas en la matriz. Estas categorías son patrones encontrados a través de la historia y son basados en el tamaño de las clases, el porcentaje de modificaciones entre versiones, y la creación o eliminación de clases (Figura 3.3). Mientras que estos patrones pueden ayudar a identificar numerosos problemas en el código, la supervisión del desarrollador es necesaria dado el alto porcentaje de falsos positivos.
A diferencia de las visualizaciones implementadas en este trabajo, los enfoques de D’Ambros y Lanza (Figuras 3.2a, 3.2b y 3.3) utilizan métricas que son recopiladas en el tiempo a medida que el sistema sufre modificaciones. A partir de un análisis de estas métricas se puede determinar la aparición o presencia de smells en el código. Un inconveniente con este enfoque es que es necesario tener acceso a las versiones del sistema desde su creación, si bien la mayoría de los sistemas modernos se desarrollan utilizando algún mecanismo de versionado no siempre es el caso. Por otro lado, la naturaleza del enfoque indica que es recomendable que este sea utilizado desde el inicio del desarrollo, de manera que esto implica que el desarrollador debe adoptarlo como parte del proceso de desarrollo, lo que puede limitar su campo de acción en casos donde los desarrolladores son reacios a dedicar tiempo de desarrollo a la utilización de este tipo herramientas, e incurren a tareas de refactoring cuando el desarrollo ha terminado.
Figura 3.4: Vista de entorno de la herramienta Stench Blossom.
Los creadores de la herramienta Stench Blossom [16] optaron por un approach en código en tiempo real para la visualización de code smells. La visualización (Figura 3.4) muestra smells relacionados con el contexto actual en el que se está trabajando. Los autores argumentan que el hecho de que la herramienta esté disponible constantemente y bajo el contexto actual de trabajo hacen a la herramienta apropiada para el “floss refactoring” [3] donde los programadores frecuentemente cambian entre tareas de refactorización y otro tipo de modificaciones en el código.
Este enfoque es apropiado para resolver los smells que se presentan en el código, sin embargo, la visión del desarrollador puede verse limitada ya que solo se tiene en cuenta el código que se está viendo para realizar un refactoring. Como se verá en este trabajo muchas veces smells del mismo tipo se presentan en varias clases de un mismo componente del sistema, y en ocasiones se extienden hacia otros componentes formando aglomeraciones, estas aglomeraciones pueden implicar problemas mayores en el diseño del sistema que requieren ser observados desde una perspectiva más amplia para su análisis. Figura 3.5: Vista de mapa de paquetes de la herramienta inCode.
Otras herramientas como inCode proveen visualizaciones interactivas basadas en métricas que permiten explorar la estructura del sistema y sus problemas. Por ejemplo, el mapa de paquetes (Figura 3.5) muestra la distribución de clases en paquetes. Con rectángulos en la gama del gris se representan los paquetes y su anidamiento, mientras que los rectángulos rojos representan a las clases. Mientras más intenso es el rojo, más deteriorada se encuentra la clase por anomalías, mientras que el ancho y el alto del rectángulo
que corresponde a cada clase representa la cantidad de atributos y cantidad de métodos en las mismas respectivamente. La vista también es configurable para mostrar el nivel de acoplamiento entre clases.
Esta herramienta implementa visualizaciones intuitivas detallando los componentes del sistema y su nivel de afectación. Por desgracia, las visualizaciones excluyen las dependencias entre paquetes, que son de utilidad para entender la estructura del sistema y en ocasiones pueden poner en evidencia problemas en el diseño producidos por una violación en la arquitectura del sistema.
Algunos autores [17] argumentan que la utilización de métricas automatiza el proceso de búsqueda de smells pero produce resultados voluminosos, imprecisos e incongruentes. Sostienen que las visualizaciones tradicionales muestran de manera eficaz la distribución de métricas del código de un sistema. Pero cuando los falsos positivos pueden alcanzar un 90%, los usuarios necesitan más detalles para entender los problemas.
Dichos autores también aseguran que aunque se ha intentado en varios trabajos la visualización de code smells, estos enfoques soportan pocos smells, fallan en advertir las imprecisiones de las métricas, y sus visualizaciones no fueron diseñadas con las técnicas de inspección de software [50] en mente. Además sostienen que estos enfoques también fallan a pequeñas escalas. Están pensados para una vista general del sistema y no son capaces de ilustrar un problema de diseño particular.
De manera que bajo estas premisas los autores de [17] presentan un catálogo de visualizaciones de code smells (Figura 3.6) y proponen una división de smells en 4 categorías diferentes: de statement, de clase, de método y de colaboración. A su vez el diseño de las visualizaciones se basan en símbolos básicos (Figura 3.7) que ayudarían a representar fielmente la diversidad de los diferentes tipos de advertencias.
Figura 3.6: Health screen construido con simbología básica (Figura 3.7).
Figura 3.7: Simbología o bloques básicos de la visualización propuesta en [17].
Un aspecto positivo de este enfoque es que la creación del panel utilizado como visualización no utiliza gran cantidad de recursos computacionales. Por otro lado, la simbología utilizada (Figura 3.7) permite plasmar gran cantidad de información en el panel, lo que puede ser de gran utilidad, pero a la vez puede ser contraproducente haciendo difícil su comprensión. Como se verá más adelante en este trabajo, uno de los problemas que se enfrentan al diseñar una visualización de este tipo es la cantidad de datos que se deben bosquejar, y cómo ordenarlos y agruparlos para que el desarrollador no se vea abrumado ante la cantidad de información que se le ofrece. Es primordial que el desarrollador sea capaz de procesar y relacionar fácilmente la información que la visualización le entrega.