Estudio de Vulnerabilidad de Protocolos y Redes de Comunicación para Medidore...
Refactorización de Aplicaciones Orientadas a Objetos a Aspectos
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. 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].
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
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
23. • Algunas ideas sobre que reestructura
Bad Smells
BAD SMELL REFACTORING PROPUESTO
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
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.
30. 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>
}
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 ControlAccess Control
Ejemplo
32. Definición de Aspectos
Aspect Control {
JoinPoint
securityOperations = call s BookStore.loan &
calls BookStore.addPartner& ...
Before securityOperations: {
if !=(validControlAcces()) then{
throwsExcepcion();
}
}
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);
}
}
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 + ").");
}
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
Si se llega a modificar su comportamiento externo formalmente no se le considera “refactorización” sino más bien una modificación.
Si bien al principio todo era programar, los conceptos AOP se trasladaron a todo el proceso de Software.
AORE: Aspect Oriented Requirement Engineering.
AOD: Aspect Oriented Design. Extensiones a UML para soportar el manejo de aspectos en la etapa de diseño. Extensiones Generales y Específicas.
Verificación, Formalización &Model Checking OA