Estudio sobre Refactoring de Aplicaciones con
Paradigma Orientado a Objetos hacia Paradigma
Orientado a AspectosM.C. Juan Carlos Olivares Rojas
UMSNH, FIE, Morelia, Mayo 2010
• Marco Teórico
• Resultados Obtenidos
• Conclusiones/Trabajos Futuros
AgendaPlanteamiento del Problema
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].
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”.
• Planteamiento del Problema
• Resultados Obtenidos
• Conclusiones/Trabajos Futuros
Agenda
Marco Teórico
• ¿Si su software fuera un edificio, se parecería mas a uno de la izquierda o de la derecha?
Refactoring
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
La gran foto
• 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
• 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
• 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
• 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
• Es correcto el siguiente modelo
• ¿Se puede mejorar?¿cómo?
Ejemplo de Refactoring
• 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
• 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
• 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
Singleton
public class Singleton { private static Singleton INSTANCE =
null; private Singleton() {} private synchronized static void
createInstance() { if (INSTANCE == null){ INSTANCE = new Singleton(); } }
Singleton
Patrón de Diseño de un Menú
¿Qué hay de malo en esto?
Antipatrón BLOB
Antipatrón BLOB
• Algunas ideas sobre que reestructuraBad Smells
BAD SMELL REFACTORING PROPUESTO
CODIGO DUPLICADO EXTRAER EL MÉTODOSUBIR VARIABLESSUSTITUIR EL ALGORITMO
MÉTODOS LARGOS EXTRAER EL MÉTODOINTRODUCIR OBJETOS COMO PARÁMETROSREEMPLAZAR EL MÉTODO CON UN OBJETO MÉTODO
CLASES GRANDES EXTRAER CLASESEXTRAER SUBCLASES
CARACTERÍSTICA DE LA “ENVIDIA” MOVER MÉTODO
CLASES “PEREZOSAS” COLAPSAR JERARQUÍAS
Patrón MVC
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.
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.
Problema del POO
Own behavior Own behavior
Persistence
Trace
……..
Own Behavior Owbn Behavior
Persistence Trace
Class A Class BClass A Class B
Classes
Aspects
Estructura de un Programa
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
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>
}
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
Definición de Aspectos
Aspect Control {
JoinPoint securityOperations = call s BookStore.loan & calls BookStore.addPartner& ...
Before securityOperations: {if !=(validControlAcces()) then{ throwsExcepcion(); }
}
Herramientas• Lenguajes para porgramar aspectos
• AspectJ• AspectC++ • AspectS• CAESAR.• Weave.NET• AspectC
Hello World con Aspectospackage 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);}
}
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
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
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 + ").");}
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)
• ¿Qué otros aspectos encontramos?Interfaz vs Clase Abstracta
Identificación de Aspectos
Uso de Tarjetas CRC
• Planteamiento del Problema
• Resultados Obtenidos
• Conclusiones/Trabajos Futuros
Agenda
Marco Teórico
• Planteamiento del Problema
• Marco Teórico
• Conclusiones/Trabajos Futuros
Agenda
Resultados Obtenidos
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.
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.
• Planteamiento del Problema
• Marco Teórico
• Resultados Obtenidos
Agenda
Conclusiones/Trabajos Futuros
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.
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
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
• 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
Dudas