Principios de Reestructuracin M C Juan Carlos Olivares

  • Slides: 142
Download presentation
Principios de Reestructuración M. C. Juan Carlos Olivares Rojas Enero 2011

Principios de Reestructuración M. C. Juan Carlos Olivares Rojas Enero 2011

Contacto • Conceptos básicos • Pasos de la reestructuración • Problemas de la reestructuración

Contacto • Conceptos básicos • Pasos de la reestructuración • Problemas de la reestructuración • Herramientas para reestructuración

Criterios de Evaluación • 70% Examen escrito • 30% Desarrollo de portafolio de evidencias

Criterios de Evaluación • 70% Examen escrito • 30% Desarrollo de portafolio de evidencias (trabajos, tareas y prácticas)

Competencia Específica • conoce los términos básicos de la reestructuración de código e identifica

Competencia Específica • conoce los términos básicos de la reestructuración de código e identifica el problema de código mal desarrollado en el contexto de desarrollo de software.

Conceptos básicos

Conceptos básicos

Problemática ¿Si en lugar de programadores fuéramos constructores ¿cómo serían nuestros edificios, como el

Problemática ¿Si en lugar de programadores fuéramos constructores ¿cómo serían nuestros edificios, como el de la izquierda o como el de la derecha?

 • “Código mutante” • “Diseño roto” • El código es antiguo y muy

• “Código mutante” • “Diseño roto” • El código es antiguo y muy grande • Falta de planeación y documentación Problemáticas • ¿Qué malas prácticas de codificación tendría un edificio como el de la izquierda?

Problemática • Debido a la complejidad del software y a la capacidad de las

Problemática • Debido a la complejidad del software y a la capacidad de las herramientas de software actuales se está generando muchas aplicaciones mal diseñadas que son ineficientes y difíciles de mantener.

Problemática • El 80% del desarrollo de software es el mantenimiento (evolución) a sistemas

Problemática • El 80% del desarrollo de software es el mantenimiento (evolución) a sistemas existentes

Problemática • En el pasado las prioridades eran tener un código rápido, pequeño (ocupa

Problemática • En el pasado las prioridades eran tener un código rápido, pequeño (ocupa poca memoria), optimizado, utilizando los algoritmos mas eficaces etc…

 • El software minimalista es todo un reto. El software debe de ser

• El software minimalista es todo un reto. El software debe de ser funcional. Problemática • Hoy en día el software debe de ser simple en su diseño y en su codificación.

 • La reestructuración es parte de la reingeniería. Problemática • La reestructuración no

• La reestructuración es parte de la reingeniería. Problemática • La reestructuración no sólo se da en código, sino en todo el proceso de desarrollo de software: datos, diseño externo, documentación.

Reingeniería • Es un proceso de mejora continua. En software se da al ir

Reingeniería • Es un proceso de mejora continua. En software se da al ir perfeccionando nuestro software iteración por iteración. • Las metodologías ágiles promueven las técnicas de reingeniería.

Definición • Para Martin Fowler, es mejorar el diseño de código existente.

Definición • Para Martin Fowler, es mejorar el diseño de código existente.

Definición • Para Roger Pressman es modificar el comportamiento interno (generalmente código fuente) sin

Definición • Para Roger Pressman es modificar el comportamiento interno (generalmente código fuente) sin modificar su comportamiento externo (apariencia, funcionalidad).

Definición • Si se llega a modificar su comportamiento externo formalmente no se le

Definición • Si se llega a modificar su comportamiento externo formalmente no se le considera “refactorización” sino más bien una modificación.

Definición • El término se creó como analogía con la factorización de números y

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.

 • La reestructuración de códigos no es una técnica para encontrar y/o corregir

• La reestructuración de códigos no es una técnica para encontrar y/o corregir errores. Definición • Para evitar cambiar el funcionamiento de un software se recomienda el uso de pruebas unitarias.

Historia • No es nada nuevo bajo el sol, se ha llevado a cabo

Historia • No es nada nuevo bajo el sol, se ha llevado a cabo de manera informal durante años • La tesis doctoral de William F. Opdyke (1993) es el primer trabajo conocido que examina específicamente esta técnica.

Historia • El libro de Martin Fowler Refactoring es la referencia clásica (1999) que

Historia • El libro de Martin Fowler Refactoring es la referencia clásica (1999) que trajo está constumbre al desarrollo de software actual.

 • XP popularizó el refactoring Historia

• XP popularizó el refactoring Historia

 • Para entender el concepto de reestructuración veremos un ejemplo práctico. • Generalmente

• Para entender el concepto de reestructuración veremos un ejemplo práctico. • Generalmente se expresa la problemática (“bad smell”) para luego dar la solución. Ejemplo

 • Ejemplo 1: Getter/Setter • Problema: Hay un atributo público en una clase

• Ejemplo 1: Getter/Setter • Problema: Hay un atributo público en una clase • Solución: hacer el atributo privado y proporcionar métodos de acceso público Ejemplo 1

 • En algunas ocasiones se muestra ejemplo en código: • public class Persona{

• En algunas ocasiones se muestra ejemplo en código: • public class Persona{ public int edad; . . . } Ejemplo 1

 • La solución también se da a veces en código: public class Ejemplo

• La solución también se da a veces en código: public class Ejemplo 1{ private int edad; public void set. Edad(int val){ edad = val } Ejemplo 1

public int get. Edad(){ return edad; } } • ¿Por qué debemos hacer esto?

public int get. Edad(){ return edad; } } • ¿Por qué debemos hacer esto? Ejemplo 1

Reestructuración • La reestructuración de códigos está basada en técnicas probadas por otras personas

Reestructuración • La reestructuración de códigos está basada en técnicas probadas por otras personas que en muchas ocasiones se dan como leyes pero que es necesario entender para mejorar nuestra práctica de programación.

Reestructuración • Por definición, los objetos tienen propiedades/carácterísticas/atributos (variables) que son propias y que

Reestructuración • Por definición, los objetos tienen propiedades/carácterísticas/atributos (variables) que son propias y que no deben de ser modificables por otros, incluso objetos del mismo tipo.

Reestructuración • Si una persona tiene un atributo peso este no puede ser modificado

Reestructuración • Si una persona tiene un atributo peso este no puede ser modificado al azar (una persona tiene 60 kilos y de repente ya 65) sólo a través de un comportamiento/hablidad (método) como hacer. Ejercicio() o comer. Golosinas().

Reestructuración • ¿Esto implica que cada atributo de la clase debe tener métodos get/set?

Reestructuración • ¿Esto implica que cada atributo de la clase debe tener métodos get/set? • No, sólo aquellos elementos que deban sr modificados en el exterior. Es como el caso de los métodos privados.

Reestructuración • ¿En que ocasiones se recomienda que los atributos de una clase sean

Reestructuración • ¿En que ocasiones se recomienda que los atributos de una clase sean públicos? • Cuando son constantes numéricas. • ¿Que propiedad de POO se utilizó en este refactoring?

Encapsulamiento

Encapsulamiento

 • Un refactoring no siempre aplica en todos los contextos. Encapsulamiento • Los

• Un refactoring no siempre aplica en todos los contextos. Encapsulamiento • Los refactorings están basados en premisas cuyo objetivo en la mayoría de los casos es que el código sea más legible.

 • Traer instalada una herramienta de modelado en UML. Recomendación Star. UML. Tarea

• Traer instalada una herramienta de modelado en UML. Recomendación Star. UML. Tarea • Darle un repaso a la propiedad de encapsulamiento de POO

Motivos para Refactorizar • Calidad • Eficiencia • Diseño evolutivo en lugar de un

Motivos para Refactorizar • Calidad • Eficiencia • Diseño evolutivo en lugar de un gran diseño industrial • Evitar la reescritura de código.

¿cuándo refactorizar? • La refactorización no es la cura para todos los males pero

¿cuándo refactorizar? • La refactorización no es la cura para todos los males pero ayuda a ser más extensible el software: • Cuando el software no es claro • Ayuda a evitar redundancia de código originando en muchos casos menor tamaño.

¿cuándo se debe refactorizar? • Aplicar la “Regla de Tres”: 1. Para añadir una

¿cuándo se debe refactorizar? • Aplicar la “Regla de Tres”: 1. Para añadir una nueva funcionalidad 2. Cuando se necesita localizar un error 3. Como revisión de código

Algunas consideraciones • Refactoring va más allá de limpiar código. • La refactorización es

Algunas consideraciones • Refactoring va más allá de limpiar código. • La refactorización es el arte de mejorar de manera segura, el diseño de código existente. • Refactorización no es reescribir todo desde cero.

Algunas consideraciones • La refactorización no se calendariza

Algunas consideraciones • La refactorización no se calendariza

 • Funciona bien • Comunica lo que esta haciendo • No tiene duplicación

• Funciona bien • Comunica lo que esta haciendo • No tiene duplicación Código Simple • El refactoring ayuda a la simplificación de código, alguna de sus ventajas son:

 • Es más seguro • Es más legible • Es más sencillo ser

• Es más seguro • Es más legible • Es más sencillo ser iterativo en el desarrollo de software • Es más fácil de mntener Código Simple • Es menos propenso a errores

 • ¿Cuál de los dos códigos siguientes es lo más correcto? Ejemplo 2

• ¿Cuál de los dos códigos siguientes es lo más correcto? Ejemplo 2 • Caso 1: double calc. Rng. Max. Per() {. . } ¿Qué hace el método?

Ejemplo 2 • Caso 2: double calcular. Rango. Maximo. Permitido( ) {. . }

Ejemplo 2 • Caso 2: double calcular. Rango. Maximo. Permitido( ) {. . } • Se recomienda este segundo caso por ser más legible • ¿cómo se llamo el refactoring?

 • El refactoring anterior “renombrar método” fue • Solucion: cambiar el número mágico

• El refactoring anterior “renombrar método” fue • Solucion: cambiar el número mágico por una constante Ejemplo 3 • Problema: El cambio de valor de un número mágico implica un cambio en todo el código con su pérdida de tiempo.

 • Considérese el siguiente código: Ejemplo 3 class Calculo. Simple { public static

• Considérese el siguiente código: Ejemplo 3 class Calculo. Simple { public static double Calcular. Cincunferencia (double diametro) { return 3. 14 * diametro; } }

 • La solución queda así: Ejemplo 3 class Calculo. Simple { public final

• La solución queda así: Ejemplo 3 class Calculo. Simple { public final double PI = 3. 14; public static double Calcular. Cincunferencia (double diametro) { return PI * diametro; } }

 • En algunas ocasiones los refactorings se dan en diagramas arquitectónicos: ¿Es correcto

• En algunas ocasiones los refactorings se dan en diagramas arquitectónicos: ¿Es correcto este modelo? ¿Cómo se puede mejorar? Ejemplo 4

 • Si. Subiendo el método a su clase padre. Ejemplo 4

• Si. Subiendo el método a su clase padre. Ejemplo 4

 • ¿En qué casos no sería conveniente esta refactorización? • Cuando los métodos

• ¿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 4

 • Aun se puede optimizar subiendo el método pero sin implementarlo en la

• Aun se puede optimizar subiendo el método pero sin implementarlo en la clase padre y sobreescribiéndolo en las clases hijas. Ejemplo 4

Actividad • Se necesita implementar una clase rectángulo para un programa tipo “Paint”. Trate

Actividad • Se necesita implementar una clase rectángulo para un programa tipo “Paint”. Trate de utilizar encapsulamiento para modelar la clase si se considera que tiene los métodos área(), dibujar(). Complete los atributos faltantes. • Escriba su solución en una herramienta de modelado o bien en un pedazo de hoja de papel con su nombre, en caso de no tener equipo de cómputo.

Solución • Pueden existir diversos modelados, lo importante es diseñar nuestro código para ser

Solución • Pueden existir diversos modelados, lo importante es diseñar nuestro código para ser extensible. Por este motivo, es importante manejar encapsulamiento, polimorfismo y herencia. • El modelado puede ser textual o gráfico.

Solución • General: • Atributos: x 1, y 1, x 2, y 2: int

Solución • General: • Atributos: x 1, y 1, x 2, y 2: int • Óptimas: • Atributos: ancho, alto: int • Origen: punto • Atributos: esq. Sup. Izq, esq. Inf. Der: punto

Solución • Clase: Punto • Atributos: X, Y: int • Métodos: get. X(), set.

Solución • Clase: Punto • Atributos: X, Y: int • Métodos: get. X(), set. X(), get. Y(), set. Y(): int • Debemos de quitarnos la idea de que si compila y el programa hace lo que debe de hacer no implica que el software esté realmente correcto.

Solución

Solución

Solución • Se recomienda utilicen el estándar XMI para hacer portable sus diagramas

Solución • Se recomienda utilicen el estándar XMI para hacer portable sus diagramas

Práctica de Refactoring • Las metodologías ágiles y esbeltas proponen realizar modelado sobre lápiz

Práctica de Refactoring • Las metodologías ágiles y esbeltas proponen realizar modelado sobre lápiz y papel o sobre pizarrones para evitar pérdida de tiempo. • A continuación se muestra un ejemplo de ello.

Práctica de Refactoring • Tomado http: //www. agilemodeling. com

Práctica de Refactoring • Tomado http: //www. agilemodeling. com

Codificar este modelo

Codificar este modelo

 • Una vez desarrollado el modelo, probar con los siguientes valores e indicar

• Una vez desarrollado el modelo, probar con los siguientes valores e indicar su resultado: Práctica • • • 6 19 28 43 118

 • Los resultados obtenidos deben de ser: Práctica • • • 6 es

• Los resultados obtenidos deben de ser: Práctica • • • 6 es perfecto 19 no es perfecto 28 es perfecto 43 no es perfecto 118 no es perfecto

 • Una vez desarrollado el modelo, ¿Detectas alguna mala práctica de programación? Práctica

• Una vez desarrollado el modelo, ¿Detectas alguna mala práctica de programación? Práctica • Al parecer en algo tan pequeño podría ser que no existieran malos diseños o prácticas de programación…

Práctica import javax. swing. *; public class programa 1 { public static void main

Práctica import javax. swing. *; public class programa 1 { public static void main (String[] args){ int Num=Integer. parse. Int(JOption. P ane. show. Input. Dialog("Introduce numero")); int i=1; int suma=0;

Práctica while(i<=(Num/2)){ if(Num%i==0){ suma+=i; i+=1; } else{ i+=1; } } if(Num==suma) JOption. Pane. show.

Práctica while(i<=(Num/2)){ if(Num%i==0){ suma+=i; i+=1; } else{ i+=1; } } if(Num==suma) JOption. Pane. show. Message. Dial og(null, "El numero "+Num+" es un número perfecto");

Práctica else JOption. Pane. show. Message. Dialog (null, "El numero "+Num+" no es un

Práctica else JOption. Pane. show. Message. Dialog (null, "El numero "+Num+" no es un número perfecto"); }} • No tomar en cuenta el mal sangrado

 • En realidad hay algunas. Práctica • La primera de ellas es la

• En realidad hay algunas. Práctica • La primera de ellas es la conjunción o mezcla de la lógica de la aplicación con la presentación. • Un objeto debe de realizar solo las cosas pertinentes al objeto.

Práctica Refactoring • Para solucionar esta problemática podemos aplicar el “”principio de separación de

Práctica Refactoring • Para solucionar esta problemática podemos aplicar el “”principio de separación de interfaces”; para ello, realizar lo siguiente: • Reestructurar para tener siguiente firma de método: public boolean es. Primo(int n){ la

Práctica de Refactoring … return true/false } • En el método main(){} hacer las

Práctica de Refactoring … return true/false } • En el método main(){} hacer las adecuaciones necesarias para la lectura de datos, la invocación de la funcionalidad y la impresión de resultados

Práctica de Refactoring • ¿Cómo visualizas la aplicación? ¿Crees que aun se pueda mejorar?

Práctica de Refactoring • ¿Cómo visualizas la aplicación? ¿Crees que aun se pueda mejorar? • En general tenemos una pequeña clase que implementa la lógica y la presentación. Si bien es cierto que ya está separada aun está en la misma clase

Práctica de Refactoring • Para ello, refactorizaremos a la siguiete arquitectura: • App •

Práctica de Refactoring • Para ello, refactorizaremos a la siguiete arquitectura: • App • +main(String args…): void • Numero • +es. Perfecto(int): boolean

Práctica de Refactoring • ¿Aún hay más problemas? • Bueno en realidad este pequeño

Práctica de Refactoring • ¿Aún hay más problemas? • Bueno en realidad este pequeño programa puede ser mejorado con la colocación de comentarios en el código. • La mejor forma es a través de la autodocumentación del código.

Práctica de Refactoring • La autodocumentación del código se puede hacer con compiladores de

Práctica de Refactoring • La autodocumentación del código se puede hacer con compiladores de documentación como Java. Doc • Javadoc es una herramienta de autodocumentación de código que genera dicha documentación en formato HTML.

Práctica de Refactoring • Se deben utilizar los comentarios especiales /** …. . */

Práctica de Refactoring • Se deben utilizar los comentarios especiales /** …. . */ con algunas palabras clave para determinar la documentación. • Las palabras clave inician con una arroba. • Se puede incrustar cualquier etiqueta de HTML.

Práctica de Refactoring • @author nombre_desarrollador • @deprecated descripción //indica un método que no

Práctica de Refactoring • @author nombre_desarrollador • @deprecated descripción //indica un método que no se recomienda su uso • @param nombre descripción

Práctica de Refactoring • @return descripción • @see referencia //asocia con otro elemento el

Práctica de Refactoring • @return descripción • @see referencia //asocia con otro elemento el cual puede ser: #método(); clase#método(); paquete. clase#método(). • @throws clase descripcion • @version versión

Práctica de Refactoring • La documentación se crea de la siguiente forma: javadoc archivo.

Práctica de Refactoring • La documentación se crea de la siguiente forma: javadoc archivo. java • En Net. Beans se puede encontrar la opción en el menú Build en la opción Generate Java. Doc for …

Ejemplo Javadoc /** * Thrown to indicate that the application has attempted to convert

Ejemplo Javadoc /** * Thrown to indicate that the application has attempted to convert * a string to one of the numeric types, but that the string does not * have the appropriate format. * * @author unascribed * @version 1. 16, 02/02/00 * @see java. lang. Integer#to. String()

Javadoc * @since JDK 1. 0 */ public class Number. Format. Exception extends Illegal.

Javadoc * @since JDK 1. 0 */ public class Number. Format. Exception extends Illegal. Argument. Exception { /** * Constructs a <code> Number. Format. Exception </code> with no detail message. */ public Number. Format. Exception () { super(); }

Javadoc /** * Constructs a <code> Number. Format. Exception </code> with the * specified

Javadoc /** * Constructs a <code> Number. Format. Exception </code> with the * specified detail message. * @param s the detail message. */ public Number. Format. Exception (String s) { super (s); } }

Laboratorio 1 • Utilizar la herramienta Analyze Javadoc de Netbeans para determinar la documentación

Laboratorio 1 • Utilizar la herramienta Analyze Javadoc de Netbeans para determinar la documentación faltante. • Agregar una nueva funcionalidad es. Primo() • Reestructura los códigos anteriores para que ahora estén en inglés.

Practica de Refactoring • ¿Sigue habiendo problemas? • En realidad no, lo que se

Practica de Refactoring • ¿Sigue habiendo problemas? • En realidad no, lo que se acostumbra a realizar no es crear pequeños programitas para probar objetos sino más bien utilizar herramientas automatizadas de pruebas unitarias como JUnit

Pruebas Unitarias • Las pruebas unitarias se realizan sobre los bloques principales de construcción

Pruebas Unitarias • Las pruebas unitarias se realizan sobre los bloques principales de construcción de códificacion. En nuestro caso de las clases. • La idea es tener pruebas automatizadas que desarrollar nuestras propias pruebas para revisar el código.

JUnit • Es el framework de pruebas unitarias para Java más utilizado en el

JUnit • Es el framework de pruebas unitarias para Java más utilizado en el mundo. • En IDEs como Netbeans y Eclipse viene de manera predeterminada. • Para crearlo en Netbeans es muy fácil sólo se escoge la opción de crear una prueba unitaria de una clase existente y crea un bosquejo de prueba con cada método impelementado.

JUnit • Existen dos versiones populares a manejar la 3. x (anticuada pero ampliamente

JUnit • Existen dos versiones populares a manejar la 3. x (anticuada pero ampliamente utilizada) y la 4. x (que maneja anotaciones pero no es compatible con versiones viejas). • La ventaja de utilizar pruebas unitarias es que nos permite corroborar nuestro código sin necesidad de crear una aplicación.

JUnit • En la versión 3. x las pruebas unitarias tienen la siguiente forma:

JUnit • En la versión 3. x las pruebas unitarias tienen la siguiente forma: • Se importa la clase junit. framework. Test. Case; • La clase de prueba hereda de Test. Case • Se puede utilizar un constructor para inicializar datos.

JUnit • Se utiliza el método set. Up() para realizar un conjunto de acciones

JUnit • Se utiliza el método set. Up() para realizar un conjunto de acciones antes de evaluar un caso de prueba. • Se utiliza el método tear. Down() para realizar acciones una vez finalizado el caso de prueba • Se utiliza el método fail() que recibe una cadena de mensaje de error para forzar a una falla.

JUnit • Se utiliza el método assert. Equals(valoresperado, valorresultante) para saber si el método

JUnit • Se utiliza el método assert. Equals(valoresperado, valorresultante) para saber si el método se ejecutó de manera exitosa. • Se puede utilizar el método assert. Not. Null(objeto) para saber si un objeto no es nullo. • Para tipos de datos flotantes el método assert. Equals utiliza un parámetro adicional

JUnit • La diferencia con la versión 4. x de Junit radica en lo

JUnit • La diferencia con la versión 4. x de Junit radica en lo siguiente: • Se importan las siguientes clases: org. junit. After, org. junit. After. Class, org. junit. Before. Class, org. junit. Test, org. junit. Assert. *; • Se utilizan las anotaciones @Before. Class, @After. Class, @Before, @After para indicar cuando se utilizan los métodos auxiliares

JUnit • La clase de prueba no extiende de ninguna otra pero cada caso

JUnit • La clase de prueba no extiende de ninguna otra pero cada caso de prueba debe utilizar la anotación @Test • Se recomienda realizar los casos de prueba de manera separada uno por uno y dejarlos siempre presente.

Práctica • Crea pruebas unitarias para “testear” el código anterior. • ¿cuántas pruebas se

Práctica • Crea pruebas unitarias para “testear” el código anterior. • ¿cuántas pruebas se necesitan para corroborrar nuestro código? • Documenta las pruebas que se hicieron al inicio de toda la dinámica.

Práctica • Se tienen dos métodos diferentes, por lo cual se requiere al menos

Práctica • Se tienen dos métodos diferentes, por lo cual se requiere al menos dos pruebas unitarias. • No puede haber pruebas exhaustivas sobre el código. • Se deben considerar casos válidos e inválidos

Pasos en la reestructuración

Pasos en la reestructuración

 • Un paso a la vez • Mejorar el diseño una vez que

• Un paso a la vez • Mejorar el diseño una vez que se ha escrito el código Pasos • De pasos sencillos (refactorings) se logra mejorar sustancialmente el código fuente.

Metodología • Escribir pruebas unitarias y funcionales. (Se es muy riesgoso si no se

Metodología • Escribir pruebas unitarias y funcionales. (Se es muy riesgoso si no se tienen) • Refactorizar los principales fallos de diseño. • Refactorizar un malor olor aunque sea sencillo y probar.

Metodología • Cuando se desarrollo software utilizando métodos ágiles, el tiempo de desarrollo se

Metodología • Cuando se desarrollo software utilizando métodos ágiles, el tiempo de desarrollo se divide en dos: 1. Agregar nuevas funcionalidades 2. Refactorizar

Metodología • Cuando se agrega nueva funcionalidad no se modifica código existente, la única

Metodología • Cuando se agrega nueva funcionalidad no se modifica código existente, la única forma de medir el avance es a través de pruebas unitarias. • Cuando se refactoriza, no se agregas pruebas unitarias

Metodología • Al realizar cambios en el código, la estructura de software es modificada

Metodología • Al realizar cambios en el código, la estructura de software es modificada y por lo tanto es necesario refactorizar. • A continuación se detalla un pequeño ejercicio aplicando el refactoring de Encapsulated Field

 • Formar equipos de dos personas • Escribir lo que relevante (10 mint)

• Formar equipos de dos personas • Escribir lo que relevante (10 mint) consideran Investigación • Leer la hoja que les corresponda del artículo Refactoring – Does it improve software quality? (15 min)

 • Socializar al resto del grupo sus ideas. (10 minutos) Investigación • Conclusiones

• Socializar al resto del grupo sus ideas. (10 minutos) Investigación • Conclusiones (10 minutos)

 • Los pasos a seguir son: • Crear los méodos get y set

• Los pasos a seguir son: • Crear los méodos get y set para cada atributo que se desea acceder. Ejercicio

 • Localizar todas las referencias y reemplazar todos los accesos a los campos

• Localizar todas las referencias y reemplazar todos los accesos a los campos con los métodos get y todas las asignaciones con set. • Compilar y cambiar después de cada referencia. Ejercicio

 • Declarar el campo como privado. • Compilar y probar. • Inicialmente se

• Declarar el campo como privado. • Compilar y probar. • Inicialmente se tiene el siguiente código: Ejercicio

public class Persona { public String name } Se tiene la siguiente prueba unitaria

public class Persona { public String name } Se tiene la siguiente prueba unitaria @Test public void prueba(){ Ejercicio

Person person; person. name = “Juan Pérez”; assert. Equals(“Juan Pérez”, person. name); } •

Person person; person. name = “Juan Pérez”; assert. Equals(“Juan Pérez”, person. name); } • Después se aplica el paso 1 (crear métodos get y set): Ejercicio

public class Person { public String name; public String get. Name() {return name; }

public class Person { public String name; public String get. Name() {return name; } public String set. Name(String New. Name){ name=New. Name; } Ejercicio

 • Ahora se aplica el paso 2: Encontrar todos los clientes; reemplazar referencias

• Ahora se aplica el paso 2: Encontrar todos los clientes; reemplazar referencias con llamadas. Se modifica la primera referencia. • Antes: person. name = “Juan Pérez”; • Después: person. set. Name(“Juan Pérez”); Ejercicio

 • Se compila y prueba. Ahora se sigue con la reestructuración de la

• Se compila y prueba. Ahora se sigue con la reestructuración de la siguiente referencia: • Antes: assert. Equals( “Juan Pérez”, person. name); • Después: assert. Equals( “Juan Pérez”, person. get. Name()); Ejercicio

 • Se compila y vuelve a probar. Una vez que se ha probado

• Se compila y vuelve a probar. Una vez que se ha probado que funciona se sigue el paso 4 de hacer privado el campo: public class Person{ private String name; ……} Ejercicio

Problemaas de la reestructuración

Problemaas de la reestructuración

Problemas • Reestructurar es riesgoso. • ¿entonces cómo debe hacerse? • De manera metículosa

Problemas • Reestructurar es riesgoso. • ¿entonces cómo debe hacerse? • De manera metículosa y paso a paso

¿por qué no refactorizamos? • Generalmente se pide una extensión a un sistema, y

¿por qué no refactorizamos? • Generalmente se pide una extensión a un sistema, y ni siquiera se comprende completamente lo que se va a hacer, cuando ya hay que hacerlo. • ¿Porqué voy yo a corregir lo que otros hicieron mal?

¿por qué no refactorizamos? • ¿Qué me garantiza que al “corregir” el código, el

¿por qué no refactorizamos? • ¿Qué me garantiza que al “corregir” el código, el programa siga funcionando tal como al principio? • Hay que cumplir con la fecha de entrega comprometida, es LA PRIORIDAD NUMERO UNO!

¿Qué pasa si no se refactoriza? • Con el tiempo, los errores se propagan

¿Qué pasa si no se refactoriza? • Con el tiempo, los errores se propagan a sí mismos. • El diseño del programa se corrompe. • El costo incremental de cambios se escala

Otros Problemas • Los desarrolladores de software no entienden bien el concepto y creen

Otros Problemas • Los desarrolladores de software no entienden bien el concepto y creen que es solo copy-paste profesional. • ¿para que lo hago si yo no disfrutaré esos beneficios?

Otros Problemas • Pondré al descubierto mi forma de codificar (buena o mala) al

Otros Problemas • Pondré al descubierto mi forma de codificar (buena o mala) al dejar componentes reusables. • El principal problema al refactorizar es el problema humano, sobre todo si se trabaja en equipo.

Otros Problemas • Muchas aplicaciones son totalmente dependientes de cierta estructura como las bases

Otros Problemas • Muchas aplicaciones son totalmente dependientes de cierta estructura como las bases de datos, por lo que al hacer refactoring implica en muchos casos parar procesos.

 • Como pudo observar en el artículo previo. • No necesariamente el refactoring

• Como pudo observar en el artículo previo. • No necesariamente el refactoring mejora la calidad de un sw. De hecho al hacer el código más claro, puede hacer más lento el código. Refactoring y desempeño del sw

Herramientas para Reestructuración

Herramientas para Reestructuración

 • Actualmente existen muchas herramientas que permiten el manejo de refactorings aunque sea

• Actualmente existen muchas herramientas que permiten el manejo de refactorings aunque sea simples. Herramientas • En un principio el refactoring se hacia de forma manual siendo en la mayoría de los casos todo un arte.

 • Generalmente no se utilizan en mucha frecuencia por que en ocasiones es

• Generalmente no se utilizan en mucha frecuencia por que en ocasiones es más fácil desarrollarlas a mano. Herramientas • Estas herramientas de refactoring se encuentran incluidas dentro de los principales IDEs

 • Toda herramienta de refactoring debe de ser capaz de seguir funcionando aun

• Toda herramienta de refactoring debe de ser capaz de seguir funcionando aun después de haber hecho la reestructuración Herramientas • Los factores a considerar en la elección de una herramienta son variables.

 • Existen varias herramientas pero destacan principalmente x. Refactory y Refactory. IT Herramientas

• Existen varias herramientas pero destacan principalmente x. Refactory y Refactory. IT Herramientas • Se debe tomar en cuenta el catalogo y complejidad de los refactorings, así como la velocidad de ejecución y que se cuente con la opción de deshacer.

Actividad • En equipos de dos personas seleccionadas por el profesor, determinar un ejemplo

Actividad • En equipos de dos personas seleccionadas por el profesor, determinar un ejemplo del catálogo de refactorizaciones de Net. Beans. • Para ello se deberá investigar en que consiste el refactoring asignado, y dar un ejemplo de cómo utilizarlo. • Revisar cuales de ellas están en el libro de Fowler.

Actividad • Entregar un breve reporte en digital que se discutirá en clase. •

Actividad • Entregar un breve reporte en digital que se discutirá en clase. • Algunas refactorizaciones son muy simples y su nombre prácticamente las describe, otras tendrán que investigarse.

Catálogo de Ref. de Net. Beans • Asignación 1: – Renombrar (Rename) – Mover

Catálogo de Ref. de Net. Beans • Asignación 1: – Renombrar (Rename) – Mover (move) – Copiar (copy) – Eliminar de forma segura (Safely Delete) • Asignación 2: – Cambiar los parámetros del método (Change Method Parameters)

Catálogo de Ref. de Net. Beans • Asignación 3: – Ascender (Pull Up) –

Catálogo de Ref. de Net. Beans • Asignación 3: – Ascender (Pull Up) – Descender (Pull Down) • Asignación 4: – Mover de nivel interior a exterior(move inner to outer level) • Asignación 5: – Convertir anónimo en miembro (convert annonymus to inner)

Catálogo de Ref. de Net. Beans • Asignación 6: – Introducir variable (introduce variable)

Catálogo de Ref. de Net. Beans • Asignación 6: – Introducir variable (introduce variable) – Introducir constante (introduce constant) – Introducir campo (introduce field) • Asignación 7: – Introducir método (replace block code with a field) – Encapsular campos (encapsulate fields)

Catálogo de Ref. de Net. Beans • Asignación 8: – Pull Up & Push

Catálogo de Ref. de Net. Beans • Asignación 8: – Pull Up & Push Down (Ascender y Descender) • Asignación 9: – Extract Interface (Extraer Interface) • Asignación 10: – Extract Superclass (Extraer superclase) – Use Supertype Where Possible (usar supertipo cuando sea psible)

Práctica 2

Práctica 2

 • Hacer revisión formal del código proporcionado. Se utilizará el método de Fanagan:

• Hacer revisión formal del código proporcionado. Se utilizará el método de Fanagan: • Especificación de Requerimientos • Arquitectura del Sistema (hasta aquí)� Laboratorio 2

 • Técnica de Programación (estilo de codificación que se verá en las siguientes

• Técnica de Programación (estilo de codificación que se verá en las siguientes diapositivas) • Pruebas unitarias • Las revisiones de código se planifican y se reúnen generalmente en equipos de trabajo. � Laboratorio 2

 • Generalmente los roles son: autor, lector, probador y moderador. • Para el

• Generalmente los roles son: autor, lector, probador y moderador. • Para el caso de comparativa se manejan estándares de referencia como los anteriormente vistos (javadoc)� Laboratorio 2

 • Una de las notaciones de estilo de codificación más utilizadas es la

• Una de las notaciones de estilo de codificación más utilizadas es la “notación camello-húngaro” • Esta notación está basada en dos estándares: camello (Java) y Húngara (Microsoft) Laboratorio 2

 • La notación húngara fue creada por Charles Simonyi de Microsoft, el cual

• La notación húngara fue creada por Charles Simonyi de Microsoft, el cual es húngaro y por eso recibió ese nombre. • Consiste en tener variables autodocumentadas agregando un prefijo de tres caracteres o menos para indicar su tipo. Laboratorio 2

Descripción Abr Carácter con signo c Carácter sin signo b Entero n Palabra (entero

Descripción Abr Carácter con signo c Carácter sin signo b Entero n Palabra (entero sin signo) Descripción Abr Objeto (parecido a las estructuras) o* Manejador (handler) h Descripción Abr Puntero a entero de 16 bits p Formulario frm w Puntero largo (32 bits) lp Check. Box chk Botón cmd Doble palabra (entero 32 bits) dw Enumeraciones e Imagen img lbl l lpsz Etiqueta Largo Menú mnu Flotante f Puntero largo a una cadena terminado en nulo d lpfn pic Doble Text. Box txt Cadena terminada en /0 sz Puntero largo a una función que devuelve un entero Picture. Box Combo. Box cbo Estructura Abc s. A Línea lin Laboratorio 2

 • Ejemplos: • int n. Test; • long l. Temp; • char *sz.

• Ejemplos: • int n. Test; • long l. Temp; • char *sz. String = "Prueba"; Laboratorio 2

 • La principal característica de la notación húngara consiste en que no separa

• La principal característica de la notación húngara consiste en que no separa nombres de identificadores (variables, métodos, objetos) con “_” para palabras compuestas. Laboratorio 2

 • Los identificadores tienen la forma de la joroba de un camello. Sigue

• Los identificadores tienen la forma de la joroba de un camello. Sigue respetando mucho de la Notación C. • Los métodos inician en minúsculas y si hay una palabra compuesta inicia con mayúscula dando la apariencia de una joroba. Laboratorio 2

 • Las clases inician con mayúscula siguiendo el mismo método. • Los métodos

• Las clases inician con mayúscula siguiendo el mismo método. • Los métodos para acceder a atributos de las clases no públicos deben llamarse por convención set y get. Laboratorio 2

Convenciones de Desarrollo • Algunas compañías como Google proponen sus propios estándares de codificación:

Convenciones de Desarrollo • Algunas compañías como Google proponen sus propios estándares de codificación: http: //code. google. com/p/google-styleguide/ • Los lenguajes que maneja son C/C++, Python, Perl, Objective-C, XML, entre otros. • Estos estándares son manejados en forma obligatoria para el desarrollo de sus proyectos.

 • Reestructurar programa para que este en notación “camello húngaro”. Laboratorio 2

• Reestructurar programa para que este en notación “camello húngaro”. Laboratorio 2

Dudas

Dudas