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
Agenda Planteamiento del Problema • Marco Teórico • Resultados Obtenidos • Conclusiones/Trabajos Futuros
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”.
Agenda
• Planteamiento del Problema
Marco Teórico • Resultados Obtenidos • Conclusiones/Trabajos Futuros
Refactoring
• ¿Si su software fuera un edificio, se parecería mas a uno de la izquierda o de la derecha?
Software Hoy en Día
• Mito: programadores ahora ya programan como de antes.
los de no los
• Herramientas más fáciles y productivas • El software es cada día más complejo
La gran foto
Definición
• 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).
Reingeniería
• Análisis de Inventario
• Reestructuración de Documentos • Ingeniería Inversa • Reestructuración de Códigos • Reestructuración de Datos
Uso de Refactoring
• 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?
Ejemplo de Refactoring
• Es correcto el siguiente modelo
Ejemplo de Refactoring
• Si. Subiendo el método a la clase padre
• ¿En qué casos no sería conveniente esta refactorización?
• Reducir
Software Sustentable
• 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.
Patrón de Diseño
• 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
Singleton
Singleton
public class Singleton {
private static Singleton INSTANCE = null; private Singleton() {} private
synchronized
createInstance() {
if (INSTANCE == null){ INSTANCE = new Singleton(); } }
static
void
Patrón de Diseño de un Menú
¿Qué hay de malo en esto?
Antipatr贸n BLOB
Antipatr贸n BLOB
Bad Smells
BAD SMELL REFACTORING PROPUESTO • Algunas ideas sobre que reestructura 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
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
Estructura de un Programa
Comiplaci贸n de Aspectos PROGRAMA DE COMPONENTES
Lenguaje base
PROGRAMA DE ASPECTOS 1
Lenguaje de aspectos 1
... ...
TEJEDOR (WEAVER)
EJECUTABLE
PROGRAMA DE ASPECTOS N
Lenguaje de aspectos N
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> }
Ejemplo class BookStore { private Book [] books ; private Partner [] partners; public BookStore() { â&#x20AC;Ś public void load( Partner p, Book b) { if validControlAccess() then{ // code of the method } else{ throwException(); } }
Access Control
public void addPartner(Partner p){ if validContolAccess() then{ // code of the method } else{ throwException(); } } // the rest of the class methods }
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 Aspectos package mx.edu.itmorelia.aspects; public class HW { private String message;
}
public HW() { this.message = â&#x20AC;&#x153;Hello World"; } public void setMessge(String M){ this.menssage = M; } public String getMessage(){ return this.message; } public void showMessage(){ System.out.println(this.message); }
Hello World con Aspectos package mx.edu.itmorelia.aspects; public class HelloWorld { public static void main(String[] args) { HW H; H= new HW(); H.showMenssage(); } }
Hello World con Aspects
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!"); } }
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 + ")."); }
37
Problema a Resolver Display
* FigureElement
Figure makePoint(..) makeLine(..)
Point getX() getY() setX(int) setY(int) moveBy(int, int)
moveBy(int, int)
2
Line getP1() getP2() setP1(Point) setP2(Point) moveBy(int, int)
HistoryUpdating
Interfaz vs Clase Abstracta
• ¿Qué otros aspectos encontramos?
Identificaci贸n de Aspectos
Uso de Tarjetas CRC
Agenda
• Planteamiento del Problema
Marco Teórico • Resultados Obtenidos • Conclusiones/Trabajos Futuros
Agenda
• Planteamiento del Problema • Marco Teórico
Resultados Obtenidos • Conclusiones/Trabajos Futuros
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.
Agenda
• Planteamiento del Problema • Marco Teórico • Resultados Obtenidos
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 Referencias
• 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, AdisonWesley.
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. Orientada
(2008), Programación a Aspectos, CINVESTAV,
Dudas