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.
Index Terms — Artificial intelligence, Neural networks,
Software metrics, Software quality, Software engineering.
I. INTRODUCCIÓN
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.
1
Palabra en inglés que representa a un defecto de software.
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:
1. 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.
2. 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].
3. Factores que sólo pueden medirse indirectamente
(facilidad de uso, mantenibilidad, etc.) y factores
directamente medibles (métricas).
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.
3
IEEE: Es una asociación técnico-profesional mundial dedicada a la
estandarización, entre otras cosas.

4. Relación con productividad económica.
5. 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 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. Excesiva presión de cronograma a los
desarrolladores.
2. Excesiva complejidad del modelo.
3. Excesivo tamaño de módulos individuales.
4. 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.
2
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
Además de las herramientas test-case, la industria de
desarrollo de software, gestiona el proceso de calidad
mediante herramientas para:
1. Documentar y administrar la detección y corrección
de errores.
2. Generar conjuntos de pruebas sobre datasets
preparados para evaluar la correctitud de las salidas.
3. 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

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.
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. 1. Diagrama de Arquitectura
7
Software que interactúa con una aplicación principal para proveer una
función específica. http://www.eclipse.org/articles/Article-Plug-in-
architecture/plugin_architecture.html
3
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.
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)
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.
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
Fig. 4. Frecuencias en series de datos
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 Cada ACF es distribuido en función de la calificación
todas sus funcionalidades. Seleccionando la implementación obtenida. Etiquetas flotantes dan referencia al código de
del módulo Analizador Sintáctico específico para cada identificación (ID) del objeto acumulado en cada serie.
lenguaje de programación ya sea procedural, objetos u Finalmente el módulo exporta los resultados al formato arff
orientado a un futuro paradigma de modelado. (attribute-relation file format) compatible con el Módulo
Los valores obtenidos a partir del primer relevamiento Clasificador Inteligente.
(resultados elementales), son registrados y referenciados en el
repositorio de la aplicación. E. Módulo Clasificador Inteligente por Red Neuronal
Como última etapa de procesamiento analítico y parte
C. Módulo Evaluador según Métricas de Software esencial de AJI está el módulo Clasificador Inteligente.
Es el componente de cálculo y traductor en operaciones Básicamente, una red neuronal de tipo perceptrón multicapa
algebraicas de las métricas seleccionadas por el analista. configurada a partir del resultado del preprocesamiento
Según lo configurado desde un archivo xml, el módulo genera realizado por el algoritmo de clustering Expectation-
métricas de software ejecutando operaciones matemáticas a Maximization (EM) (ver Tabla 5) y entrenada utilizando el
partir de resultados elementales obtenidos por el módulo procedimiento de retropropagación (backpropagation) [21].
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. 5. Red Neuronal de AJI

9
Herramienta de software desarrollada por Sun Microsystems para
En el diagrama de la Fig. 5 está representada la estructura
generar documentación en formato HTML a partir de código fuente Java. de la red neuronal de 3 capas. La capa de entrada con
10
Anglicismo: calibración, configuración para optimizar rendimiento.
 5

atributos [v1, v2, v3 ... v14] correspondientes a los resultados de TABLA 1

CARACTERÍSTICAS DE LA MUESTRA
cada métrica. Sólo 1 capa oculta de 9 nodos y la capa de
Tipo de autor Origen Cantidad Tamaño
salida asociada a los 5 clusters predefinidos por EM. promedio
Aficionado planet-source- 250 7K
F. Módulo API (Reportes) (poco o medianamente code.com
experimentado)
Los resultados del análisis son registrados en la base de Académico Patterns In Java 250 2.7 K
datos y están disponibles desde una API en 2 modalidades: Volume I, The
una gráfica (reportes) y otra accesible desde software Java Java Tutorials
(API). Profesional Aplicaciones 250 10.8 K
La interfase consiste en una serie de clases con métodos y Open Source
Sun Microsystems API J2SE 250 8K
atributos públicos desde donde la aplicación permite obtener
instancias de resultados, parametrizar informes y realizar
Del total, un 25% codificado por programadores
consultas SQL (querys) sobre los datos.
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
Fig. 6. Informe de resultados
requirieron individualmente el siguiente tiempo de ejecución:

El estilo de los reportes es configurado desde un archivo TABLA 2

MEDICIÓN DE TIEMPOS DE EJECUCIÓN
jrxml por lo que es posible diseñarlos desde una herramienta
Programa Tarea Tiempo Tiempo
gráfica externa [22]. La información relevante a cada análisis (mseg) (min)
puede ser representada visualmente desde gráficos chart11 o en AJI Parsing, métricas 156.274 2,60’
forma de listado, regulando el grado de detalle a través de y discretización
consultas predefinidas (drill down / up) 12. de resultados
Un archivo Java (.jar) conteniendo las clases e interfases Weka Clustering – EM 14.030 0,23’
específicas, su correspondiente javadoc y credenciales de AJI.weka Clasificación NN 174.127 2,90’
(Evaluation on
acceso a la base de datos de resultados, es todo lo requerido
training set)
para interactuar con la API de AJI. AJI.weka Clasificación NN 1.521.605 25,36’
(Cross
Validation)

II. CARACTERÍSTICAS DEL EXPERIMENTO En total, el proceso automático de análisis, evaluación,

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.
12
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.
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 ) (1)

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
Fig. 7. Definición de fronteras según nivel de concordancia con la
bondad o credibilidad de éstas probabilidades lo llama log
especificación del lenguaje. likelihood. Se obtiene como la productoria de las
probabilidades condicionales sobre toda la muestra:
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 Productoria para todo i en la muestra de:
relevadas por AJI.
 xi   xi   xi   xi   xi 
r 1.P   + r 2.P   + r 3.P   + r 4.P   + r 5.P   (2)
Data Mining : 15  
a  
b  
c  
d e
Previamente a la clasificación automática y con el objetivo
de obtener un training set16 representativo del UEC, en una A partir de éste resultado parcial, el objetivo se enfocó en
primera fase se experimentó con el algoritmo de clustering k- incrementar el log likelihood, es decir, la calidad de clusters.
means17. En las diferentes configuraciones se buscó minimizar Para ello se reconfiguró el algoritmo EM con los siguientes
la distancia cuadrática de todos los puntos al centro del cluster, parámetros:
obteniendo los siguientes resultados:
Máximo de iteraciones: 100
TABLA 3 Desviación estándar mínima: 1.0 x 10-6
ERROR EN CLUSTERS DEFINIDOS POR K-MEANS Cantidad de clusters: 5
Seeds >> Cantidad de semillas (seeds): 200
5 10 15 20
Clusters Modo de cluster: evaluar sobre datos de entrenamiento
5 139.5 126.30 128.87 138.12
10 96.72 91.32 94.89 95.60 Obteniendo el siguiente resultado:
15 78.55 76.14 80.53 76.20
20 67.58 61.98 62.56 59.06 TABLA 5
INSTANCIAS POR CLUSTER
cluster # instancias %
0 326 33
Dado que el resultado de inferior valor era aún superior a 50 1 50 5
se decidió cambiar al algoritmo Expectation-Maximization 2 190 19
(EM) para definir clusters [23]. Parametrizado para 3 246 25
seleccionar automáticamente por cross validation (validación 4 188 19
cruzada, método pesimista) el número de clusters, EM arrojó
los siguientes resultados:
Log likelihood: -9.06605
TABLA 4
CLUSTERS DEFINIDOS POR EM
cluster # instancias %
0 9 1
1 127 13
2 102 10
3 149 15
4 572 57
5 4 4

Log likelihood: -1.79183

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

frecuencias.
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.
 7

Red Neuronal:
Para el contexto descripto en la presente sección, una red Estadístico Kappa:
neuronal perceptrón multicapa resultó ser la estructura P( A ) − P( E )
(3)
neuronal más precisa para clasificar el UEC. Entrenada con el 1 − P( E )
algoritmo backpropagation y configurada con los siguientes Donde P(A) es la proporción de veces en las que los valores del modelo
parámetros: resultaron iguales al valor actual y P(E) es la proporción esperada.

Tasa de aprendizaje: 0.3 Error absoluto promedio:

(La cantidad en que los pesos son actualizados). a1 − c1 + a 2 − c 2 + ... + an − cn
(4)
n
Momentum: 0.2 El promedio de la diferencia entre la predicción y el valor actual en todos los
(Énfasis aplicado a los pesos durante la actualización). casos.

Tiempo de entrenamiento: 500 epochs Error promedio cuadrático:

( a1 − c1 ) + ( a 2 − c 2 ) + ... + ( an − cn )
2 2 2
(La cantidad de ciclos requeridos para entrenar la red
(5)
neuronal). n
El error promedio cuadrático muestra el valor del error en la misma
Umbral de validación: 20 dimensión que los valores de la predicción.
(El valor define la cantidad de veces que puede repetirse un
error antes de finalizar el entrenamiento). Error absoluto relativo:
a1 − c1 + a 2 − c 2 + ... + an − cn
(6)
Fuente de entrenamiento: training set y cross validation a1 − a + a 2 − a + ... + an − a
Es el total de error absoluto hecho relativo a lo que el error habría sido si la
Se obtuvieron resultados descriptos a continuación. 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
III. RESULTADOS OBTENIDOS
(7)
( a1 − a ) + ( a 2 − a ) + ... + ( an − a )
2 2 2

Como parte del conjunto de resultados, también deberá Es el total de error cuadrático hecho relativo a lo que el error habría sido se la
considerarse el proceso de data mining por clustering predicción fuese el promedio del valor absoluto.
empleado para etiquetar18 los ACF previamente caracterizados
por métricas de software. Es evidente que la red neuronal entrenada tanto utilizando el
En el cuadro de la Tabla 6 se comparan los resultados training set (método optimista) o por cross-validation a 10
obtenidos al clasificar utilizando la red neuronal (NN) del folds alcanza marcas de precisión destacables.
Módulo Clasificador Inteligente de AJI: En la siguiente Tabla 7, la matriz de confusión
correspondiente al ensayo A:
TABLA 6
RESULTADOS DE ENTRENAMIENTO DE RED NEURONAL TABLA 7
Ensayo A B MATRIZ DE CONFUSIÓN ENSAYO A
Modo de cross validation a b c d e << clasificado
training set
entrenamiento (10 folds)
310 2 9 1 4 cluster 0
Instancias
clasificadas 938 93.8 % 914 91.4 % 3 28 16 0 3 cluster 1
correctamente 12 0 171 4 3 cluster 2
Instancias 0 0 0 246 0 cluster 3
clasificadas 62 6.2% 86 8.6 % cluster 4
incorrectamente 4 0 1 0 183
Estadístico
Kappa 0.918 0.8866
Error absoluto Esta matriz presenta los aciertos en la diagonal. La
promedio
0.0347 0.0478
Error promedio
sumatoria horizontal corresponde al total real de instancias
cuadrático
0.1322 0.1755 para el cluster y las columnas el valor definido por la red
Error absoluto neuronal.
relativo
11.435 % 15.7361 %
Error
cuadrático 33.9189 % 45.0392 %
relativo
Número de
instancias
1000 1000

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

Gráficamente contrastado sobre el histograma de IV. CONCLUSIÓN Y TRABAJO FUTURO

frecuencias de clusters:
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
Fig. 9. Resultado del ensayo A representado en un histograma de frecuencias. 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
Cada columna está formada por las instancias representadas partir del training set.
con el color originalmente asignado por el algoritmo de
En base a los resultados obtenidos en la sección anterior,
clustering. En el diagrama de la Fig. 9, las instancias
donde se aprecia una notable precisión según el coeficiente
clasificadas erróneamente integran distintos clusters pero
kappa [0.8866 y 0.918], podemos decir que AJI presenta una
conservan el color original.
nueva forma de evaluar código fuente. Estableciendo un
Para el ensayo B, la matriz de confusión es la siguiente: concepto que extiende el valor de las métricas a partir del uso
de inteligencia artificial en el análisis de calidad del software.
TABLA 8
MATRIZ DE CONFUSIÓN ENSAYO B Trabajo futuro:
a b c d e << clasificado La siguiente fase de investigación tiene como objetivo
300 0 19 1 6 cluster 0
desarrollar una versión AJI de producción, integrada por una
1 28 14 0 7 cluster 1
interfaz hombre-máquina diseñada para uso intensivo y
6 4 168 7 5 cluster 2
orientada tanto al ámbito académico como empresarial.
0 2 0 243 1 cluster 3
Del mismo modo que también está previsto incrementar el
6 1 4 2 175 cluster 4
tamaño de la muestra (ACF) y continuar desarrollando un
training set suficientemente representativo y performante20.
Asimismo se continuará investigando a partir del marco
Visualmente en el histograma del ensayo B representado en
teórico-práctico que representan los resultados del presente
la Fig. 10, también es fácilmente comprobable la mínima
trabajo a fin de definir nuevos criterios de calidad en la
diferencia de clasificación en relación al training set:
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 [1] Roe and Lytle, pp. 99, 1935.
y la capacidad de la red neuronal para distinguir diferencias [2] Moore, pp. 652, 1958.
[3] James D. Arthur, “Managing Software Quality: A Mesurement
entre atributos y clasificar correctamente. Framework for Assessments and Prediction”, Springer, 2002.
[4] 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] Roger S. Pressman, “Ingeniería del Software: Un Enfoque Práctico”, Mc
Graw Hill, 1998.
[6] Stephen H. Kan, “Metrics and Models in Software Quality
Engineering”, Addison-Wesley Professional, 2002.
[7] Capers Jones, “Applied software measurement: assuring productivity
and quality”, Mc Graw Hill, 1996.
[8] Bugzilla: http://www.bugzilla.org/about/
[9] http://www.oracle.com/technology/pub/articles/server_side_unit_tests.ht
ml
[10] http://www-128.ibm.com/developerworks/java/library/j-junit4.html
[11] Eva van Emden, Leon Moonen, “Java Quality Assurance by Detecting
Code Smells”.
[12] Rigi: http://www.rigi.csc.uvic.ca/Pages/description/whatitis.html
[13] Neil Walkinshaw, “Partitioning Object-Oriented Source Code for
Inspections”, University of Strathclyde, Glasgow, 2006.
[14] AgitarOne: http://www.agitar.com/solutions/products/agitarone.html
[15] AI Group: http://www.palermo.edu/ingenieria/itlab.html
[16] W.A. Woods, “Transition Network Grammars for Natural Language
Análisis”, pp. 591-606, Communications of the ACM, 1970.
[17] Bruce Eckel, “Thinking in Patterns”, 2003.
[18] Mark Watson, “Practical Artificial Intelligence Programming in Java”,
2005.
[19] James Gosling, Bill Joy, Guy Steele, Gilad Bracha “The Java Language
Specification 3rd Edition ”, Pretience Hall, 2005.
[20] 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.
[21] Patrick H. Winston, “Inteligencia Artifical, tercera edición”, Addison
Wesley Iberoamericana, 1992.
[22] iReport: http://sourceforge.net/projects/jasperreports/
[23] Ian H. Witten, Eibe Frank "Data Mining: Practical Machine Learning
Tools and Techniques", pp. 265, Morgan Kaufmann, 2005.
[24] 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.