Software Reengineering

1. Software Reengineering Juan Carlos Olivares Rojas MSN: juancarlosolivares@hotmail.com jcolivar@itmorelia.edu.mx http://antares.itmorelia.edu.mx/~jcolivar/ @jcolivares Social Network: Facebook, LinkedIn. Hi5

2. Competencias • Específica: conoce los términos básicos de la reingeniería de software y aplica técnicas de reingeniería para el mejoramiento de software existente así mismo utiliza mejores prácticas para el desarrollo de software. • Genéricas • Instrumentales: Capacidad de análisis y síntesis, Solución de problemas, Toma de decisiones.

3. Competencias • Interpersonales: Capacidad crítica y autocrítica, Capacidad de trabajar en equipo interdisciplinario, Habilidad para trabajar en un ambiente laboral, Compromiso ético. • Sistémicas: Capacidad de aprender, Capacidad de adaptarse a nuevas situaciones, Capacidad de generar nuevas ideas (creatividad), Habilidad para trabajar en forma autónoma, Preocupación por la calidad.

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

5. Reingeniería del Software • ¿Si su software fuera un edificio, se parecería mas a uno de la izquierda o de la derecha?

6. Software Sustentable • 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.

7. Software Hoy en Día • En el pasado las prioridades eran tener un código rápido, pequeño (ocupa poca memoria), optimizado, utilizando los algoritmos mas eficaces etc... • Hoy en día el software es más complejo pero a la vez hay herramientas más poderosas, por lo que actualmente el enfoque es que este código tiene que ser simple.

8. Beneficios Código Simple • El código es mas fácil de cambiar, evolucionar o arreglar (más del 60% de desarrollo de sw es darle mantenimiento a software existente) • Es más fácil desarrollar de un modo iterativo e incrementando • El código es más fácil de leer (entender).

9. Reingeniería • 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.

10. Ejemplo de Reingeniería

11. Reingeniería del Software • 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.

12. Reingeniería del Software

13. Reingeniería del Software • 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:

14. Reingeniería del Software

15. Reingeniería del Software

16. La gran foto

17. Definición • 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]

18. 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).

19. Uso de Refactoring • 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í

20. Ejemplo de Refactoring • Es correcto el siguiente modelo • ¿Se puede mejorar?¿cómo?

21. 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?

22. Ejemplo Renombrar Métodos • ¿Cuál de los dos códigos siguientes es lo más correcto? • Caso1: double calcRngMaxPer() { .... } • Caso 2: double calcularRangoMaximoPermitido() { .... }

23. Ejemplo Renombrar Métodos • ¿Por qué? • Cómo puede observarse en algunas situaciones las recomendaciones de refactoring pueden ser algo subjetivas. • Para este caso se recomienda el caso 2 ya que es más representativo el nombre del método. Se abreviaba generalmente en el pasado debido a las restricciones de los lenguajes con el tamaño de los identificadores, actualmente ya no es tanto problema.

24. Ejemplo números mágicos • Cambiar números mágicos por constantes. • El cambio de valor de un número mágico implica un cambio en todo el código con su pérdida de tiempo. class CalculoSimple { public static double CalcularCincunferencia (double diametro) { return 3.14 * diametro; } }

25. Ejemplo números mágicos • ¿Cómo debe de quedar la reestructuración? class CalculoSimple { public const double PI = 3.14; public static double CalcularCincunferencia (double diametro) { return PI * diametro; } } • ¿En qué lenguaje está este código?

26. Patrón de Diseño • 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

27. Singleton

28. Singleton public class Singleton { private static Singleton INSTANCE = null; private Singleton() {} private synchronized static Singleton createInstance() { if (INSTANCE == null){ INSTANCE = new Singleton(); } return INSTANCE; } }

29. Patrón de Diseño de un Menú

30. Patrón MVC

31. Bad Smells • Algunas ideas sobre que reestructura

32. Herramientas de Refactoring • Existen muchas herramientas de reestructuración de códigos para los principales lenguajes: • Java • Xrefactory, RefactorIT, jFactor, IntelliJ IDEA • C++ • CppRefactory, Xrefactory • C# • C# Refactoring Tool, C# Refactory

33. Herramientas de Refactoring • Los principales IDE’s las contienen de forma natica • NetBeans: RefactorIT • Oracle Jdeveloper: RefactorIT • Borland Jbuilder: RefactorIT • Eclipse: built-in (propia) • Emacs: Xrefactory • Visual Studio .NET: C# Refactory

34. Herramientas de Refactoring • Sólo soportan refactoring primitivo: • Refactorización de clases (Añade (sub)clases a la jerarquía, renombra, elimina clases). • Reestructuración de métodos (añade a una clase, renombra, elimina, mueve hacia abajo, hacia arriba, añade parámetros, extrae código. • Reestructuración de variables (añade a una clase, renombra, elimina, cambia modificadores, mueve de lugar.

35. Antipatrones de Diseño • Antipatrón es un patrón de diseño que invariablemente conduce a una mala solución para un problema. • Al documentarse los antipatrones, además de los patrones de diseño, se dan argumentos a los diseñadores de sistemas para no escoger malos caminos, partiendo de documentación disponible en lugar de simplemente la intuición.

36. Antipatrones de Diseño • El estudio de los antipatrones es muy útil porque sirve para no escoger malos caminos en el desarrollo de sistemas, teniendo para ello una base documental y así evitar usar simplemente la intuición. Además proporciona una denominación común a problemas que facilita la comunicación entre diferentes desarrolladores.

37. Antipatrón BLOB • Mejor conocido como “objeto todopoderoso”. Se presenta cuando una clase es muy grande tanto en atributos y/o en métodos. • Entre más grande son las clases es más difíciles de mantener, reusar y probar. Su gran tamaño puede perjudicar el tiempo de carga. Generalmente son el resultado de un mal diseño o de sistemas legados.

38. Antipatrón BLOB

39. Antipatrón BLOB

40. Antipatrón BLOB

41. Antipatrones de Diseño • Algunos autores consideran al Singleton (Simplicidad) un ejemplo de un antipatrón ¿por que? • Se tiene que estudiar el código para ver las dependencias en lugar de simplemente ver las interfaces de nuestras clases. • Dificulta las pruebas de código ya que promueve un alto acoplamiento.

42. Antipatrones de Diseño • Los singleton permiten controlar las instancias de nuestras clases, esto no está bien porque una clase solo debe tener responsabilidades de negocio. Para controlar la creación de clases deberemos usar un patrón Factoría sobre las clases de negocio. • En general su naturaleza estática y pública no son del todo bien vistas.

43. Catálogo de Ref. de NetBeans • Renombrar (Rename) • Cambia el nombre de una clase • Mover (move) • Mueve de forma segura una clase a otra ubicación • Copiar (copy) • Copia una clase a otra ubicación • Eliminar de forma segura (Safely Delete) • Borra una clases y las referencias a ésta.

44. Catálogo de Ref. de NetBeans • Cambiar los parámetros del método (Change Method Parameters) • Modifica parámetros de un método • Ascender (Pull Up) • Mueve los métodos y campos a una clase que hereda de su clase actual. • Descender (Pull Down) • Mueve las clases internas, métodos y campos para todas las subclases de la claseactual (a las clases hijas).

45. Catálogo de Ref. de NetBeans • Mover de nivel interior a exterior(move inner to outer level) • Toma una clase interna (que se encuentre dentro de otra) y la saca de ésta para colocarla en su propio archivo • Convertir anónimo en miembro (convert annonymus to inner) • Sirve para cambiar una clase miembro anónima (no instanciable) a una clase miembro actual.

46. Catálogo de Ref. de NetBeans • Introducir variable (introduce variable) • Permite introducir una variable e inicializarla a partir de la selección. • Introducir constante (introduce constant) • Introduce una constante al código con su referente valor y tipo. • Introducir campo (introduce field) • Toma una expresión seleccionada y crea un campo con el valor de la expresión; la cual será reemplazada con el nombre del campo.

47. Catálogo de Ref. de NetBeans • Introducir método (replace block code with a field) • A partir de varias líneas de código seleccionadas, el reestructurador declara un nuevo método y también se encarga de aplicarlo en lugar de las líneas. • Encapsular campos (encapsulate fields) • Toma las variables seleccionadas y crea métodos set y get para dicha variable.

48. Catálogo de Ref. de NetBeans • Pull Up & Push Down (Ascender y Descender) • Aplica las dos refactorizaciones en un solo paso • Extract Interface (Extraer Interface) • Crea una nueva Interface de los métodos públicos no estáticos dentro de una Clase o Interface.

49. Catálogo de Ref. de NetBeans • Extract Superclass (Extraer superclase) • Crea una nueva Clase Abstracta, extiende a la Clase actual la nueva Clase, y mueve los métodos seleccionados y campos a la nueva Clase. • Use Supertype Where Possible (usar supertipo cuando sea psible) • Convierte el uso de una Subclase a una Superclase

50. Refactorización Pequeña • Reemplazar una Temp con un Query • Reemplazar