Implementación de la solución

En esta sección se describen los aspectos relevantes involucrados en la implementación de la solución.

4.4.1 Aplicación de refactorings

Para el caso de Extract Method, JDT ya tiene implementado el control de precondiciones necesarias para decidir si es posible la aplicación del refactoring sin introducir errores de compilación o modificar el comportamiento del sistema.

Para el caso de Move Method, es insuficiente depender únicamente del conjunto de precondiciones establecidas por el IDE Eclipse. Esto se debe a que Eclipse implementa precondiciones débiles para este refactoring [44, 45, 46]. Se denominan precondiciones débiles cuando el conjunto de precondiciones implementadas son insuficientes para garantizar la preservación del comportamiento del sistema al aplicar un refactoring. Por esta razón, es necesario analizar las cinco precondiciones adicionales propuestas por la herramienta JDeodorant y mencionadas por Sales et al. [47]:

1. La clase objetivo no debe heredar un método que posea el mismo nombre que el método a mover.

2. El método a ser movido no debe sobreescribir un método heredado en su clase original.

3. El método a ser movido no debe ser synchronized.

4. El método a ser movido no debe contener asignaciones a campos de la clase origen (incluyendo campos heredados).

5. El método a ser movido debe tener una relación uno a uno con la clase objetivo.

Este enfoque propone encapsular el Move del método realizando un Extract Method en todas las situaciones, incluso cuando se pretende mover completamente el método. En la Figura 4.11 se presenta un ejemplo de la refactorización realizada por el enfoque propuesto. En la parte izquierda se puede ver el método original. Este es el código analizado por JSpIRIT, el cual es enviado a Bandago para hallar un conjunto de soluciones. En la parte derecha de la figura se puede ver el fragmento de código extraído por la heurística y cómo este es reemplazado en el método original. En lugar de mover el método completo a la clase candidata, se realiza un extract previo que previene los conflictos señalados en las precondiciones 1 y 2, así como inconsistencias en los llamados ya existentes a dicho método en todo el sistema, debido a que el método original conserva el mismo nombre.

45

Figura 4.11: Extracción de un método previo a ser movido.

En cuanto a la precondición 4, este escenario particular introduce errores detectables en tiempo de compilación que deben ser solucionados manualmente por el desarrollador. Estos errores se consideran aceptables con el objetivo de restringir una menor cantidad de refactorizaciones. Estos casos se analizarán en profundidad durante el desarrollo del enfoque, debido a que la corrección de errores es una actividad contemplada por el esquema de la solución planteada.

Con respecto a las precondiciones 3 y 5, no se realizó ningún control debido a la dificultad que plantea la detección de estos escenarios.

4.4.2 Vista arquitectónica de Bandago

Se presenta en la Figura 4.12 un diagrama de contexto [43] de Bandago. JSpIRIT detecta los Code Smells de un proyecto, priorizados según su importancia de refactorización. De este conjunto de Code Smells, el desarrollador selecciona uno para hallar las posibles soluciones. La Figura 4.12 describe la interacción entre JSpIRIT y Bandago en el caso que el Code Smell seleccionado sea una Feature Envy. El sistema solo recibe como entrada la Feature Envy seleccionada por el desarrollador. Luego, el desarrollador elige una de las soluciones provistas para aplicar efectivamente en el código original, generando una solución final al problema seleccionado con anterioridad en la herramienta JSpIRIT.

46

Figura 4.12: Diagrama de contexto de Bandago.

La Figura 4.12 presenta una visión de la arquitectura de Bandago usando la vista de componentes y conectores [43]. Todos los componentes de este proyecto se ejecutan utilizando la plataforma Eclipse como soporte.

En el catálogo de elementos de la tabla 4.2 se detalla cada elemento de la arquitectura representado en la vista.

Elemento Descripción

JSpIRIT Esta es una herramienta externa que se encarga de encontrar todos los Code Smells de un sistema.

Bandago genera una extensión a una vista de esta herramienta y se acopla a su vista.

Eclipse JDT Es la plataforma brindada por Eclipse para poder generar,

comprobar y ejecutar una refactorización al código Java. Se encarga de la modificación directa de la ICompilationUnit.

Eclipse Platform Eclipse es una plataforma de integración de herramientas de código abierto. Esta contiene un ambiente de desarrollo de programación Java ofreciendo un alto nivel de productividad y flexibilidad. Además, puede ser ejecutado en una gran variedad de sistemas operativos. Bandago fue desarrollado sobre Eclipse.

47

Eclipse Platform Runtime

Execution

Eclipse provee el runtime event manager para el manejo y control de las interfaces de usuario. El mismo implementa el estilo arquitectónico implicit invocation. Cuando el event manager publica un evento generado por una acción de usuario como un click de un botón, draganddrop, etc., entonces los componentes que están suscritos a estos eventos serán invocados y activados.

Bandago

Refactoring Core

Este componente contiene toda la funcionalidad para soportar el enfoque de eliminación del Code Smell Feature Envy, generando varias soluciones al problema mediante el uso de una heurística que respeta una interfaz. De esta manera, se brinda la posibilidad de desarrollar distintas heurísticas a futuro y poner el foco en distintas estrategias para analizar el Code Smell. En base a esto, se puede decidir el fragmento de código a extraer. La idea principal es desacoplar el análisis que se realiza para decidir el fragmento de código a mover, de todo lo necesario para realizar el refactor propiamente dicho, dando la posibilidad de analizar el code smell desde diferentes enfoques.

Cuando se quiere eliminar las Feature Envy de un proyecto se interactúa con la herramienta JSpIRIT para obtener todos los Code Smells y luego con la User Interface views & controls se solicita cuál de estas desea eliminar. Luego se muestran en otra vista (Code Smells Solutions) todas las soluciones generadas con sus

respectivas métricas al usuario.

User Interface views & controls

Es un conjunto de componentes de interfaces de usuario (vistas, cuadros de dialogo and action handlers) que componen a Bandago. Estos presentan la interfaz de usuario y a través de ella se provee la funcionalidad que los desarrolladores van a utilizar. El usuario puede interactuar con los wizards para realizar las refactorizaciones encadenadas. Además, se puede visualizar las soluciones

propuestas.

ICompilationUnit Este es el archivo que contiene todo el código Java. Es la manera de representar y modificar todo el acceso al código fuente de un

proyecto en la plataforma de Eclipse. Es donde se aplica la

refactorización y se mantiene un archivo de estos por cada solución generada.

Code Smell Feature Envy

Este archivo contiene la información que genera la herramienta JSpIRIT. Contiene el código fuente del Code Smell identificado y más información relevante como el tipo, donde se encuentra y qué clases están afectadas.

48

Figura 4.13: Arquitectura de alto nivel de Bandago.

El componente Bandago Refactoring Core es considerado el más importante ya que se encarga de generar y ejecutar todas los posibles refactorizaciones. También este componente se encarga de hacer el traspaso de información entre el plugin JSpIRIT y Bandago, obteniendo así, todos los code smells de un proyecto con sus respectivos rankings. Todas las decisiones tomadas por el desarrollador, como la elección del Code Smell a refactorizar, son a través del componente User Interface views & controls que a su vez se comunica con el Eclipse Runtime.

49