Refactorizacin 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
Introducción (III)

• Ejemplo
• Modelo de la solución

Vector
Catalogo
módulos
7
Introducción (III)

• Ejemplo

Vector
Catalogo
módulos
8
Introducción (III)

• Ejemplo

Vector
Catalogo
módulos
9
Introducción (III)

• Ejemplo

10
Introducción (III)
X

• Ejemplo

Vector
Catalogo
módulos
Adaptación incremental
Lista
11
Introducción (III)

• Ejemplo

Vector
Catalogo
módulos
Adaptación incremental
Lista
12
Introducción (III)

• Ejemplo

Catalogo
Vector
módulos
Adaptación incremental
Lista
13
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
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
... 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. LISTAT),
• la clase original pasa a ser una instancia de la
  nueva clase (Ej. LISTAINTEGER),
• - 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ónreorganizació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.
  195-115, 1994.

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
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
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. 889120, 2001.
• Refactoring home page http//www.refactoring.com