1.
Estudio sobre Refactoring de
Aplicaciones con Paradigma
Orientado a Objetos hacia
Paradigma Orientado a Aspectos
M.C. Juan Carlos Olivares Rojas
UMSNH, FIE, Morelia, Mayo 2010

2.
• Marco Teórico
• Resultados Obtenidos
• Conclusiones/Trabajos Futuros
Agenda
Planteamiento del Problema

3.
Planteamiento del Problema
• Un tipo de refactoring aplicado con mucha frecuencia
consiste en migrar aplicaciones desarrolladas en un
paradigma de programación hacia otro.
• En el Instituto Tecnológico de Morelia se imparte dentro
de la especialidad de Ingeniería de software la materia de
“Reestructuración de Códigos” [Refactoring].

4.
Planteamiento del Problema
• En dicha materia se pretende que el alumno aplique
mejores prácticas en la codificación así como tratar nuevas
metodologías y paradigmas de programación.
• El objetivo de este trabajo es ver en que grado las
aplicaciones orientadas a objetos pueden mejorarse a través
del uso del paradigma orientado a objetos. En una
primera instancia se ha aplicado a programas “escolares”.

5.
• Planteamiento del Problema
• Resultados Obtenidos
• Conclusiones/Trabajos Futuros
Agenda
Marco Teórico

6.
• ¿Si su software fuera un edificio, se parecería mas a uno de
la izquierda o de la derecha?
Refactoring

7.
Software Hoy en Día
•Mito: los programadores
de ahora ya no
programan como los de
antes.
•Herramientas más fáciles
y productivas
•El software es cada día
más complejo

8.
La gran foto

9.
• Refactoring (Reestructuración) es modificar el
comportamiento interno (generalmente código fuente) sin
modificar su comportamiento externo (apariencia,
funcionalidad).
• Un cambio al sistema que deja su comportamiento
inalterable (sin cambios), pero aumenta alguna cualidad
no funcional como simplicidad, flexibilidad, comprensión,
… [Beck, 1999]
Definición

10.
• El término se creó como analogía
con la factorización de números y
polinomios. Por ejemplo, x² 1 puede−
ser factorizado como (x + 1)(x 1),−
revelando una estructura interna
que no era visible previamente
(como las dos raíces en -1 y +1)
• El libro de Martin Fowler Refactoring
es la referencia clásica (1999).
Definición

11.
• Análisis de Inventario
• Reestructuración de Documentos
• Ingeniería Inversa
• Reestructuración de Códigos
• Reestructuración de Datos
• Ingeniería directa
Reingeniería

12.
• Aplicaciones como el edificio de la derecha padecen de
malas prácticas en el desarrollo de software como:
• “Código mutante”
• “Diseño roto”
• El código es antiguo y muy grande
• Falta de planeación y documentación
• ¿El softwre sufre degeneración?
• Sí
Uso de Refactoring

13.
• Es correcto el siguiente modelo
• ¿Se puede mejorar?¿cómo?
Ejemplo de Refactoring

14.
• Si. Subiendo el método a la clase padre
• ¿En qué casos no sería conveniente esta refactorización?
• Cuando los métodos difieren en su implementación. ¿Pero
aun así es mala?
Ejemplo de Refactoring

15.
• Reducir
• Reusar
• Reciclar
• 80% Desarrollo de Software es para mantenimiento. Por
lo tanto se necesita de un código simple, legible y bien
diseñado para que en un futuro pueda ser extensible.
Software Sustentable

16.
• Par Problema-Solución. Mejores prácticas.
• Patrón Singletón
• Problema: se admite exactamente una instancia de una
clase. Los objetos necesitan un único punto de acceso
global.
• Solución: Defina un método estático de la clase que
devuelva el Singleton
Patrón de Diseño

17.
Singleton

18.
public class Singleton {
private static Singleton INSTANCE = null;
private Singleton() {}
private synchronized static void
createInstance() {
if (INSTANCE == null){
INSTANCE = new Singleton();
}
}
Singleton

19.
Patrón de Diseño de un Menú

20.
¿Qué hay de malo en esto?

21.
Antipatrón BLOB

22.
Antipatrón BLOB

23.
• Algunas ideas sobre que reestructura
Bad Smells
BAD SMELL REFACTORING PROPUESTO
CODIGO DUPLICADO EXTRAER EL MÉTODO
SUBIR VARIABLES
SUSTITUIR EL ALGORITMO
MÉTODOS LARGOS EXTRAER EL MÉTODO
INTRODUCIR OBJETOS COMO PARÁMETROS
REEMPLAZAR EL MÉTODO CON UN OBJETO
MÉTODO
CLASES GRANDES EXTRAER CLASES
EXTRAER SUBCLASES
CARACTERÍSTICA DE LA “ENVIDIA” MOVER MÉTODO
CLASES “PEREZOSAS” COLAPSAR JERARQUÍAS

24.
Patrón MVC

25.
Aspectos
• AOP fue creado por Gregor Kickzales en Palo Alto
Research Center en 1996.
• “An Aspect is a modular unit that is spreand in another
functional units. The aspects exist in the design stage as in
the implementación stage…”
• Un aspecto es un ladrillo de software tal como en su
momento fueron las subrutinas, objetos, servicios, etc.

26.
Aspectos
• Encapsulan ”cross-cutting concern”
• Promueven la separación de elementos entre mezclados
para el reuso.
• En general los objetos permiten el reuso con mecanismos
como la herencia. El detalle es que se da un todo o nada.
Si una clase sólo ocupa una funcionalidad de otra clase
tendría que heredar todo.

27.
Problema del POO

28.
Estructura de un Programa

29.
Comiplación de Aspectos
...
Lenguaje
base
Lenguaje de
aspectos 1
Lenguaje de
aspectos N...
TEJEDOR (WEAVER)
EJECUTABLE
PROGRAMA DE
ASPECTOS N
PROGRAMA DE
ASPECTOS 1
PROGRAMA DE
COMPONENTES

30.
Ejemplo
class Book {
…..
<all things about book>
<error handling>
…
}
class Partner {
…..
<all things about Partner>
<error handling>
<access controlling>
}
class Rent {…..
<all things about Rent>
<error handling>
<access controlling>
}

31.
class BookStore {
private Book [] books ;
private Partner [] partners;
public BookStore() {
…
public void load( Partner p, Book b) {
if validControlAccess() then{
// code of the method
}
else{
throwException();
}
}
public void addPartner(Partner p){
if validContolAccess() then{
// code of the method
}
else{
throwException();
}
}
// the rest of the class methods
}
Access ControlAccess Control
Ejemplo

32.
Definición de Aspectos
Aspect Control {
JoinPoint
securityOperations = call s BookStore.loan &
calls BookStore.addPartner& ...
Before securityOperations: {
if !=(validControlAcces()) then{
throwsExcepcion();
}
}

33.
Herramientas
• Lenguajes para porgramar aspectos
• AspectJ
• AspectC++
• AspectS
• CAESAR.
• Weave.NET
• AspectC

34.
Hello World con Aspectos
package mx.edu.itmorelia.aspects;
public class HW {
private String message;
public HW() {
this.message = “Hello World";
}
public void setMessge(String M){
this.menssage = M;
}
public String getMessage(){
return this.message;
}
public void showMessage(){
System.out.println(this.message);
}
}

35.
package mx.edu.itmorelia.aspects;
public class HelloWorld {
public static void main(String[] args) {
HW H;
H= new HW();
H.showMenssage();
}
}
Hello World con Aspectos

36.
package mx.edu.itmorelia.aspects;
public aspect Aspect {
pointcut messagesToPrint() : call (void
HW.showMessage());
before(): messagesToPrint(){
System.out.println(“Hi everybody!");
}
after(): messagesToPrint(){
System.out.println(“Chao everybody!");
} }
Hello World con Aspects

37.
37
Tipos de Advices
• ¿Qué hace el siguiente código?
• pointcut setXY(FigureElement fe, int x, int y):
call(void FigureElement.setXY(int, int))
&& target(fe)
&& args(x, y);
• after(FigureElement fe, int x, int y) returning: setXY(fe, x, y) {
System.out.println(fe + " moved to (" + x + ", " + y + ").");
}

38.
Problema a Resolver
HistoryUpdating
Display
*
2Point
getX()
getY()
setX(int)
setY(int)
moveBy(int, int)
Line
getP1()
getP2()
setP1(Point)
setP2(Point)
moveBy(int, int)
Figure
makePoint(..)
makeLine(..)
FigureElement
moveBy(int, int)

39.
• ¿Qué otros aspectos encontramos?
Interfaz vs Clase Abstracta

40.
Identificación de Aspectos
Uso de Tarjetas CRC

41.
• Planteamiento del Problema
• Resultados Obtenidos
• Conclusiones/Trabajos Futuros
Agenda
Marco Teórico

42.
• Planteamiento del Problema
• Marco Teórico
• Conclusiones/Trabajos Futuros
Agenda
Resultados Obtenidos

43.
Resultados
• Se escogió una muestra de 17 alumnos cada uno de ellos
con 5 programas de por lo menos 250 LOC (85
programas en total) diferentes.
• Sólo 14 programas rebasaron la barrera de los 1,000
LOC.
• Se observó que 31 programas como tal no tenían manejo
de aspectos pero que podrían ser aspectizables con nuevos
comportamientos.

44.
Resultados
• De los 54 programas aspectizables se encontraron que 47
manejaban logging, 29 manejo de errores, 22 manejo de
sesiones, 15 persistencia.
• Aspectos como manejo de memoria y seguridad fueron
poco manejados 4 y 2.
• La identificación de aspectos no fue realmente difícil pero sí
su conversión ya que en promedio por cada aspecto se
invirtieron en promedio 1:55 por cada aspecto encontrado.

45.
• Planteamiento del Problema
• Marco Teórico
• Resultados Obtenidos
Agenda
Conclusiones/Trabajos Futuros

46.
Conclusiones
• Realmente nuestras aplicaciones están mal diseñadas. Se
utiliza POO pero sin sus ventajas.
• Los aspectos no son realmente algo nuevo bajo el sol y
para cuestiones repetitivas pueden ayudar bastante.
• Los aspectos sólo sirven para determinado tipos de
elementos entre cruzados.

47.
Trabajo Futuro
• Realización de un estudio amplio de aplicaciones a nivel
profesional. Ya que a nivel estudiantil son aplicaciones
muy controladas.
• Determinar tiempos promedios de análisis y de refactoring
hacia aspectos de cada aplicación.
• Hasta el momento sólo empresas grandes manejan
aspectos en proyectos

48.
Calidad del Software en México
• Roger S. Pressman, Ingeniería de software un enfoque
práctico.Ed. McGraw Hill.
•
• Piattini M.G. y F.O, Calidad en el desarrollo y
mantenimiento del software. Ed. RAMA.
•
• Fowler, M. (1999), Refactoring, Adison-Wesley.
Referencias

49.
• Sanchez, M., (2009), Material del Curso de
Reestructuración de Códigos, Instituto Tecnológico de
Morelia.
• Vidal S., et al. (2009), Santiago Proceso Iterativo para
la Refactorización de Aspectos, Cuarto Congreso
Colombiano de Computación 2009
• Mejía, P. (2008), Programación
Orientada a Aspectos, CINVESTAV,
México.
Referencias

50.
Dudas