ArticlePDF Available

Abstract

Bad smells are a frequent cause of technical debt, which denotes the cost of adopting a quick and dirty design or development approach. There are works on characterizing bad smells as well as on detecting and fixing them automatically. However, few of these works characterize, detect and fix architectural bad smells. The work presented in this article represents an initial effort to fill this by contributing to: (i) the characterization of bad smells tha are relevant to the MVC architecture style, and (ii) the automatic detection of these using static analysis of software techniques. The obtained results show that most of the defined bad smells exist in practice and that the proposed detection method reduces by a wide margin the detection time required by a code review
54 RISTI, N.º 26, 03/2018
54
Revista lbérica de Sistemas e Tecnologias de Informação
Revista lbérica de Sistemas y Tecnologías de Información
Recebido/Submission: 10/12/2017
Aceitação/Acceptance: 05/02/2018
54
Caracterización y Detección Automática de Bad
Smells MVC
Perla Velasco-Elizondo1, Lucero Castañeda-Calvillo2, Alejandro García-Fernández3, y
Sodel Vazquez-Reyes4
pvelasco@uaz.edu.mx, b160629@sagitario.cic.ipn.mx, agarciafdz@cimat.mx, vazquezs@uaz.
edu.mx
1 Universidad Autónoma de Zacatecas, Zacatecas, ZAC, 98000, México.
2 Centro de Investigación en Computación, Ciudad de México, 07738, México.
3 Centro de Investigación en Matemáticas, Zacatecas, ZAC, 98060, México.
4 Universidad Autónoma de Zacatecas, Zacatecas, ZAC, 98000, México.
DOI: 10.17013/risti.26.54–67
Resumen: Los bad smells son causa frecuente de acumulación de deuda técnica;
término que se reere al costo en que se incurre por utilizar un enfoque de diseño o
desarrollo apresurado y descuidado. Existen trabajos sobre la caracterización de bad
smells, así como sobre enfoques para detectarlos y corregirlos automáticamente.
Sin embargo, pocos de estos trabajos caracterizan, detectan y corrigen bad smells
arquitectónicos. Este trabajo es un esfuerzo inicial para a llenar este vacío y contribuir
en: (i) la caracterización de bad smells relevantes al estilo de arquitectura MVC,
y (ii) la detección automática de estos bad smells utilizando técnicas de análisis
estático de software. Los resultados obtenidos muestran que la mayoría de los bad
smells denidos existen en la práctica, y que la estrategia de detección propuesta
reduce en un amplio margen el tiempo requerido para detectar bad smells mediante
una revisión de código de forma manual.
Palabras-clave: Arquitectura de Software; Bad Bad smells; Análisis Estático;
MVC; Yii.
Characterization and Automatic Detection of Bad Smells MVC
Abstract: Bad smells are a frequent cause of technical debt, which denotes the
cost of adopting a quick and dirty design or development approach. There are works
on characterizing bad smells as well as on detecting and xing them automatically.
However, few of these works characterize, detect and x architectural bad
smells. The work presented in this article represents an initial eort to ll this by
contributing to: (i) the characterization of bad smells tha are relevant to the MVC
architecture style, and (ii) the automatic detection of these using static analysis of
software techniques. The obtained results show that most of the dened bad smells
exist in practice and that the proposed detection method reduces by a wide margin
the detection time required by a code review.
Keywords: Software Architecture, Bad Bad smells, Static Analysis, MVC, Yii.
55
RISTI, N.º 26, 03/2018
RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação
1. Introducción
El éxito de un proyecto de desarrollo de sistemas no sólo depende de que el sistema creado
se termine dentro plazo y presupuesto establecido, sino también que genere valor (Espejo
Chavarría, Bayona Oré, & Pastor, 2016; Morales Huanca & Bayona Oré, 2017). Así, durante
la actividad de diseño de sistemas de software, es muy importante denir un modelo que
permita satisfacer los comportamientos y características de calidad especicadas durante la
actividad de análisis de requerimientos. Para logar esto es recomendable que se haga uso de
conceptos de diseño, como por ejemplo los patrones. Un patrón describe una solución general
a un problema recurrente en el desarrollo de sistemas (Gamma et al. 1995). Sin embargo, el
uso de patrones de manera diferente a la denida propicia la generación de bad smells.
En Ingeniería de Software el término bad smell es utilizado para denotar un síntoma
como consecuencia de un diseño pobre o implementación que negativamente impacta las
propiedades de un sistema de software (Fowler et al. 1999), por ejemplo, mantenibilidad,
reusabilidad. Un bad smell es usualmente utilizado para indicar un problema en el
software. Aunque no hay un consenso universal en el área, generalmente se acepta
que los bad smells pueden ocurrir en diferentes niveles de abstracción: desde el código
fuente, por ejemplo, una long parameter list (Source Makings, Code Smells 2017) hasta
la arquitectura, por ejemplo, connector envy (Garcia et al. 2009). A estos últimos, esto
es a los patrones de arquitectura, también se les llama estilos arquitectónicos.
Los bad smells son una causa frecuente de acumulación de deuda técnica ( B r o w n e t
al. 2010). La deuda técnica, es un término que hace referencia al costo en el que
se incurre por un enfoque de diseño o desarrollo apresurado y descuidado en el que se
ignoran principios y conceptos establecidos, en lugar de usar un enfoque sistemático
y disciplinado. Por lo tanto, detectar y corregir bad smells se vuelve relevante para el
diseño y desarrollo de sistemas de software.
En años recientes, la comunidad de investigación ha estado activamente identicando las
características de bad smells, por ejemplo (Ganesh, Sharma, and Suryanarayana 2013), así
como en el desarrollo de enfoques para detectarlos y corregirlos por ejemplo (Fernandes et
al. 2016). Sin embargo, la mayoría de estos enfoques se centran en bad smells que ocurren
en niveles de abstracción más bajos y pocos de ellos se caracterizan, identican y corrigen
a nivel de arquitectura. Adicionalmente, en estos trabajos de presta poca atención a la
realización de estas actividades en el contexto de los estilos arquitectónicos, estructuras
de diseño comúnmente utilizadas para el desarrollo de software.
El trabajo presentado en este artículo, es un enfoque inicial para llenar ese vacío y contribuir
en: (i) la caracterización de bad smells que son relevantes para el estilo de arquitectura
Modelo-Vista-Controlador (Model-View-Controller o MVC, por sus siglas en inglés)
(Best MVC Practices 2017), que ha sido ampliamente adoptado en frameworks para el
desarrollo de sistemas Web, y (ii) la detección automática de estos bad smells utilizando
técnicas de análisis estático de software en sistemas implementados con el Framework
Yii (yiiFramework 2017). Los resultados obtenidos muestran que los bad smells denidos
existen en la práctica y permiten tener una idea inicial sobre cuáles ocurren con mayor
frecuencia. Con respecto al método de detección automática, los resultados muestran que
el método de detección propuesta reduce en un amplio margen el tiempo requerido para
detectar bad smells mediante una revisión de código de forma manual
56 RISTI, N.º 26, 03/2018
Caracterización y Detección Automática de Bad Smells MVC
El contenido de este documento está organizado de la siguiente manera. En la sección
2, se explica el estilo arquitectónico MVC y, en función de sus limitaciones generales,
se dene una caracterización de bad smells relacionados. En la sección 3, se explica
el método usado para la detección automática de estos bad smells. En la Sección 4 se
presentan obtenidos al realizar dos experimentos para determinar la relevancia de
las contribuciones esperadas. En la Sección 5 se presenta una discusión del trabajo
relacionado. Finalmente, en la Sección 6, se presentan las conclusiones de este trabajo,
así como algunas líneas de trabajo futuro.
2. Estilo Arquitectónico MVC y Bad Smells Relacionados
La arquitectura de un sistema de software es un modelo de alto nivel de un sistema
denido en términos componentes, conectores y propiedades de ambos (Bass, Clements,
and Kazman 2012). Si bien es posible especicar la arquitectura de un sistema utilizando
este vocabulario genérico, en dominios de aplicación especícos es mejor adoptar un
vocabulario más especializado. A este vocabulario especializado da lugar a los estilos
arquitectónicos (Bass, Clements, and Kazman 2012), como por ejemplo cliente servidor,
tres capas o MVC.
El estilo arquitectónico MVC ha sido ampliamente adoptado para el diseño e
implementación de sistemas Web. Actualmente, varios frameworks de desarrollo
permiten la construcción de sistemas Web utilizando este estilo, como por ejemplo,
Spring (Spring 2018), Django (Django 2018), Rails (Rails 2018), Laravel (Laravel
2018), and Yii. Este estilo separa la lógica de negocio de la lógica de presentación, lo que
da como resultado un sistema más fácil de probar y mantener. La Figura 1 muestra
una vista estática del estilo arquitectónico MVC y la Tabla 1 describe los elementos que
esta vista incluye.
El estilo arquitectónico MVC dene la siguientes restricciones generales:
El Modelo no debe tratar directamente con el procesamiento de las solicitud
del usuario nal. Por ejemplo, su implementación no debe contener variables
$_GET, $_POST.
El Modelo no debe tratar directamente con la presentación de los datos para la
solicitud del usuario nal. Por ejemplo, su implementación no debe contener
código de presentación HTML.
La Vista no debe tratar directamente de realizar un acceso explícito a los datos
del sistema. Por ejemplo, su implementación no debe contener código para
consultas a Bases de Datos.
La Vista no debe tratar directamente con la solicitud del usuario nal. Por
ejemplo, su implementación no debe contener variables $_GET, $_POST.
El Controlador, no debe tratar directamente de realizar un acceso explícito a
los datos del sistema. Por ejemplo, su implementación no debe contener código
para consultas a Bases de Datos.
El Controlador no debe tratar directamente con la presentación de los datos para la
solicitud del usuario nal. Por ejemplo, su implementación no debe contener código de
presentación HTML.
57
RISTI, N.º 26, 03/2018
RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação
Figura 1 – Representación gráca del estilo arquitectónico MVC.
Elemento Descripción
Modelo Representa los datos del sistema y las reglas de negocio que rigen el acceso a los datos.
El Modelo notica a la Vista si se ha hecho un cambio a los datos.
Vista Es la representación del Modelo en un formato deseado por el usuario nal. La Vista
consulta al Modelo para cualquier cambio en los datos.
Controlador Es un intermediario entre la Vista y el Modelo. El Controlador recibe las acciones del
usuario nal, las solicitudes de comandos provenientes de la Vista, invoca los métodos
requeridos en el Modelo y cambia la presentación de la Vista del Modelo cuando es
necesario.
Tabla 1 – Descripción de los elementos del estilo arquitectónico MVC.
2.1. Caracterización de Bad Smells MVC
El concepto de bad smell arquitectónico fue originalmente usado en (Lippert and Roock
2006) para describir la aparición de un problema de diseño o implementación que
ocurre a un alto nivel de abstracción. Esto es, problema de diseño o implementación
en la arquitectura. Las causas de los bad smells arquitectónicos incluyen, entre otros,
aplicar un concepto de diseño arquitectónico en un contexto inapropiado, mezclar
responsabilidades entre componentes o aplicar abstracciones de diseño en el nivel a un
nivel de granularidad incorrecto (Lippert and Roock 2006).
Aunque casi todos los desarrolladores Web conocen el estilo MVC, su implementación
correcta elude a muchos de estos (Best MVC Practices 2017). Frecuentemente, las
restricciones generales, que se denieron en la sección anterior, no son respetadas. Esto
da como resultado decisiones de diseño decientes de diseño o implementación, que en
este trabajo llamamos bad smells MVC. Especícamente, y considerando las restricciones
antes mencionadas, la Tabla 2 describe una caracterización de bad smells MVC.
Es importante resaltar que esta caracterización de bad smells no es propuesta desde cero
por nosotros; se deriva de una recopilación de información extraída de varias fuentes
(por ejemplo, blogs de desarrolladores, sitios de preguntas y respuestas), que hemos
denido en este trabajo de manera más completa y consolidada.
58 RISTI, N.º 26, 03/2018
Caracterización y Detección Automática de Bad Smells MVC
Id Elemento Descripción
1. El Modelo incluye cálculos y/o
datos de la Vista
Ocurre cuando el Modelo realiza responsabilidades
relacionadas a presentación o recepción de datos en la interfaz
del usuario (por ejemplo, código HTML).
2. El Modelo incluye cálculos y/o
datos del Controlador
Ocurre cuando el Modelo accede de forma directa a
información sobre las solicitudes del usuario (por ejemplo,
acceso directo a las variables $_GET, $_POST).
3. La Vista incluye cálculos y/o
datos del Modelo
Ocurre cuando la Vista tiene responsabilidades relacionadas
a la consulta y persistencia de datos (por ejemplo, código de
acceso a la base de datos).
4. La Vista incluye cálculos y/o
datos del Controlador
Ocurre cuando la Vista accede de forma directa a información
sobre las solicitudes del usuario (por ejemplo, acceso directo a
las variables $_GET, $_POST).
5. El Controlador incluye cálculos
y/o datos de la Vista
Ocurre cuando el Controlador Modelo realiza
responsabilidades relacionadas a presentación o recepción de
datos en la interfaz del usuario (por ejemplo, código HTML).
6. El Controlador incluye cálculos
y/o datos del Modelo
Ocurre cuando el Controlador tiene responsabilidades
relacionadas a la consulta y persistencia de datos (por
ejemplo, código de acceso a la base de datos).
Tabla 2 – Caracterización de bad smells relevantes en el estilo arquitectónico MVC.
Una vez presentada la caracterización de bad smells relevantes en el estilo arquitectónico
MVC, que es la primera contribución presentada en este trabajo, en la siguiente sección
describimos el método de detección automática de estos bad smells.
3. Detección automática de Smells MVC
La herramienta de detección automática de smells MVC presentada en este trabajo
funciona para sistemas implementados en el framework Yii. Yii es un framework de
desarrollo creado en el año 2008. Yii es orientado a objetos, usa en el lenguaje PHP
(PHP 2018) y es ampliamente utilizado para el desarrollo de una amplia gama de
sistemas Web. Gracias a que no demanda grandes recursos para la ejecución de los
sistemas implementados, Yii es adecuado para desarrollar sistemas Web de gran tráco
como portales, foros, sistemas de administración de contenidos, sistemas de comercio
electrónico, etc. Como la mayoría de los frameworks PHP, Yii es un framework MVC
(modelo-vista-controlador).
En lugar de construir una herramienta desde el principio, se decidió extender las
capacidades de la herramienta PHP_CodeSnier. En las siguientes secciones se proveen
los detalles correspondientes.
3.1.PHP_CodeSnier.
PHP_CodeSnier es una herramienta de análisis estático de software (PHP_CodeSnier
2018). El análisis estático de software es un tipo de análisis que se realiza sin ejecutar
el código fuente de un sistema –en contraste con el análisis dinámico de software que
se realizado sobre un sistema en ejecución. En la mayoría de los casos, el análisis se
59
RISTI, N.º 26, 03/2018
RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação
realiza en alguna versión del código fuente y en otros casos se realiza en el código objeto.
El término se aplica generalmente a los análisis realizados automáticamente usando una
herramienta –en contraste con el análisis realizado por un humano, que es denominado
comprensión de programas o revisión de código.
PHP_CodeSnier utiliza archivos denominados snis para detectar violaciones
al conjunto de reglas denidas en un estándar de código (PHP_CodeSnier 2017).
Un estándar de código puede denirse como un conjunto de convenciones que deben
utilizarse para escribir archivos de código fuente con el objetivo de lograr estructuras de
código que tienen más calidad. Algunos ejemplos de estándares de codicación incluyen:
el estándar de código PEAR (PEAR - PHP Extension and Application Repository 2018)
o el de GNOME (GNOME Programming Guidelines 2018).
PHP_CodeSnier funciona sobre la base de separar el contenido de un archivo
de código en bloques de construcción, llamados tokens y luego validarlos para vericar
una variedad de aspectos especicados en un estándar de codicación. Se pueden usar
múltiples estándares de codicación dentro de PHP_CodeSnier. Después del proceso
de análisis estático, PHP_CodeSnier genera una lista de las violaciones que han sido
encontradas, con los correspondientes mensajes de error y números de línea.
Un estándar de código en PHP_CodeSnier consiste en una colección de archivos de
código abierto denominados archivos sni. Cada archivo sni verica una convención
del estándar de código y puede ser codicada en PHP, JavaScript, o CSS. Por lo
tanto es posible crear nuevos estándares de codicación, reutilizando, extendiendo y
construyendo nuevos archivos sni.
3.2. Estándar de Código para Detectar Smells MVC.
Para detectar bad smells Arquitectónicos MVC, construimos una estándar de código
llamado Yii MVC. Los archivos sni en este estándar de código son clases PHP, que se
utilizan en seis algoritmos de detección para identicar los bad smells MVC denidos
en la Tabla 2.
La Figura 2 muestra un extracto de código de un archivo sni. Este archivo sni, en
comparación con otros, es utilizado para detectar el bad smell número 6, que ocurre
cuando el Controlador incluye cálculos y/o datos del Modelo. Como se explicó
anteriormente, este bad smell está relacionado con el problema que aparece cuando un
Controlador realiza las responsabilidades de un Modelo. Por lo tanto en términos de
código, este bad smell resulta incluir un modelo de código para leer escribir o actualizar
los datos e incluso almacenarlos, en una base de datos.
Como se muestra en la Figura 2, una clase de tipo Sni debe implementar la interfaz
PHP_CodeSnier_Sni. Esta interfaz declara dos funciones que son necesarias para
el análisis estático del código: la función register y la función process. La función
register permite a un sni recuperar los tipos de tokens que van a analizar, en este
caso el análisis es sobre cadenas de texto. Una vez que las cadenas están listas para ser
analizadas, se llama a la función process con una referencia al archivo de código que
se está analizando y otra referencia a una pila en donde se encuentran las cadenas de
texto: la primer referencia es el parámetro denominado PHP_CodeSnier_File y la
segunda referencia es el parámetro $stackPtr, respectivamente.
60 RISTI, N.º 26, 03/2018
Caracterización y Detección Automática de Bad Smells MVC
Se puede encontrar información sobre una cadena de texto con el método getTokens
en el archivo que contiene el código que se está analizando (línea 13). Este método
regresa un arreglo de cadenas, que se indexa de acuerdo a la posición de la cadena en la
pila de cadenas. Las cadenas tienen un índice denominado content para acceder a su
contenido tal y como aparece en el código.
El análisis implementado detecta la declaración delete (línea 14) en el código
de un archivo que pertenece al Controlador. Esta declaración permite la eliminación
de registros en la base de datos. Si la declaración delete se encuentra en el código
se activa el mensaje de detección del bad smell (líneas 17-20). Un sni indica que ha
ocurrido un error mediante el método addError, el cual es el encargado de generar el
mensaje de error como primer argumento, y la posición en la pila donde fue detectado
el error como segundo argumento, incluido el código para identicar de forma única el
tipo de error dentro del sni y un arreglo de datos utilizado dentro del mensaje de error.
...
5: class Yii_Snis_Bad smellsArchitectureMVC_SA6_DeleteSni implements
6: PHP_CodeSnier_Sni {
7: public function register() {
8: return array(T_STRING);
9: }
10:
11: public function process(PHP_CodeSnier_File $phpcsFile, $stackPtr){
12: $name = $phpcsFile->getFilename();
13: $tokens = $phpcsFile->getTokens();
14: if ($tokens[$stackPtr][‘content’] === ‘delete’) {
15: ...
16: if (strpos($name, “controllers”)) {
17: $error = ‘6. Controller includes Model’s computations and/or
18: data --> Executes a SQL statement.;
19: Delete found’;
20: $data = array(trim($tokens[$stackPtr][‘content’]));
21: $phpcsFile->addError($error, $stackPtr, ‘Found’, $data);
22: }
23: }
24: }
...
Figura 2 – Extracto de un archivo sni para el bad smell número 6: El Controlador incluye
cálculos y/o datos del Modelo.
Cuando PHP_CodeSnier se ejecuta en un proyecto Yii usando el estándar de código
Yii MVC, existen dos tipos de reportes que se pueden obtener: detallado o resumido.
La Figura 3 muestra un ejemplo de un reporte detallado que produce una lista de bad
smells encontrados, incluyendo el mensaje de error correspondiente y el número de
línea. En la Figura 3 se muestra el reporte producido en el análisis estático del archivo
de código: CongurationController.php. La Figura 4 muestra un ejemplo de
61
RISTI, N.º 26, 03/2018
RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação
reporte resumido, que contiene una lista de todos los bad smells detectados en el análisis
estático los cuales están ordenados por tipo.
Una vez que se ha presentado la herramienta de detección automática de bad smells
MVC, que es la segunda contribución presentada en este trabajo, en la siguiente sección
se describe la evaluación de las contribuciones presentadas.
4. Evaluación
En esta sección se presentan los resultados obtenidos al realizar dos experimentos para
determinar la relevancia de las contribuciones esperadas: (i) la caracterización de bad
smells relevantes para el estilo MVC y (ii) la detección automática de estos bad smells
utilizando técnicas de análisis estático.
4.1. Caracterización Propuesta y Detección Automática.
Idealmente para evaluar si la caracterización de los bad smells era relevante, se deberían
comparar los bad smells detectados con los contenidos en un gold standard como en los
Sistemas de Recuperación de Información (Manning, Raghavan and Schütze 2017). Hasta
donde sabemos, no existe un gold standard para determinar el número de bad smells
introducidos en un sistema MVC. Por esta razón realizamos una serie de experimentos básicos
en algunos sistemas existentes. Especícamente, se analizaron cinco sistemas creados por
terceros e implementados con el Framework Yii para detectar los bad smells MVC utilizando
PHP_CodeSnier con el estándar de código Yii MVC. Los sistemas son públicos y de código
abierto, y pueden ser descargados desde GitHub (GitHub 2018).
FILE ... protected/Controllers/CongurationController.php
----------------------------------------------------------------------
FOUND 6 ERRORS AFFECTING 6 LINES
----------------------------------------------------------------------------
84 | ERROR | 6. Controller includes Model’s computations and/or data --> Executes a
| | SQL statement.;
Delete found
154| ERROR | 6. Controller includes Model’s computations and/or data --> Executes a
| | SQL statement.;
Count found
222| ERROR | 6. Controller includes Model’s computations and/or data --> Executes a
| | SQL statement.;
Delete found
244| ERROR | 6. Controller includes Model’s computations and/or data --> Executes a
| | SQL statement.;
Update found
264| ERROR | 6. Controller includes Model’s computations and/or data --> Executes a
| | SQL statement.;
Insert found
291| ERROR | 6. Controller includes Model’s computations and/or data --> Executes a
| | SQL statement.;
Delete found
Figura 3 – Un ejemplo de un reporte de errores detallado.
62 RISTI, N.º 26, 03/2018
Caracterización y Detección Automática de Bad Smells MVC
La Tabla 3 muestra los resultados obtenidos al ejecutar los experimentos. Se comprobó
que todos los sistemas analizados tenían bad smells MVC. El bad smell MVC detectado
con mayor frecuencia fue el bad smell número 6: El Controlador incluye cálculo y/o
datos del Modelo. El único bad smell MVC sin ocurrencias en los análisis realizados a
todos los sistemas fue el número 4: La Vista incluye cálculos y/o datos del Controlador.
Aunque los tiempos de detección automática son un tanto heterogéneos, es claro que
estos aumentan entre más líneas de código tenga el sistema.
CODE BAD SMELLS SUMMARY
---------------------------------------------
STANDARD BAD SMELL ID COUNT
---------------------------------------------------
Yii MCV 6 91
Yii MCV 3 50
Yii MCV 3 12
Yii MCV 2 9
Yii MCV 5 6
Yii MCV 1 5
Yii MCV 2 2
Yii MCV 2 1
---------------------------------------------
A TOTAL OF 176 BAD SMELLS FOUND
---------------------------------------------------
TIME: 69 MIN, 49 SEC
Figura 4 – Un ejemplo de un reporte de errores resumido.
Sistema Líneas de
código
Bad smells
detectados
Bad smells
con mayor
ocurrencia
Bad
smells sin
ocurrencias
Tiempo
1. Linkbooks 66, 954 176 6 4 69 min,
49 seg.
2. yii play
ground 17, 341 20 6 4 10 min,
54 seg.
3. Blog
Bootstrap 6, 393 15 6 4 5 min,
5 seg.
4. yii2-shop 5, 324 14 6 4 4 min,
37 seg.
5. yii-jenkis 836 1 6 1, 2, 3, 4
y 5 1.57 seg.
Tabla 3 – Resultados obtenidos utilizando PHP_CodeSnier con el estándar de código Yii MVC.
4.2. Caracterización Propuesta y Detección Manual.
Para evaluar el grado de disminución de tiempo y esfuerzo en la detección de bad smells
MVC usando el PHP_CodeSnier se realizó otro experimento. El experimento consistió
63
RISTI, N.º 26, 03/2018
RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação
en la detección manual de los bad smells MVC en el sistema en el cual el cual el PHP_
CodeSnier consumió mas tiempo: Linkbooks. La detección la realizaron a un grupo
de 15 desarrolladores de nivel experimentado, con conocimientos sólidos en ingeniería
de software, arquitectura de software, el estilo arquitectónico MVC y el framework Yii.
Los sistemas fueron proporcionados los participantes y se les pidió que realizaran una
revisión de código durante 69 minutos y 49 segundos. Esto es durante el mismo tiempo
que tomó la detección automática de bad smells MVC en el sistema Linkbooks. Se explicó
y proporcionó la caracterización propuesta de bad smells MVC a los desarrolladores.
Diez desarrolladores detectaron de 2 a 5 bad smells, tres desarrolladores encontraron
de 6 a 10 bad smells y dos desarrolladores encontraron de 10 a 20 bad smells. Así, con
la revisión de código realizada por 15 desarrolladores durante 69 minutos y 49 segundos
se detectaron un total de 45 bad smells MVC. Esto en contraste con los 176 detectados
automáticamente.
De este total de 44, el bad smell MVC detectado con mayor frecuencia fue el número 6:
El Controlador incluye cálculo y/o datos del Modelo, con 33 ocurrencias. Los bad smells
MVC que no fueron detectados son el número 4: La Vista incluye cálculos y/o datos del
Controlador y el número 5: El Controlador incluye cálculos y/o datos de la Vista.
Habiendo discutido los resultados de estos análisis básicos, en la siguiente sección
abordaremos trabajos relacionados.
5. Trabajos Relacionados
Hay dos tipos de categorías principales para trabajos relacionados: (i) catálogos de
bad smells y (ii) las herramientas para la detección de bad smells. En esta sección,
relacionamos nuestro trabajo con el encontrado en la literatura sobre estas dos
categorías.
5.1. Catálogos de bad smells.
En la literatura se distinguen varios tipos de bad smells, que al ser organizados ha
propiciado la denición de catálogos que caracterizan los bad smells en los siguientes
tipos: (i) de código, (ii) de diseño y (iii) de arquitectura. A continuación describimos
cada uno de estos.
Los bad smells de código decriben problemas originados por malas prácticas de
programación. Existen catálogos que denen bad smells de código; entre los más
relevantes encontramos (SourceMaking: Code Smells 2018).
Los bad smells de diseño se producen generalmente por violaciones a principios o conceptos
del diseño orientado a objetos. Existen catálogos que denen bad smells de diseño como
por ejemplo (Ganesh, Sharma, and Suryanarayana 2013) y (Lippert and Roock 2006).
La arquitectura de un sistema es un término que se utiliza para referirse a un modelo
de alto nivel que describe su estructuración general en términos de componentes y
relaciones (también llamados conectores) entre ellos y las propiedades de ambos (Bass,
64 RISTI, N.º 26, 03/2018
Caracterización y Detección Automática de Bad Smells MVC
Clements, and Kazman 2012). Los bad smells de arquitectura se reeren a soluciones
no apropiadas al contexto o uso inapropiado de abstracciones de diseño arquitectónico.
A pesar de la gran variedad de trabajos que analizan el impacto de los bad
smells en arquitecturas de software, se han propuesto muy pocos catálogos de bad
smells arquitectónicos. Uno de ellos se propone en (García et al. 2009) e incluye
cuatro bad smells arquitectónicos mencionados a continuación: connector envy,
scattered parasitic functionality, ambiguous interfaces, y extraneous adjacent
connector. En (Vale et al. 2014) los autores realizaron una revisión sistemática para
caracterizar los bad smells arquitectónicos.. Los autores reportaron un conjunto
de 14 bad smells arquitectónicos, que además de los 4 bad smells arquitectónicos
reportados en (García et al. 2009) y en versiones especícas de SLP (por ejemplo,
connector envy SPL), se encontraron otros como: component concern overload,
cyclic dependency, overused interface, redundant interface, unwanted dependencies
y feature concentration. Además de los pocos catálogos que consideran los bad smell
a nivel arquitectónico, ninguno de ellos considera los bad smells dentro del contexto
de un estilo arquitectónico, en contraste con nuestro trabajo.
5.2. Herramientas para la detección de bad smells.
Existen herramientas que permiten la detección automática de algunos de los bad
smells mencionados anteriormente y otras herramientas que proporcionan una vista de
la estructura del sistema para encontrarlos manualmente.
En (Fernandes et al. 2016) los autores presentan los hallazgos de una revisión sistemática
en la literatura con un total de 84 herramientas para la detección de bad smells. Entre
otras observaciones los autores reportan que las herramientas existentes para analizar el
código, se concentran en 3 lenguajes de programación, como Java, C, y C++. Encontraron
4 herramientas para el análisis de sistemas de código desarrollados en PHP. Con respecto
a las estrategias de detección, los autores descubrieron que la mayoría de la herramientas
están basadas en métricas. Finalmente, los autores encontraron 61 bad smells diferentes
detectables por herramientas, incluyendo Fowler’s [1] así como otras encontradas en
(Bavota et al. 2015), (Khomh et al. 2011), (Maiga et al. 2012) y (Vidal, Marcos, and
Díaz-Pace 2014). A diferencia de la mayoría de estas herramientas descritas, la
herramienta presentada en este trabajo puede detectar bad smells en sistemas
implementados en PHP. Además, los bad smells detectados por nuestra herramienta
son arquitectónicos y relevantes para el estilo arquitectónico MVC.
6. Conclusiones y Trabajo Futuro
En este trabajo, presentamos nuestro progreso en la caracterización (i) de un conjunto
de bad smells que son relevantes para el estilo arquitectónico MVC, así como (ii) la
detección automática de estos bad smells utilizando técnicas de análisis estático en
código de sistemas implementados con el Framework Yii.
La realización de este trabajo nos permite armar que las herramientas de detección
de bad smells arquitectónicos son ciertamente útiles para evaluar qué partes del código
65
RISTI, N.º 26, 03/2018
RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação
deben mejorarse para respetar las restricciones impuestas por el estilo arquitectónico
utilizado. Es posible concluir que es se pueden desarrollar herramientas de detección
de bad smells arquitectónicos usando análisis estático y estándares de código denidos
para este propósito.
Los resultados obtenidos en nuestros experimentos en la detección automática
muestran que la mayoría de los bad smells MVC denidos existen en la práctica.
Además, aunque los tiempos de detección automática son un tanto heterogéneos, son
mejores en comparación con los requeridos en una revisión de código realizada de forma
manual. Para el experimento realizado con una revisión de código, involucrando a 15
desarrolladores, se logró detectar solo el 25.5 % de los bad smells MVC que detectaron
usando la herramienta PHP_CodeSnier. A nivel individual el desarrolladores
que rindió mejor detectó 20 bad smells MVC, lo que representa solo el 11.3 % de los que
detectaron de forma automática.
Aunque este trabajo continúa en progreso, consideramos que los resultados obtenidos
hasta el momento son importantes no solo en el área de investigación sino también para
el área desarrollo, donde podría ser de gran utilidad el uso de los artefactos generdos.
Como posibles líneas trabajo a futuro, tenemos planeado investigar aspectos
relacionados, incluyendo la identicación y caracterización de otros bad smells que
pueden ocurrir en arquitecturas MVC, la detección de bad smells en otros lenguajes
de programación, y la mejora continua de la herramienta. En los siguiente párrafos
abundamos sobre estas líneas.
Consideramos que es posible agregar a nuestro conjunto inicial de bad smells
arquitectónicos MVC otros bad smells que no se están documentados en la literatura.
Nosotros visualizamos la clasicación de bad smells MVC basada considerando
dimensiones, como por ejemplo el comportamiento y la estructura (Ganesh, Sharma,
and Suryanarayana 2013). Todos los bad smells detectados por usando el enfoque
descrito en este trabajo consideran solo la una dimensión de comportamiento.
Como se describe en (Fernandes et al. 2016) la mayoría de las herramientas que permiten
detectar bad smells, están restringidas para solo detectar bad smells en un lenguaje de
programación especíco, lo cual se convierte en una limitación signicativa para cada
una de las herramientas que permiten detectar bad smells. Por otro lado, existen técnicas
de machine learning que son métodos computacionales que usan la “experiencia” para
obtener una mejor precisión en la predicción. Consideramos que la aplicación de técnicas
de machine learning para la detección de bad smells arquitectónicos puede favorecer
el desempeño y la precisión, así como soportar más de un lenguaje de programación,
siempre y cuando se tengan conjuntos de ejemplos para el entrenamiento.
Finalmente, con respecto a la mejora del soporte de herramientas, tenemos la intención
de explorar la identicación de posibles refactorizaciones del código para corregir los
bad smells identicados. Además, también sería útil que los bad smells detectados
se pudieran mostrar de manera visual. Consideramos que esto contribuiría a que
programadores novatos pudieran comprender de forma más fácil por qué no se respeta
las restricciones del estilo.
66 RISTI, N.º 26, 03/2018
Caracterización y Detección Automática de Bad Smells MVC
Referencias
Bass, L., Clements, P., & Kazman, R. (2012). Software Architecture in Practice. Boston,
MA, USA: Addison-Wesley Professional.
Bavota, G. (2015). An Experimental Investigation on the Innate Relationship between
Quality and Refactoring. Journal of Systems and Software, 107, 1–14.
SourceMaking. (2018). SourceMaking: Code Smells 2018. Retrieved from:
https://sourcemaking.com/refactoring/badsmellsincode
Yiiframework. (2017). Best MVC Practices. Retrieved from: http://www.yiiframework.
com/doc/guide/1.1/en/basics.best-practices.
Brown, N. (2010). Managing Technical Debt in Software Reliant Systems. In Proceedings
of Workshop on Future of Software Engineering Research, at the 18th ACM
SIGSOFT International Symposium on Foundations of Software Engineering,
ACM, (pp. 47-52). Santa Fe, NM, USA : ACM.
Django Software Foundation. (2018). Django. Retrieved from: https://www.
djangoproject.com.
Espejo Chavarría, A., Bayona Oré, S., & Pastor, C. (2016). Aseguramiento de la calidad en
el proceso de desarrollo de software utilizando CMMI, TSP y PSP. RISTI - Revista
Ibérica de Sistemas y Tecnologías de Información, 20(12), 62–77.
Fernandes, E. (2016). A Review-Based Comparative Study of Bad Smell Detection Tools.
In Proceedings of 20th International Conference on Evaluation and Assessment in
Software Engineering (pp. 109-20). New York: ACM.
Fowler, M. (1999). Refactoring: Improving the Design of Existing Code. Boston, MA,
USA: Addison-Wesley.
Gamma, E. (1995). Design patterns: Elements of reusable object-oriented software.
Reading, MA, USA: Addison-Wesley.
Ganesh, S. G., Sharma, T., & Suryanarayana, G. (2013). Towards a Principle-Based
Classication of Structural Design Smells. Journal of Object Technology 12(2):
1–29.
García, J., Popescu, D., Edwards, G., & Medvidovic, N. (2009). Toward a Catalogue of
Architectural Bad Smells. In Proceedings of 5th International Conference on the
Quality of Software Architectures (pp. 146–62). Berlin, Heidelberg: Springer-Verlag.
GitHub. (2018). GitHub. Retrieved from: https://github.com/
GNOME developer. (2018). GNOME Programming Guidelines. Retrieved from:
https://developer.gnome.org/programming-guidelines/stable/
Khomh, F., Vaucher, S., Guéhéneuc, Y., & Sahraoui, H. (2011). BDTEX: A GQM-Based
Bayesian Approach for the Detection of Antipatterns. Journal of Systems and
Software 84: 559–72.
Laravel. (2018). Laravel. Retrieved from: https://laravel.com.
67
RISTI, N.º 26, 03/2018
RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação
Lippert, M., & Roock, S. (2006). Refactoring in Large Software Projects: Performing
Complex Restructurings Successfully. Wiley.
Maiga, A. (2012). Support Vector Machines for Anti-Pattern Detection. In Proceedings
of 27th International Conference on Automated Software Engineering,
(pp. 278-81). New York: IEEE Press.
Manning, C. D., Raghavan, P., & Schütze, H. (2017). Introduction to information
retrieval. Delhi: Cambridge University Press.
Morales Huanca, L., & Bayona Oré, S. (2017). Factores que afectan la precisión de la
estimación del esfuerzo en proyectos de software usando puntos de caso de uso.
RISTI - Revista Ibérica de Sistemas y Tecnologías de Información, 21(03), 18–32.
PEAR. (2018). PEAR - PHP Extension and Application Repository. Retrieved from:
http://pear.php.net/
PEAR. (2018). PHP_CodeSnier. Retreived from: https://pear.php.net/package/
PHP_CodeSnier.
PHP. (2018). PHP: Hypertext Processor. Retrieved from: https://secure.php.net/
Rails. (2018). Rails. Retrieved from: http://rubyonrails.org
Source Makings. (2017). Source Makings, Code Smells. Retreived from:
https://sourcemaking.com/refactoring/smells.
Spring. (2018). Spring. Retrieved from: https://spring.io.
Vale, G., Figueiredo, E., Abílio, R., & Costa, H. (2014). Bad Smells in Software Product
Lines: A Systematic Review. In Proceedings of Eighth Brazilian Symposium on
Software Components, Architectures and Reuse (pp. 84–94). Washington, DC,
USA: IEEE Computer Society.
Vidal, S., Marcos, C., & Díaz-Pace, J. (2014). An Approach to Prioritize Code Smells for
Refactoring. Automated Software Engineering 23: 501–32.
YiiFramework. (2017). YiiFramework. Retreieved from: http://www.yiiframework.com/.
Article
Full-text available
Previous studies have investigated the reasons behind refactoring operations performed by developers, and proposed methods and tools to recommend refactorings based on quality metric profiles, or on the presence of poor design and implementation choices, i.e., code smells. Nevertheless, the existing literature lacks observations about the relations between metrics/code smells and refactoring activities performed by developers. In other words, the characteristics of code components increasing/decreasing their chances of being object of refactoring operations are still unknown. This paper aims at bridging this gap. Specifically, we mined the evolution history of three Java open source projects to investigate whether refactoring activities occur on code components for which certain indicators—such as quality metrics or the presence of smells as detected by tools—suggest there might be need for refactoring operations. Results indicate that, more often than not, quality metrics do not show a clear relationship with refactoring. In other words, refactoring operations are generally focused on code components for which quality metrics do not suggest there might be need for refactoring operations. Finally, 42% of refactoring operations are performed on code entities affected by code smells. However, only 7% of the performed operations actually remove the code smells from the affected class.
Article
Full-text available
Code smells are a popular mechanism to find structural design problems in software systems. Consequently, several tools have emerged to support the detection of code smells. However, the number of smells returned by current tools usually exceeds the amount of problems that the developer can deal with, particularly when the effort available for performing refactorings is limited. Moreover, not all the code smells are equally relevant to the goals of the system or its health. This article presents a semi-automated approach that helps developers focus on the most critical problems of the system. We have developed a tool that suggests a ranking of code smells, based on a combination of three criteria, namely: past component modifications, important modifiability scenarios for the system, and relevance of the kind of smell. These criteria are complementary and enable our approach to assess the smells from different perspectives. Our approach has been evaluated in two case-studies, and the results show that the suggested code smells are useful to developers.
Article
Full-text available
Developers may introduce anti-patterns in their software systems because of time pressure, lack of understanding, communication, and--or skills. Anti-patterns impede development and maintenance activities by making the source code more difficult to understand. Detecting anti-patterns in a whole software system may be infeasible because of the required parsing time and of the subsequent needed manual validation. Detecting anti-patterns on subsets of a system could reduce costs, effort, and resources. Researchers have proposed approaches to detect occurrences of anti-patterns but these approaches have currently some limitations: they require extensive knowledge of anti-patterns, they have limited precision and recall, and they cannot be applied on subsets of systems. To overcome these limitations, we introduce SVMDetect, a novel approach to detect anti-patterns, based on a machine learning technique---support vector machines. Indeed, through an empirical study involving three subject systems and four anti-patterns, we showed that the accuracy of SVMDetect is greater than of DETEX when detecting anti-patterns occurrences on a set of classes. Concerning, the whole system, SVMDetect is able to find more anti-patterns occurrences than DETEX.
Article
Full-text available
Fred Brooks in his book "The Mythical Man Month" describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an "essential" difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address "design smells" that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.
Conference Paper
Bad smells are symptoms that something may be wrong in the system design or code. There are many bad smells defined in the literature and detecting them is far from trivial. Therefore, several tools have been proposed to automate bad smell detection aiming to improve software maintainability. However, we lack a detailed study for summarizing and comparing the wide range of available tools. In this paper, we first present the findings of a systematic literature review of bad smell detection tools. As results of this review, we found 84 tools; 29 of them available online for download. Altogether, these tools aim to detect 61 bad smells by relying on at least six different detection techniques. They also target different programming languages, such as Java, C, C++, and C#. Following up the systematic review, we present a comparative study of four detection tools with respect to two bad smells: Large Class and Long Method. This study relies on two software systems and three metrics for comparison: agreement, recall, and precision. Our findings support that tools provide redundant detection results for the same bad smell. Based on quantitative and qualitative data, we also discuss relevant usability issues and propose guidelines for developers of detection tools.
Article
Software product line (SPL) is a set of software systems that share a common, managed set of features satisfying the specific needs of a particular market segment. Bad smells are symptoms that something may be wrong in system design. Bad smells in SPL are a relative new topic and need to be explored. This paper performed a Systematic Literature Review (SLR) to find and classify published work about bad smells in SPLs and their respective refactoring methods. Based on 18 relevant papers found in the SLR, we identified 70 bad smells and 95 refactoring methods related to them. The main contribution of this paper is a catalogue of bad smells and refactoring methods related to SPL.
Conference Paper
Almost every expert in Object-Oriented Development stresses the importance of iterative development. As you proceed with the iterative development, you need to add function to the existing code base. If you are really lucky that code base is structured just right to support the new function while still preserving its design integrity. Of course most of the time we are not lucky, the code does not quite fit what we want to do. You could just add the function on top of the code base. But soon this leads to applying patch upon patch making your system more complex than it needs to be. This complexity leads to bugs, and cripples your productivity.