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

Marco Teórico Resultados Obtenidos Conclusiones/Trabajos Futuros Agenda 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

Algunas ideas sobre que reestructura Bad Smells BAD SMELLREFACTORING PROPUESTO CODIGO DUPLICADOEXTRAER EL MÉTODO SUBIR VARIABLES SUSTITUIR EL ALGORITMO MÉTODOS LARGOSEXTRAER EL MÉTODO INTRODUCIR OBJETOS COMO PARÁMETROS REEMPLAZAR EL MÉTODO CON UN OBJETO MÉTODO CLASES GRANDESEXTRAER 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 “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

Ejemplo class Book { ….. … } class Partner { ….. } class Rent {….. }

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 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 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); }

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 * 2 Point 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