Refactorización de software

1. Refactorización de software Yania Crespo González-Carvajal

2. Índice • Introducción a la refactorización de software • Refactorizaciones y reutilización • Una clasificación para su estudio • Estado del arte • Un ejemplo del trabajo propio • Resumen y conclusiones

3. Introducción • El término refactorización1 de software fue introducido por Opdyke [Opdyke, 1992]. • Se define en el contexto de la Orientación a Objetos (O.O.). • Refactorización es una forma especial de adaptación de software. 1 del término en inglés:refactoring

4. Introducción (II) • La adaptación de software en el contexto de la O.O. se puede caracterizar como: • Adaptación incremental: cuando la adaptación se realiza indirectamente, gracias a herencia, composición, genericidad. • Reestructuración: cuando se modifica directamente la estructura de las clases. • Reorganización: cuando se modifica la estructura de las clases y las relaciones entre estas.

5. Introducción (III) • Ejemplo: Modelo del dominio del negocio 10 Modulo Catalogo módulos

6. módulos.total=10 Introducción (III) • Ejemplo: Modelo de la solución Vector Catalogo módulos

7. módulos.total=10 Vector Catalogo • - int elems[] • - int total • int capacity • + Vector(int cap) • + bool esta_vacia() • + bool esta_llena() • + void adiciona(int elem) # Vector modulos Introducción (III) • Ejemplo: Vector Catalogo módulos

8. módulos.total=10 Catalogo ... class Catalogo { Vector modulos ... Catalogo() { ... modulos = new Vector(10) } ... # Vector modulos ... + Catalogo() Introducción (III) • Ejemplo: Vector Catalogo módulos

9. Lista Vector * bool esta_llena() * void adiciona(int elem) • - int elems[] • - int total • int capacity • + Vector(int cap) • + bool esta_vacia() • + bool esta_llena() • + void adiciona(int elem) Adaptación incremental Introducción (III) • Ejemplo:

10. módulos.total=10 ¿ ? ... class Catalogo { Vector modulos ... Catalogo() { ... modulos = new Vector(10) } ... Solución tipo “parche” new Lista() Introducción (III) X • Ejemplo: Vector Catalogo módulos Adaptación incremental Lista

11. ... class Catalogo { Vector modulos ... Catalogo() { ... modulos = new Lista() } ... Reestructuración depende de las relaciones a considerar Introducción (III) • Ejemplo: Vector Catalogo módulos Adaptación incremental Lista

12. ¿ ? ... class Catalogo { Vector modulos ... Catalogo() { ... modulos = new Vector(10) } ... Introducción (III) • Ejemplo: Vector Catalogo módulos Adaptación incremental Lista

13. ... class Catalogo { Vector modulos ... Catalogo() { ... modulos = new Vector(10) } ... new Lista() y reestructuración Introducción (III) • Ejemplo: Vector Catalogo módulos Adaptación incremental Lista Lista modulos Reorganización

14. Introducción (IV) • Una refactorización es una adaptación de software que: • consiste en la aplicación de reestructuraciones a una agrupación de clases, • los cambios implican reorganizaciones, • no dependen de qué hace el sistema, el framework, etc, sino de cómo está estructurada la solución, • generalmente tienen como objetivo refinar un diseño plasmado en un Lenguaje O.O. (L.O.O.).

15. módulos.total=10 ... class Catalogo { Vector modulos ... Catalogo() { ... modulos = new Vector(10) } ... new Lista() y reestructuración Introducción (V) X ¿Se ha refactorizado? • Ejemplo: X Vector Catalogo módulos Adaptación incremental Lista Lista modulos Reorganización

16. Introducción (VI) • Lo que sí es una refactorización

17. Introducción (VI) El calculo depende de codPrecio si NORMAL, ESTRENO o NINNOS

18. Introducción (VI)

19. Introducción (VI) Las diferencias de precios vienen resueltas polimórficamente

20. Refactoring & reuse

21. Refactoring & reuse (II)

22. Clasificación para su estudio • Se categorizan las transformaciones de tipo refactorización: • según motivo, ¿con qué objetivo se concibió la refactorización? ¿para apoyar qué aspecto en el proceso de desarrollo? • según la dirección en la que actúa, a partir de la idea de que la construcción de clases flexibles se manifiesta en dos direcciones (vertical y horizontal). vertical: se identifica con la herencia, horizontal: se identifica con la genericidad y composición • según sus resultados, ¿la transformación obtiene elementos directamente almacenables en el repositorio? Reutilización, Cambio de requisitos, Mant. y calidad Vertical, Horizontal Universal, Particular

23. Clasificación ... (II) Agresiva, Resp. clientes, Resp. objetos • según sus consecuencias, ¿qué impacto tendría empezar a utilizar los elementos resultantes en lugar de los originales? • según el método, ¿cómo se desencadenan las transformaciones? • según la intervención humana, ¿se necesita al desarrollador para la toma de decisiones? ¿en qué medida? • según el objeto, ¿de qué tipo son los elementos objeto de la trasformación? fase del ciclo de desarrollo de la que proceden. Inferencia, Demanda Manual, Semiautomática, Automática elementos de Análisis, Diseño, Implementación

24. Clasificación... (III)

25. Clasificación... (IV) Por ejemplo: Casais [1991...1994] Posicionamiento: Las jerarquías de herencia deben cumplir una serie de reglas de buena formación. “Diferir o re-implementar un método concreto heredado es un patrón inapropiado que no debería ocurrir en una jerarquía de herencia.” “Diferentes usos de la herencia --extensión, especialización, implementación,...-- deben estar separados en diferentes pasos de abstracción.”

26. Clasificación... (V) Define la siguiente refactorización:

27. Clasificación... (VI)

28. Clasificación... (VII) • Permite estudiar y presentar el estado del arte de forma concisa. • Facilita el análisis de nuevas propuestas. • No es una clasificación cerrada, puede extenderse, refinarse, o integrar otras “clasificaciones” [Li, 1999], [Lieberherr et al, 1994], [Casais, 1991].

29. Estado del arte • Trabajos más citados: • R. Johnson & B. Foote (U. Illinois at Urbana Champaign) • W. Opdyke (U. Illinois at Urbana Champaign) • P. Bergstein (NorthEastern U.) • K. Lieberherr et al. (NorthEastern U.) • E. Casais (U. Geneve) • W. Brown et al. (Concept Five Technologies, ...) • M. Fowler et al. (ThoughtWorks, ...)

30. Estado del arte (II)

31. Estado del arte (III)

32. Estado del arte (IV) • Tendencias • Construcción de herramientas. • Aparición de catálogos de “patrones" de refactorización. • Introducción en el ciclo de vida de métodos de desarrollo. • Aumento de los trabajos dirigidos a obtener resultados particulares. • Por supuesto, continuar definiendo nuevas refactorizaciones.

33. Estado del arte (V) • Técnicas aplicadas en la definición de refactorizaciones: • aproximaciones algorítmicas, • Heurísticas, • reescritura de grafos, • inteligencia artificial, • análisis de conceptos formales, • troceado de programas (program slicing), • ...

34. Estado del arte (VI)

35. Un ejemplo del trabajo propio

36. nuevo parámetro genérico clase objetivo entidad guía ... trabajo propio (I) Refactorización que permita obtener clases genéricas a partir de clases no genéricas. CUENTA_BANCARIA.parameterize(saldo as T) otro ejemplo: LISTA.parameterize((insertar, elem) as T)

37. ... trabajo propio (II) • Resultado: • - una clase genérica, replica de la clase objetivo (Ej.: LISTA[T]), • la clase original pasa a ser una instancia de la nueva clase (Ej.: LISTA[INTEGER]), • - la propagación de los cambios a todas las clases que sea necesario (Ej.: ).

38. ... trabajo propio (III) • ¿por qué una entidad guía y no el tipo que se desea cambiar? • misión: definir el conjunto de entidades que debe cambiar su tipo a variable, debido a que una entidad guía cambiará su tipo para ser un parámetro genérico formal (entidades génerico-dependientes).

39. ... trabajo propio (IV) Resumen gráfico de las operaciones

40. ... trabajo propio (IV) Resumen gráfico de las operaciones

41. ... trabajo propio (IV) Resumen gráfico de las operaciones

42. ... trabajo propio (IV) Resumen gráfico de las operaciones

43. ... trabajo propio (IV) Resumen gráfico de las operaciones

44. ... trabajo propio (IV) Resumen gráfico de las operaciones

45. ... trabajo propio (IV) Resumen gráfico de las operaciones

46. ... trabajo propio (V) • Herramienta de parametrización Click aquí para lanzar demo representación gráfica

47. ... trabajo propio (VI)

48. Resumen y conclusiones • Transformaciones de elementos de software. • Con características particulares: del tipo reestructuración+reorganización preservando comportamiento. • Esto implica que no todas las adaptaciones de software son refactorizaciones. Pero se pueden ver (y es deseable) las refactorizaciones como pasos previos a la adaptación.

49. Resumen y conclusiones (II) • Intensa actividad actualmente. • Se trabaja en elevar el nivel de abstracción de los elementos que se refactorizan. • Ligar refactorizaciones y patrones de diseño. • Es un tema muy importante en el campo de la reutilización. Ver p.e. [Tokuda y Batory , 2001]

50. Referencias • [Bergstein, 1991] Bergstein, P.L., “Object-preserving class transformation.” SIGPLAN Notices 26(11): 299-313, 1991. • [Brown et al., 1998] Brown, W., Malveau, R., Brown, W., McCormick, H., y Mowbray, T. “AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis”. John Wiley & Sons, 1998. • [Casais, 1991] Casais, E., “Managing Evolution in Object Oriented Environments: An Algorithmic Approach”, Ph.D. Thesis Centre Universitaire d'Informatique, University of Geneve, May, 1991. • [Casais, 1992] Casais, E. “An incremental class reorganization approach.” In Madsen, O., editor, Proceedings of ECOOP'92, LNCS 615, pages 114-132. Springer-Verlag, 1992. • [Casais, 1994] Casais, E. “Automatic reorganization of object-oriented hierarchies: a case study”. Object-Oriented Systems vol. 1:95-115, 1994.