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 B

Class 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