Estimación de Líneas de Código Orientada a Plantillas de Código Fuente

Transcripción

1 Estimación de Líneas de Código Orientada a Plantillas de Código Fuente Mario R. MORENO SABIDO Depto. de Sistemas y Computación, Instituto Tecnológico de Mérida Mérida, Yucatán 97118, México y Jorge BAROUDI PEREZMILICUA Depto. de Sistemas y Computación, Instituto Tecnológico de Mérida Mérida, Yucatán 97118, México RESUMEN En este artículo se describe el proceso de estimación para entornos de desarrollo ágiles, el cual se basa en características funcionales pequeñas de los sistemas a implementar. Para las estimaciones iniciales se puede utilizar la generación de código fuente a partir de plantillas de código ligadas a meta-datos, como por ejemplo, estructuras de tablas de bases de datos. El resultante en líneas de código puede complementarse con la estimación de las líneas de código que se tendrán que modificar para que el código generado se adapte a las variantes que se presentan en las diversas características funcionales del sistema. Si se realiza una retroalimentación de las plantillas de código en cada iteración del proceso, se puede lograr un desarrollo aún más ágil por cada una de las características funcionales comunes entre proyectos. Palabras Claves: Estimación de Proyectos de Software, XML, XSLT, Generación de Código, Refactorización de Código. 1. INTRODUCCIÓN La estimación del tamaño de un proyecto de desarrollo de software es una de las actividades más retadoras e importantes, y a menudo una tarea difícil. A medida que los requerimientos son más complejos, la estimación del tamaño tiene que incluir nuevos factores de estimación propios del proyecto, y por ello resulta muy difícil realizar modelos adecuados para la mayoría de los casos. Por otro lado, la experiencia en la metodología de desarrollo y en la tecnología en la que se desarrolla, difiere de persona a persona, por lo tanto, tomar datos de manera general puede llegar a ser inútil para calcular una estimación aproximada del tamaño sino se cuenta con una madurez en el equipo de desarrollo, esto es, que se integren estándares para todas las actividades de la programación. Para realizar una estimación de un proyecto, muchos equipos y organizaciones buscan definir un único proceso que generalice todo el desarrollo de software, pensando que si pudiera desarrollar software usando los mismos procesos, recursos, y produciendo los mismos documentos, sería mucho más fácil la administración y el aseguramiento de la calidad [1]. El problema es que en los sistemas de software, la tecnología y las organizaciones difieren tanto, que cualquiera de los modelos que realmente definan el desarrollo de software con su amplia gama de variaciones se vuelve de poco uso práctico, a menos que se describa cada posible rol, actividad, salida y paso en detalle, lo que en la práctica no resulta nada fácil. La única forma con la que se cuenta hasta ahora para lidiar con dicho problema es descomponerlo en partes más pequeñas, las cuales, en caso de requerirse, se manejarían en porciones aún más pequeñas, hasta que se llegue a un punto en el que se determine su solución práctica, y en que tiempo y con que capacidad de esfuerzo horas-hombre se hará dicha solución [2]. 2. ESTIMACIÓN DEL ESFUERZO DE DESARROLLO La estimación generalmente es una aproximación o un cálculo especulativo de un resultado futuro basado en aproximaciones, especulaciones y otros datos inciertos e incompletos [3]. La aplicación de una métrica para determinar el tamaño de un programa de software o componente se puede representar por medio del número de líneas de código. Una vez que se realiza el desarrollo se pueden hacer comparaciones para determinar lo acertado de la estimación y calificar los criterios de estimación utilizados. Los diferentes factores que forman parte de la estimación pueden ser ajustados conforme se obtenga mayor experiencia en circunstancias similares, reduciendo la diferencia entre la estimación del esfuerzo y el tiempo real de desarrollo. Con el uso de patrones de diseño [4] y la estimación basada en módulos análogos [5], un equipo comandado por Hugo Troche, originario de Asunción Paraguay, realizó estimación para proyectos en la universidad de Auburn, Alabama durante los años 2002 al 2004 mediante el número de líneas de código que se integran por cada patrón de diseño de la aplicación que cumplen funciones específicas previamente identificadas en cualquier contexto, como es el caso de los componentes de acceso a datos (DAO s, Data Access Objects), los cuales están encargados de las conexiones con los servidores a base de datos y la ejecución de las consultas SQL. En este caso se identifican cuantas líneas de código pueden resultar en el DAO a partir de una sola columna, para luego multiplicar su valor por el número de columna y el número de tablas, obteniendo un total de líneas de código estimadas para dichos componentes o patrón de diseño. El número de líneas de código por columna está basado en datos históricos por patrón o componente.

2 3. XML Y XSLT XML (extensible Markup Language, Lenguaje de Marcado Extensible) viene a ser una versión reducida de SGML, y está especialmente diseñado para la definición de estructuras de documentos y el almacenamiento de datos. Se puede decir que XML puede utilizarse para el desarrollo de dos tipos de aplicaciones: Aplicaciones de Datos: los documentos XML por definición son unidades de almacenamiento de datos y el principal objetivo de este lenguaje consiste en definir una estructura lógica en forma de árbol de dichos datos. Aplicaciones de Documento: Permite la publicación de documentos XML utilizando técnicas de creación de estilos (CSS, XSL: FO) y técnicas para aplicar formatos (XSL, XSLT) a los contenidos XML. Las aplicaciones de documento posibilitan la publicación a cualquier formato conocido: HTML, PDF, entre otros [6]. XSLT (extensible Stylesheet Language Transformations, Lenguaje de Hojas Extensibles de Transformación) permite convertir documentos XML de una sintaxis a otra (por ejemplo, de XML a un documento HTML). XSL: FO (Lenguaje de Hojas Extensibles de Formateo de Objetos) es un lenguaje que permite especificar el formato visual con el cual se quiere presentar un documento XML; es usado principalmente para generar documentos PDF. XPath, o XML Path Language es una sintaxis (no basada en XML) para acceder o referirse a porciones de un documento XML. La conjunción de XML con XSLT, que es un lenguaje estándar de estilo para archivos XML, permite realizar transformaciones de los datos en el archivo XML a cualquier formato de archivo [3] (ver Figura 1). Figura 2. Representación XML de las Tablas de la Base de Datos. A continuación se presenta como ejemplo el código XML para la representación de una tabla de productos (ver Figura 3). <?xml version="1.0" encoding="iso "?> <tabla nombre="productos"> <campos> <campo nombre="codigo" tipo="varchar" tamaño="10" llave_primaria="true" /> <campo nombre="descripcion" tipo="varchar" tamaño="100" /> <campo nombre="clasificacion" tipo="char" tamaño="3" /> <campo nombre="status" tipo="char" tamaño="1" valor_predefinido="a" /> </campos> </tabla> Figura 3. Representación en XML de la Tabla de Productos. Un ejemplo de generación de código con la estructura de la tabla Productos en un archivo XML y una serie de plantillas XSL se presenta en la Figura 4. En esta fase también se realiza la estimación de un porcentaje de líneas a refactorizar en la siguiente etapa. La generación del código puede realizarse en diferentes herramientas, tal es el caso de los navegadores de Internet como Mozilla FireFox e Internet Explorer. Una forma práctica y sencilla para realizar la generación del código es agregar una línea al archivo XML con la directiva xml-stylesheet y abriéndolo en el navegador (ver Figura 5). Figura 1. Transformación XML/XSL a otro Formato. 4. GENERACIÓN DE CÓDIGO CON PLANTILLAS XSL A continuación se presenta una representación en archivos XML de las tablas de una base de datos y plantillas de código fuente creadas a partir de archivos XSL y un procesador XSLT. Un ejemplo de la generación de código se puede observar en la Figura 2. Sin embargo, a pesar de que XSL tiene funciones para manejo de cadenas, números y otras funciones, puede llegar a ser muy difícil obtener un resultado al cien por ciento fiable de código que cumpla con los estándares de nombres de un lenguaje o del equipo de desarrollo. En la Figura 6 se muestra una clase generada con una plantilla XSL en lenguaje Java donde los métodos get y set no cumplen con la especificación de JavaBeans de Sun Microsystems, la cual indica que hay que capitalizar la primera letra de cada palabra a partir del prefijo get o set [7].

3 La plantilla XSL para generar el código de la Figura 6 consta del encabezado y una plantilla (xsl-template) interna que genera cada una de las propiedades de la clase conforme a los datos de los campos. Esta plantilla recibe como parámetro el tipo de dato y el nombre del campo para generar el atributo private de la clase y sus métodos public de acceso (ver Figura 7). <xsl:template name="createproperty"> <xsl:param name="tipodato" /> <xsl:param name="nombrecampo" /> private <xsl:value-of select="$tipodato" /><xsl:text> </xsl:text><xsl:value-of select="$nombrecampo" />; public <xsl:value-of select="$tipodato" /> get<xsl:value-of select="$nombrecampo" />(){ return />; } public void set<xsl:value-of select="$nombrecampo" />(<xsl:value-of select="$tipodato" /> valor){ /> = valor; } </xsl:template> Figura 4. Generación de Código con Plantillas XSL. <?xml version="1.0" encoding= "ISO "?> <?xml-stylesheet href="plantilla_entidades.xsl" type="text/xsl"?> <tabla nombre="productos"> Figura 5. Preparación de un Archivo XML para la Generación de Código a Partir de una Plantilla XSL. public class Productos { private String codigo; public String getcodigo(){ return this.codigo; } public void setcodigo(string valor){ this.codigo = valor; } private String descripcion; public String getdescripcion(){ return this.descripcion; } public void setdescripcion(string valor){ this.descripcion = valor; } private String clasificacion; public String getclasificacion(){ return this.clasificacion; } public void setclasificacion(string valor){ this.clasificacion = valor; } private String status; public String getstatus(){ return this.status; } public void setstatus(string valor){ this.status = valor; } } Figura 7. Extracto de la Plantilla XSL para la Generación de Código Fuente con base en un Archivo XML de la Estructura de la Tabla Productos. 5. REFACTORIZACIÓN DE CÓDIGO La refactorización (del inglés Refactoring) es una técnica de la ingeniería de software para reestructurar un código fuente, alterando su estructura interna sin cambiar su comportamiento externo. Al final de la refactorización, cualquier cambio en el comportamiento es claramente un error y puede ser arreglado de manera separada a la depuración de la nueva funcionalidad. Un ejemplo de una refactorización trivial es cambiar el nombre de una variable para que sea más significativo, como una sola letra 't' a 'tiempo'. Una refactorización más compleja es transformar una parte de código dentro de un bloque en una subrutina. Una refactorización todavía aún más compleja es remplazar una sentencia condicional if por polimorfismo [3]. Existen herramientas de refactorización integradas a los entornos visuales de programación que facilitan este trabajo. Para el ejemplo de código generado de la Figura 6, y de acuerdo con el convencionalismo señalado por la especificación JavaBeans, se requiere refactorizar los nombres de los métodos, capitalizando la primera letra después del prefijo get y el prefijo set (modificaciones resaltadas en negritas y subrayado) (ver Figura 8). También en esta etapa se cambió en nombre de la clase a Producto (antes Productos). Sin la refactorización, estos cambios afectarían directamente a otros archivos de la aplicación que utilicen la clase Producto. Figura 6. Código Generado de la Tabla Productos a Partir de la Estructura XML y una Plantilla XSL.

4 public class Producto { private String codigo; public String getcodigo(){ return this.codigo; } public void setcodigo(string valor){ this.codigo = valor; } private String descripcion; public String getdescripcion(){ return this.descripcion; } public void setdescripcion(string valor){ this.descripcion = valor; } private String clasificacion; public String getclasificacion(){ return this.clasificacion; } public void setclasificacion(string valor){ this.clasificacion = valor; } private String status; public String getstatus(){ return this.status; } public void setstatus(string valor){ this.status = valor; } } Figura 8. Código Refactorizado de la Clase Producto. 6. COMPARACIÓN DE LÍNEAS DE CÓDIGO GENERADO Y CÓDIGO REFACTORIZADO En esta fase se realiza una comparación de los archivos de forma manual o utilizando una herramienta de comparación línea a línea del código refactorizado contra el código generado. En el caso del archivo generado que se presenta en la Figura 6, se realizaron 9 cambios en la etapa de refactorización: 8 cambios para adaptarlo al convencionalismo de nombres de la especificación de JavaBeans y 1 más para cambiar el nombre de la clase (ver Figura 8). Este dato se registrará como el esfuerzo realizado. Cada archivo de clase o de un componente específico sería comparado con su archivo origen que fue generado por una plantilla XSL. Esta relación sirve para comparaciones futuras con la finalidad de establecer un historial de los cambios que ha tenido una clase o componente. La comparación implica también un esfuerzo pero sirve como indicador para determinar que plantillas se deben mejorar y así minimizar el esfuerzo durante refactorizaciones futuras a código generado. 7. RETROALIMENTACIÓN DE PLANTILLAS XSL Una vez que se han comparado los archivos de código generado y código refactorizado, se busca mejorar las plantillas en una fase de retroalimentación conforme a las experiencias obtenidas por los programadores durante la refactorización. En el ejemplo del código refactorizado de la Figura 8 se puede observar que ciertos detalles pueden ser mejorados para alcanzar apegarse al estándar. En la Figura 9 se presenta un fragmento de código mejorado después de la retroalimentación sobre la plantilla XSL original de la Figura 7. En este caso se cambió el método de salida de la plantilla a HTML en vez de texto plano con la finalidad de manipular letras capitales con el atributo style. <xsl:template name="createproperty"> <xsl:param name="tipodato" /> <xsl:param name="nombrecampo" /> private <xsl:value-of select="$tipodato" /><xsl:text> </xsl:text><xsl:value-of select= "$nombrecampo" />;<br /> public <xsl:value-of select="$tipodato" /> get<span style="text-transform:uppercase"><xsl:valueof select="substring($nombrecampo,1,1)" /></span><xsl:value-of select="substring($nombrecampo,2,stringlength($nombrecampo)-1)" />() { return />; }<br /> public void set<span style="texttransform:uppercase"><xsl:value-of select="substring($nombrecampo,1,1)" /></span><xsl:value-of select="substring($nombrecampo,2,stringlength($nombrecampo)-1)" />(<xsl:value-of select="$tipodato" /> valor){ /> = valor; }<br /> </xsl:template> Figura 9. Retroalimentación de la plantilla XSL con Código Generado de Acuerdo al Estándar de JavaBeans. 8. PROCESO DE MEJORA CONTINUA DE LAS PLANTILLAS Una vez retroalimentada la plantilla, ésta se utiliza de nuevo para generar código en proyectos alternos o incluso dentro del mismo proyecto de desarrollo aplicando siempre el proceso cíclico de generación, refactorización, comparación y retroalimentación de las diferentes tablas de la base de datos. Este proceso conlleva a una mejora continua de las plantillas XSL y por ende a la adaptación de estándares definidos por el equipo de trabajo. 9. RESULTADOS Como resultado de este trabajo se obtuvo un proceso de estimación para entornos de desarrollo ágiles. Para probar este proceso fue necesario aplicarlo en proyectos reales, la mayoría de estos enfocados al desarrollo web. En la Figura 10 se presentan los datos de 2 proyectos reales a los cuales se les aplicó el proceso descrito en este documento. El proyecto 1 utilizó plantillas comerciales sin modificaciones por parte de los programadores. Las plantillas están separadas por capas: Modelo, Vista, Controlador. Durante el proceso se eligió una tabla que tuvo cambios en la presentación principalmente durante la vida del proyecto para reflejar modificaciones en capas de vista.

5 En el proyecto 2 se realizaron adaptaciones a las plantillas después de la generación, principalmente a las plantillas de Controlador (para adaptar un método de paginación en listados) y a una plantilla de vista para Listados, mismo que era utilizado en el proyecto anterior. Se puede ver que existen menos cambios (si se compara el 168% de cambios entre revisiones del primer proyecto contra el 78.8% del segundo), lo cual le permitió al programador minimizar el número de líneas a modificar en los listados, aún cuando los formularios respectivos sufrieron cambios mucho más fuertes (debido a sugerencias del usuario). Figura 10. Resultados de Aplicar el Proceso a Proyectos Reales. En la Figura 11 se ilustra por medio de un gráfica la diferencia de la comparación de una plantilla retroalimentada (dando por hecho que se realizó todo el proceso descrito en este documento) versus la generación de código sobre otra tabla de la base de datos utilizando la misma plantilla XSL (la cual fue usada en una segunda iteración del proceso de desarrollo). Esta plantilla fue usada en un proyecto diferente a los que se mencionan en la Figura 10. Esta diferencia se muestra con los porcentajes calculados a partir del total de líneas de código y las líneas de código estimadas y refactorizadas para los casos correspondientes. (Empleado.java) se puede observar que el grado de inclinación es menor. Es posible que no se pueda eliminar con las plantillas XSL la intervención de un programador para adaptar el archivo generado al contexto de la aplicación, principalmente en los casos de código de interfaces gráficas, sin embargo, el objetivo principal es que cada vez se logre una menor diferencia en las estimaciones de código que se necesitará refactorizar (en la fase de refactorización) y el resultado final que se obtuvo. 10. CONCLUSIONES En este artículo se presentó un proceso para realizar la estimación de un proyecto de software, basada en plantillas XSL de una fuente que representa en un archivo XML la estructura de las tablas de la base de datos. Este proceso consta de 4 fases iniciando con la generación de código a partir de un archivo XML y una serie de plantillas XSL. Además, en esta fase se realiza la estimación inicial de un porcentaje de líneas a refactorizar en la siguiente. En la segunda fase se realiza la refactorización de acuerdo a las especificaciones de los estándares a seguir. Posteriormente, en la tercera fase se compara el archivo original generado con el refactorizado para determinar la diferencia entre la estimación y la refactorización. Finalmente, en la última fase se procede a una fase de retroalimentación de las plantillas XSL tomando en cuenta la experiencia adquirida por los programadores durante la refactorización. Una de las ventajas de usar el proceso de estimación ágil es que permite que las iteraciones futuras se beneficien minimizando el número de líneas a refactorizar. El uso de plantillas XSL por su parte permite adaptar diferentes estructuras plasmadas en XML a diferentes lenguajes de programación. A medida que se desarrolla el modelo de la aplicación, se van simplificando las tareas de refactorización e incluyendo mejoras y nuevas tecnologías al código base que se genera, sin embargo, conforme se sube de nivel hacia la interfaz gráfica la adaptación de las plantillas es más complicada. 11. REFERENCIAS Figura 11. Historial del Uso de una Plantilla XSL para Generar Código. La inclinación de la línea de la primera iteración (Producto.java) en la gráfica indica que se tiene una diferencia entre la estimación y el resultado final. En la segunda iteración [1] Palmer, R. y J. Felsing, (2002). A practical guide to Feature Driven Development. Ed. Prentice Hall PTR [2] Weinberg, G., ( ). Quality Software Management. Vols Ed. New York Dorset House. [3] Wikipedia, (2008). Estimación de Proyectos de Software [En línea]. Disponible en: [Accesado el día 23 de Junio de 2008] [4] Gamma, E. et al., (1995). Design Patterns. Ed. Boston: Addison Wesley. [5] Humphrey, W., (1994). A discipline for Software Engineering. Ed. Boston: Addison Wesley. [6] Rodríguez, A., (2004). Publicación en Internet y Tecnología XML. Ed. Alfaomega [7] Sun Microsystems, (2008). Especificación de JavaBeans [En línea]. Disponible en: [Accesado el día 14 de Agosto de 2008]