Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Replayable Refactorings by Juan Cruz Gardey

36 views

Published on

Reuse greatly streamlines development, but makes systems depend on the components they reuse. By components we mean frameworks, libraries or services, which may provide APIs to interact with them. These APIs change very frequently (methods change names, become obsolete, new appear new, etc.), which impacts on the programs that use them. The purpose of the work is to develop a solution to export changes to components in the form of refactorings, and then be able to reproduce them in the code that makes use of them, in order to automatically apply software updates. These automatic updates provide the advantage of reducing maintenance costs for both component developers and programmers that use them. We have constructed a tool in Pharo that allows recording and saving refactorings in the developers’ image, and lets programmers replay the refactorings in the target image. At replay, the tool first checks all refactorings’ preconditions in the target code and highlights unsafe refactorings together with the ones that depend on them for the user to inspect. Moreover, the tool allows users to discard refactorings from the replay list, which automatically checks dependencies with other refactorings using postconditions; in this way the tool always preserves a safe sequence of refactoring to replay.

Published in: Technology
  • Login to see the comments

  • Be the first to like this

Replayable Refactorings by Juan Cruz Gardey

  1. 1. Replayable Refactorings Juan Cruz Gardey
  2. 2. ¿Qué permite hacer la herramienta? Capturar y exportar refactorings realizados en una imagen para poder re-ejecutarlos en otras.
  3. 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. 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. 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. 6. Beneficios ➔ Desarrolladores de componentes pueden realizar modificaciones libremente. ➔ Usuarios actualizan sus aplicaciones automáticamente. Menor costo de mantenimiento para ambos
  7. 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. 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.
  9. 9. 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.
  10. 10. 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.
  11. 11. 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.
  12. 12. 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.
  13. 13. 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.
  14. 14. 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.
  15. 15. 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”.
  16. 16. Funcionamiento

×