La herramienta permite capturar refactorings realizados en una imagen y exportarlos para re-ejecutarlos en otras imágenes. Esto permite que los desarrolladores actualicen componentes libremente y que los usuarios actualicen automáticamente sus aplicaciones, reduciendo los costos de mantenimiento. La herramienta identifica las dependencias entre refactorings para asegurar que se apliquen de manera exitosa.

1. Replayable Refactorings
Juan Cruz Gardey

2. ¿Qué permite hacer la herramienta?
Capturar y exportar refactorings realizados en una
imagen para poder re-ejecutarlos en otras.

3. Motivación
➔ Las aplicaciones se desarrollan reutilizando componentes (frameworks,
librerías, etc.).
➔ El código de estos componentes suele cambiar con mucha frecuencia.
◆ los cambios muchas veces “rompen” el código de las aplicaciones.
◆ Los usuarios se ven obligados a modificar su código para poder usar la
última versión de un componente.

4. Motivación (2)
➔ Para no tener problemas de compatibilidad, se dejan de realizar algunas
modificaciones.
◆ Ejemplo: eliminación de métodos “deprecated”.
◆ Mayor costo de mantenimiento.

5. Solución propuesta
➔ Realizar modificaciones por medio de refactorings.
➔ Exportar estos refactorings y volver a ejecutarlos en otras imágenes.
➔ Imagen origen (entorno de desarrollo de un componente):
◆ Los refactorings actualizan el código del componente.
➔ Imagenes destino (aplicaciones que utilizan ese componente):
◆ los refactorings actualizan el componente y también las aplicaciones
clientes.

6. Beneficios
➔ Desarrolladores de componentes pueden realizar modificaciones libremente.
➔ Usuarios actualizan sus aplicaciones automáticamente.
Menor costo de mantenimiento para ambos

7. Grabado de refactorings
➔ Capturar cada refactoring ni bien es aplicado en el código.
➔ Guardar todos sus datos para poder recrearlos en otro entorno.
➔ Exportación
◆ Archivos: Portabilidad.

8. Grabado de refactorings (2)
➔ El usuario puede elegir cuándo iniciar y finalizar una sesión de grabado.
◆ Visualizar los refactorings capturados hasta el momento.
◆ Cuando decide terminar se genera un archivo con todos sus
refactorings.
➔ Las ediciones manuales de código no se exportan. Únicamente los
refactorings.

10. Re-ejecución de refactorings
➔ Validez de los refactorings.
◆ Pueden ser válidos en una imagen y en otras no…
◆ Ejemplo: Una clase definida con el mismo nombre.
◆ Realizar chequeos para mostrarle al usuario cuáles no pueden ser
aplicados.
◆ Darle la posibilidad de corregir su código para poder realizarlos.
➔ Permitir aplicar solamente aquellos que resultaron válidos.

12. Re-ejecución de refactorings (2)
➔ El usuario debe poder elegir cuáles refactorings re-ejecutar.
◆ Ventaja: Flexibilidad, puede descartar aquellas modificaciones que no le
convengan…
◆ Problema: Algunos refactorings son aplicados sobre el resultado de otro
anterior
● DEPENDENCIAS ENTRE REFACTORINGS.

13. Re-ejecución de refactorings (3)
DEPENDENCIA ENTRE REFACTORINGS: La ejecución de un refactoring habilita la
aplicación de otro.
R1 = AddClass (Monolith).
R2 = AddMethod (Monolith, #bar).
R2 no puede ejecutarse sin R1.
➔ Necesidad de identificar estas dependencias.

14. Re-ejecución de refactorings (4)
Identificación de dependencias:
➔ Si se decide ejecutar un refactoring, también deben realizarse aquellos de los
cuales depende.
➔ Si no se hace un refactoring, tampoco pueden hacerse los que necesitan la
ejecución de este.

16. Re-ejecución de refactorings (5)
Identificación de dependencias:
➔ Asegurar que cualquier conjunto de refactorings elegidos por el
usuario se realiza de manera exitosa…
➔ Definición de postcondiciones de los refactorings.

17. Limitaciones de la herramienta
➔ Todos los cambios deben hacerse por medio de refactorings
◆ Hay algunas modificaciones que pueden ser hechas más rápidamente de forma
manual.
● Agregar una variable de instancia.
➔ No se puede asegurar que los refactorings elegidos por el usuario
conservan la funcionalidad de la aplicación.

18. Conclusiones
➔ Se construyó una herramienta que permite re-ejecutar refactorings en
una imagen del código cliente.
➔ Se calculan las precondiciones nuevamente en la imagen destino antes
de la ejecución.
➔ El desarrollador puede decidir no aplicar algún refactoring (ej: Remove
Method).
➔ La herramienta está disponible en SmalltalkHub con nombre
“ReplayableRefactorings”.

19. Funcionamiento