Trabajos Relacionados
3.1 Factores de éxito
En [38] se definen ciertos factores que tienen una influencia positiva en el éxito de las herramientas de detección automática de code smells. Algunos de los cuales fueron tomados en cuenta para el desarrollo de este trabajo.
3.1.1 Usabilidad
En [37, 16] se plantean ciertos lineamientos (Tabla 3.1) relacionados con la usabilidad que son deseables en herramientas de detección de code smells y cuya relevancia es evaluada experimentalmente en [38] donde se toma como hipótesis que las herramientas que siguen estas reglas generales son más exitosas en este aspecto.
Limitación La herramienta no debe agobiar al desarrollador con los smells que detecta.
Relacionalidad Cuando se muestran detalles acerca de los code smells, la herramienta debería mostrar las relaciones entre los elementos del sistema afectados.
Preferencia La herramienta debería enfatizar los smells que son difíciles de encontrar sin herramientas de soporte.
No distracción La herramienta no debe distraer al desarrollador.
Estimabilidad La herramienta debería ayudar a estimar la extensión de un smell en el código.
No obstrucción La herramienta debería permitir al programador realizar otros trabajos mientras se realiza el análisis.
Sensibilidad al contexto La herramienta debería dar prioridad a señalar los smells relacionados al código en el cual el programador está trabajando.
Lucidez Además de encontrar smells, la herramienta debería hacer saber al programador por qué determinados smells existen. Tabla 3.1: Reglas generales para las herramientas de detección de smells.
3.1.2 Continuidad
En [3] se propone usar la “Metáfora de los dos sombreros” que significa el cambio constante entre dos actividades: agregar funcionalidad y refactorizar. Este tipo de refactoring se denomina “root canal refactoring”. Por el contrario, existe el “floss refactoring” en el cual no se distingue entre el agregado de funcionalidad y el refactoring, sino que se propone el refactoring a medida que se agrega el código. Se ha argumentado que el “root canal refactoring” es ineficiente [42]. Cuando se usa este tipo de refactoring el desarrollador debe primero examinar el código para volver a entender el contexto, y de esa manera ser capaz de reconocer una oportunidad de refactoring. Esta tarea se vuelve engorrosa y consume tiempo. En contraste, cuando se utiliza “floss refactoring” el desarrollador ya se encuentra en el contexto del código a refactorizar.
Para que el refactoring sea eficiente y tolerable, debe ser aplicado de manera continua. Visualizar los smells y bugs en el contexto actual de programación alienta al desarrollador a refactorizar continuamente. De manera que los detectores de smells deberían soportar al programador continuamente con información de detección de smells y propuestas de refactoring.
3.1.3 Interpretación
Muchas herramientas existentes calculan métricas de código. Pero unas pocas puede interpretar las métricas y reaccionar ante esas interpretaciones. Una característica faltante entre la mayoría de los detectores de smells es la capacidad de realizar refactorings directamente como una solución a un smell detectado o al menos de proponer uno. Esto puede no ser posible para todos los smells, pero si para los más sencillos como por ejemplo “Duplicated Code” [3]. En este caso el refactoring propuesto sería “Extract Method” o “Extract Class”.
3.1.4 Especificidad
Además de las herramientas de detección convencionales, están los detectores de malas prácticas. Estos detectores son específicos a un lenguaje de programación, ya que cada lenguaje tiene sus propias malas prácticas.
Figura 3.1: Mala práctica encontrada por el plugin Findbugs para Eclipse.
Por ejemplo en la Figura 1 el plugin Findbugs para el IDE Eclipse ha 4 encontrado una mala práctica de Java: Usar concatenación de strings convencional en un ciclo que implica una baja de performance. En reemplazo es recomendado utilizar el tipo StringBuffer. Esto es un inconveniente en Java ya
que en otros lenguajes el operador “+=” está sobrecargado para utilizar un
StringBuffer o similar por detrás.
Como se puede ver, los detectores de malas prácticas no solo ayudan a mejorar la calidad del código sino también en ocasiones a mejorar la performance. Además poseen gran potencial para mejorar el código, ya que las reglas de detección están adaptadas a lenguajes de programación específicos.
3.1.5 Integración
La mayoría de las herramientas de métricas o detección de code smells son aplicaciones standalone o plugins. Las aplicaciones standalone tienen la desventaja de complicar el cumplimiento de los factores de continuidad e interpretación explicados en 3.1.3, y 3.1.2. Para poder realizar sugerencias de refactoring la herramienta necesita integración visual con el IDE. La continuidad no puede lograrse debido a que una aplicación standalone nunca sabría qué pieza de código el desarrollador está editando. Deployado como un plugin un detector puede mostrar continuamente si se encontraron nuevos smells sin forzar al programador a tener que dejar la IDE. Cuando un smell es encontrado la herramienta puede fácilmente mostrar su presencia y proponer como eliminarlo. Este comportamiento también hace énfasis en el factor de usabilidad, introducido en la sección 3.1.1.
3.2 Herramientas
En esta sección se describen algunas de las herramientas que se encuentran actualmente disponibles para la detección automática de code smells y se detallan comparativas de algunas de sus características (Tabla 3.2), así como también los diferentes smells detectados por cada una (Tabla 3.3).
Herramienta Tipo Lenguajes Refactoring Indicadores en código
Checkstyle Eclipse plugin, Standalone
Java No Si
DECOR Standalone Java No No
iPlasma Standalone C++, Java No No inFusion Standalone C, C++, Java No No JDeodorant Eclipse
plugin
Java Si Si
PMD Eclipse plugin, Standalone
Java No Si
Stench Blossom
Eclipse plugin
Java No Si
Tabla 3.2: Herramientas de detección de code smells.
Algunas de estas herramientas fueron desarrolladas para mejorar la calidad del código durante el desarrollo de software, mientras que otras dan soporte a actividades de mantenimiento y reingeniería. La mayoría de las herramientas no son capaces de aplicar refactorings automáticamente sobre los code smells (JDeodorant) es la única que provee opciones de refactoring), pero
los IDE modernos generalmente son capaces de realizar ciertos refactorings automáticamente. Sería deseable al menos que las herramientas ayuden al usuario a entender la causa de los smells y que no muestren la información de manera que agobie al desarrollador en casos donde los smells proliferan como se explicó en la sección 3.1.
Checkstyle
Checkstyle fue desarrollada para ayudar a los programadores a escribir código5 Java que adhiere a un estándar de codificación. Es capaz de detectar los smells “Large Class”, “Long Method”, “Long Parameter List”, y “Duplicated Code”.
DECOR
En [43, 44] se define un approach que permite la especificación y detección automática de smells de código y de diseño (también llamados antipatrones). Se especifican seis smells usando un lenguaje personalizado, se generan automáticamente sus algoritmos de detección mediante templates, y se validan dichos algoritmos en términos de precisión y exactitud. Este approach es implementado en la plataforma “Decor platform for software analysis” . 6
inFusion
inFusion es la evolución comercial de iPlasma. Es capaz de detectar más de 207 defectos de diseño y smells, como “Duplicated Code”, clases que rompen la encapsulacion (Data Class, God Class), métodos y clases fuertemente acoplados, o jerarquías de clases con diseños defectuosos.
iPlasma
Esta herramienta [45] es una plataforma integrada para la evaluación de la calidad de los sistemas orientados a objetos que incluye soporte para todas las fases de análisis, desde extracción de modelos, hasta análisis basados en
5 http://checkstyle.sourceforge.net/ 6 http://www.ptidej.net/download
métricas de alto nivel. iPlasma es capaz de detectar lo que los autores definen 8 como “desarmonías” de código, clasificadas en desarmonías de identificación, desarmonías de colaboración y desarmonías de clasificación. La descripción detallada de estas se puede encontrar en [8]. Varios smells son considerados desarmonías, por ej: Duplicated Code, God Class, Feature Envy, y Refused Parent Bequest.
JDeodorant
JDeodorant [15] es un plugin para Eclipse que identifica automáticamente los smells Feature Envy, God Class, Long Method y Switch Statement (en su variante “Type Checking”) en código Java . La herramienta asiste al usuario en 9 determinar una secuencia apropiada de refactorings determinando las posibles transformaciones que resuelven los problemas identificados, rankeandolos según su impacto en el diseño, presentandolos al desarrollador, y aplicando automáticamente la escogida por este.
PMD
PMD10 escanea el código fuente Java y busca por potenciales problemas o posibles bugs como código muerto, bloques try/catch/finally/switch vacíos, variables locales o parámetros no utilizados, y código duplicado. PMD puede detectar los smells Large Class, Long Method, Long Parameter List, y Duplicated Code, y permite al usuario configurar umbrales para las métricas.
Stench Blossom
Stench Blossom [16] es un detector de smells que provee un entorno de visualización interactiva diseñado para dar a los desarrolladores un vistazo rápido y de alto nivel de los smells en el código y su origen. La herramienta es un plugin para el IDE Eclipse que provee a los programadores tres diferentes vistas, que ofrecen más información sobre los smells visualizados. El feedback es sintético y visual, y tiene la forma de un conjunto de pétalos cercanos al
8 http://loose.upt.ro/iplasma/index.html 9 http://http://www.jdeodorant.com/ 10 http://pmd.sourceforge.net/
elemento de código en el editor del IDE. El tamaño del pétalo es directamente proporcional a la “fuerza” del smell del elemento de código al que refiere. El único procedimiento posible para encontrar smells es revisar el código fuente, buscando por pétalos lo suficientemente grandes como para suponer que existe un code smell en esa parte del código. La herramienta es capaz de detectar 8 smells diferentes.
Tabla 3.3: Soporte para code smells.
Otras herramientas
Otras herramientas desarrolladas o métodos para la detección de smells han sido propuestos. CodeVizard [46] es una herramienta actual (sin release al público)
que puede detectar varios smells, esencialmente siguiendo las reglas de detección de [8]. inCode es un plugin para Eclipse basado en inFusion, que 11 provee detección de problemas de diseño a medida que el código es escrito. Otras herramientas son: FxCop para .NET, Analyst para Java (comercial), JCosmo [47] (para Linux), CloneDigger y ConQat.