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

2 2 Índice Introducción a la refactorización de software 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 3 Introducción El término refactorización 1 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 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 5 Introducción (III) Ejemplo: Modelo del dominio del negocio ModuloCatalogo 10 módulos

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

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

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

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

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

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

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

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

14 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 15 Introducción (V) Ejemplo: Vector Lista Adaptación incremental... class Catalogo { Vector modulos... Catalogo() {... modulos = new Vector(10) }... new Lista() y reestructuración Reorganización Lista modulos Catalogo módulos X ¿Se ha refactorizado? módulos.total=10 X

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

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

18 18 Introducción (VI)

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

20 20 Refactoring & reuse

21 21 Refactoring & reuse (II)

22 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 23 Clasificación... (II) – 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. Agresiva, Resp. clientes, Resp. objetos Inferencia, Demanda Manual, Semiautomática, Automática elementos de Análisis, Diseño, Implementación

24 24 Clasificación... (III)

25 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 26 Clasificación... (V) Define la siguiente refactorización:

27 27 Clasificación... (VI)

28 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 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 30 Estado del arte (II)

31 31 Estado del arte (III)

32 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 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 34 Estado del arte (VI)

35 35 Un ejemplo del trabajo propio

36 36... 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) clase objetivoentidad guía nuevo parámetro genérico

37 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 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 39... trabajo propio (IV) Resumen gráfico de las operaciones

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

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

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

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

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

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

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

47 47... trabajo propio (VI)

48 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 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 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.

51 51 Referencias (II) [Chae, 1996] Chae, H. “Restructuring of classes and inheritance hierarchy in object-oriented systems”. Master's thesis, Software Engineering Laboratory, Computer Science Depart. Korea Advanced Institute of Science and Technology (KAIST), 1996. [Crespo, 2000] Crespo, Y. “Incremento del potencial de reutilización del software mediante refactorización”. PhD thesis, Universidad de Valladolid, 2000. [Fowler et al., 1999] Fowler, M., Beck, K., Brant, J., Opdyke, W., y Roberts, D. “Refactoring: Improving the Design of Existing Code”. Object Technology Series. Addison-Wesley, 1999. [Godin y Mili, 1993] Godin, R. y Mili, H. “Building and maintaining analysis-level class hierarchies using Galois lattices”. In Proceedings of OOPSLA'93, pages 394-410, 1993. [Johnson y Foote, 1988] Johnson, R. y Foote, B. “Designing reusable classes”. JOOP: Journal of Object Oriented Programming, 1(2):22-35, 1988.

52 52 Referencias (III) [Li, 1999] Li, X. “A survey of schema evolution in object-oriented databases”. In Chen, J., Lu, J., y Meyer, B., editors, Proceedings of TOOLS 31th, Asia'99.IEEE CS Press, 1999. [Lieberherr et al., 1994] Lieberherr, K., Hürsch, W., y Xiao, C. “Object-extending class transformation”. Formal Aspects of Computing, 6(4):391-416, 1994. [Marqués, 1995] Marqués, J. “Jerarquías de herencia en el diseño de software orientado al objeto”. PhD thesis, Universidad de Valladolid, 1995. [Moore, 1995] Moore, I. “Guru- a tool for automatic restructuring of Self inheritance hierarchies”. In Proceedings of TOOLS USA. Prentice-Hall, 1995. [Opdyke, 1992] Opdyke, W. “Refactoring Object-Oriented Frameworks”. PhD thesis, Department of Computer Science, University of Illinois at Urbana-Champaign, 1992.

53 53 Referencias (IV) [Pagh Schultz et al., 1999] Pagh Schultz, U., Lawall, J., Consel, C., y Muller, G. “Towards automatic specialization of Java programs”. In Guerraoui, R., editor, Proceedings of ECOOP'99, volume 1628 of Lecture Notes in Computer Science, pages 367- 390. Springer, 1999. [Rodríguez et al., 1998] Rodríguez, J., Crespo, Y., y Marqués, J. “Transformación de jerarquías de herencia múltiple en jerarquías de herencia sencilla”. Technical Report TR-GIRO-03-98, Departamento de Informática, Universidad de Valladolid, 1998. [Tip y Sweeney, 1997] Tip, F. y Sweeney, P. “Class hierarchy specialization”. In Proceedings of the Conference ACM SIGPLAN OOPSLA'97, 1997. [Tokuda y Batory, 2001] Tokuda, L. y Batory, D. “Evolving Object- Oriented Designs with Refactorings”. Automated Software Engineering, vol. 8:89–120, 2001. Refactoring home page http://www.refactoring.comhttp://www.refactoring.com