View
33
Download
3
Category
Preview:
DESCRIPTION
Refactorización de software. Yania Crespo González-Carvajal. Í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. Introducción. - PowerPoint PPT Presentation
Citation preview
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
Introducción (III)Introducción (III)
Ejemplo:
Modelo de la solución
Vector Catalogomódulos
módulos.total=10
7
Introducción (III)Introducción (III)
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
Introducción (III)Introducción (III)
Ejemplo: Vector Catalogo
módulos
Catalogo
# Vector modulos...
+ Catalogo()
...class Catalogo { Vector modulos ... Catalogo() { ...
modulos = new Vector(10) }...
módulos.total=10
9
Introducción (III)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
módulos.total=10
Introducción (III)Introducción (III)
Ejemplo: Vector
ListaAdaptaciónincremental
¿ ?
...class Catalogo { Vector modulos ... Catalogo() { ...
modulos = new Vector(10) }...
Catalogomódulos
Solución tipo “parche”new Lista()
X
11
Introducción (III)Introducción (III)
Ejemplo: Vector
ListaAdaptaciónincremental
Catalogomódulos
...class Catalogo { Vector modulos ... Catalogo() { ...
modulos = new Lista() }...
Reestructuración
depende de las relaciones a considerar
12
Catalogo
Introducción (III)Introducción (III)
Ejemplo:Vector
ListaAdaptaciónincremental
...class Catalogo { Vector modulos ... Catalogo() { ...
modulos = new Vector(10) }...
módulos¿ ?
13
Introducción (III)Introducción (III)
Ejemplo:Vector
ListaAdaptaciónincremental
...class Catalogo { Vector modulos ... Catalogo() { ...
modulos = new Vector(10) }...
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
ListaAdaptaciónincremental
...class Catalogo { Vector modulos ... Catalogo() { ...
modulos = new Vector(10) }...
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
+apply_scrolling():void
ScrollUp
+execute():void
+update():void
ScrollDown
+update():void
+execute():void
MovementY
+execute():void
+apply_scrolling():void
+set_space_yevent():void
MovementDown
+apply_scrolling():void
MovementUp
+apply_scrolling():void
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)
repositorio de clasesG
... trabajo propio (IV)... trabajo propio (IV)Resumen gráfico de las operaciones
construcción del universo de trabajo
41
clases X en eluniverso de trabajo
G I
clase objetivoC
repositorio de clasesG
... trabajo propio (IV)... trabajo propio (IV)Resumen gráfico de las operaciones
determinar GDD y GDI
42
clases X candidatasa ser parametrizadas
G C
G I
repositorio de clasesG
... trabajo propio (IV)... trabajo propio (IV)Resumen gráfico de las operaciones
selección de clases candidatas
43
clases X candidatasa ser parametrizadas
G C
G I
repositorio de clasesG
... trabajo propio (IV)... trabajo propio (IV)Resumen gráfico de las operaciones
¿qué se puede
parametrizar?
44
clases finalesG F
G I
clases finalesG F
G C
repositorio de clasesG
... trabajo propio (IV)... trabajo propio (IV)Resumen gráfico de las operaciones
eliminación de clases no parametrizables
45
clases finalesG F
G I
clases finalesG F
G C
repositorio de clasesG
... trabajo propio (IV)... trabajo propio (IV)Resumen gráfico de las operaciones
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
Recommended