Modelo Conceptual Del Conjunto de Programas C4.5

MODELO CONCEPTUAL DEL CONJUNTO DE
PROGRAMAS C4.5
Tesis sometida a revición al Departamento de Ciencias Básicas, Ingenierı́a y

Tecnologı́a de la
Universidad Autónoma de Tlaxcala
Como requisito parcial para obtener el grado de
Licenciatura en Ingenierı́a en Computación
Presenta
Javier Juárez Palma
Asesorado por:
M. C. Ricardo Solano Monje
Comité de Revisión:
M. C. Leticia Flores Pulido
M. C. Orion Fausto Reyes Galaviz
M. C. Marva Angélica Mora Lumbreras
Mayo del 2005

c
Propiedad literaria °2005 por Javier Juárez Palma
U.A.T. Todos los derechos reservados
Dedicatorias
A mis padres
que con su esfuerzo y cariño me
impulsaron en mi formación
profesional
A mis hermanos
por su apoyo y comprensión
durante todo el tiempo que no
pude estar con ellos
iii
Contenido
Lista de figuras VI
Prefacio VI
Agradecimientos VI
Resumen VI
1. Preliminares 1
1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Marco Teórico 8
2.1. Minerı́a de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Árboles de decisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Representación de árboles de decisión . . . . . . . . . . . . . . 9
2.2.2. Problemas apropiados para el aprendizaje con árboles de decisión 11
2.2.3. C4.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. El lenguaje unificado de modelado . . . . . . . . . . . . . . . . . . . . 14
2.4. Ingenierı́a directa e inversa . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5. Diagramas de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6. Diagramas de interacción . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.1. Diagramas de colaboración . . . . . . . . . . . . . . . . . . . . 19
2.7. Diagramas de estados . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
iv
3. Estado del arte 21
3.1. Entendiendo la estructura de sistemas . . . . . . . . . . . . . . . . . . 23
3.2. Usando ingenierı́a inversa para descubrir estructuras de software . . . 23
3.3. Experiencias del mundo real . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1. Fases de redocumentación estructural . . . . . . . . . . . . . . 26
3.4. De lo procedural al paradigma orientado a objetos . . . . . . . . . . . 27
3.5. Trabajos Conexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4. Definición del problema 30

4.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1. Objetivos especı́ficos . . . . . . . . . . . . . . . . . . . . . . . 31
4.2. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5. Desarrollo 33
5.1. Planteamiento de migración . . . . . . . . . . . . . . . . . . . . . . . 33
5.2. Diseño del modelo orientado a objetos . . . . . . . . . . . . . . . . . 35
5.3. Proceso de diseño de diagramas de clases . . . . . . . . . . . . . . . . 36
5.3.1. Identificación de programas principales . . . . . . . . . . . . . 36
5.3.2. Identificación de objetos, métodos y variables . . . . . . . . . 39
5.3.3. Identificación de la relación entre objetos . . . . . . . . . . . . 41
5.3.4. Acoplamiento de variables y métodos en el paradigma orientado
a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4. Diagramas de colaboración . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5. Diagramas de estados . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6. Conclusiones 56
6.1. Trabajos a futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A. Diagramas de colaboración 58
v
B. Diagramas de estado 67
vi
Lista de figuras
1.1. Comparación entre la descomposicón orientada a objetos y la descom-

posición orientada a funciones. . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Un árbol de decisión para la autorización de un préstamo. . . . . . . 10

2.2. Definición de clases y atributos en el ejemplo labor-neg . . . . . . . . 14
2.3. Salida de C4.5 sobre datos labor-neg . . . . . . . . . . . . . . . . . . 15
2.4. Forma grafica del árbol de decisión para el ejemplo labor-neg . . . . . 16
5.1. Estrategias de migración al paradigma orientado a objetos. . . . . . . 34

5.2. Diagrama de secuencia para el sistema C4.5. . . . . . . . . . . . . . . 37
5.3. Lista del conjunto de programas de C4.5. . . . . . . . . . . . . . . . . 38
5.4. Relación de los 4 programas principales con los demás programas en
C4.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.5. Ejemplo de transformación de funciones en el formato K&R al formato
de métodos en el POO. . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.6. Correspondencia de un archivo fuente C con un objeto. . . . . . . . . 40
5.7. Identificación de las relaciones entre objetos. . . . . . . . . . . . . . . 41
5.8. Primera aproximación al paradigma orientado a objetos de C4.5. . . . 43
5.9. Cambio de apuntadores por arreglos. . . . . . . . . . . . . . . . . . . 44
5.10. Eliminación de variables externas. . . . . . . . . . . . . . . . . . . . . 45
5.11. Objetos derivados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.12. Diagrama de clases para el generador de árboles de decisión (C4.5). . 48
5.13. Diagrama de clases para el generador de reglas de producción (C4.5rules). 49
vii
5.14. Diagrama de clases para el consultor de árboles de decisión (Consult). 50
5.15. Diagrama de clases para el consultor de reglas de producción (Consultr). 51
5.16. Correspondencia de los 4 programas principales con los diagramas de
colaboración. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.17. Proceso de obtención de los diagramas de colaboración. . . . . . . . . 54
5.18. Correspondencia de un diagrama de estados con el código fuente. . . 55
A.1. Diagrama de colaboración para el generador de árboles de decisión

(C4.5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.2. Continuación del diagrama de colaboración para el generador de árbo-
les de decisión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
les de decisión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
les de decisión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.5. Diagrama de colaboración para el generador de reglas de producción
(C4.5rules). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
A.6. Continuación del diagrama de colaboración para el generador de reglas
de producción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.7. Diagrama de colaboración para el consultor de árboles de decisión
(Consult). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.8. Diagrama de colaboración para el consultor de reglas de producción
(Consultr). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B.1. Método main de la clase C4.5 . . . . . . . . . . . . . . . . . . . . . . 68

B.2. Método readName de la clase GetNames . . . . . . . . . . . . . . . . 68
B.3. Método getNames de la clase GetNames . . . . . . . . . . . . . . . . 69
viii
Prefacio
La cantidad de información almacenada en todo el mundo ha rebasado la capaci-
dad humana para su análisis. Por tal razón, ha surgido un nuevo enfoque de análisis
de información denominado minerı́a de datos.
Motivación Personal
Este trabajo de tesis surge a partir de mi interés en la minerı́a de datos. Inicial-
mente estuve interesado en realizar un sistema para el diagnostico de enfermedades
respiratorias de forma inductiva, utilizando para su programación Redes Bayesianas.
Sin embargo, se presentaron ciertas complicaciones para la realización de dicho siste-
ma, entre ellas la obtención de datos.
Posteriormente tuve la oportunidad de iniciar un trabajo de tesis con el M. C.
Ricardo Solano Monje, el cual consistı́a en Migrar el conjunto de programas C4.5
al paradigma orientado a objetos en el lenguaje de programación Java, como parte
de mantenimiento al sistema. Dicho trabajo cumplı́a con mis intereses personales y
decidı́ iniciar a leer la información necesaria para realizar el trabajo planteado.
Desde luego acepte la propuesta del trabajo de tesis y continué con las actividades
pertinentes. No obstante, durante la definición precisa del trabajo de tesis fue nece-
sario realizar modificaciones que condujeron a documentar el conjunto de programas
C4.5 en un modelo conceptual dando como resultado el trabajo descrito en esta tesis
de licenciatura.
Organización de la tesis
Nuestro trabajo se encuentra organizado de la siguiente manera. En el Capı́tulo
1, damos una introducción que describe de manera general el interés de esta tesis. En
el Capı́tulo 2, presentamos los principales conceptos necesarios para la comprensión
ix
de los temas básicos tratados en nuestro trabajo. En el Capı́tulo 3, damos una idea
de los trabajos relacionados con la evolución y redocumentación de sistemas. En el
Capı́tulo 4, describimos la definición del problema, ası́ como también, la definición de
objetivos. En el Capı́tulo 5, mostramos detalladamente lo forma de obtención de un
modelo conceptual para el conjunto de programas C4.5. Finalmente en el Capı́tulo 6,
presentamos nuestras conclusiones y posibles trabajos a futuro que pueden surgir de
este trabajo de tesis.
Javier Juárez Palma

Asesor: M. C. Ricardo Solano Monje
Apizaco, Tlax., Junio del 2005
x
Agradecimientos
A mi tı́o Lorenzo
que con su apoyo mis estudios
de licenciatura fueron más
fáciles de realizar
A toda mi familia
por haber confiado todo el
tiempo en mi
A todos mis profesores

en especial a:
MC. Ricardo Solano Monje, MC. Leticia
Flores Pulido, MC. Orion Fausto Reyes Galaviz
y MC. Marva Angélica Mora Lumbreras
por haber dedicado un poco de su
valiso tiempo en la realización
de éste trabajo
xi
Resumen
La tecnologı́a actual ha permitido el desarrollo de aplicaciones computacionales
para el apoyo en la toma de decisiones.
C4.5 es una aplicación que ha tenido gran éxito para la generación de modelos
en forma de árboles de decisión para la toma de decisiones, dicha aplicación fue
desarrollada desde una perspectiva estructural. Sin embargo, este paradigma tiende
a producir sistemas frágiles y no es factible desechar un sistema y reemplazarlo por
otro totalmente nuevo en lugar de reutilizarlo, repararlo o extender su funcionalidad.
Para dar mantenimiento a un sistema durante su evolución, es necesario el cono-
cimiento acerca de su arquitectura, a pesar de esto, C4.5 no cuenta con un modelo
que muestre su arquitectura a nivel conceptual.
Este trabajo de tesis documenta el sistema C4.5 desde una perspectiva orientada
a objetos que permita mostrar las caracterı́sticas esenciales de éste.
Hemos elegido una perspectiva orientada a objetos, debido a que ha demostrando
ser un concepto muy potente y unificador ofreciendo ventajas para evolucionar en el
tiempo, no obstante, se requiere realizar cambios estructurales debido a las diferencias
existentes entre la perspectiva estructural y la perspectiva orientada a objetos.
El diseño del modelo orientado a objetos toma la aproximación de derivar una
estructura de objetos desde la perspectiva estructural actual del sistema.
El modelo generado que documenta el sistema expone la estructura interna del
sistema mediante diagramas de clases, diagramas de colaboración y diagramas de
estados.
xii
Capı́tulo 1
Preliminares
La toma de decisiones constituye una de las tareas más importantes a ser rea-
lizada en una organización, pues es fácil suponer que al tomar decisiones correctas
o incorrectas definirán su futuro. Por ello, el uso de la tecnologı́a computacional ha
incursionado en el desarrollo de aplicaciones de apoyo en la toma de decisiones, me-
diante herramientas de análisis de información para la identificación de patrones.
1.1. Introducción
La mayorı́a de aplicaciones que se han desarrollado para la toma de decisiones
están basadas en la construcción de modelos de conocimiento, usados por un experto
humano, pues en algunos casos, se considera que la tarea que un experto realiza
es clasificar ejemplos asignando cosas a categorı́as o clases determinadas por sus
propiedades.
Por ejemplo, Quinlan [1] cita un sistema desarrollado por American Express para
asistir a autorizadores de crédito, en dicho sistema se considera el historial de crédito
de un cliente en particular, y las clases correspondientes para aprobar o rechazar la
transacción. En el sistema se analiza una autorización de crédito mediante la clasifi-
cación del cliente y ası́ se autoriza o se rechaza el crédito.
En un modelo de clasificación, la conexión entre clases y propiedades puede estar
1
definida por algo tan simple como un organigrama o tan complejo y no estructurado
como un manual de procedimientos. Si restringimos la discusión a modelos ejecutables,
aquellos que puedan ser representados como un programa computacional, hay dos
formas muy diferentes en las cuales pueden ser construidos.
Por una parte, el modelo puede ser obtenido por entrevistar un experto o expertos;
la mayorı́a de sistemas basados en conocimiento han sido construidos de esta manera,
a pesar de las dificultades bien conocidas que acompañan a este tipo de sistemas.
Alternativamente, numerosos registros clasificatorios pueden ser examinados y cons-
truir un modelo inductivamente, por generalización de ejemplos especı́ficos.
Una forma de identificación y representación de patrones de forma sencilla en el
proceso de descubrimiento de conocimiento son los árboles de decisión, cuyo proceso
se basa en la partición del conjunto de ejemplos, según ciertas condiciones que se
aplican a los valores de los atributos. Una herramienta para la generación de árboles
de decisión que ha tenido gran éxito es el algoritmo ID3 desarrollado por Ross Quinlan
que se basa en la creación del árbol mediante la selección de los atributos que mejor
particionen a los ejemplos, mediante una medida de ganancia de información. Los
nodos del árbol están etiquetados con nombres de atributos, las ramas con los posibles
valores del atributo, y las hojas con las diferentes clases.
Los problemas para los que funcionan los algoritmos de decisión deben tener las
siguientes caracterı́sticas: Casos que son representados por pares atributo-valor, fun-
ciones objetivo que tienen valores de salida discretos, descripciones disyuntivas pue-
den ser requeridas, datos de entrenamiento que pueden contener errores y datos de
entrenamiento que pueden contener valores de atributo perdidos.
Sin embargo, el algoritmo ID3 tiene ciertas deficiencias, como la generación de
árboles muy extensos no comprensibles, además de no considerar atributos con valores
continuos y valores predidos. ID3 ha sido extendido para la eliminación de estos
problemas, teniendo como resultado el sistema C4.5 [1, 2].
C4.5 no es un simple algoritmo, sino más bien está integrado por un conjunto de
programas escritos en el lenguaje de programación C, cuyo funcionamiento es generar
2
árboles de decisión y reglas de producción de manera inductiva a partir de datos de
entrenamiento para un problema especı́fico. En el proceso de generación del árbol se
consideran atributos que tienen valores continuos, además de incorporar el término
de poda para la reducción de árboles muy extensos.
El desarrollo de software involucra enfrentarnos al manejo de cierta complejidad
que se encuentra inherente al problema que intentamos solucionar, según lo menciona
Booch [3], la complejidad se deriva de cuatro elementos:
La complejidad del dominio del problema,
la dificultad de gestionar el proceso de desarrollo,
la flexibilidad que se puede alcanzar a través del software y
los problemas que plantea la caracterización del comportamiento de sistemas

discretos.
Aunado a esto, complejidad adicional es agregada debido a que los requisitos de

un sistema de software cambian frecuentemente. Por otra parte también se menciona
que “Cuanto más complejo sea el sistema, más abierto está al derrumbamiento total”,
produciendo un ciclo de vida del software muy corto.
No podemos permitir desechar software y reemplazarlo con uno totalmente nuevo
en lugar de intentar reutilizarlo, repararlo o extender su funcionalidad, ya que un
sistema grande de software es una inversión considerable, no es admisible el desechar
un sistema existente cada vez que los requerimientos cambian. Previsto o no, los
sistemas grandes tienden a evolucionar en el tiempo.
Durante las ultimas dos décadas, la programación orientada a objetos (POO) ha
llegado a ser un paradigma de programación dominante. Muchos productores de sof-
tware tienen interés en lanzar versiones orientadas a objetos de sus productos, ya que
el modelo de objetos ha demostrado ser un concepto muy potente y unificador, ofre-
ciendo ventajas tales como: la construcción de sistemas que sean duraderos, flexibles
y útiles, interesándose los profesionales de la informática en construir sistemas con
este tipo de caracterı́sticas.
3
Los sistemas orientados a objetos son más resistentes al cambio y por lo tanto
están mejor preparados para evolucionar en el tiempo. En realidad, la descomposición
orientada a objetos reduce en gran medida el riesgo que representa construir sistemas
de software complejos, por que están diseñados para evolucionar de forma incremental
partiendo de sistemas más pequeños en los que ya se tiene certidumbre. Es más,
la descomposición orientada a objetos resuelve la complejidad inherente al software
ayudando a tomar decisiones inteligentes respecto a la separación de actividades en
objetos.
El uso de objetos promueve la reutilización no sólo del software, sino de diseños en-
teros, conduciendo a la creación de marcos de desarrollo de aplicaciones reutilizables,
para la mayorı́a de los lenguajes orientados a objetos dominantes hay un gran núme-
ro incremental de librerı́as que asisten en el desarrollo de aplicaciones para muchos
dominios. Se ha encontrado que los sistemas orientados a objetos son frecuentemente
más pequeños que sus implantaciones equivalentes no orientadas a objetos. Esto no
sólo significa escribir y mantener menos código, sino que la mayor reutilización del
software también se traduce en beneficios de costo y planificación [3].
En el software hay varias formas de enfocar un modelo. Las dos formas más comu-
nes son la perspectiva orientada a objetos y la perspectiva estructural mostradas en
la figura 1.1.
La visión hasta hace algunos años del desarrollo de software tomaba una pers-
pectiva estructural. En este enfoque, el bloque principal de construcción de todo el
software es el procedimiento o función. Esta visión conduce a los desarrolladores a
centrarse en cuestiones de control y de descomposición de algoritmos grandes en otros
más pequeños.
No hay nada inherentemente malo en este punto de vista, salvo que tiende a
producir sistemas frágiles. Cuando los requisitos cambian (¡lo harán!) y el sistema
crece (¡lo hará!), los sistemas construidos con el enfoque algorı́tmico se vuelven muy
frágiles en su mantener.
4
Figura 1.1: Comparación entre la descomposicón orientada a objetos y la descompo-
sición orientada a funciones.
La visión actual del desarrollo de software toma una perspectiva orientada a ob-
jetos. En este enfoque, el principal bloque de construcción de todos los sistemas de
software es el objeto o clase. De forma sucinta, un objeto es una cosa, generalmente
extraı́da del vocabulario del espacio del problema o del espacio de la solución; una
clase es una descripción de un conjunto de objetos similares.
A lo largo de los últimos años, la tecnologı́a orientada a objetos se ha desarrollado
en diferentes segmentos de las ciencias de la computación. La madurez de la ingenierı́a
de software ha conducido al desarrollo de métodos de análisis, diseño y programación
orientados a objetos, todos los cuales tienen la misión de resolver problemas de la
programación a gran escala.
El lenguaje unificado de modelado (UML, Unified Modeling Language) es un len-
guaje gráfico para documentar los artefactos de un sistema con gran cantidad de
software. UML proporciona una forma estándar de escribir los planos de un sistema,
5
con el fin de construir modelos para comprender mejor el sistema que se esta desa-
rrollando. Es decir, construimos modelos de sistemas complejos porque no podemos
comprender el sistema en su totalidad. Cabe mencionar que cualquier proyecto puede
beneficiarse de un modelo conceptual como UML [4].
El modelado es importante, pero hay que recordar que el producto principal de un
equipo de desarrollo es el software, no diagramas. Por supuesto, la razón por la que
se crean modelos es para entregar de forma predecible, en el momento oportuno, el
software adecuado que satisfaga los objetivos cambiantes de los usuarios y la empresa.
Durante la evolución del software se aplican cambios al código fuente, para agregar
funcionalidad, reparar defectos y mejorar su calidad. En sistemas con documentación
pobre, el código es la única fuente de información fiable del sistema, sin embargo, el
código no contiene toda la información necesaria.
Tı́picamente, el conocimiento acerca de la arquitectura, el diseño y el dominio
de la aplicación sólo existe en la mente del diseñador, desafortunadamente con el
tiempo las personas se van, los documentos decaen y la complejidad aumenta. Por
consiguiente, existe un hueco en la comprensión de la información útil conocida y la
información necesaria requerida para reforzar cambios en el software.
El conocimiento de la arquitectura del software desde diferentes perspectivas de
usuario es necesario para hacer cambios estructurales y tener la capacidad de recons-
truir la arquitectura [5]. Diseñar puede ser difı́cil, pero reconstruir y (re)documentar
eficazmente el diseño de un sistema de software existente es aun más difı́cil [6]. Como
resultado, el proceso de ingenierı́a inversa se ha enfocado en el entendimiento del
código. El proceso de ingenierı́a inversa identifica los componentes del sistema actual,
descubre sus dependencias y genera abstracciones para dirigir la complejidad [7].
C4.5 es un sistema creado desde la perspectiva estructural y como se ha mencio-
nado los sistemas creados desde este punto de vista tienden a ser frágiles. Por esta
razón, nos interesa desarrollar un modelo orientado a objetos de C4.5 que permita
mostrar las caracterı́sticas esenciales del sistema, con el fin de dar una comprensión
mas clara de la estructura interna del sistema para propósitos de mantenimiento, ya
6
que no se cuenta con este modelo, este trabajo de tesis propone la extracción del
modelo orientado a objetos a partir de la implementación en C del código existente.
Este proceso comúnmente se le conoce como ingenierı́a inversa, que es el proceso de
transformar código en un modelo a través de una correspondencia con un lenguaje de
programación especı́fico [4].
7
Capı́tulo 2
Marco Teórico
A continuación presentamos un panorama general de los principales conceptos que

se utilizan en el desarrollo de esta tesis, para dar al lector una mejor comprensión y
apreciación del trabajo.
2.1. Minerı́a de datos

La minerı́a de datos o descubrimiento de conocimiento en base de datos, busca pro-
veer de métodos automáticos confiables, que puedan lidiar con la naturaleza creciente
de la información y que también sean capaces de descubrir principios, mecanismos
y causas que se encuentren implı́citamente contenidas en los datos, de manera que
podamos tener un mejor y más profundo conocimiento del fenómeno bajo estudio.
Para lograrlo, esta disciplina combina ideas de diversas áreas, como bases de datos,
estadı́stica, aprendizaje automático e inteligencia artificial, entre otras.
Se denomina minerı́a de datos al conjunto de técnicas y herramientas aplicadas
al proceso no trivial de extraer y presentar un conocimiento implı́cito, previamente
desconocido, potencialmente útil y comprensible por el humano, a partir de gran-
des conjuntos de datos, con objeto de predecir de forma automatizada tendencias,
comportamientos y describir modelos previamente desconocidos.
8
2.2. Árboles de decisión
El aprendizaje con árboles de decisión es uno de los métodos de inferencia inductiva
más usados y practicados. El aprendizaje con árboles de decisión es un método para
aproximar funciones objetivo de valores discretos, en el cual la función objetivo es
representada por un árbol de decisión. Los árboles inferidos también pueden ser re-
representados por un conjunto de reglas If-Then-Else para mejorar la comprensión
humana. Estos métodos de aprendizaje están entre los algortimos más populares
de inferencia inductiva y han sido satisfactoriamente aplicados a una extensa gama
de tareas de aprendizaje, desde casos de diagnostico médico, hasta la evaluación de
riesgos de crédito en una aplicación de préstamo.
2.2.1. Representación de árboles de decisión

Un árbol de decisión es inferido a partir de un conjunto de registros, donde cada
registro tiene la misma estructura, es decir, consiste de un mismo número de pares
atributo/valor. Cada atributo representa una caracterı́stica y uno de estos atributos
representa la categorı́a del registro.
En el árbol de decisión cada nodo corresponde a un atributo y cada arco o rama a
un valor posible de aquel atributo. Una hoja del árbol especifica el valor (categorı́a)
esperado(a) para los registros descritos por la ruta seguida desde el nodo raı́z hasta
el nodo hoja. En el árbol de decisión cada nodo deberá ser asociado a un atributo
categórico, el cual contenga la mayor parte de información de entre los atributos aun
no considerados en la ruta desde el nodo raı́z.
Un árbol de decisión es un árbol en el cual cada rama representa una selección entre
un número de alternativas, y cada nodo hoja representa una clasificación o decisión.
Los árboles de decisión clasifican ejemplos al ordenar estos en forma descendente en
un árbol desde un nodo raı́z a algún nodo hoja, el cual proporciona la clasificación del
ejemplo. Cada nodo en el árbol especifica una prueba de algún atributo del ejemplo,
y cada rama descendiente del nodo corresponde a uno de los posibles valores para
9
Figura 2.1: Un árbol de decisión para la autorización de un préstamo.
ese atributo. Un ejemplo es clasificado al realizar una serie de pruebas para cada
atributo, iniciando en el nodo raı́z del árbol, y siguiendo la rama del valor para el
atributo especificado por este nodo, entonces se continúa el proceso de prueba para
el nodo que continua en la rama correspondiente al valor del atributo hasta alcanzar
un nodo hoja.
La figura 2.1 muestra un árbol de decisión para asistir a una institución financiera
en la realización de un préstamo a un persona. El árbol de decisión clasifica la rea-
lización del préstamo de acuerdo a los ingresos del aspirante, antecedentes penales,
años en su empleo y el pago de sus tarjetas de crédito. Por ejemplo para el caso
(Ingreso del aspirante = $35000, años en su empleo = 3, ¿paga sus tarjetas de crédi-
to? = si)
10
Se realizan las pruebas en los nodos correspondientes comenzando en el nodo de
¿Ingresos del aspirante?, se sigue la rama de en medio y ası́ sucesivamente, hasta
alcanzar la hoja “Prestar”, que en este caso es la categorı́a o resultado del árbol.
En general los árboles de decisión representan una disyunción de uniones de res-
tricciones sobre los valores de los atributos de ejemplo. Cada ruta de la raı́z del árbol
a una hoja corresponde a una unión de atributos de prueba, y el árbol mismo a una
disyunción de estas uniones.
2.2.2. Problemas apropiados para el aprendizaje con árboles

de decisión
A pesar de que una variedad de métodos de aprendizaje con árboles de decisión han
sido desarrollados con algunas capacidades y requerimientos diferentes, el aprendizaje
con árboles de decisión está generalmente mejor preparado para problemas con las
siguientes caracterı́sticas [2]:
Casos que son representados por pares atributo-valor. Los ejemplos son descritos
por un conjunto fijo de atributos (p.e. Temperatura) y sus valores (p.e. caliente).
La situación más fácil para el aprendizaje con árboles de decisión es cuando cada
atributo toma un número pequeño de valores posibles.
La función objetivo tiene valores de salida discretos. Los métodos de árboles de

decisión fácilmente se extienden a funciones de aprendizaje con más de dos
valores de salida. Una extensión más sustancial permite aprender funciones
objetivo con valores de salida reales.
Como notamos arriba, los árboles de decisión naturalmente representan expre-

siones disyuntivas.
Los datos de entrenamiento pueden contener errores. Los métodos de apren-

dizaje con árboles de decisión son robustos a errores, tanto en errores de los
11
ejemplos de clasificación, como en los valores de los atributos que describen
estos ejemplos.
Los datos de entrenamiento pueden contener valores de atributo omitidos. Los

métodos de árboles de decisión pueden ser usados aún cuando algunos ejemplos
de entrenamiento tienen valores desconocidos.
Muchos problemas prácticos han sido encontrados para ajustar estas caracterı́sti-
cas. El aprendizaje con árboles de decisión ha sido aplicado por consiguiente a proble-
mas tales como aprendizaje para clasificación médica de pacientes por sus sı́ntomas,
en mal funcionamientos de equipo por sus causas, en aplicaciones de préstamo por
sus posibilidades predefinidas de pago. Tales problemas en los cuales la tarea es la
clasificación de ejemplos dentro de una categorı́a posible, de valores discretos, son
referidos a menudo como problemas de clasificación.
2.2.3. C4.5
Este conjunto de programas genera un clasificador en la forma de un árbol de
decisión, estructurado como sigue:
Una hoja, indica una clase, o
Un nodo de decisión que especifica una prueba a llevarse a cabo sobre un valor
de atributo simple, con una rama y subárbol para cada salida posible de la
prueba.
El sistema C4.5 consiste de cuatro programas principales.
1. El generador de árbol de decisión (‘C4.5’)
2. El generador de reglas de producción (‘C4.5rules’)
3. El interprete de árboles de decisión (‘consult’), y
12
4. El interprete de reglas de producción (‘consultr’)
A continuación se describe un ejemplo de ejecución aplicado al sistema, para

mostrar al lector la forma de funcionamiento de C4.5.
Ejemplo: Negociación del pago de mano de obra
La Universidad de California en Irvine guarda una librerı́a accesible públicamente

de bases de datos que han sido usadas en experimentos aprendizaje-maquina.1 Una
de estas, proporcionada por Stan Matwin de la Universidad de Ottawa, involucra el
resultado de la negociación de contratos Canadienses en 1987-1988. La información
proporcionada contiene datos utilizados para describir un contrato aceptado o no. A
partir de un numero de casos, el sistema puede construir un modelo de clasificación
que relacione la aceptabilidad de un contrato con los valores de las propiedades de
los registros.
Todas las tareas a ser procesadas por el sistema C4.5 necesitan un nombre breve; en
este caso ha sido llamado labor-neg. El primer paso es definir las clases y los atributos
en un archivo llamado labor-neg.names como se muestra en la figura 2.2.
El siguiente paso es proporcionar información de los casos individuales, esto in-
volucra separar los valores de los atributos por una coma y seguidos por la clase del
caso. Tres de los casos para este ejempo son:
2,2.5,3.0,?,?,40,none,?,?,?,11,below average,?,?,?,?,bad
2,4.5,4.0,?,?,40,?,?,4,?,10,generous,?,half,?,full,good
1,6.0,?,?,?,38,?,8,3,?,9,generous,?,?,?,?,good
Hay 57 casos como estos en la base de datos. En este ejemplo 40 de los casos han
sido seleccionados aleatoriamente para formar un conjunto de entrenamiento desde los
cuales el clasificador será construido, 17 de los casos son reservados para un conjunto
de prueba. Los casos de entrenamiento son colocados en el archivo labor-neg.data, y
los de prueba en labor-neg.test. El comando de UNIX
1
Estas bases de datos pueden ser obtenidas en ftp://ftp.ics.uci.edu/pub/machine-learning-
databases
13
Figura 2.2: Definición de clases y atributos en el ejemplo labor-neg
C4.5 -f labor-neg -u
invoca C4.5 con la opción -f dando el nombre de la tarea o archivo y la opción -u

indicando que el clasificador será probado con casos inadvertidos. La salida del gene-
rador del árbol de decisión para este ejemplo aparece en la figura 2.3. Tal estructura
no puede ser observada como un árbol, en consecuencia, mostramos una forma gráfica
más usual en la figura 2.4.
2.3. El lenguaje unificado de modelado

El lenguaje unificado de modelado (UML) es un lenguaje gráfico para visualizar,
especificar, construir y documentar los artefactos de un sistema con gran cantidad de
software. UML proporciona una forma estándar de escribir los planos de un sistema,
cubriendo tanto las cosas conceptuales, tales como procesos del negocio y funciones
del sistema, como las cosas concretas, tales como las clases escritas en un lenguaje
de programación especı́fico, esquemas de bases de datos y componentes de software
15
Figura 2.3: Salida de C4.5 sobre datos labor-neg

Figura 2.4: Forma grafica del árbol de decisión para el ejemplo labor-neg
reutilizables.
UML es un lenguaje para:
Visualizar
Especificar
Construir
Documentar
A través del modelado, conseguimos cuatro objetivos [4]:
1. Los modelos nos ayudan a visualizar cómo se desea que sea el sistema.
2. Los modelos nos permiten especificar la estructura o el comportamiento de un

sistema.
16
3. Los modelos nos proporcionan plantillas que nos guı́an en la construcción de un
sistema.
4. Los modelos documentan las decisiones que hemos adoptado.
Cualquier proyecto puede beneficiarse del modelado. Incluso en el dominio de

software desechable donde a veces es más efectivo deshacerse del software inadecuado.
La productividad ofrecida por los lenguajes de programación visuales ayuda al equipo
de desarrollo a visualizar mejor el plano de su sistema y a permitirles desarrollar más
rápidamente al ayudarles a construir el producto apropiado.
Todos los sistemas interesantes y útiles tienen una tendencia natural a hacerse
más complejos con el paso del tiempo. Ası́ que, aunque al inicio se pueda pensar que
no es necesario modelar, cuando el sistema evolucione se lamentará esa decisión y
entonces será demasiado tarde.
2.4. Ingenierı́a directa e inversa

La ingenierı́a directa es el proceso de transformar un modelo en código a través de
una correspondencia con un lenguaje de implementación. La ingenierı́a directa pro-
duce una pérdida de información, porque los modelos escritos en UML son semántica-
mente más ricos que cualquier lenguaje de programación orientado a objetos actual.
De hecho, esta es una de las razones principales por las que se necesitan modelos
además del código. Las caracterı́sticas estructurales, tales como las colaboraciones, y
las caracterı́sticas de comportamiento, tales como las interacciones, pueden visuali-
zarse claramente en UML, pero no tan claramente a partir de simple código fuente.
La ingenierı́a inversa es el proceso de transformar código en un modelo a través
de una correspondencia con un lenguaje de programación especı́fico. La ingenierı́a
inversa produce un aluvión de información, alguna de la cual está a un nivel de
detalle más bajo del que se necesita para construir modelos útiles. Al mismo tiempo,
la ingenierı́a inversa es incompleta. Hay una pérdida de información cuando se hace
ingenierı́a directa de modelos a código, ası́ que no se puede recrear completamente
17
un modelo a partir de código a menos que las herramientas incluyan información en
los comentarios del código fuente que vaya más allá de la semántica del lenguaje de
implementación.
La combinación de estas dos vı́as de generación de código y de ingenierı́a inversa
produce una ingenierı́a de “ida y vuelta”, entendiendo por esto la posibilidad de traba-
jar en una vista grafica o textual, mientras las herramientas mantienen la consistencia
entre las dos vistas.
2.5. Diagramas de clases

Los diagramas de clases son los más utilizados en el modelado de sistemas orien-
tados a objetos. Un diagrama de clases muestra un conjunto de clases, interfaces y
colaboraciones, ası́ como sus relaciones. Los diagramas de clases se utilizan para mo-
delar la vista de diseño estática de un sistema. Principalmente, esto incluye modelar
el vocabulario del sistema, modelar las colaboraciones o modelar esquemas.
Los diagramas de clases son importantes no sólo para visualizar, especificar y
documentar modelos estructurales, sino también para construir sistemas ejecutables,
aplicando ingenierı́a directa e inversa.
Para indicar de qué manera los objetos se conectan entre sı́ a través de atributos,
una lı́nea con una flecha en la punta indicará un atributo.
El diagrama de clases del diseño describe gráficamente las especificaciones de las
clases de software y de las interfaces (las de Java, por ejemplo) en una aplicación.
Normalmente contiene la siguiente información:
Clases, asociaciones y atributos
Interfaces, con sus operaciones y constantes
Métodos
Información sobre los tipos de los atributos
18
Navegabilidad
Dependencias
2.6. Diagramas de interacción

Los diagramas de secuencia y los diagramas de colaboración (ambos llamados
diagramas de interacción) son dos de los cinco tipos de diagramas de UML que se
utilizan para modelar los aspectos dinámicos de los sistemas. Un diagrama de interac-
ción muestra una interacción, que consiste en un conjunto de objetos y sus relaciones,
incluyendo los mensajes que se pueden enviar entre ellos.
Los diagramas de interacción no son solo importantes para modelar los aspectos
dinámicos de un sistema, sino también para construir sistemas ejecutables por medio
de ingenierı́a directa e inversa.
Un diagrama de interacción muestra una interacción, que consta de un conjunto
de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos.
Un diagrama de secuencia es un diagrama de interacción que destaca la ordenación
temporal de los mensajes. Gráficamente, un diagrama de secuencia es una tabla que
representa objetos, dispuestos a lo largo del eje X, y mensajes, ordenados según se
suceden en el tiempo, a lo largo del eje Y. Un diagrama de colaboración es un diagrama
de interacción que destaca la organización estructural de los objetos que envı́an y
reciben mensajes. Gráficamente, un diagrama de colaboración es una colección de
nodos y arcos [4].
2.6.1. Diagramas de colaboración

El diseño orientado a objetos tiene por objeto definir las especificaciones lógicas del
software que cumplan con los requisitos funcionales, basándose en la descomposición
por clases de objetos. Un paso esencial de esta fase es la asignación de responsabilida-
des entre los objetos y mostrar cómo interactúan a través de mensajes, expresados en
19
diagramas de colaboración. Éstos presentan el flujo de mensajes entre las instancias
y la invocación de métodos.
Los diagramas de colaboración explican gráficamente cómo los objetos interactúan
a través de mensajes para realizar las tareas y las interacciones existentes entre las
instancias (y las clases) del modelo de éstas [4].
2.7. Diagramas de estados

Los diagramas de estados (statechart) son uno de los cinco tipos de diagramas de
UML que se utilizan para el modelado de los aspectos dinámicos de un sistema.
Definición 2.1 Un diagrama de estados muestra un flujo de control entre estados.

Principalmente, muestra el comportamiento que especifica la secuencia de estados
por las que pasa un objeto a lo largo de su vida en respuesta a eventos, junto con
respuestas a esos eventos.
Definición 2.2 Un estado es una condición o situación en la vida de un objeto

durante la cual satisface alguna condición, realiza alguna actividad o espera algún
evento.
Definición 2.3 Un evento es la especificación de un acontecimiento significativo que

ocupa un lugar en el tiempo y en el espacio. En el contexto de los diagramas de estados,
un evento es la aparición de un estimulo que puede activar una transición de estado.
Definición 2.4 Una transición es una relación entre dos estados que indica que un
objeto que está en el primer estado realizará ciertas acciones y entrará en el segun-
do estado cuando ocurra un evento especificado y se satisfagan algunas condiciones
especı́ficas.
Las definiciones anteriores son descritas en [4] y se utilizan para la elaboración de

un diagrama de estados.
20
Capı́tulo 3
Estado del arte
Diversos investigadores se han dado la tarea de explicar la importancia de contar

con modelos que forman parte de la documentación de los sistemas de software, debido
a que la documentación de un sistema, tradicionalmente juega un papel clave como
ayuda en el entendimiento de programas [6]. Sin embargo, en muchas ocasiones no se
cuenta con tal documentación, o ésta se encuentra dispersa en diferentes medios, aun
cuando la documentación es indispensable para el entendimiento de un sistema.
Esto es crucial en la industria del software, para tratar efectivamente con el proble-
ma de la evolución y entendimiento de sistemas de software de legado. La evolución de
sistemas de legado requiere de un conocimiento sustancial de conocimiento acerca del
sistema. A principios de los noventa la necesidad de reingenierı́a de sistemas de legado
ha sido aguda, pero recientemente la demanda se ha incrementado significativamente
[5].
En sistemas de legado de software, uno necesita la documentación que describe los
aspectos de alto nivel sobre la arquitectura de un sistema de software desde múltiples
perspectivas. Una forma de producir tal documentación estructural para sistemas de
software existente, es usar tecnologı́as de ingenierı́a inversa.
Dentro de la ingenierı́a inversa, un modelado de objetos permite a diseñadores y
programadores de software, describir concisamente la esencia del diseño de un sistema.
Extraer automáticamente modelos de objetos desde código puede ser útil por muchas
21
razones: resume la arquitectura del sistema, puede ayudar ha resolver anomalı́as en
el diseño, o a descubrir errores. Un modelado de objetos proporciona a diseñadores
de programas orientados a objetos una forma de documentar concisamente la esencia
del diseño de un sistema [8].
Un modelo de objetos es una representación del estado abstracto de un programa.
Este toma la forma de una grafica cuyos nodos representan un conjunto de objetos,
y cuyos bordes representan relaciones o asociaciones entre objetos. Un modelo de
objetos es una vista de la arquitectura de un sistema, mostrando sus componentes
esenciales y cómo ellos interactúan. En la fase de mantenimiento, un modelo de objetos
es invaluable [9].
El propósito de un modelo es conservar caracterı́sticas seleccionadas de artefactos
del mundo real. Los modelos son usados en la mayorı́a de las disciplinas de ingenierı́a.
Un modelo puede ser una teorı́a matemática, una entidad fı́sica, o la imagen de una
guı́a mental en el cerebro de un diseñador. El propósito de un diseño es facilitar el
análisis, explicita o implı́citamente.
El uso efectivo de abstracciones es la clave de la construcción satisfactoria de
modelos. La construcción de un modelo abstracto, a su vez, es la clave del éxito del
análisis.
Cuando se construye un modelo, un experto lo puede verificar tı́picamente al
consultar con el diseñador del sistema, que es fuente de estudio, o por una lectura
extensa de la documentación del sistema y en algunos casos del código fuente de la
aplicación, para llegar a un entendimiento del diseño proyectado. Este proceso por lo
menos puede tomar dı́as, a menudo semanas y algunas veces meses [10].
Realizar el diseño de un modelo suele ser difı́cil, no obstante reconocer abstraccio-
nes en sistemas del mundo real es tan difı́cil como diseñar abstracciones adecuadas
para un nuevo sistema. Esto es especialmente verdadero para legado de sistemas de
software escritos hace 10-25 años, los cuales están a menudo en condiciones de docu-
mentación pobre. En la evolución de sistemas de legado se requiere un conocimiento
sustancial agrupado.
22
Los trabajos relacionados en el área de obtención de modelos son variados, sin em-
bargo, la mayorı́a de estos tienen un enfoque similar sobre el objetivo de la obtención
de modelos a partir de código fuente. La mayorı́a de trabajos relacionados manejan la
obtención de modelos como un proceso de ingenierı́a inversa para el descubrimiento
y la obtención de artefactos del mundo real, para ser plasmados dichos artefactos en
un modelo que explique desde diferentes perspectivas la arquitectura de un sistema
de software.
3.1. Entendiendo la estructura de sistemas

Es ampliamente aceptado que por encima del 50 % de trabajos en la evolución
de software, están dedicados al entendimiento de programas. La documentación ha
jugado tradicionalmente un papel importante en esta consideración. La mayorı́a de la
documentación de software describe el programa a nivel de algoritmos y estructuras
de datos.
El entendimiento de programas es una problemática especialmente para ingenieros
de software, que son administradores técnicos, responsables del mantenimiento de tal
sistema. La documentación que existe para estos sistemas usualmente describe partes
aisladas de éste; la cual no describe la arquitectura global del sistema. Por otra parte,
la documentación está a menudo dispersa en todo el sistema y sobre diferentes medios,
como consecuencia, esta documentación es abandonada para fines de mantenimiento
[6].
3.2. Usando ingenierı́a inversa para descubrir es-

tructuras de software
Estructuras de software es la colección de artefactos usados por ingenieros cuando
forman modelos mentales de sus sistemas. Estos artefactos incluyen componentes
de software tales como procedimientos, módulos e interfaces; dependencias entre los
23
componentes tales como cliente-proveedor, herencia y flujo de control; y atributos
tales como el tipo de componentes, tamaño de interfaces y longitud de interconexión.
La estructura de un sistema es la organización y la interacción de estos artefactos.
Una técnica de apoyo computacional de la reconstrucción de modelos estructurales
es ingenierı́a inversa.
El proceso de ingenierı́a inversa [6]:
identifica los componentes del sistema actual,
descubre sus dependencias y
genera abstracciones para manejar complejidad.
Este entendimiento puede entonces mejorar el desarrollo subsecuente, y produce una

facilidad de mantenimiento y re-ingenierı́a.
Chikofsky y Cross introducen una taxonomı́a de ingenierı́a inversa y descubrimien-
to de diseños [5]. Ellos definen ingenierı́a inversa como “analizar un sistema objetivo
para identificar sus componentes y dependencias actuales, y extraer y crear abstrac-
ciones de sistemas junto con información de su diseño”.
En la investigación y práctica actual, el enfoque de ingenierı́a inversa y directa es
a nivel de código. Los procesos de ingenierı́a directa engranan hacia producir código
de calidad. Durante la evolución del software, se realizan cambios al código fuente,
para agregar funcionalidad, corregir defectos y mejorar su calidad. En sistemas con
documentación pobre es solo fiable la fuente de información del sistema. Como resul-
tado, el proceso de ingenierı́a inversa se ha enfocado en el entendimiento del código.
Sin embargo, el código no contiene toda la información que es necesaria. Tı́picamente,
el conocimiento acerca de la arquitectura y diseño se encuentran fuera del alcance del
código [5].
El proceso de ingenierı́a inversa identifica los componentes del sistema actual,
descubre sus dependencias y genera abstracciones para dirigir la complejidad [7].
En sistemas con documentación pobre, el código es la única fuente de información
sobre el sistema, como resultado el proceso de ingenierı́a inversa se enfoca en entender
24
el código. Sin embargo, el código no contiene toda la información que necesitamos,
a menos que ésta se encuentre codificada en el código. Por consiguiente, existe un
hueco en la comprensión de la información útil conocida y la información requerida
necesaria para reforzar cambios en el software [9].
3.3. Experiencias del mundo real

Una aproximación desarrollada por el proyecto Rigi –un entorno flexible para el
entendimiento arquitectural– en la Universidad de Victoria [6], se ha aplicado satisfac-
toriamente a diversos sistemas de software del mundo real. Estos incluyen un sistema
de registros fı́sicos paciente-médico (escrito en COBOL), un programa de control pa-
ra un acelerador de partı́culas (escrito en C), y numerosas utilerı́as de UNIX. Esta
experiencia ha demostrado que se pueden producir vistas o modelos que contienen
información desde diferentes perspectivas de usuario.
Los administradores técnicos se han beneficiado de la documentación producida
por el sistema Rigi en varias formas.
Primero, fue posible ver la estructura de software lógica previamente retenida

sólo en la mente del diseñador de los sistemas.
Segundo, las vistas resaltan áreas crı́ticas de la estructura del software que
necesitan más atención, tales como componentes centrales que tienen un gran
número de dependencias casuales.
Tercero, las vistas proporcionan un objetivo básico para discutir y mantener

software, ya que ellos están basados en el código fuente actual.
Cuarto, las vistas verifican que la estructura del software de sus sistemas fue,
al menos, entendible para una experiencia de análisis desde afuera.
Esta aproximación se llego a validar efectivamente cuando tomaron el desafio

de re-documentar SQL/LS, un sistema manejador de bases de datos, que contiene
25
alrededor de 1,300 unidades de compilación, bruscamente esta dividido en 3 sistemas
grandes (y varios pequeños más). Los desarrolladores son forzados a especializarse en
componentes particulares, aun cuando varios componentes interactúan. SQL/DS es
un tı́pico sistema de software de legado.
3.3.1. Fases de redocumentación estructural

En Rigi, la primera fase de redocumentación estructural es automática, esta invo-
lucra un análisis sintáctico en el código fuente del software de legado, para almacenar
los artefactos extraı́dos en un depósito. Esto produce un flujo gráfico del software.
Los administradores técnicos encargados del mantenimiento de software, pueden usar
este flujo gráfico de componentes para representar las dependencias estructurales de
interés, tales como funciones de llamada y datos de acceso.
Para manejar la complejidad, la segunda fase involucra patrones humanos pa-
ra reconocer habilidades y caracterı́sticas de subsistemas independientes del lengua-
je, compuesto de técnicas para generar múltiples capas jerárquicas para niveles de
abstracción más altos. Por ejemplo, el analista puede agrupar funciones dentro de
subsistemas de acuerdo a reglas de negocios o al aceptar principios de software mo-
dularmente, proporcionando las múltiples perspectivas alternativas necesarias para
mantener el software.
Los usuarios pueden especificar cuales artefactos extraer, en varios niveles de deta-
lle. Por ejemplo, una opción selecciona si el análisis sintáctico deberı́a extraer llamadas
a rutinas del sistema. Para entender programas, es importante construir abstracciones
que enfaticen temas importantes y suprima detalles irrelevantes; decidir que incluir
y que ignorar es un arte.
26
3.4. De lo procedural al paradigma orientado a ob-
jetos
El éxito de sistemas de software procedurales llama a su continuo uso y mante-
nimiento. Como Wilde et al. apuntan: “Cualquier sistema de software exitoso en el
futuro entra en una prolongada y costosa fase de mantenimiento, no como consecuen-
cia de fallas, sino de éxito. Si un sistema es exitoso, los usuarios demandaran que este
sea fortalecido y actualizado” [11].
Al diseñar y desarrollar programas orientados a objetos desde una perspectiva
procedural, uno puede experimentar lo que es conocido como “cambio de paradigma”.
Este cambio requiere que, el diseñador no piense en términos de los procedimientos
que un sistema de software debe ejecutar, si no más bien, en términos de las entidades
u objetos que participan en el sistema.
El derivar una estructura de clases desde una perspectiva estructural de un pro-
grama procedural, toma la aproximación de no diseñar estructuras de clases desde el
principio, sino más bien, derivar estas desde la estructura actual del sistema.
Para facilitar la transición de programas procedurales dentro de un estilo orientado
a objetos, Ignacio Silva [11] propone derivar su estructura de clases al considerar sus
estructuras de datos como objetos de alto nivel y transformando procedimientos en
métodos, que serán agregados a los objetos para definir su comportamiento.
Jacobson y Lindströum [12] proponen reingenierı́a a sistemas antiguos dentro de
una arquitectura orientada a objetos en dos pasos fundamentales.
1. Ingenierı́a inversa. Modelado de los sistemas ya desarrollados mediante una

derivación de clases, a partir de las estructuras de datos actuales del sistema.
2. Ingenierı́a directa. Mejoramiento del sistema usando completamente métodos

orientados a objetos.
Por otra parte, en [13] se menciona que una de las formas más comunes de evo-
lución de un sistema, involucra la extensión de un esquema existente, por la adición
27
de nuevas clases de objetos o la adición de atributos a los objetos originales. Algunas
veces, la estructura de clases es reorganizada incluso cuando el conjunto de objetos no
se esta cambiando. En este caso la reorganización puede presentar una optimización
del sistema o sólo un cambio en la perspectiva de usuario. En el otro extremo, una
reorganización de clases no sólo puede reflejar extensión y reclasificación de objetos
existentes, sino también cambios estructurales en los objetos originales.
3.5. Trabajos Conexos

Johannes Martin [14] presenta en su tesis de doctorado un estudio y evaluación
de algunas aproximaciones actuales, para la migración de código fuente a Java. Prin-
cipalmente, se enfoca en el lenguaje de programación C y C++ como el lenguaje
fuente.
Utilizando sus experiencias adquiridas en el estudio realizado, establece un número
de metas para una aproximación de migración mejorada y para desarrollar esta apro-
ximación en el ambiente Ephedra. Proporciona diversas estrategias de transformación,
considerando una conversión de código fuente C a código fuente Java integrando las
estrategias más apropiadas.
Para cada constructor del lenguaje fuente, se plantea una estrategia de conversión
a un constructor simulado o nativo del lenguaje objetivo (Java). Presentando un
catalogo de conversión de los principales constructores más comunes usados en el
lenguaje C.
Considera principalmente tres fases de conversión:
1. Normalización. Es esta fase se realiza una conversión de código C en el estilo

K&R (Kernighan and Ritchie) al estándar ANSI C.
2. Traducción. Durante esta fase se realiza la traducción de código desde C a

Java, por lo tanto, en esta fase se utiliza la aproximación planteada para cada
constructor del lenguaje.
28
3. Optimización. Por último, esta fase realiza un mejoramiento del código fuente
aplicando estrategias de reingenierı́a.
La meta de la aproximación de Johannes Martin [14] es proporcionar una mejor

solución al problema de integración de código fuente C dentro de programas Java.
Esto proporciona una aproximación estructurada para migrar código fuente C a la
Máquina Virtual de Java.
29
Capı́tulo 4
Definición del problema
Como se describió en el Capı́tulo 1, esté o no previsto, los sistemas tienden a

evolucionar en el tiempo, ya sea por agregar funcionalidad al sistema, reparar defec-
tos o simplemente por dar mantenimiento y mejorar la calidad del sistema. Estamos
seguros de que C4.5 es un sistema que no esta exento de cambio, sin embargo, no se
cuenta con un modelo conceptual que permita observar el sistema desde diferentes
perspectivas que capturen las caracterı́sticas esenciales, para la comprensión y man-
tenimiento del sistema. Por esta razón, nos interesa obtener el modelo orientado a
objetos que muestre el comportamiento de C4.5 a nivel conceptual, enfrentándonos a
ciertas dificultades que se describen a continuación.
1. Debido a que existen diferencias notables entre ambas perspectivas de progra-

mación (la orientada a objetos y la estructural1 ) consideramos que no es posible
obtener un modelado directo, limpio y rápido, y que es necesaria una estruc-
turación del sistema que va desde la perspectiva estructural a la perspectiva
orientada a objetos.
2. No se cuenta con información del sistema que describa las caracterı́sticas gene-
rales de su comportamiento, teniendo que enfocarnos únicamente en el código
de C4.5 para la obtención del modelo orientado a objetos.
1
En este caso particular, C4.5 está desarrollado en el lenguaje C.
30
4.1. Objetivo General
Extraer el modelo conceptual orientado a objetos a partir del código en C de
C4.5 que permita documentar de forma concisa la arquitectura desde la vista de
diseño de C4.5.
4.1.1. Objetivos especı́ficos

Separar apropiadamente el conjunto de programas C4.5 en un modelo orientado
a objetos, y obtener los siguientes diagramas:
Diagramas de clases,
Diagramas de colaboración y
Diagramas de estados.
4.2. Hipótesis
Es posible documentar un sistema a partir de su código fuente, mediante la obten-
ción de un modelo conceptual en el paradigma orientado a objetos. Desde el principio,
este modelo puede ser derivado a partir de la estructura actual del sistema haciendo
uso de metodologı́as establecidas.
4.3. Justificación
El modelo del conjunto de programas C4.5 en el paradigma orientado a objetos
nos permitirá obtener un software reutilizable, legible y principalmente mantenible
dentro del ciclo de vida de éste.
Las caracterı́sticas estructurales, tales como las colaboraciones, y las caracterı́sti-
cas de comportamiento, como son las interacciones, pueden visualizarse claramente
en UML, pero no tan claramente a partir del código fuente simple.
31
Debido a que los modelos escritos en UML son semánticamente más ricos que
cualquier lenguaje de programación orientado a objetos actual, se necesitan modelos
además de código. Pues hay una pérdida de información cuando se hace ingenierı́a
directa de modelos a código.
32
Capı́tulo 5
Desarrollo
Hasta ahora hemos descrito la problemática que implica el no tener un modelo

conceptual de C4.5 y el porque debemos de considerar tener este modelo. A partir
de aquı́, se describe la manera en que se obtuvo el modelo conceptual a partir del
código de C4.5, no sin antes mencionar porque se decidió plantear en primer lugar un
modelo y después planteamos como un trabajo a futuro la migración de este modelo
a un lenguaje de programación orientado a objetos, como puede ser Java.
5.1. Planteamiento de migración

Cuando iniciamos este trabajo, nuestro principal objetivo era migrar el conjunto
de programas C4.5, al paradigma orientado a objetos, en el lenguaje de programación
Java. Sin embargo, nos encontramos con la tarea de decidir que camino de los que a
continuación describiremos, deberı́amos de seguir para lograr nuestro objetivo, pues
no es tan fácil migrar de un lenguaje de programación a otro, debido a las diferencias
existentes en ambos lenguajes. Estas estrategias de migración que planteamos son las
mostradas en la figura 5.1.
1. En primer lugar consideramos que a partir del código de C4.5 en el lenguaje de

programación C, realizáramos una traducción automática del código a Java, por
33
Figura 5.1: Estrategias de migración al paradigma orientado a objetos.
medio del uso de un traductor, después de obtener el código en Java, realizar un

mejoramiento de este código, y por ultimo la obtención del modelo conceptual
orientado a objetos. Sin embargo, detectamos que ninguno de los traductores
desarrollados hasta el momento para dichos fines nos era de gran utilidad.
2. En segundo lugar, nos dimos a la tarea de investigar la manera en que funcionan

dichos traductores y determinamos realizar un planteamiento de traducción para
lograr una transcripción del código a Java, a continuación de la obtención del
código obtendrı́amos un modelo casi inmediato posiblemente utilizando una
herramienta CASE.
3. Por último, nuestra decisión tomada y la mas conveniente a nuestro punto de

vista es desarrollar en primer lugar el modelo orientado a objetos del código
de C4.5 que muestre la relación y colaboración entre objetos, para permitir al
lector una fácil y clara comprensión del sistema, para que de esta manera la
transcripción o codificación del código a un lenguaje de programación orientado
34
a objetos sea mas clara y precisa.
Decidimos seguir la tercera aproximación, debido a que es la forma en que lo

exponen Jacobson y Lindströum [12], ya que como se mencionó en la sección 3.4,
primero derivan un modelo aplicando ingenierı́a inversa, y después, se realiza un
mejoramiento del sistema usando completamente métodos orientados a objetos. Cabe
mencionar, que en la aproximación desarrollada en el proyecto Rigi de la Universidad
de Victoria [6], también se realiza en primer lugar la obtención de un modelo para la
comprensión de un sistema en estudio.
5.2. Diseño del modelo orientado a objetos

Cuando se modela un sistema, su modelo puede ser realizado desde diferentes vis-
tas, de hecho se construye el sistema simultáneamente desde múltiples dimensiones.
La vista de modelado debe ser elegida apropiadamente de forma que exprese mejor
la arquitectura del sistema, por medio de los artefactos que capturen los detalles
esenciales de funcionamiento, en mayorı́a de las veces, estos artefactos consistirán de
diagramas UML. Dichos diagramas pasaran a ser parte primordial de la documenta-
ción del sistema. Algunas vistas de modelado mostradas en [4] son:
Vista de casos de uso.
• Diagramas de casos de uso.
• Diagramas de actividades (para modelado del comportamiento).
Vista de diseño.
• Diagramas de clases (para modelado estructural).
• Diagramas de interacción (para modelado del comportamiento).
• Diagramas de estados (para modelado del comportamiento).
Vista de procesos.
35
• Diagramas de clases (para modelado estructural).
• Diagramas de interacción (para modelado del comportamiento).
Vista de implementación.
• Diagramas de componentes.
Vista de despliegue.
• Diagramas de despliegue.
El modelado del conjunto de programas C4.5 hemos decidido realizarlo desde la

vista de diseño, cuyos artefactos o diagramas por los que está compuesta muestran
las caracterı́sticas esenciales del modelo estructural y de comportamiento del sistema.
Dichos diagramas fueron descritos en el Capı́tulo 2.
5.3. Proceso de diseño de diagramas de clases

El proceso de desarrollo para la construcción de los diagramas de clases se realizo
mediante varias fases que son descritas a continuación:
1. Identificación de los 4 programas principales (c4.5, c4.5rules, consult y consultr)

con su respectiva colaboración con los demás programas,
2. Identificación de posibles objetos, ası́ como también sus variables y métodos,
3. Identificación de la colaboración entre objetos y
4. Acoplamiento de variables y métodos en el paradigma orientado a objetos.
5.3.1. Identificación de programas principales

Como se mencionó en el Capı́tulo 2, C4.5 consiste de 4 programas principales,
dichos programas colaboran con los demás para realizar una tarea especı́fica a petición
36
Figura 5.2: Diagrama de secuencia para el sistema C4.5.
del usuario, en particular, las tareas que son ejecutadas por cada programa principal
son:
la generación de árboles de decisión,
la generación de reglas de producción,
la interpretación o prueba de árboles de decisión y
la interpretación o prueba de reglas de producción.
La forma en que fluyen los eventos que pasan del usuario al sistema los podemos
observar en el diagrama de secuencia de la figura 5.2.
En general, C4.5 consta de los programas listados en la figura 5.3. A partir de saber
que el sistema consiste de 4 programas principales, nos enfocamos en la identificación
de la colaboración de cada uno de estos con los demás programas, dicha identificación
se logro a partir del archivo makefile en el que se describen sus relaciones con los demás
archivos o programas. Para cada uno de los 4 programas principales mostramos su
relación con los demás programas en la figura 5.4.
37
Figura 5.3: Lista del conjunto de programas de C4.5.
Figura 5.4: Relación de los 4 programas principales con los demás programas en C4.5.
38
5.3.2. Identificación de objetos, métodos y variables
Según la aproximación de Ignacio Silva [11], derivar una estructura de clases desde
una perspectiva estructural, no se debe realizar desde un principio, sino más bien, se
deriva desde la estructura actual del sistema. Por tal motivo, seguimos esta aproxi-
mación para realizar el modelo conceptual de C4.5.
Un objeto es una cosa, generalmente extraı́da del vocabulario del espacio del pro-
blema o del espacio de la solución,en este sentido, todo objeto tiene identidad (puede
nombrarse o distinguirse de alguna manera de otros objetos), estado (generalmente
hay algunos datos asociados a él), y el comportamiento (se le puede hacer cosas al
objeto, y él a su vez puede hacer cosas a otros objetos).
Para la identificación de objetos en el dominio del sistema C4.5, nos basamos en
la aproximaciones expuestas por Ignacio Silva [11] y Johannes Martin [14], en donde
se expone de forma similar que un programa C consta de uno o más archivos de
código fuente, de la misma forma, un programa en el paradigma orientado a objetos
puede estar constituido por una o más clases. A cada archivo o programa fuente C lo
asociamos con una clase u objeto, cuya identidad es el nombre del archivo fuente C,
los métodos y variables que contiene este objeto son aquellos que se encuentran en el
mismo archivo.
En la fase de normalización, seguida en la aproximación de Johannes Martin [14],
se realiza una transformación de funciones del código en el formato K&R al formato
de un método, esta correspondencia de código se puede observar en la figura 5.5 y
será aplicada en cada una de las funciones del código fuente en C con el fin de mostrar
la forma adecuada en el correspondiente diagrama de clases.
La forma que ha tomado hasta aquı́ cada clase se puede observar en la figura
5.6. Como podemos ver, aún no se encuentra cada clase en la manera adecuada,
prácticamente ha sido tomado directamente del código fuente C, con la definición de
variables apuntador, los métodos empiezan con mayúscula y el nombre del objeto
con minúscula. Una fase posterior realiza y explica la adaptación de este objeto al
paradigma orientado a objetos.
39
Figura 5.5: Ejemplo de transformación de funciones en el formato K&R al formato
de métodos en el POO.
Figura 5.6: Correspondencia de un archivo fuente C con un objeto.
40
Figura 5.7: Identificación de las relaciones entre objetos.
5.3.3. Identificación de la relación entre objetos

Durante esta fase, realizamos una revisión total del código fuente para identificar
las llamadas a funciones (métodos) que son externas a un archivo. Es decir, aquellas
funciones que no son locales y se encuentran en algún otro archivo fuente pero que
interactúan entre si para realizar una tarea o actividad especı́fica. Esto implica que
existe una relación entre estos archivos (clases en nuestro modelo orientado a objetos)
como se ha planteado y que estas relaciones deben ser mostradas en el diagrama de
clases. Un ejemplo de estas relaciones puede ser visualizado en la figura 5.7.
Después de haber realizado la identificación de objetos, sus correspondientes méto-
dos y variables, además de la identificación de sus relaciones con otros objetos, estamos
41
preparados para presentar una primera aproximación al paradigma orientado a ob-
jetos. Este diagrama se presenta en la figura 5.8, sin embargo no es un diagrama de
clases final, pues aún falta realizar un refinamiento de éste para alcanzar un diagrama
de clases concreto.
5.3.4. Acoplamiento de variables y métodos en el paradigma

orientado a objetos
Durante la fase final de desarrollo de los diagramas de clase para los 4 programas
principales de C4.5, principalmente nos enfocamos en el refinamiento del diagrama
presentado en la figura 5.8 y los 3 diagramas correspondientes a los otros tres pro-
gramas principales. En este refinamiento se considera la aproximación tomada por
Johannes Martin [14], para la correspondencia de los principales constructores del
lenguaje C:
Cambio de variables apuntador en los objetos. La correspondencia del lengua-

je de programación para el cual proponemos el diagrama de clases es Java. El
manejo de apuntadores en C es distinto al manejo de referencias en Java. Por
lo que es necesaria la eliminación del uso extenso de variables apuntador, que
se han integrado al diagrama de la figura 5.8. Notamos que principalmente el
uso de estas variables apuntador es para la asignación dinámica de memoria, y
a su vez sean tratadas como arreglos. Por esta razón, se sustituye la definición
de estas variables por la definición de arreglos como es mostrado en la figura
5.9.
Eliminación de variables externas. La definición de variables externas en el códi-

go fuente c se realiza con la intención de decir al compilador que la variable
será utilizada en el archivo o programa actual pero que se encuentra definida
en otro archivo. Para el caso del paradigma orientado a objetos no es necesaria
esta definición, pues solo basta con utilizar la variable externa por medio de
una referencia al objeto en el que se encuentra definida, esta caracterı́stica se
42
Figura 5.8: Primera aproximación al paradigma orientado a objetos de C4.5.
43
Figura 5.9: Cambio de apuntadores por arreglos.
ilustra en la figura 5.10 y por razones obvias son eliminadas del diagrama de
clases en cada objeto que contiene este tipo de variables. Además, el archivo
extern.i al igual que el archivo buildex.i desaparecen debido a que su contenido
es únicamente la definición de variables externas.
Normalización de nombre de objetos, métodos y variables. El paradigma orien-

tado a objetos se caracteriza por estandarizar la definición de nombres de va-
riables, métodos y objetos. Un objeto debe tener un nombre que inicie con una
letra mayúscula, un método y una variable deben iniciar con una letra minúscu-
la, y en cualquier caso la unión de dos o más palabras es identificada por una
mayúscula al inicio de palabra continua. En el caso del diagrama de la figura 5.9
no se cumple con estos requerimientos y es necesaria la corrección mencionada.
Estos se ven reflejados en los diagramas de clases finales de las figuras 5.12,
5.13, 5.14 y 5.15.
44
Figura 5.10: Eliminación de variables externas.
Cambio de tipos y objetos derivados. El lenguaje de programación C soporta

la definición de tipos derivados. Ambos tipos, fundamentales y derivados pue-
den tener nombres adicionales usando el mecanismo typedef. En el paradigma
orientado a objetos, la definición de un tipo derivado como por ejemplo una es-
tructura o unión, en la aproximación de Johannes Martin [14] es transformado a
un objeto y las referencias a los nombres adicionales de un tipo son cambiadas
para referir a los nombres o tipos originales. En nuestro caso hemos seguido
esta aproximación y los tipos derivados principalmente los hemos obtenido del
archivo types.i, el cual es sustituido por los objetos derivados. Un objeto más,
derivado del conjunto de programas C4.5 es el archivo defns.i, el cual contiene
la definición de algunas macros y constantes. Las constantes pasan a ser va-
riables del objeto junto de algunas constantes definidas en el archivo types.i,
y algunas de las macros se representa como métodos en el objeto. Lo descrito
anteriormente lo podemos observar en la figura 5.11.
45
Figura 5.11: Objetos derivados.
46
Finalmente, después de realizar los cambios mencionados anteriormente, hemos
logrado desarrollar los 4 diagramas de clases para los 4 programas principales corres-
pondientes a C4.5, estos diagramas se muestran en las figuras 5.12, 5.13, 5.14 y 5.15.
5.4. Diagramas de colaboración

En cualquier sistema, los objetos interactúan entre sı́ pasándose mensajes. Una
interacción es un comportamiento que incluye un conjunto de mensajes intercambia-
dos por un conjunto de objetos dentro de un contexto para lograr un propósito. Un
mensaje es la especificación de una comunicación entre objetos que transmite infor-
mación, con la expectativa de que se desencadene una actividad. Las interacciones
se utilizarán para modelar los aspectos dinámicos de las colaboraciones, que repre-
sentan sociedades de objetos que juegan roles especı́ficos, y colaboran entre sı́ para
llevar a cabo un comportamiento mayor que la suma de los comportamientos de sus
elementos. Un diagrama de interacción muestra una interacción, que consiste en un
conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar
entre ellos. Un diagrama de colaboración es un diagrama de interacción que destaca la
organización estructural de los objetos que envı́an y reciben mensajes, principalmente
estos mensajes provocan la invocación de métodos entre instancias.
Los diagramas de interacción constituyen uno de los artefactos más importantes
que se generan en el análisis y el diseño orientados a objetos. Por lo tanto, formal parte
esencial de la documentación del sistema. Según [15] el tiempo y el esfuerzo dedicados
a su preparación deberı́an absorber un porcentaje considerable de la actividad total
destinada del proyecto. Para elaborar un diagrama de colaboración podemos encontrar
en [15] las siguientes normas:
Para preparar un diagrama de colaboración:
1. Elabore un diagrama por cada operación del sistema durante el ciclo actual de
desarrollo.
En cada mensaje, dibuje un diagrama incluyéndolo como mensaje inicial.
47
Figura 5.12: Diagrama de clases para el generador de árboles de decisión (C4.5).
48
Figura 5.13: Diagrama de clases para el generador de reglas de producción (C4.5rules).
49
Figura 5.14: Diagrama de clases para el consultor de árboles de decisión (Consult).
50
Figura 5.15: Diagrama de clases para el consultor de reglas de producción (Consultr).
51
2. Si el diagrama se torna complejo (por ejemplo, si no cabe holgadamente en una
hoja de papel de 8.5 x 11), divı́dalo en diagramas más pequeños.
3. Diseñe un sistema de objetos interactivos que realicen las tareas especı́ficas.
Según se planteó en la sección 5.2, el modelo orientado a objetos de C4.5 también

esta formado por los diagramas de colaboración correspondientes al sistema, para
mostrar los aspectos dinámicos de las colaboraciones entre objetos y realizar las tareas
especificas en la construcción y consulta de árboles de decisión y reglas de producción.
Hasta aquı́ hemos identificado la relación existente entre objetos, apreciables estas
relaciones en los diagramas de clases. Ahora hemos comprendido la importancia de
los diagramas de colaboración en la documentación de un sistema, por lo que es
necesaria su obtención a partir del código fuente.
El diseño de los diagramas de colaboración consta de 4 diagramas principales,
observando su correspondencia en la figura 5.16. Sin embargo cada uno de estos 4
diagramas se torna complejo y no es apropiado mostrarlo en un solo bloque. Siguien-
do las normas de construcción de un diagrama de colaboración, cada uno de ellos ha
sido dividido en diagramas más pequeños para una fácil presentación y comprensión.
El proceso de desarrollo para la obtención de estos diagramas es similar al de los dia-
gramas de clases, al hacer una revisión total del código fuente e identificar las llamadas
a métodos que no son propios del objeto, tomando en cuenta que dichos métodos se
encuentran en otra clase, se modelan como mensajes que son intercambiados por am-
bos objetos. Este proceso de modelado es mostrado en la figura 5.17, agregando un
fragmente de código fuente Java para ilustrar de forma concisa la localización de un
método en una instancia.
A continuación se presentan los diagramas de colaboración en las figuras A.1,
A.2, A.3, A.4, A.5, A.6, A.7 y A.8. Desarrollados a partir del código fuente en C del
conjunto de programas C4.5.
52
Figura 5.16: Correspondencia de los 4 programas principales con los diagramas de
colaboración.
5.5. Diagramas de estados

Los diagramas de estados (statechart) se utilizan para el modelado de los aspectos
dinámicos de un sistema. Un diagrama de estados muestra el flujo de control entre
estados.
Hemos explicado en la sección 2.7 las principales definiciones que involucran el
desarrollo de los diagramas de estados, estas definiciones son: 2.2, 2.3 y 2.4.
Al igual que los diagramas de clases y de colaboración, los diagramas de estados
forman parte de la vista de diseño de un modelo, que es la vista de modelado que
se desarrolla en este trabajo de tesis. Por lo tanto, también hemos desarrollado los
diagramas de estados correspondientes al código fuente de C4.5. Estos diagramas se
han desarrollado para cada método en un objeto, puesto que muestran la secuencia
de estados por las que pasa cada método de un objeto a lo largo de su vida, en este
caso, modelamos la secuencia de estados por la que pasa cada uno de los métodos en
respuesta a un evento.
Este procedimiento lo podemos ver en la figura 5.18. Principalmente identificamos
a cada estado como aquel que realiza una actividad y satisface alguna condición, un
53
Figura 5.17: Proceso de obtención de los diagramas de colaboración.
54
Figura 5.18: Correspondencia de un diagrama de estados con el código fuente.
evento como aquel acontecimiento que especifica que la tarea ha sido realizada y el
estado se encuentra en espera de una transición, las transición es aquella que especifica
la realización de otra actividad en un siguiente evento que cumpla las condiciones
indicadas.
Finalmente, los diagramas de estados obtenidos desde el código fuente C del con-
junto de programas C4.5 son presentados en la siguientes páginas en la figura B.1.
55
Capı́tulo 6
Conclusiones
Hemos logrado la obtención del modelo conceptual orientado a objetos en la vista

de diseño, desde el código fuente de C4.5, que permite documentar el sistema de
forma concisa, mostrando las dependencias estructurales existentes en una estructura
orientada a objetos.
Para la creación del modelo utilizamos algunas aproximación que nos han sido
muy útiles en la realización de nuestro trabajo, por lo tanto, no fue necesario su
desarrollo desde cero. El modelo fue derivado aplicando técnicas de conversión para
las principales estructuras del lenguaje de programación C al paradigma orientado a
objetos.
Las aproximaciones principalmente utilizadas en nuestro trabajo fueron:
Obtención del modelado de un sistema ya desarrollado mediante una derivación
de clases, a partir de las estructuras de datos actuales del sistemas, para después
realizar un mejoramiento del sistema usando métodos completamente orientados a
objetos, expuesto por Jacobson y Lindströum [12].
La derivación de la estructura de clase se realizó al considerar sus estructuras de
datos como posibles objetos de alto nivel y desmontando procedimientos dentro de
sentencias de código que son candidatos viables para llegar a ser métodos ligados a
la estructura de clases, propuesto por Ignacio Silva [11].
56
Las principales estrategias de conversión de código fuente C a estructuras orien-
tadas a objetos fueron obtenidas del trabajo de Johannes Martin [14], utilizando pri-
mordialmente los equivalentes para estructuras, uniones, variables externas y macros
del lenguaje de programación C hacia el paradigma orientado a objetos.
6.1. Trabajos a futuro

Dado que C4.5 es un sistema que ha tenido gran éxito en el aprendizaje artificial
para el desarrollo de aplicaciones en la toma de decisiones. Ahora que contamos con un
modelo conceptual que muestra la arquitectura de alto nivel del sistema, planteamos
como trabajo a futuro los siguientes puntos:
Mejoramiento del sistema aplicando técnicas orientadas a objetos como patrones

de diseño, ası́ como también técnicas de reingenierı́a, las cuales realizan una
modificación de la estructura interna del sistema sin afectar su comportamiento.
Codificación del modelo conceptual de C4.5 en un lenguaje de programación

orientado a objetos como Java.
Considerar la posibilidad de convertir la aplicación C4.5 en un paquete Java, de

forma tal que la tecnologı́a de C4.5 pueda ser incluida en aplicaciones especı́ficas.
Finalemente, podemos comentar que hemos enmarcado los trabajos a futuro como
parte del mantenimiento del software C4.5.
57
Apéndice A
Diagramas de colaboración
58
59
60
Figura A.2: Continuación del diagrama de colaboración para el generador de árboles

de decisión.
de decisión.
61
de decisión.
62
63
64
Figura A.6: Continuación del diagrama de colaboración para el generador de reglas

de producción.
Figura A.7: Diagrama de colaboración para
65 el consultor de árboles de decisión (Con-
sult).
Figura A.8: Diagrama de colaboración para el consultor de reglas de producción
(Consultr).
66
Apéndice B
Diagramas de estado
67
Figura B.1: Método main de la clase C4.5
Figura B.2: Método readName de la clase GetNames
68
Figura B.3: Método getNames de la clase GetNames
69
Referencias
[1] J. R. Quinlan. C4.5: Programs for Machine Learning. Morgan Kaufmann, first
edition, 1993.
[2] Tom Mitchell. Machine Learning. McGraw Hill, 1997.
[3] Grady Booch. Análisis y Diseño orientado a objetos. Addison Wesley Longman,
2nd edition, 1996.
[4] Ivar Jacobson Grady Booch, James Rumbaugh. El lenguaje unificado de mode-
lado. Addison Wesley Iberoamericana, 1999.
[5] Hausi A. Muller, Jens H. Jahnke, Dennis B. Smith, Margaret-Anne D. Storey,

Scott R. Tilley, and Kenny Wong. Reverse engineering: a roadmap. In ICSE —
Future of SE Track, pages 47–60, 2000.
[6] Kenny Wong, Scott R. Tilley, Hausi A. Müller, and Margaret-Anne D. Storey.
Structural redocumentation: A case study. IEEE Software, 12(1):46–54, 1995.
[7] Scott R. Tilley, Kenny Wong, Margaret-Anne D. Storey, and Hausi A. Müller.
Programmable reverse engineering. International Journal of Software Enginee-
ring and Knowledge Engineering, 4(4):501–520, 1994.
[8] Allison Leah Waingold. Automated extraction of abstract object models. Mas-
ter’s thesis, Massachusetts Institute of Technology, May 2001.
70
[9] Daniel Jackson and Allison Waingold. Lightweight extraction of object models
from bytecode. In International Conference on Software Engineering, pages 194–
202, 1999.
[10] G. J. Holzmann. From code to models. pages 3–10, Newcastle upon Tyne, U.K.,
2001.
[11] Ignacio Silva-Lepe. Techniques for Reverse-Engineering and Re-Engineering in-

to the Object-Oriented Paradigm. Doctor of philosophy, College of Computer
Science of Northeastern University, June 1994.
[12] Ivar Jacobson and Fredrik Lindström. Re-engineering of old systems to an object-
oriented architecture. In OOPSLA Conference, Special Issue of SIGPLAN Noti-
ces, pages 340–350, Phoenix, AZ, 1991.
[13] Paul L. Bergstein. Maintenance of object-oriented systems during structural

schema evolution. Theory and Practice of Object Systems, 3(3):185–212, 1997.
[14] Johannes Martin. Ephedra, a C to Java Migration Environment. Doctor of

philosophy, Northern Illinois University, 1996.
[15] Craig Larman. UML y Patrones. Prentice Hall, primera edition, 1999.
71

Modelo Conceptual Del Conjunto de Programas C4.5

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Modelo Conceptual Del Conjunto de Programas C4.5

Încărcat de

Drepturi de autor:

Formate disponibile

MODELO CONCEPTUAL DEL CONJUNTO DE

Tesis sometida a revición al Departamento de Ciencias Básicas, Ingenierı́a y

Mayo del 2005

4. Definición del problema 30

1.1. Comparación entre la descomposicón orientada a objetos y la descom-

2.1. Un árbol de decisión para la autorización de un préstamo. . . . . . . 10

5.1. Estrategias de migración al paradigma orientado a objetos. . . . . . . 34

A.1. Diagrama de colaboración para el generador de árboles de decisión

B.1. Método main de la clase C4.5 . . . . . . . . . . . . . . . . . . . . . . 68

Javier Juárez Palma

A todos mis profesores

La complejidad del dominio del problema,

la dificultad de gestionar el proceso de desarrollo,

la flexibilidad que se puede alcanzar a través del software y

los problemas que plantea la caracterización del comportamiento de sistemas

Aunado a esto, complejidad adicional es agregada debido a que los requisitos de

A continuación presentamos un panorama general de los principales conceptos que

2.1. Minerı́a de datos

2.2.1. Representación de árboles de decisión

2.2.2. Problemas apropiados para el aprendizaje con árboles

La función objetivo tiene valores de salida discretos. Los métodos de árboles de

Como notamos arriba, los árboles de decisión naturalmente representan expre-

Los datos de entrenamiento pueden contener errores. Los métodos de apren-

Los datos de entrenamiento pueden contener valores de atributo omitidos. Los

Una hoja, indica una clase, o

El sistema C4.5 consiste de cuatro programas principales.

1. El generador de árbol de decisión (‘C4.5’)

2. El generador de reglas de producción (‘C4.5rules’)

3. El interprete de árboles de decisión (‘consult’), y

A continuación se describe un ejemplo de ejecución aplicado al sistema, para

Ejemplo: Negociación del pago de mano de obra

La Universidad de California en Irvine guarda una librerı́a accesible públicamente

invoca C4.5 con la opción -f dando el nombre de la tarea o archivo y la opción -u

2.3. El lenguaje unificado de modelado

Figura 2.3: Salida de C4.5 sobre datos labor-neg

A través del modelado, conseguimos cuatro objetivos [4]:

2. Los modelos nos permiten especificar la estructura o el comportamiento de un

4. Los modelos documentan las decisiones que hemos adoptado.

Cualquier proyecto puede beneficiarse del modelado. Incluso en el dominio de

2.4. Ingenierı́a directa e inversa

2.5. Diagramas de clases

Clases, asociaciones y atributos

Interfaces, con sus operaciones y constantes

Información sobre los tipos de los atributos

2.6. Diagramas de interacción

2.6.1. Diagramas de colaboración

2.7. Diagramas de estados

Definición 2.1 Un diagrama de estados muestra un flujo de control entre estados.

Definición 2.2 Un estado es una condición o situación en la vida de un objeto

Definición 2.3 Un evento es la especificación de un acontecimiento significativo que

Las definiciones anteriores son descritas en [4] y se utilizan para la elaboración de

Estado del arte

Diversos investigadores se han dado la tarea de explicar la importancia de contar

3.1. Entendiendo la estructura de sistemas

3.2. Usando ingenierı́a inversa para descubrir es-

identifica los componentes del sistema actual,

descubre sus dependencias y

genera abstracciones para manejar complejidad.

Este entendimiento puede entonces mejorar el desarrollo subsecuente, y produce una

3.3. Experiencias del mundo real

Primero, fue posible ver la estructura de software lógica previamente retenida

Tercero, las vistas proporcionan un objetivo básico para discutir y mantener

Esta aproximación se llego a validar efectivamente cuando tomaron el desafio