refactorización de software

Refactorización de softwareRefactorización de software

Yania Crespo González-Carvajal

2

ÍndiceÍndice

Introducción a la refactorización de software

Refactorizaciones y reutilizaciónUna clasificación para su estudioEstado del arteUn ejemplo del trabajo propioResumen y conclusiones

3

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

Ejemplo:

Modelo del dominio del negocio

Modulo Catalogo10

módulos

6


Ejemplo:

Modelo de la solución

Vector Catalogomódulos

módulos.total=10

7


Ejemplo: Vector Catalogo

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


Ejemplo: Vector Catalogo

módulos

Catalogo

# Vector modulos...

+ Catalogo()

...class Catalogo { Vector modulos ... Catalogo() { ...

modulos = new Vector(10) }...

módulos.total=10

9


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

módulos.total=10


Ejemplo: Vector

ListaAdaptaciónincremental

¿ ?



Catalogomódulos

Solución tipo “parche”new Lista()

X

11


Ejemplo: Vector


Catalogomódulos


modulos = new Lista() }...

Reestructuración

depende de las relaciones a considerar

12

Catalogo


Ejemplo:Vector




módulos¿ ?

13


Ejemplo:Vector




Catalogomódulos

new Lista()y reestructuración

Reorganización

Lista modulos

14

Introducción (IV)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)Introducción (V)

Ejemplo:Vector




new Lista()y reestructuración

Reorganización

Lista modulos

CatalogomódulosX

¿Se ha refactorizado?módulos.total=10

X

16

1

1 *seAlquila

*

alquila

Cliente

+Cliente(_nombre:String)

+situacionAlquileres():int

+annadeAlquiler(nuevo:Alquiler):void

nombre:String

Pelicula

+NORMAL:int=0

+ESTRENO:int=1

+NINNOS:int=2

+Pelicula(_titulo:String,_codPrecio:int)

titulo:String

codPrecio:int

Alquiler

+Alquiler(cual:Pelicula,dias:int)

peliculaAlquilada:Pelicula

diasAlquilado:int

Introducción (VI)Introducción (VI)

Lo que sí es una refactorización

17

Introducción (VI)Introducción (VI)unaPelicula

Pelicula

Empleado

unCliente

Cliente

unAlquiler

Alquiler

getCodPrecio():int

getPeliculaAlquilada():Pelicula

*[para todos los alquileres]

getDiasAlquilado():int

totalAFacturar:=situacionAlquileres():int

El calculo depende de codPrecio si NORMAL, ESTRENO o NINNOS

18

Introducción (VI)Introducción (VI)

*1 seAlquila

1

1

*

alquila

Alquiler

+Alquiler(cual:Pelicula,dias:int)

+cuantoCobrar():int

peliculaAlquilada:Pelicula

diasAlquilado:int

Pelicula

+Pelicula(_titulo:String,_precioInicial:Precio)

+precio():int

titulo:String

suPrecioActual:Precio

Cliente

+Cliente(_nombre:String)

+situacionAlquileres():int

+annadeAlquiler(nuevo:Alquiler):void

nombre:String

PrecioNormal

+precio():int

interface

Precio

+precio():int

PrecioEstreno

+precio():int

PrecioNinnos

+precio():int

19

Introducción (VI)Introducción (VI)unPrecio

Precio

unaPelicula

Pelicula

Empleado

unAlquiler

Alquiler

unCliente

Cliente

precio():int

precio():int cobroPorDia:=cuantoCobrar():int

*[para todos los alquileres]

totalAFacturar:=situacionAlquileres():int

cuantosDias:=getDiasAlquilado():int

Las diferencias de precios vienen resueltas

polimórficamente

20

Refactoring & reuseRefactoring & reuse

- adaptación por reutilización- adaptación por modificación de requisitos- adaptación por mantenimiento y calidad

Adaptación de Software: Causas

- adaptación incremental- reestructuración y reorganización

Adaptación de Software: Formas Generales

¿cómo?

¿por qué?

Desarrollo con reutilizacióniteración propiadel desarrollo

Desarrollo p arareutilización

iteración propiadel desarrollo

influye

prepara

conduce

conduceconduce

adaptación porreutilización

21

Refactoring & reuse (II)Refactoring & reuse (II)

Entorno dedesarrollo de

alto nivel

Repositorio

Sistema

Sistemacongelado

Lenguajes de POO

compiladores

o

cambiosmínimos

generación

diseño detallado

Herramientas deReestructuración y

Reorganización

univ

ersa

les

Herramientas deReestructuración y

Reorganización

part

icul

ares

22

Clasificación para su estudioClasificació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)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

Clasificación... (III)Clasificación... (III)

25

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

CursorUp

+execute():void

+set_space_yevent():void

+apply_scrolling():void

CursorDown

+execute():void


ScrollUp

+execute():void

+update():void

ScrollDown

+update():void

+execute():void

MovementY

+execute():void


+set_space_yevent():void

MovementDown


MovementUp


ScrollUp

+execute():void

+update():void

CursorUp

+execute():void

CursorDown

+execute():void

ScrollDown

+update():void

+execute():void

27

Clasificación... (VI)Clasificación... (VI)

28

Clasificación... (VII)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 arteEstado 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)Estado del arte (II)

31

Estado del arte (III)Estado del arte (III)

32

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

Clases

Abstractas Concretas

heredar haciendo efectivau obtener por refinamientos

hereda, usa hereda, usa

generalizar mediante refactorizacióno mecanismos lingüísticos

Genéricas No Genéricas

heredar o usar con una sustitucióncompletamente instanciada o mediante

refactorizaciones de especialización

parametrizar mediante refactorización

hereda, usa hereda, usa

(des)componer mediante refactorización

especializar mediante refactorización

35

Un ejemplo del trabajo propioUn ejemplo del trabajo propioCUENTA_BANCARIA

titular: STRINGsaldo: INTEGER

dni: INTEGER

crear(titular_: STRING)extraer( cuanto: INTEGER )

depositar( cuanto: INTEGER )

CUENTA_BANCARIA

titular: STRINGsaldo: REAL

dni: INTEGER

crear(titular_: STRING)extraer( cuanto: REAL )

depositar( cuanto: REAL )

CUENTA_BANCARIA

titular: STRINGsaldo: T

dni: INTEGER

crear(titular_: STRING)extraer( cuanto: T )

depositar( cuanto: T )

T

pesetas = CUENTA_BANCARIA[INTEGER]

euros = CUENTA_BANCARIA[REAL]

grandes numeros = CUENTA_BANCARIA[DOUBLE]

36

... trabajo propio (I)... 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 objetivo entidad guíanuevo parámetro genérico

37

... trabajo propio (II)... 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)... 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).

Nodo

elem : Intsiguiente : Nodo

crearponer_siguiente(otro: Nodo)cambiar_elem( un_elem: Int )

Lista

total : Intprimero : Nodo

crearinsertar( elem : Int )

eliminarvacio: Bool

39

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

C. parameterize(...)

repositorio de clasesG

40

clases X en eluniverso de trabajo

G I

clase objetivoC

Dependientes delas clases en G I

Dependientes directosde las clases en G I

Hijas (X)

Desc (X )

Condic (X)



construcción del universo de trabajo

41

clases X en eluniverso de trabajo

G I

clase objetivoC



determinar GDD y GDI

42

clases X candidatasa ser parametrizadas

G C

G I



selección de clases candidatas

43

clases X candidatasa ser parametrizadas

G C

G I



¿qué se puede

parametrizar?

44

clases finalesG F

G I

clases finalesG F

G C



eliminación de clases no parametrizables

45

clases finalesG F

G I

clases finalesG F

G C



a partir de G F :- analizar genericidad acotada- ejecutar transformaciones- reajustar dependientes directos

46

... trabajo propio (V)... trabajo propio (V)Herramienta de parametrización

Click aquí para lanzar demo

clases Eiffel

parametrizar

Prototipo Operativo

clases de G F

transformadas

obtener G CdeterminarGDD(e) y GDI(e)

Anal

izad

or b

asad

o en

YAC

C

prea

naliz

arcl

ases

cons

trucc

ión

de G

I (C

)clases de las bibliotecas

predefinidas de ISE-Eiffe

l

clases de los usuarios

C.p

aram

eter

ize

(e a

s T

)

Repositorio de clases Eiffelpreanalizadas

clases de las bibliotecas

predefinidas de ISE-Eiffe

l

clases de los usuarios

representación gráfica

47

... trabajo propio (VI)... trabajo propio (VI)

48

Resumen y conclusionesResumen 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)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

ReferenciasReferencias

[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

Referencias (II)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)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)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.com

refactorización de software

Documents