4. OPTIMIZACIÓN Y DOCUMENTACIÓN

1. REFACTORIZACIÓN

2. CONTROL DE VERSIONES

3. DOCUMENTACIÓN

1. REFACTORIZACION

• Refactorización:

Disciplina que realiza pequeñas transformaciones en el código de un programa, para mejorar la estructura sin cambiar el comportamiento ni la funcionalidad del mismo.

• Objetivo: Mejorar la estructura interna del código.

• Consecuencia: Se mejora el diseño del software, la compresión, más sencillo el mantenimiento, mayor rapidez y ayuda a la localización de errores.

1.1. CONCEPTO DE REFACTORIZACIÓN

• Se basa en el concepto de la factorización de polinomios.

• Definiciones de refactorización:

– Refactorizar: Cambiar la estructura interna del software para facilitar su comprensión y modificar sin variar su comportamiento. Ej: extraer métodos, encapsular campos.

Encapsular campos: Usar métodos getter (asignación) y setter (consulta) para cada campo de la clase. Para acceder y/o modificar el valor de un campo se invocan los métodos.

– Refactorizar: Reestructurar el software con refactorizaciones sin cambiar su comportamiento.

• Propósito: Hacer el software más fácil de entender y modificar.

• Diferencias entre refactorización y optimización:

– Ambos procesos pretenden mejorar la estructura interna de una aplicación o componente, sin modificar su comportamiento.

– La optimización persigue la mejora del rendimiento -velocidad-, la refactorización no.

– La refactorización: No cambia el comportamiento observable del software, este sigue cumpliendo la misma función que hacía antes.

1.2. LIMITACIONES

• La refactorización presenta problemas en algunos aspectos del desarrollo:

– La refactorización de las BBDD.

• Las dificultades por la gran cantidad de interdedendencias y su modificación incluye modificación del esquema y migración de datos.

– El cambio de interfaces.

• Los cambios internos no afectan a la interfaz, pero si renombramos métodos hay que cambiar todas las referencias que se realizan a él.

– La refactorización se dificulta cuando hay errores de diseño.

– La refactorización no se recomienda cuando la estructura a modificar es de vital importancia en el diseño de la aplicación.

– La refactorización no se debe realizar cuando es más fácil reescribirlo desde el principio.

1.3. PATRONES DE REFACTORIZACIÓN HABITUALES.

• El proceso sigue una serie de patrones preestablecidos:

– Renombrado: Cambio de nombre a un paquete, clase, método o campo por un nombre más significativo.

– Sustituir bloques de código por un método.

– Campos encapsulados. Creación de métodos getter y setter para cada campo se defina en una clase.

– Mover la clase: De un paquete a otro o de un proyecto a otro para no duplicar código, imponiendo la actualización de todo el código fuente.

– Borrado seguro: Al eliminar un elemento se eliminan todas las referencias a él.

– Cambiar los parámetros del proyecto: Se añaden nuevos parámetros a un método y cambiar los modificadores de acceso.

– Extraer la interfaz: Crea una nueva interfaz de los métodos public nostatic seleccionados en una clase o interfaz.

– Mover del interior a otro nivel: Mover una clase interna a una clase superior en la jerarquía.

1.4. ANALIZADORES DE CÓDIGO

• Cada IDE incluye herramientas de refactorización y analizadores de código:

– La refactorización, los IDE ofrecen asistentes que de forma automática ayudan a refactorizar el código.

– Los analizadores de código que se pueden añadir como complementos a los entornos de desarrollo.

• Análisis de código (automático o manual): proceso cuyo objetivo es evaluar el software, sin llegar a ejecutarlo.

• El analizador recibe el código fuente, lo procesa para averiguar la funcionalidad del mismo, da sugerencias y muestra posibles mejoras sin modificar su semántica.

• Funciones del analizador: encontrar partes del código que puedan reducir el rendimiento, provocar errores en el software, tener excesiva complejidad, complicar el flujo de datos, crear problemas de seguridad.

• Ejemplos:

– FindBugs en Netbeans: forma parte del IDE.

– PMD: Basa su funcionamiento en la detección de patrones.

– CPD: Forma parte de PDM y busca código duplicado.

1.5. REFACTORIZACIÓN Y PRUEBAS.

• Un enfoque actual que pretende integrar las pruebas y la refactorización, es el Desarrollo Guiado por Pruebas (TDD, Test Driven Development).

• TDD propone agilizar el ciclo de escritura de código, y realización de pruebas de unidad (comprueba la calidad de un módulo desarrollado).

• Con el TDD el programador realiza las pruebas de unidad en su propio código, e implementa esas pruebas antes de escribir el código a ser probado.

• Para realizar la refactorización siguiendo TDD, se refactoriza el código tan pronto como pasa las pruebas para eliminar la redundancia y hacerlo más claro.

1.6. HERRAMIENTAS DE AYUDA A LA REFACTORIZACIÓN.

• Los IDE actuales proveen herramientas que facilitan la labor de refactorizar el código.

• En el IDE Netbeans, la refactorización está integrada como una función más, de las utilidades que incorpora.

• Los patrones de refactorización más comunes, con la herramienta IDE:

– Renombrar. Cambiar el nombre de un paquete, clase, método o campo para darle un nombre más significativo. Netbeans lo permite y actualizará todo el código fuente del proyecto donde se haga referencia al nombre modificado.

– Introducir método. Este patrón permite seleccionar un conjunto de código, y reemplazarlo por un método.

– Encapsular campos. Netbeans puede generar métodos getter y setter automaticamente para un campo, y puede actualizar todas las referencias al código para acceder al campo, con los métodos getter y setter.

2. CONTROL DE VERSIONES

• Versión hace referencia a la evolución de un único elemento, o de cada elemento por separado, dentro de un sistema en desarrollo.

• Ventajas de utilizar un Sistema de Control de Versiones:

– Permite a varios desarrolladores trabajar en un mismo proyecto de forma simultánea, sin entorpecerse unos a otros.

– Permiten volver a una versión estable previa del código fuente.

• Una versión es una forma particular de un objeto en un instante o contexto dado.

• Revisión: Evolución en el tiempo. Pueden coexistir varias versiones alternativas en un instante dado, por lo que hay que disponer de un método de designación de las versiones adecuada.

• En java existen 2 sistemas de control de versiones de código abierto: CVS y Subversión.

– CVS (Sistema de Versiones Concurrente): Herramienta de código abierto muy usada por organizaciones.

– Subversión: Sucesor de CVS, ya que se adapta mejor a las nuevas practicas de desarrollo de software.

2.1. ESTRUCTURA DE HERRAMIENTAS DE CONTROL DE VERSIONES.

• Herramienta de control de versiones: sistema de mantenimiento de código fuente útil para grupos de desarrolladores que trabajan cooperativamente usando una red. Ej: CVS.

• CVS utiliza arquitectura cliente-servidor: El servidor guarda la versión actual del proyecto, y los clientes se conectan para sacar una copia del proyecto, modificarla y subir los cambios.

• El sistema de control de versiones está formado por un conjunto de componentes:

– Repositorio: lugar donde se guardan los datos de los proyectos (directorio en un equipo).

– Módulo: directorio especifico del repositorio. Identifica una parte o al proyecto por completo.

– Revisión: cada una de las versiones parciales o cambios en los archivos o repositorio completo.

– Etiqueta: información textual añadida a los archivos o a un módulo completo para indicar información importante.

– Rama: revisiones paralelas de un módulo para efectuar cambios sin tocar la evolución principal. Para pruebas o para mantener los cambios en versiones antiguas.

• Las órdenes que se pueden ejecutar son:

– checkout: obtiene un copia del trabajo para poder trabajar con ella.

– Update: actualiza la copia con cambios recientes en el repositorio.

– Commit: almacena la copia modificada en el repositorio.

– Abort: abandona los cambios en la copia de trabajo.

2.2. REPOSITORIO.

• El repositorio almacena toda la información y datos de un proyecto, es la parte fundamental del sistema de control de versiones.

• El repositorio es un almacén general de versiones. En la mayoría de las herramientas de control de versiones, suele ser un directorio.

• El repositorio centraliza todos los componentes de un mismo sistema, incluyendo las distintas versiones de cada componente.

2.3. HERRAMIENTAS DE CONTROL DE VERSIONES

• En Java, actualmente destacan 2 herramientas de control de cambios:

– CVS. Herramienta de código abierto ampliamente utilizada en organizaciones.

– Subversión. Sucesor natural de CVS, está rápidamente integrándose en los nuevos proyectos Java, gracias a sus características que lo hacen adaptarse mejor a las modernas prácticas de programación Java.

• Otras herramientas de control de versiones:

– SourceSafe: Herramienta que forma parte del IDE Microsoft Visual Studio.

– Visual Studio Team Foundation Server: Sustituto de Source Safe. Ofrece control de código fuente, recolección de datos, informes y seguimiento de proyectos, y está destinado a proyectos de colaboración de desarrollo de software.

– Darcs: Sistema de gestión de versiones distribuido. Características: posibilidad de hacer commits locales (sin conexión), cada repositorio es una rama en sí misma, independencia de un servidor central, posibilidad de renombrar ficheros, varios métodos de acceso (local, ssh, http y ftp, etc).

– Git: Herramienta de control de versiones, diseñada por Linus Torvalds.

– Mercurial: Herramienta funciona en Linux, Windows y Mac OS X.

2.4. PLANIFICACIÓN DE LA GESTIÓN DE CONFIGURACIONES

• La Gestión de Configuraciones Software (GCS) es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida.

• Una configuración es una combinación de versiones particulares de los componentes que forman un sistema consistente.

• Una configuración cambia porque se añaden/eliminan/modifican elementos. También, debido a la reorganización de los componentes, sin que estos cambien.

• La GCS se va compone de 4 tareas básicas:

– Identificación. Se establecen estándares de documentación y esquemas de identificación de documentos.

– Control de cambios. Se evalúan y registran todos los cambios que se hagan de la configuración software.

– Auditorías de configuraciones. Garantizan que el cambio se ha implementado correctamente.

– Generación de informes. El sistema se compone de elementos, que evolucionan de manera individual y se debe garantizar la consistencia del conjunto del sistema.

• Actividades de GCS: Propuesta, gestión GCS, actividades GCS a realizar, agenda GCS, recursos CGS, mantenimiento de GCS.

2.5. GESTIÓN DE VERSIONES Y ENTREGAS

• Las versiones hacen referencia a la evolución de un único elemento en un sistema software. La evolución puede representarse en forma de grafo.

• Grafo de evolución simple: Se expresa una secuencia lineal y se designan mediante números correlativos.

• Propagación de cambios: cuando se tienen variantes que se desarrollan en paralelo.

• Fusión de variantes: se deja de mantener una rama, de ser necesario.

• Técnicas de almacenamiento: Se organiza el almacenamiento para que no se desaproveche el espacio, repitiendo los datos en común de varias versiones.

• Gestión de entregas: Entrega es una instancia del sistema que se distribuye a los usuarios externos al equipo de desarrollo. Se compone de:

– Programas ejecutables,

– Archivos de configuración que definan como se configura la entrega,

– Archivos de datos que se necesitan para el funcionamiento del sistema,

– Programa de instalación para instalar el sistema en el hardware de destino,

– Documentación electrónica y en papel y

– Embalaje y publicidad asociados, diseñados para esta entrega.

2.7. HERRAMIENTAS CASE PARA LA GESTIÓN DE CONFIGURACIONES

• Las herramientas CASE de apoyo son imprescindibles para la gestión de configuraciones. Estas herramientas se pueden combinar con entornos de trabajo de gestión de configuraciones. Tipos de entornos de trabajo de Gestión de Configuraciones:

• Entornos de trabajo abiertos: las herramientas de Gestión de Configuraciones son integradas de acuerdo con procedimientos organizacionales estándar. Ejs: Bugzilla (herramienta de seguimiento o bug-tracking), RCS, CVS, Make o Imake.

• Entornos integrados: Ofrecen facilidades integradas para la gestión de versiones, construcción del sistema o seguimiento de cambios. Ejs: Rational: Entorno de configuración que incorpora ClearCase –construcción y gestión de versiones-y ClearWest –seguimiento de cambios-.

• Los IDE integran clientes de control de versiones:

– Microsoft Visual Estudio: Usa Visual Studio Team Foundation con gestión centralizada.

– Eclipse y Netbeans: incorporan plug-in o complementos como: CVS, SVN (Subversión) y Mercurial.

3. DOCUMENTACION

• Documentar:

Sirve para explicar su funcionamiento, de forma que cualquier persona que lea el cometario, puede entender la finalidad del código.

• Sirve para la detección de errores y para su funcionamiento posterior, que puede ser realizado por personas diferentes a las que intervinieron en su creación.

• Objetivo:

Explicar porque se hace esa sección de código (no para parafrasear el código).

• Se trata de explicar la funcionalidad de una clase, paquete, método, una variable, porque se implementa un algoritmo de una forma o de otra, etc.

3.1. USO DE COMENTARIOS.

• Es una anotación que se realiza en el código, que el compilador ignora, para indicar a los desarrolladores de código diferentes aspectos del código que útiles.

• Propósitos:

– Explicar el objetivo de las sentencias: Para saber la función de esa sentencia.

– Explicar que realiza un método, clase y como lo realiza: Explicar los valores que devolverá un método.

• Tipos:

// Comentarios de una línea

/* Comentario de varias líneas */

//**

* Comentarios de JavaDoc

*/

• Los comentarios son obligatorios con JavaDoc y se deben incorporar el principio de cada clase, método y variable de clase.

3.2. ALTERNATIVAS

• El desarrollo rápido de aplicaciones va en detrimento de una buena documentación de código. Si no esta bien documentado, será más difícil de entender, solucionar errores y mantenerlo.

• Opciones:

1. Documentar el código con comentarios.

2. Uso de herramientas para automatizar nuestra documentación

• Algunas herramientas: JavaDoc, SchemeSpy y Doxygen.

• En Java los criterios de documentación de clases son establecidos por JavaDoc:

• Se utiliza la notación: /** : Primera línea

* : líneas intermedias

*/ : Última línea.

• Las etiquetas obligatorias son: @autor (nombre del/aautor/a) y @version (identificación de la versión y fecha)

DOCUMENTACIÓN DE CONSTRUCTORES Y MÉTODOS.

• Al menos se indican las etiquetas:

– @param: seguido del nombre, indica cada uno de los parámetros que tienen el constructor o método.

– @return: si el método no es void, se indica lo que devuelve.

– @exception: se indica el nombre de la excepción, especificando cuales pueden lanzarse.

– @throws: se indica el nombre de la excepción, especificando las excepciones que pueden lanzarse.

• Los campos (atributos) de una clase, también pueden incluir comentarios, aunque no existen etiquetas obligatorias en JavaDoc.

3.4. HERRAMIENTAS.

• Los IDE de Java, incluyen una herramienta para generar documentación de páginas HTML a partir de los comentarios incluidos en el código fuente (JavaDoc).

• Para que JavaDoc pueda generar las páginas HTML es necesario seguir una serie de normas de documentación en el código fuente, estas son:

– Los comentarios JavaDoc empiezan por /** y terminar por */.

– Los comentarios pueden ser a nivel de clase, de variable y de método.

– La documentación se genera para métodos public y protected.

– Se puede usar tag para documentar distintos aspectos del código, como parámetros.

TAGS MÁS HABITUALES