2. 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
3. • ¿Si su software fuera un edificio, se parecería mas a uno de
la izquierda o de la derecha?
Reingeniería del Software
5. • 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
6. • Se originó a finales de la década de 1980 aunque se
popularizó en la década de 1990.
• La reingeniería es un proceso que trata de dar respuesta a una
interrogante: ¿Estamos acaso haciendo las cosas bien o
podríamos hacerlas mejor?
• Es el rediseño o cambio drastico de un proceso en un
negocio (deriva hacia el producto). Es comenzar de cero,
cambio de todo o nada.
Reingeniería
8. • La reingeniería de software es costosa y consumidora de
tiempo.
• La reingeniería es una actividad de reconstrucción,
preferible de realizar antes de que se “derrumbe” la obra.
• Antes de derribar una casa, quizás se necesita corroborar
que está mal.
Reingeniería del Software
10. • La reingeniería es un proceso que altera los elementos
internos de toda obra, no es una sola remodelación de la
fallada.
• La reingeniería ayuda a la evolución y mantenimiento del
software
• Generalmente se siguen los siguientes pasos para aplicar
reingeniería:
Reingeniería del Software
13. • 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]
Refactoring
14. • 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
15. • Es correcto el siguiente modelo
• ¿Se puede mejorar?¿cómo?
Ejemplo de Refactoring
16. • 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
20. • 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
21. • Se aplica para obtener un modelo detallado de análisis,
ingeniería de requerimientos, diseño y en algunos casos
implementación teniendo una solución, la cual es una
actividad consumidora de tiempo.
• Tanto la Ingeniería Inversa como la Reingeniería en la
mayoría de las licencias de Software se encuentran penadas
por la ley.
Ingeniería Inversa
22. • Los archivos ejecutables pueden ser desemsamblados
obteniendo su código fuente en ensamblador.
• Los archivos ejecutables con código portable (Java,
.NET) pueden ser desemsamblados para obtener su
código fuente.
Ingeniería Inversa
24. • El reuso es una de las técnicas de resolución de problemas
que más utilizamos los humanos. De hecho es lo primero
que verifica nuestro cerebro.
• El reuso en software nos ayuda a mejorar la producción y
calidad del software al “no reinventar la rueda”.
• Desafortunadamente no todo se puede reutilizar.
Reuso de Software
25. • La reutilización es la propiedad de utilizar conocimiento,
procesos, metodologías o componentes de software ya
existente para adaptarlo a una nueva necesidad,
incrementando significativamente la calidad y
productividad del desarrollo.
• Para que un objeto pueda ser reusable se necesita de un
alto nivel de abstracción. Entre mayor es su nivel de
abstracción, mayor es su nivel de reuso.
Reuso de Software
27. • P1: Reestructuración de auto documentación con
Javadoc
• P2: traducción de un código a otro
• P3: Estándares de codificación (notación Camello-
Húngaro, manejo de IDs) y Pruebas Unitarias.
• P4: manejo de versiones, construcción desde cero.
Ofuscación de código.
Otros Ejercicios
28. • P5: reestructuración de datos (archivos a base de datos).
Internalización.
• P6: creación de bibliotecas utilizando patrón de diseño
MVC
• P7: uso de catálogo de refactorings
• P8: Utilización de patrón de diseño factoría
Otros Ejercicios
29. • P9: Refactoring otro lenguaje mismo paradigma de
programación
• P10: Ingeniería inversa
• P11: Refactoring de POO a Aspectos
• P12: Patrón Diseño Adapter
• P13: Patrón diseño memento
Otros Ejercicios
30. 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
32. • Departamento de Sistemas y Computación
• Edificio I, Inst. Tec. De Morelia
• jcolivar@itmorelia.edu.mx
• http://antares.itmorelia.edu.mx/~jcolivar
• MSN: juancarlosolivares@hotmail.com
• Skype: juancarlosolivares
• Twitter: @jcolivares
• Facebook: Juan Carlos Olivares Rojas
Datos de Contacto
Notas do Editor
Si se llega a modificar su comportamiento externo formalmente no se le considera “refactorización” sino más bien una modificación.