Aji Tfg_martin_aguero

1

Analizador Java Inteligente Martín Jorge Agüero, Facultad de Ingeniería de la Universidad de Palermo, Buenos Aires, Argentina

Abstract — Este trabajo estudia la aplicación de métricas de software para la evaluación de calidad de código fuente Java. También se definen nuevas métricas. A fin de detectar patrones de codificación, se emplea una red neuronal perceptrón multicapa para clasificar las muestras. Características determinadas a partir de métricas son la base para la definición de perfiles. Los resultados muestran una marcada tendencia hacia la configuración de este tipo de perfiles.

A continuación en las siguientes subsecciones se presentan distintos enfoques de calidad en el software: una breve referencia al marco teórico vigente, estrategias de implementación2 y herramientas actuales: A. Calidad en el Software Adaptando y ampliando las definiciones clásicas, la industria del software propone hacer énfasis en los siguientes puntos:

Index Terms — Artificial intelligence, Neural networks, Software metrics, Software quality, Software engineering.

1.

2. I. INTRODUCCIÓN 3.

S

i se define a un programa de computadora (software) como maduro y libre de errores (bugs1) una vez cumplida la especificación de requerimientos de software (SRS), será necesario contar con una estrategia que dé soporte al proceso. El objetivo de todo proyecto de desarrollo de software es alcanzar el más alto nivel de conformidad en relación a lo esperado, es decir, la mayor calidad. Históricamente el significado del término calidad fue adaptado y ha evolucionado según las distintas tecnologías para las que fue aplicado. Ya en la industria metalúrgica de los años ‘30 se define a la calidad como la “conformidad a los requerimientos”, o sea, desviaciones del óptimo reflejan pérdida de calidad y una disminución en la confiabilidad del producto. El resultado final es la reducción de costos al disminuir defectos y en consecuencia, inferior repetición de trabajo [1]. Una definición surgida del ámbito industrial-manufacturero de los años ’50 afirma que a mayores niveles de calidad los costos aumentan exponencialmente, incluso pueden aumentar aún más que la calidad misma. Es por ello que propone especificaciones que incluyan tolerancias, en otras palabras, las desviaciones de la perfección. El aseguramiento de que el producto está dentro de una tolerancia predefinida es alcanzada a través de la inspección. El propósito de la inspección es preventivo, identificar productos fuera de la especificación para su posterior corrección [2]. Si bien el software no insume costos de producción en serie (fabricación de réplicas y control de calidad de las mismas) es una actividad mentalmente intensiva [3]. Requiere la interacción y coordinación de distintos especialistas durante todas sus fases de desarrollo.

La garantía de calidad del software (SQA), es una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería del software, consiste básicamente en la auditoría y las funciones de información de la gestión [5]. Proyectos de software exitosos obtienen excelentes resultados de control de calidad, concretamente en inspecciones de calidad a través de métricas. Si bien un exhaustivo control de calidad del software incrementa costos, es una actividad con un muy alto retorno de inversión (ROI). Sin verificación empírica con indicadores y medición de datos, las teorías y proposiciones permanecen abstractas [6]. B. Estrategias para el Aseguramiento de la Calidad del Software Métricas de estimación: Como respuesta a las deficiencias y omisiones de la técnica de estimación por líneas de código, a principios de los años 80, A. Albrecht difunde masivamente a través de IEEE3 el concepto denominado Puntos de Función (FP) demostrando que no era técnicamente posible medir tasas de producción de software a partir de la métrica líneas de código. Originalmente FP propone métricas para: 1. Características externas al software. 2. Características de interés para el usuario. 3. Aplicación en etapas tempranas del ciclo de vida del producto. 2

Anglicismo cuya traducción correcta al castellano es implantación. IEEE: Es una asociación técnico-profesional mundial dedicada a la estandarización, entre otras cosas. 3

1

Palabra en inglés que representa a un defecto de software.

Los requerimientos del software son la base de las métricas de la calidad, o sea, la falta de concordancia con los requerimientos es una falta de calidad. Estándares específicos definen un conjunto de criterios de desarrollo, la ausencia de estándares, en muchos casos, es un indicio de baja calidad [4]. Factores que sólo pueden medirse indirectamente (facilidad de uso, mantenibilidad, etc.) y factores directamente medibles (métricas).

2

4. 5.

Relación con productividad económica. Independiente al código fuente o lenguaje.

A partir de FP, revisiones posteriores y metodologías derivadas [7] dieron lugar a la creación de diversas instituciones, entre ellas la International Function Points User’s Group4 desde donde organizaciones asociadas obtienen estándares y guías para estimar:

Estudios han confirmado que:
Generalmente los test-case contienen más errores que los productos para los cuales fueron desarrollados.
Típicamente un tercio de los test-case están duplicados, lo cual no aporta extra por la calidad, incrementa costos y por ende desaprovecha recursos [7]. C. Software de Gestión de la Calidad





Estudios económicos de costos de producción. Esfuerzo del staff y dimensión de recursos.

Si bien podría decirse en la actualidad FP es la métrica estándar más difundida para estudios de productividad, el presente desafío consiste en el desarrollo de herramientas automáticas y no subjetivas que analicen el código fuente y retroalimenten de PF las estimaciones originales del producto [7]. Lenguajes OO: El desarrollo con lenguajes orientados al paradigma de objetos, ha reducido los niveles de defectos en comparación con lenguajes procedurales [7]. De todas maneras, el software nunca está exento de padecer defectos causados por otros factores como por ejemplo: 1. 2. 3. 4.

Excesiva presión de cronograma a los desarrolladores. Excesiva complejidad del modelo. Excesivo tamaño de módulos individuales. Errores al testear5 el módulo una vez terminada la codificación.

Metodologías estratégicas: Total Quality Management6 puede ser exitoso únicamente con un fuerte compromiso de la gerencia, es decir, depende de la aplicación de efectivos programas de calidad, uso de revisiones técnicas e implementado en organizaciones donde el control de la calidad era bueno o excelente antes de aplicar Total Quality Management (TQM) al modelo de negocio. Empresas que desisten de aplicar métricas de calidad y pretenden obtener un incremento marginal de sus ganancias utilizando TQM como un slogan, difícilmente logren resultados positivos [7]. Herramientas test-case: Actualmente es muy popular el uso de herramientas test-case. Dichas herramientas pueden identificar y aislar secuencias que no son ejecutadas o que no devuelven el resultado esperado. No obstante, la ejecución del 90% de un programa no significa que serán encontrados el 90% de defectos, se ha demostrado que normalmente menos del 30% de defectos son encontrados con testeos unitarios. Asimismo la presencia de test-case no garantiza correctitud, debido a que durante su construcción también pudieron haberse cometido errores.

4 IFPUG: Es una organización de desarrolladores de software cuyo objetivo agrupar y estandarizar trabajos basados en el análisis por puntos de función (FPA). 5 Anglicismo cuya traducción al español es evaluar. 6 Una estrategia de gestión orientada a crear conciencia de calidad en todos los procesos organizacionales.

Además de las herramientas test-case, la industria de desarrollo de software, gestiona el proceso de calidad mediante herramientas para: 1. 2. 3.

Documentar y administrar la detección y corrección de errores. Generar conjuntos de pruebas sobre datasets preparados para evaluar la correctitud de las salidas. Verificar la conformidad según especificaciones y estándares.

Entre las de tipo 1, existen aplicaciones como Bugzilla [8] que proponen una solución orientada a la comunicación y documentación de bugs encontrados durante la fase de desarrollo y testing. Posiblemente el punto menos atractivo de estas herramientas sea la falta de integración con el código fuente. Una propuesta tipo 2 es el framework JUnit [9], una herramienta Open Source de testing altamente difundida y utilizada tanto por la comunidad de desarrollo independiente como el mundo corporativo, presenta un conjunto de clases Java con el cual es posible crear casos de prueba (test cases) con el propósito de evaluar, de forma automática, las salidas de los métodos de clase. El framework también propone un mecanismo de aserciones (assertions) y otro de control de excepciones con el cual es posible automatizar aún más la verificación de los algoritmos. No obstante, JUnit requiere significativas horas de programación para preparar casos de prueba y la limitada posibilidad de reutilizar código es otra de sus desventajas [10]. Entre las clasificadas como de tipo 2, la comunidad de desarrollo independiente también propone otra herramienta evaluadora de calidad: jCosmo, se basa en detectores de problemas en el código fuente llamados “code smells” [11]. Permite extender la cantidad de detectores agregando módulos de tipo estándar o crear propios. Asimismo los “code smells” entregan resultados sobre la estructura del programa a nivel de paquete, clase, métodos y su interrelación. La principal limitación de este software es su dependencia con Rigi [12], una herramienta externa requerida para visualizar los resultados del análisis. A partir de la interpretación gráfica es posible descubrir defectos en el código y la estructura del programa. No obstante, éstos gráficos, en su mayoría requieren la inversión de varias horas de aprendizaje, estudio e interpretación según el caso [13]. Otra herramienta clasificada tanto tipo 2 como tipo 3 es AgitarONE de Agitar Software [14] ofrece, además de crear automáticamente casos de prueba para usar con JUnit, evaluar calidad mediante un “agitador” de código, el cual aparte de analizar sintácticamente el código según convenciones y

3

estándares, pone a prueba el comportamiento de clases y métodos Java generando entradas aleatorias y analizando los resultados. Se integra con Eclipse como un plug-in7 y genera reportes a nivel proyecto. Los valores de entrada no siempre son adecuados para todos los métodos y puede reportar errores incorrectamente. Otra limitación es que su licencia de uso no es Open Source. El presente trabajo propone una herramienta de soporte a la calidad del software, un evaluador y clasificador de código fuente Java basado en técnicas de inteligencia artificial. Software Java desarrollado en el laboratorio de investigación AIGroup de la Universidad de Palermo [15]: Analizador Java Inteligente (AJI). Una propuesta cuyo objetivo es dar soporte al desarrollo de código fuente con el propósito de mejorar la calidad del software a través de la inspección, calificación y clasificación de código fuente en forma automática. A continuación, en la sección I se presenta una descripción de la arquitectura de la herramienta, considerando modularidad y desacoplamiento como factores determinantes durante la fase de diseño, en la sección II se presenta las configuración inicial del experimento, características de las entradas y salidas, la sección III presenta una nueva propuesta de caracterización del software a partir de los resultados obtenidos. Finalmente en la sección IV se resumen las conclusiones más importantes y trabajo futuro.

El diseño modular y la parametrización por archivos de configuración hacen de AJI una herramienta flexible y adaptable tanto a los requerimientos científicos como empresariales. Se trata software desarrollado totalmente en lenguaje Java por lo que es ejecutable desde cualquier plataforma JRE 1.5 (Java Runtime Environment versión 1.5) compatible. El diseño de los algoritmos optimiza la utilización de CPU y memoria, posibilitando el análisis de grandes volúmenes de código fuente Java (ver Tabla 2) en pocos minutos de ejecución. En las siguientes secciones se describe el diseño y principales aspectos funcionales de cada módulo. A. Módulo Secuenciador de Contenidos Como se aprecia en el diagrama de la figura 2, el módulo Secuenciador de Contenidos es el nexo de AJI con los archivos de código fuente Java (ACF). Esencialmente es la extensión a una implementación de la interfase Collection de la API (Application Program Interface) de Java.

I. ARQUITECTURA La arquitectura de AJI está dividida en 6 módulos, 4 principales (núcleo) y 2 secundarios (externos). Como puede apreciarse en Fig. 1 la comunicación entre componentes es únicamente a través de resultados almacenados en la base de datos y las interfaces externas (archivos de código fuente y reportes) son delegadas a módulos específicos e independientes del núcleo.

Fig. 2. Diagrama Secuenciador de Contenidos

Encapsula las palabras y símbolos de los ACF, serializando sincrónicamente y de forma transparente la información a procesar. Es configurable para definir símbolos de separación de palabras y normaliza el código fuera de estándar. Ha sido desarrollado por AIGroup en simultáneo con AJI y próximamente será liberada la versión 1 para uso público bajo la licencia GNU General Public License8. B. Módulo Analizador Sintáctico (Parser)

Fig. 1. Diagrama de Arquitectura

Como primer componente del núcleo de AJI está el módulo Analizador Sintáctico, cuya función es interpretar y relevar en contexto el código fuente serializado y sincronizado por Secuenciador de Contenidos. Conceptualmente el algoritmo parser adapta a la sintaxis Java el modelo propuesto por W. A. Woods, Redes de Transición Aumentadas (ATN) [16]. Básicamente la implementación en Java está definida por los patrones de diseño State y Memento [17]. Éste algoritmo detecta y responde a palabras reservadas, símbolos y estructuras cambiando a un siguiente estado o retornando a uno anterior.

7 Software que interactúa con una aplicación principal para proveer una función específica. http://www.eclipse.org/articles/Article-Plug-inarchitecture/plugin_architecture.html

8 Licencia cuyo propósito es declarar que el software cubierto es libre y gratuito y para protegerlo de intentos de apropiación y limitación de uso.

4

D. Módulo Evaluador / Normalizador de Resultados A partir de valores cuantitativos específicos a cada métrica, el módulo Evaluador de Resultados obtiene calificadores valuados entre -1 y 1. Tal como se observa en la Fig. 4, para representar determinada clasificación, se establecen grupos a partir de ciertos valores de corte (denominados fronteras).

Fig. 3. Red de Transición Aumentada

El diagrama de la Fig. 3 es una representación simplificada de una ATN aplicada a texto, donde los nodos definen estados y las flechas la evaluación que los componentes de la frase deberán superar para pasar al siguiente estado [18]. El diseño modular de AJI permitirá extender a otros lenguajes todas sus funcionalidades. Seleccionando la implementación del módulo Analizador Sintáctico específico para cada lenguaje de programación ya sea procedural, objetos u orientado a un futuro paradigma de modelado. Los valores obtenidos a partir del primer relevamiento (resultados elementales), son registrados y referenciados en el repositorio de la aplicación. C. Módulo Evaluador según Métricas de Software Es el componente de cálculo y traductor en operaciones algebraicas de las métricas seleccionadas por el analista. Según lo configurado desde un archivo xml, el módulo genera métricas de software ejecutando operaciones matemáticas a partir de resultados elementales obtenidos por el módulo antecesor. Por ejemplo, supongamos un resultado denominado v1 como la diferencia entre el total de clases y el número de clases cuyo nombre comienza con una letra en minúscula, es decir, incumpliendo la especificación Java [19]. Otra forma de medir calidad es a partir de una métrica identificada como v12 desde donde AJI pondera el equilibrio entre el total de comentarios relevados en el ACF y los que son de tipo javadoc9, estableciendo como de inferior calidad una desproporción entre los mismos. Se trata de la primer fase del análisis donde es ajustable la relevancia de cada operador Será de gran importancia seleccionar el conjunto de métricas que definan con mayor precisión la identidad (atributos) de cada ACF. Es decir, un tunning10 artesanal de parámetros [20].

Fig. 4. Frecuencias en series de datos

Cada ACF es distribuido en función de la calificación obtenida. Etiquetas flotantes dan referencia al código de identificación (ID) del objeto acumulado en cada serie. Finalmente el módulo exporta los resultados al formato arff (attribute-relation file format) compatible con el Módulo Clasificador Inteligente. E. Módulo Clasificador Inteligente por Red Neuronal Como última etapa de procesamiento analítico y parte esencial de AJI está el módulo Clasificador Inteligente. Básicamente, una red neuronal de tipo perceptrón multicapa configurada a partir del resultado del preprocesamiento realizado por el algoritmo de clustering ExpectationMaximization (EM) (ver Tabla 5) y entrenada utilizando el procedimiento de retropropagación (backpropagation) [21].

Fig. 5. Red Neuronal de AJI

9

Herramienta de software desarrollada por Sun Microsystems para generar documentación en formato HTML a partir de código fuente Java. 10 Anglicismo: calibración, configuración para optimizar rendimiento.

En el diagrama de la Fig. 5 está representada la estructura de la red neuronal de 3 capas. La capa de entrada con

5

atributos [v1, v2, v3 ... v14] correspondientes a los resultados de cada métrica. Sólo 1 capa oculta de 9 nodos y la capa de salida asociada a los 5 clusters predefinidos por EM. F. Módulo API (Reportes) Los resultados del análisis son registrados en la base de datos y están disponibles desde una API en 2 modalidades: una gráfica (reportes) y otra accesible desde software Java (API). La interfase consiste en una serie de clases con métodos y atributos públicos desde donde la aplicación permite obtener instancias de resultados, parametrizar informes y realizar consultas SQL (querys) sobre los datos.

Fig. 6. Informe de resultados

TABLA 1 CARACTERÍSTICAS DE LA MUESTRA

Tipo de autor

Origen

Cantidad

Aficionado

planet-sourcecode.com

250

(poco o medianamente experimentado)

Académico

Profesional Sun Microsystems

Selección de muestras: Con el propósito de definir un universo de estilos de codificación (UEC) a partir de un conjunto de muestras heterogéneas, suficientemente representativas y correctas13, fueron recopilados un total de 1000 ACF con las siguientes características:

11

Anglicismo: diagrama de barras, torta, histograma, etc. Anglicismos: refieren a operaciones y transformaciones en la forma de mostrar datos multidimensionales. Ver data mining. 13 Interpretable por el compilador Java y traducible a bytecode Java para ser ejecutado desde una JVM. Libre de errores en tiempo de compilación. 12

2.7 K

10.8 K 8K

Del total, un 25% codificado por programadores aficionados y poco o medianamente experimentados, 25% desarrollado por autores de material académico Java, otro 25% corresponde a fuentes de aplicaciones Open Source de uso comercial muy difundidas (Spring Framework, MySQL JDBC Driver, iReport, Jdepend y JavaNCSS) y el último cuarto ACF que son parte de la API de J2SE14. Plataforma de ensayo: La ejecución del experimento se desarrolló en un equipo con las siguientes características: PC procesador Pentium II 400 MHz, RAM 512 MB, S.O. Windows 2000 y JDK 1.5.0_03. Durante el procesamiento de la muestra (1000 ACF) intervinieron diferentes programas o módulos, los cuales requirieron individualmente el siguiente tiempo de ejecución: TABLA 2 MEDICIÓN DE TIEMPOS DE EJECUCIÓN

El estilo de los reportes es configurado desde un archivo jrxml por lo que es posible diseñarlos desde una herramienta gráfica externa [22]. La información relevante a cada análisis puede ser representada visualmente desde gráficos chart11 o en forma de listado, regulando el grado de detalle a través de consultas predefinidas (drill down / up) 12. Un archivo Java (.jar) conteniendo las clases e interfases específicas, su correspondiente javadoc y credenciales de acceso a la base de datos de resultados, es todo lo requerido para interactuar con la API de AJI.

II. CARACTERÍSTICAS DEL EXPERIMENTO

Patterns In Java 250 Volume I, The Java Tutorials Aplicaciones 250 Open Source API J2SE 250

Tamaño promedio 7K

Programa AJI

Weka AJI.weka

AJI.weka

Tarea

Tiempo (mseg) Parsing, métricas 156.274 y discretización de resultados Clustering – EM 14.030 Clasificación NN 174.127 (Evaluation on training set) Clasificación NN 1.521.605 (Cross Validation)

Tiempo (min) 2,60’

0,23’ 2,90’

25,36’

En total, el proceso automático de análisis, evaluación, entrenamiento y clasificación de los 1000 ACF con AJI demanda 5,50 minutos de procesamiento neto en un equipo de las características descriptas. Ponderación de resultados: Para establecer valores de corte determinantes de grupos de calificación relativos a cada métrica, previamente se evaluaron resultados de más de 200 ACF. La tarea consistió básicamente en determinar de un valor límite para cada grupo en función del nivel de correctitud cuantificado desde los resultados obtenidos en cada métrica [v1, v2, v3 ... v14]. En todos los casos, se definen 3 niveles en relación a la concordancia con la especificación del lenguaje Java. 14

Colección de programas parte de Java 2 Platform Standard Edition.

6

Sabiendo que el algoritmo EM finaliza cuando la fórmula que mide la calidad de clusters no muestra incremento significativo. Para ello supone:

r 1.P ( a ) + r 2.P( b ) + r 3.P( c ) + r 4.P( d ) + r 5.P( e )

Fig. 7. Definición de fronteras según nivel de concordancia con la especificación del lenguaje.

Los valores a y b del ejemplo de la Fig. 7 determinan rangos relativos de tolerancia específicos a 1 de las 14 métricas relevadas por AJI. 15

Data Mining : Previamente a la clasificación automática y con el objetivo de obtener un training set16 representativo del UEC, en una primera fase se experimentó con el algoritmo de clustering kmeans17. En las diferentes configuraciones se buscó minimizar la distancia cuadrática de todos los puntos al centro del cluster, obteniendo los siguientes resultados: TABLA 3 ERROR EN CLUSTERS DEFINIDOS POR K-MEANS Seeds >> 5 10 15 20 Clusters 5 139.5 126.30 128.87 138.12

96.72 78.55 67.58

10 15 20

91.32 76.14 61.98

94.89 80.53 62.56

95.60 76.20 59.06

Dado que el resultado de inferior valor era aún superior a 50 se decidió cambiar al algoritmo Expectation-Maximization (EM) para definir clusters [23]. Parametrizado para seleccionar automáticamente por cross validation (validación cruzada, método pesimista) el número de clusters, EM arrojó los siguientes resultados:

Siendo a,b,c,d ,e clusters y r1, r2, r3, r4, r5 los parámetros. El algoritmo usa un registro de las probabilidades de que los parámetros sean los verdaderos. Estas probabilidades van cambiando a medida que procesa datos. A la medida de bondad o credibilidad de éstas probabilidades lo llama log likelihood. Se obtiene como la productoria de las probabilidades condicionales sobre toda la muestra: Productoria para todo i en la muestra de:

 xi   xi   xi   xi   xi  r 1.P   + r 2.P   + r 3.P   + r 4.P   + r 5.P   a b c d         e

2 3 4 5

127 102 149 572 4

Máximo de iteraciones: 100 Desviación estándar mínima: 1.0 x 10-6 Cantidad de clusters: 5 Cantidad de semillas (seeds): 200 Modo de cluster: evaluar sobre datos de entrenamiento

Obteniendo el siguiente resultado: TABLA 5 INSTANCIAS POR CLUSTER cluster # instancias % 0 326 33 1 2 3 4

50 190 246 188

5 19 25 19

Log likelihood: -9.06605

13 10 15 57 4

Log likelihood: -1.79183

15 Proceso automático de búsqueda de características en común en grandes volúmenes de datos. 16 Conjunto de datos de entrada y resultados utilizados en inteligencia artificial para entrenar, entre otros, redes neuronales. 17 Por ser un algoritmo clásico, de rápida convergencia y fácil uso.

(2)

A partir de éste resultado parcial, el objetivo se enfocó en incrementar el log likelihood, es decir, la calidad de clusters. Para ello se reconfiguró el algoritmo EM con los siguientes parámetros:

TABLA 4 CLUSTERS DEFINIDOS POR EM cluster # instancias % 0 9 1 1

(1)

Fig. 8. Clusters definidos por EM representados en un histograma de frecuencias.

7

Red Neuronal: Para el contexto descripto en la presente sección, una red neuronal perceptrón multicapa resultó ser la estructura neuronal más precisa para clasificar el UEC. Entrenada con el algoritmo backpropagation y configurada con los siguientes parámetros: Tasa de aprendizaje: 0.3 (La cantidad en que los pesos son actualizados).

Estadístico Kappa:

P( A ) − P( E ) 1 − P( E )

(3)

Donde P(A) es la proporción de veces en las que los valores del modelo resultaron iguales al valor actual y P(E) es la proporción esperada. Error absoluto promedio:

a1 − c1 + a 2 − c 2 + ... + an − cn

(4)

n Momentum: 0.2 (Énfasis aplicado a los pesos durante la actualización).

El promedio de la diferencia entre la predicción y el valor actual en todos los casos.

Tiempo de entrenamiento: 500 epochs (La cantidad de ciclos requeridos para entrenar la red neuronal).

Error promedio cuadrático:

Umbral de validación: 20 (El valor define la cantidad de veces que puede repetirse un error antes de finalizar el entrenamiento).

( a1 − c1 )

+ ( a 2 − c 2 ) + ... + ( an − cn ) 2

2

(5)

n El error promedio cuadrático muestra el valor del error en la misma dimensión que los valores de la predicción. Error absoluto relativo:

a1 − c1 + a 2 − c 2 + ... + an − cn a1 − a + a 2 − a + ... + an − a

Fuente de entrenamiento: training set y cross validation

Se obtuvieron resultados descriptos a continuación.

2

(6)

Es el total de error absoluto hecho relativo a lo que el error habría sido si la predicción fuese simplemente el promedio de los valores actuales. Error cuadrático relativo:

( a1 − c1 ) + ( a 2 − c 2 ) + ... + ( an − cn ) 2 2 2 ( a1 − a ) + ( a 2 − a ) + ... + ( an − a ) 2

III. RESULTADOS OBTENIDOS Como parte del conjunto de resultados, también deberá considerarse el proceso de data mining por clustering empleado para etiquetar18 los ACF previamente caracterizados por métricas de software. En el cuadro de la Tabla 6 se comparan los resultados obtenidos al clasificar utilizando la red neuronal (NN) del Módulo Clasificador Inteligente de AJI: TABLA 6 RESULTADOS DE ENTRENAMIENTO DE RED NEURONAL Ensayo A B Modo de cross validation training set entrenamiento (10 folds) Instancias clasificadas 938 93.8 % 914 91.4 % correctamente Instancias clasificadas 62 6.2% 86 8.6 % incorrectamente Estadístico 0.918 0.8866 Kappa Error absoluto 0.0347 0.0478 promedio Error promedio 0.1322 0.1755 cuadrático Error absoluto 11.435 % 15.7361 % relativo Error cuadrático 33.9189 % 45.0392 % relativo Número de 1000 1000 instancias

18 Término extraído de Data Mining: Practical Machine Learning Tools and Techniques [24].

2

2

(7)

Es el total de error cuadrático hecho relativo a lo que el error habría sido se la predicción fuese el promedio del valor absoluto.

Es evidente que la red neuronal entrenada tanto utilizando el training set (método optimista) o por cross-validation a 10 folds alcanza marcas de precisión destacables. En la siguiente Tabla 7, la matriz de confusión correspondiente al ensayo A:

a

TABLA 7 MATRIZ DE CONFUSIÓN ENSAYO A b c d e << clasificado

310 3 12 0 4

2 28 0 0 0

9 16 171 0 1

1 0 4 246 0

4 3 3 0 183

cluster 0 cluster 1 cluster 2 cluster 3 cluster 4

Esta matriz presenta los aciertos en la diagonal. La sumatoria horizontal corresponde al total real de instancias para el cluster y las columnas el valor definido por la red neuronal.

8

Gráficamente contrastado frecuencias de clusters:

sobre

el

histograma

Fig. 9. Resultado del ensayo A representado en un histograma de frecuencias.

Cada columna está formada por las instancias representadas con el color originalmente asignado por el algoritmo de clustering. En el diagrama de la Fig. 9, las instancias clasificadas erróneamente integran distintos clusters pero conservan el color original. Para el ensayo B, la matriz de confusión es la siguiente:

a

TABLA 8 MATRIZ DE CONFUSIÓN ENSAYO B b c d e << clasificado

300 1 6 0 6

0 28 4 2 1

19 14 168 0 4

1 0 7 243 2

6 7 5 1 175

IV. CONCLUSIÓN Y TRABAJO FUTURO

de

cluster 0 cluster 1 cluster 2 cluster 3 cluster 4

Visualmente en el histograma del ensayo B representado en la Fig. 10, también es fácilmente comprobable la mínima diferencia de clasificación en relación al training set:

El propósito de éste paper es presentar una nueva metodología para evaluar calidad de código fuente. Para ello queda demostrado que no sólo será necesario cuantificar atributos sintácticos (métricas) del código fuente sino que también intervendrán técnicas de data mining y machine learning19 en el proceso. Se han relevado por muestreo las principales características de estilos de codificación Java, contrastando resultados con la especificación, definiendo un modelo de información común para cada muestra. Agrupados por clustering, cada ACF es etiquetado formando, en conjunto, un training set de referencia. Finalmente una red neuronal en fase de entrenamiento, clasifica esos ACF y evalúa su precisión a partir del training set. En base a los resultados obtenidos en la sección anterior, donde se aprecia una notable precisión según el coeficiente kappa [0.8866 y 0.918], podemos decir que AJI presenta una nueva forma de evaluar código fuente. Estableciendo un concepto que extiende el valor de las métricas a partir del uso de inteligencia artificial en el análisis de calidad del software. Trabajo futuro: La siguiente fase de investigación tiene como objetivo desarrollar una versión AJI de producción, integrada por una interfaz hombre-máquina diseñada para uso intensivo y orientada tanto al ámbito académico como empresarial. Del mismo modo que también está previsto incrementar el tamaño de la muestra (ACF) y continuar desarrollando un training set suficientemente representativo y performante20. Asimismo se continuará investigando a partir del marco teórico-práctico que representan los resultados del presente trabajo a fin de definir nuevos criterios de calidad en la evaluación de software.

V. AGRADECIMIENTOS El autor, en calidad de miembro del grupo de investigación AI Group, agradece la colaboración de la Directora del laboratorio Daniela López De Luise y a las autoridades de la Facultad de Ingeniería, especialmente al Decano Esteban Di Tada y a las Directoras del Departamento de Ciencias Exactas Patricia González y Gabriela Dussault. Fig. 10. Resultado del ensayo B representado en un histograma de frecuencias.

VI. REFERENCIAS Un promedio general superior al 90% confirma una marcada correlación entre ACF agrupados en clusters por EM y la capacidad de la red neuronal para distinguir diferencias entre atributos y clasificar correctamente.

[1] [2] [3] [4]

Roe and Lytle, pp. 99, 1935. Moore, pp. 652, 1958. James D. Arthur, “Managing Software Quality: A Mesurement Framework for Assessments and Prediction”, Springer, 2002. ISO/IEC 9126: http://www.cse.dcu.ie/essiscope/sm2/9126ref.html

19 Es una rama de inteligencia artificial dedicada al diseño y desarrollo de algoritmos y técnicas de “aprendizaje” de computadores. 20 Anglicismo: de buen desempeño.

9 [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]

[21] [22] [23] [24]

Roger S. Pressman, “Ingeniería del Software: Un Enfoque Práctico”, Mc Graw Hill, 1998. Stephen H. Kan, “Metrics and Models in Software Quality Engineering”, Addison-Wesley Professional, 2002. Capers Jones, “Applied software measurement: assuring productivity and quality”, Mc Graw Hill, 1996. Bugzilla: http://www.bugzilla.org/about/ http://www.oracle.com/technology/pub/articles/server_side_unit_tests.ht ml http://www-128.ibm.com/developerworks/java/library/j-junit4.html Eva van Emden, Leon Moonen, “Java Quality Assurance by Detecting Code Smells”. Rigi: http://www.rigi.csc.uvic.ca/Pages/description/whatitis.html Neil Walkinshaw, “Partitioning Object-Oriented Source Code for Inspections”, University of Strathclyde, Glasgow, 2006. AgitarOne: http://www.agitar.com/solutions/products/agitarone.html AI Group: http://www.palermo.edu/ingenieria/itlab.html W.A. Woods, “Transition Network Grammars for Natural Language Análisis”, pp. 591-606, Communications of the ACM, 1970. Bruce Eckel, “Thinking in Patterns”, 2003. Mark Watson, “Practical Artificial Intelligence Programming in Java”, 2005. James Gosling, Bill Joy, Guy Steele, Gilad Bracha “The Java Language Specification 3rd Edition ”, Pretience Hall, 2005. Daniela López DeLuise, Martín Agüero, “Aplicación de Métricas Categóricas en Sistemas con Lógica Difusa”, Revista IEEE América Latina, 2007. Patrick H. Winston, “Inteligencia Artifical, tercera edición”, Addison Wesley Iberoamericana, 1992. iReport: http://sourceforge.net/projects/jasperreports/ Ian H. Witten, Eibe Frank "Data Mining: Practical Machine Learning Tools and Techniques", pp. 265, Morgan Kaufmann, 2005. Ian H. Witten, Eibe Frank "Data Mining: Practical Machine Learning Tools and Techniques", pp. 337, Morgan Kaufmann, 2005.

Las diferentes marcas y tecnologías citadas en el presente trabajo son propiedad de sus respectivos dueños y/o autores.