En este trabajo se presentan los resultados de una prueba realizada con las herramientas de análisis y medición de código administrado de Visual Studio® 2008. El análisis se aplicó a dos piezas de código abierto: Database Commander y SQL Buddy, que están enfocadas a crear un entorno para acceder a diversos backends de bases de datos, y se describen los datos cualitativos obtenidos acerca de qué tan fácil se instalan las herramientas para analizar los proyectos designados y qué tan rápido se encuentran errores empleándolas.
Herramientas de análisis de código
Las herramientas de análisis llevan a cabo diversas verificaciones para determinar la presencia de defectos en el código, analizando los ensamblados y reportando cierta información acerca de aquéllos, tal como violaciones de reglas de programación y diseño, establecidas en los lineamientos de diseño del .NET Framework. Estas herramientas representan las verificaciones que se llevan a cabo durante el análisis como advertencias. Los mensajes de advertencias identifican cualquier problema de diseño o programación relevante y cuando es posible, dan información acerca de cómo corregirlo.
Las advertencias antes mencionadas indican violaciones de reglas en bibliotecas de código administrado y están organizadas en una serie de áreas tales como diseño, desempeño, seguridad, etcétera. Este tipo de herramientas tienen la capacidad de permitir al usuario indicar que una determinada advertencia no es aplicable, con lo cual se informa a los desarrolladores, a quienes revisen el código posteriormente que esa advertencia ya fue investigada.
Finalmente, permiten que uno se asegure de que el código que esta siendo protegido esté limpio, mediante el establecimiento de una política de protección que requiera que el análisis de código sea ejecutado; de esta manera solamente se podrá proteger una pieza de código. Si ésta pasó exitosamente aquél.
Herramientas de medición de código
Las herramientas de medición son empleadas para generar métricas del código, referentes a su complejidad y la facilidad para darle mantenimiento, que permiten a los programadores entender mejor lo que están desarrollando. Al emplear las métricas, los desarrolladores pueden entender qué tipos y/o métodos deben ser escritos nuevamente o probados con mayor profundidad. Asimismo, pueden identificar riesgos, entender mejor el estado actual del proyecto y dar seguimiento al progreso del mismo. Sin embargo, estas métricas no sirven a menos que tengan sentido para la persona que las está usando, en este caso el desarrollador, por lo que a continuación se presenta una breve descripción del significado de algunas de las cinco métricas ofrecidas por las herramientas.
• Acoplamiento de clases. Indica el número total de dependencias de otros tipos que un determinado nivel tiene. Este número no incluye tipos primitivos o incorporados, tales como int32, object o string, y cuando es mayor, aumenta la probabilidad que los cambios realizados en otros tipos se propaguen al elemento que está siendo analizado. Un valor más bajo de acoplamiento de clases generalmente indica un candidato para reutilización.
• Complejidad ciclomática. Mide el número total de rutas individuales a lo largo del código en cada nivel, y se calcula contando el número ramas (tales como switch, foreach y ciclos for) más uno. Esta métrica generalmente es una buena indicación del número de pruebas unitarias que se requerirán para obtener una completa cobertura del código.
• Índice de facilidad de mantenimiento. Es un número que va de 0 a 100, se calcula para cada miembro y nivel de tipo, e indica su facilidad de mantenimiento en general. Se calcula en base a otras métricas incluyendo la complejidad ciclomática y el número de líneas de código, e incluye un indicador icónico. Un número menor indica que el código es complejo y difícil de darle mantenimiento. El rango menor, 0-9, muestra un círculo rojo, mientras que el rango intermedio, 10-19, muestra un triángulo amarillo y por último, una caja verde indica alta facilidad de mantenimiento con valores entre 20 y 100.
Instalación de Visual Studio® 2008 Team Suite
Después de descargar la versión de evaluación por 90 días de la Visual Studio® 2008 Team Suite, se inicia el proceso de instalación. En virtud de que se quiso hacer el proceso de instalación lo más ligero y ágil posible, se seleccionaron solamente aquellas opciones que eran absolutamente necesarias para que las herramientas de análisis y medición de código funcionaran sobre proyectos de C#. Sin embargo, el proceso de instalación tuvo problemas, la instalación del .NET Framework versión 3.5 falló. La bitácora de instalación no proporcionó suficiente información para determinar cuál era el problema, probablemente hubo un conflicto entre el mencionado componente y otro no identificado que ya estaba instalado en el equipo. La solución fue crear una máquina virtual desde cero instalando únicamente el sistema operativo y Visual Studio®.
El proceso de instalación de la documentación fue sencillo, bastó con invocar un asistente de instalación por separado.
Database Commander
Después de descargar el código fuente del DBCommander, en-contramos varios problemas. En virtud de que el código fuente del DBcommander no fue escrito originalmente con Visual Studio® 2008, fue necesario invocar el asistente de conversión de soluciones que viene incluido. Lo anterior produjo algunos errores, ninguno de los cuales era crítico. Por ejemplo: la imposibilidad de respaldar archivos con extensión .MDX era un error trivial, ya que esta clase de archivos constituyen un tipo de base de datos.
Después de la conversión, intentamos compilar el proyecto, para lo cual fue necesario compilar un proyecto dependiente (que estaba incluido en el código fuente, pero no en la solución) que proveía un control para la aplicación. Una vez que concluimos lo anterior, fuimos capaces de compilar el código fuente en Visual Studio® 2008 por primera vez.
Ya con el proyecto cargado, intentamos invocar el análisis. En base a una entrada de blog que identificamos, sabíamos que era necesario intentar obtener primero las métricas de código. A pesar de que en un principio no entendimos por completo el significado de las métricas, fue gratificante observar que los resultados se produjeron muy fácil y rápidamente. El hecho de que todos los proyectos se hayan mostrado en color verde nos transmitió confianza acerca del estado del código fuente.
Figura 2. Métricas del código del Database Commander.
Cuando miramos las métricas en Visual Studio® 2008, se nos dificultó un poco entender exactamente qué significaban, partiendo del hecho de que se presentan como un árbol, en donde el nivel del proyecto constituye la raíz, y cada nivel de éste puede representar un tipo diferente. Es decir, las métricas tienen un significado diferente en función al tipo de un nivel en particular.
Posteriormente probamos el análisis de código. Esta función está disponible seleccionando el proyecto de inicio en el explorador de proyectos y la opción “Ejecutar Análisis de Código” del menú de análisis. De esta manera se ejecuta el análisis que verifica el código contra los lineamientos de diseño de Microsoft que mencionamos anteriormente. ¡Este análisis generó 159 advertencias! Sólo tomando en cuenta el proyecto de arranque. Sin embargo, nos tranquilizó el hecho de que no se encontraron errores. Después de ejecutar el mismo análisis en cada uno de los otros dos proyectos, obtuvimos un total de 509 advertencias.
La primera advertencia se debía a que el nombre de un ensamblado estaba mal escrito. Al hacer clic derecho sobre el error se nos permitió seleccionar la opción mostrar Ayuda del Error. Lo anterior nos proporcionó una descripción acerca de cómo corregir la advertencia, lo que involucró agregar la palabra mal escrita al diccionario personalizado contra el cual se realizan las verificaciones. El diccionario personalizado es un archivo llamado CustomDictionary.xml. En el ejemplo de la ayuda, fue interesante ver que el archivo todavía tiene referencias al sitio anterior de FXCop. Todo este proceso nos pareció incómodo. Lo que esperábamos era encontrar una opción que nos permitiera agregar una palabra directamente al diccionario personalizado.
SQL Buddy
Tal y como ocurre en el caso del DBCommander, el código fuente de SQL Buddy no fue escrito empleando Visual Studio® 2008, de modo que fue necesario hacer una conversión. Afortunadamente, el proceso de conversión se inició automáticamente cuando abrimos la solución de SQL Buddy la primera vez y concluyó sin errores.
Figura 3. Reporte de conversión del código de SQL Buddy.
Para calcular las métricas de código simplemente accedimos al menú analizar y seleccionamos la opción “Calcular Métricas de Código para SQL Buddy”. La ventana de métricas de código muestra los datos que son generados por el análisis. Decidimos enfocarnos exclusivamente en el índice de facilidad de mantenimiento para el proyecto.
Recordemos qué, un icono verde indicia un grado relativamente alto de facilidad de mantenimiento, mientras un icono amarillo indica un grado moderado de facilidad de mantenimiento, por último, que un icono rojo indica baja facilidad de mantenimiento y un área potencialmente problemática. Los resultados del índice de facilidad de mantenimiento indican que el código fuente del SQL Buddy tiene relativamente un alto grado de facilidad de mantenimiento y no contiene áreas que puedan ser problemáticas. Antes de analizar el código del proyecto decidimos activar únicamente la categoría de reglas de nomenclatura.
Figura 4. Selección de categorías de reglas para el análisis de SQL Buddy.
La ejecución del análisis de código fue una operación muy intuitiva, desde el menú analizar seleccionamos la opción “Ejecutar el Análisis de Código en SQL Buddy”. Después de que el análisis fue concluido, la ventana lista de errores fue desplegada mostrando todas las advertencias. Esa ventana incluye la descripción de la alerta, el archivo y el número de línea donde está localizada.
Al dar doble clic sobre ésta, se mostró el archivo y la línea de código que contiene el problema. El análisis produjo 297 advertencias. Consideramos que este es un número alto de advertencias, tomando en cuenta el hecho de que la cantidad de código fuente de SQL Buddy es relativamente pequeña. A partir de estos resultados pudimos concluir que el código fuente tiene un bajo nivel de apego a las reglas de nomenclatura de los lineamientos de diseño del .NET Framework.
Las herramientas de análisis de código incluyen información detallada acerca de cada advertencia incluyendo: el código específico que provoca su generación, una descripción de los problemas detrás de la advertencia, una explicación de cómo cambiar el código fuente para satisfacer la regla y prevenir que se genere además de, una descripción de cuándo es conveniente suprimir una advertencia.
Para mirar esta información hicimos clic derecho en una advertencia y seleccionamos la opción “Mostrar Ayuda del Error”. Gracias a esta información, la tarea de entender el significado de las advertencias fue muy fácil. Por otro lado notamos que un número pequeño de las primeras advertencias en la lista tenían valores en blanco para el archivo y el número de línea. Al principio no entendimos porqué, sin embargo posteriormente descubrimos que el problema estaba relacionado con varios archivos. Las advertencias antes mencionadas estaban relacionadas con el uso de letras mayúsculas y minúsculas en el nombre de algunos espacios de nombres.
Después de analizar las explicaciones detalladas de estas advertencias y el código fuente, llegamos a la conclusión de que estas eran válidas y decidimos corregirlas, para hacerlo empleamos la capacidad de refactorización del entorno. Finalmente, ejecutamos el análisis de código nuevamente y verificamos que las advertencias ya no aparecieran. En este caso encontramos que el proceso fue fácil y las capacidades del entorno que empleamos resultaron ser muy intuitivas.
Conclusión
Estas herramientas son intuitivas y fáciles de usar. La realización de la mayoría de las operaciones básicas tales como iniciar un análisis, mirar sus resultados, encontrar el código que tiene el problema y corregirlo, fue sencilla. La documentación del producto es muy abundante lo cual facilita el entendimiento de las advertencias. La funcionalidad de métricas de código es muy poderosa, porque permitió tener un panorama claro acerca del nivel de facilidad de mantenimiento del código fuente, a pesar de que no estábamos familiarizados con él. Adicionalmente, estas herramientas no requieren prácticamente ningún tipo de configuración. Asimismo la conversión de los
proyectos fue automática. Encontramos y corregimos advertencias sobre reglas de nomenclatura en los espacios de nombres del código fuente de SQL Buddy. Por último, éstas pueden hacer una excelente combinación con las herramientas de pruebas unitarias, ya que soportan el establecimiento de una política de protección de código.
Por otro lado, las herramientas de análisis y medición de código únicamente pueden ser aplicadas a ensamblados administrados, lo cual constituye una limitación importante ya que no pueden procesar código producido en otros lenguajes predominantes tales como C++ o Java. Las herramientas de Visual Studio® 2008 están empotradas en el entorno de Visual Studio® la cual es un producto grande y complejo que en ocasiones puede ser difícil de instalar. Llevar a cabo la selección de un subconjunto de alertas relevantes para un proyecto en particular no es una tarea trivial ya que requiere conocimiento de los lineamientos de diseño de la compañía que los produce. Asimismo, no existe la noción de severidad dentro de las advertencias obtenidas que pueda ayudar al desarrollador a decidir por dónde comenzar a corregir las advertencias.
Por último, las herramientas de análisis de Visual Studio® 2008 son por mucho las más fáciles de instalar de todas las que hemos usado hasta el momento. De modo que, en dependencia de cuáles atributos de calidad estés tratando de dar seguimiento y mejorar en su proyecto, la suite puede ser de mucha utilidad.
Referencias
[blogs.msdn.com/fxcop/archive/2007/10/03/new-for-visual-studio-2008-code-metrics.aspx]
[ dbcommander.sourceforge.net]
[msdn2.microsoft.com/en-us/library/czefa0ke(VS.71).aspx]
[msdn2.microsoft.com/en-us/vstudio/products/aa700831.aspx]
[sqlbuddy.sourceforge.net]
Acerca de los autores
Rigoberto Calleja Cervantes (rigobertoc@alumni.cmu.edu) tiene cuatro años de experiencia como consultor en ingeniería de software, impartiendo cursos y participando en proyectos de adopción de herramientas de gestión del ciclo de vida de desarrollo de software. Rigoberto tiene un posgrado en ingeniería de software de la Universidad Carnegie Mellon.
Rajah James (rjames@andrew.cmu.edu) es ingeniero senior en Yellowstone Hotel Systems y está trabajando en la última versión de su software principal OpenBook; antes trabajó durante seis años para Rockwell Software y Rockwell Automation, donde estuvo involucrado con sus soluciones de manufactura e integración empresarial basadas en .NET. Rajah tiene un posgrado en ingeniería de software de la Universidad Carnegie Mellon.
- Log in to post comments