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

Presentación del tema: "Estudio sobre Refactoring de Aplicaciones con Paradigma Orientado a Objetos hacia Paradigma Orientado a Aspectos M.C. Juan Carlos Olivares Rojas UMSNH,"— Transcripción de la presentación:

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 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

23 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

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

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

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 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 * 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)

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