Metaheurísticas e ingenieria del software

TESIS DOCTORAL

Metaheurísticas e
Ingeniería del Software

Autor
José Francisco Chicano García

Director
Dr. Enrique Alba Torres

Departamento
Lenguajes y Ciencias de la Computación

UNIVERSIDAD DE MÁLAGA

Julio de 2007

El Dr. Enrique Alba Torres, Titular de Universidad del Departamento de
Lenguajes y Ciencias de la Computación de la Universidad de Málaga,

Certifica

que D. José Francisco Chicano García, Ingeniero en Informática por la
Universidad de Málaga, ha realizado en el Departamento de Lenguajes y
Ciencias de la Computación de la Universidad de Málaga, bajo su
dirección, el trabajo de investigación correspondiente a su Tesis Doctoral
titulada

Metaheurísticas e Ingeniería del Software

Revisado el presente trabajo, estimo que puede ser presentado al tribunal
que ha de juzgarlo, y autorizo la presentación de esta Tesis Doctoral en la
Universidad de Málaga.

En Málaga, Julio de 2007

Firmado: Dr. Enrique Alba Torres
Titular de Universidad
Dpto. de Lenguajes y Ciencias de la Computación
Universidad de Málaga

Agradecimientos

La realizaciń de esta tesis doctoral ha sido posible gracias, en parte, a muchas personas e insti-
o
tuciones que han contribuido de una forma u otra durante todos estos aõs. Las primeras palabras de
n
agradecimiento son para Enrique, quien me ha mostrado el maravilloso mundo de la investigaciń y me
o
ha guiado por ´l magistralmente. Gracias a su constante apoyo, paciencia y dedicaciń, ha sido posible
e o
que este volumen exista aqu´ y ahora.
ı
No puedo dejar de mencionar a mis compa˜eros de laboratorio, que siempre me han ofrecido su ayuda,
n
especialmente cuando la he necesitado. Debo agradecer tambiń a Antonio J. Nebro y Juan Miguel Molina
e
sus enseãnzas y sugerencias.
n
Dedico un muy especial agradecimiento a Eva, una de las personas que m´s ha “sufrido” esta tesis,
a
por su comprensiń, su ayuda y su incondicional apoyo. Agradezco tambiń el apoyo de mi familia, que
o e
desde el primer momento confi´ en m´ y me ayud´ en todo lo posible.
o ı o
Finalmente, me gustar´ dedicar un especial reconocimiento a la Junta de Andaluc´ por la confianza
ıa ıa,
que mostr´ al concederme una beca para la formaciń de doctores con la cual me fue posible iniciar
o o
este camino.

v

vii

¿Por qu´ esta magn´
e ıfica tecnolog´ cient´
ıa ıfica,
que ahorra trabajo y nos hace la vida mas fćil,
a
nos aporta tan poca felicidad?
La repuesta es esta, simplemente: porque ań u
no hemos aprendido a usarla con tino.
Albert Einstein (1879-1955)

´
Indice general

1. Introducciń
o 1
1.1. Planteamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivos y fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Organizaciń de la tesis
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

I Fundamentos de las metaheur´
ısticas y la Ingenier´ del Software
ıa 7
2. Problemas de optimizaciń en Ingenier´ del Software
o ıa 9
2.1. Clasificaciń de los problemas de optimizaciń en Ingenier´
o o ıa del Software . . . . . . . . . . 10
2.1.1. An´lisis de requisitos . . . . . . . . . . . . . . . . . .
a . . . . . . . . . . . . . . . . . 11
2.1.2. Diseõ . . . . . . . . . . . . . . . . . . . . . . . . . .
n . . . . . . . . . . . . . . . . . 11
2.1.3. Implementaciń . . . . . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . 12
2.1.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.5. Implantaciń . . . . . . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . 14
2.1.6. Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.7. Gestiń . . . . . . . . . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . 15
2.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3. Problemas abordados 19
3.1. Planificaciń de proyectos software . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . . . . 19
3.1.1. Definiciń del problema . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . . . . 20
3.1.2. Experimentos in silico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.3. Trabajos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2. Generaciń autom´tica de casos de prueba . . . . . .
o a . . . . . . . . . . . . . . . . . . . . . 26
3.2.1. Definiciń del problema . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . . . . 27
3.3. B´squeda de violaciones de propiedades de seguridad
u en sistemas concurrentes . . . . . . 34
3.3.1. Aut´matas de B¨chi . . . . . . . . . . . . . .
o u . . . . . . . . . . . . . . . . . . . . . 35
3.3.2. Propiedades y l´gicas temporales . . . . . . .
o . . . . . . . . . . . . . . . . . . . . . 36
3.3.3. Model checking LTL con aut´matas de B¨chi
o u . . . . . . . . . . . . . . . . . . . . . 37
3.3.4. Model checking heur´ıstico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.5. Reducciń de orden parcial . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . . . . 40

ix

x ´
INDICE GENERAL

3.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4. Metaheur´ ısticas 45
4.1. Definiciń formal . . . . . . . . . . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . 48
4.2. Clasificaciń de las metaheur´
o ısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.1. Metaheur´ ısticas basadas en trayectoria . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.2. Metaheur´ ısticas basadas en poblaciń . . . . . . . . . .
o . . . . . . . . . . . . . . . 52
4.3. Metaheur´ ısticas paralelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.1. Modelos paralelos para m´todos basados en trayectoria
e . . . . . . . . . . . . . . . 54
4.3.2. Modelos paralelos para m´todos basados en poblaciń .
e o . . . . . . . . . . . . . . . 56
4.4. Metaheur´ ısticas usadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.1. Algoritmos evolutivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.2. Optimizaciń basada en c´mulos de part´
o u ıculas . . . . . . . . . . . . . . . . . . . . 63
4.4.3. Optimizaciń basada en colonias de hormigas . . . . . .
o . . . . . . . . . . . . . . . 65
4.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

II Resoluciń de los problemas de Ingenier´ del Software seleccionados 71
o ıa

5. Propuestas metodol´gicas
o 73
5.1. Propuesta para la planificaciń de proyectos software . . .
o . . . . . . . . . . . . . . . . . . 73
5.1.1. Generador de instancias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1.2. Detalles del GA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2. Propuesta para la generaciń de casos de prueba . . . . .
o . . . . . . . . . . . . . . . . . . 78
5.2.1. Funciń de distancia . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . 79
5.2.2. Instrumentaciń del programa objeto . . . . . . . .
o . . . . . . . . . . . . . . . . . . 80
5.2.3. El proceso de generaciń . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . 81
5.2.4. Medidas de cobertura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2.5. Detalles de las metaheur´ ısticas empleadas . . . . . . . . . . . . . . . . . . . . . . . 84
5.2.6. Representaciń y funciń de fitness . . . . . . . . .
o o . . . . . . . . . . . . . . . . . . 85
5.3. Propuesta para la b´squeda de violaciones de propiedades
u de seguridad en sistemas con-
currentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.3.1. Justificaciń de ACOhg . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . 85
5.3.2. Longitud de los caminos de las hormigas . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3.3. Funciń de fitness . . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . 88
5.3.4. Rastros de feromona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.5. Grafo de construcciń . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . 89
5.3.6. Pseudoc´digo de ACOhg . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . 90
5.3.7. Integraciń de ACOhg y HSF-SPIN . . . . . . . .
o . . . . . . . . . . . . . . . . . . 92
5.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

´
INDICE GENERAL xi

6. Aplicaciń de GA a la planificaciń de proyectos software
o o 93
6.1. Configuraciń del algoritmo . . . . . . . . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . 93
6.2. Primer grupo de instancias: variaciń en el n´mero de empleados . . .
o u . . . . . . . . . . . 94
6.3. Segundo grupo de instancias: cambio en el n´mero de tareas . . . . . .
u . . . . . . . . . . . 95
6.4. Tercer grupo de instancias: cambio en la experiencia de los empleados . . . . . . . . . . . 96
6.5. Cuarto grupo de instancias: especializaciń del conocimiento constante
o . . . . . . . . . . . 97
6.6. Quinto grupo de instancias: experiencia de los empleados constante . . . . . . . . . . . . . 98
6.7. An´lisis detallado de la din´mica del algoritmo . . . . . . . . . . . . .
a a . . . . . . . . . . . 100
6.8. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

7. Aplicaciń de metaheur´
o ısticas a la generaciń de casos de prueba
o 107
7.1. Casos de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.2. Par´metros de los algoritmos . . . . . . . . . . . . . . . . . . . . . . .
a . . . . . . . . . . . 108
7.3. Algoritmos descentralizados frente a centralizados . . . . . . . . . . . . . . . . . . . . . . . 110
7.4. Generaciń aleatoria de casos de prueba . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . 112
7.5. An´lisis del enfoque distribuido . . . . . . . . . . . . . . . . . . . . . .
a . . . . . . . . . . . 113
7.5.1. An´lisis del modo de b´squeda . . . . . . . . . . . . . . . . . .
a u . . . . . . . . . . . 113
7.5.2. An´lisis del criterio de parada . . . . . . . . . . . . . . . . . . .
a . . . . . . . . . . . 114
7.5.3. An´lisis del n´mero de semillas . . . . . . . . . . . . . . . . . .
a u . . . . . . . . . . . 114
7.5.4. An´lisis del periodo de migraciń . . . . . . . . . . . . . . . . .
a o . . . . . . . . . . . 115
7.6. Resultados de PSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.7. Resultados previos en la literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.8. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8. Aplicaciń de ACOhg a la b´ squeda de violaciones de propiedades
o u de seguridad en
sistemas concurrentes 119
8.1. Conjunto de sistemas concurrentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.2. Par´metros de ACOhg . . . . . . . . . . . . . . . . . . . . . . . . . . . .
a . . . . . . . . . . 120
8.3. Influencia de λant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.4. An´lisis de las tćnicas misionera y de expansiń . . . . . . . . . . . . .
a e o . . . . . . . . . . 123
8.4.1. Tćnica misionera . . . . . . . . . . . . . . . . . . . . . . . . . .
e . . . . . . . . . . 123
8.4.2. Tćnica de expansiń . . . . . . . . . . . . . . . . . . . . . . . .
e o . . . . . . . . . . 125
8.4.3. Comparaciń de ambas tćnicas . . . . . . . . . . . . . . . . . . .
o e . . . . . . . . . . 126
8.5. Comparaciń entre ACOhg y algoritmos exhaustivos . . . . . . . . . . .
o . . . . . . . . . . 130
8.6. Combinaciń de ACOhg y reducciń de orden parcial . . . . . . . . . . .
o o . . . . . . . . . . 134
8.6.1. Recursos computacionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
8.6.2. Estados expandidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
8.6.3. Longitud de las trazas de error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
8.7. Resultados previos en la literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
8.8. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

xii ´
INDICE GENERAL

III Conclusiones y trabajo futuro 141

IV Apńdices
e 151
A. An´lisis de la configuraciń de los algoritmos
a o 153
A.1. Generaciń de casos de prueba . . . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . 153
A.1.1. Selecciń de par´metros para ES . . . . . . . . . . . . . .
o a . . . . . . . . . . . . . . 153
A.1.2. Selecciń de par´metros para GA . . . . . . . . . . . . . .
o a . . . . . . . . . . . . . . 156
A.2. B´squeda de violaciones de propiedades de seguridad en sistemas
u concurrentes . . . . . . 158
A.2.1. Par´metros base . . . . . . . . . . . . . . . . . . . . . . .
a . . . . . . . . . . . . . . 158
A.2.2. Longitud del camino de las hormigas . . . . . . . . . . . . . . . . . . . . . . . . . . 158
A.2.3. Tćnica misionera . . . . . . . . . . . . . . . . . . . . . .
e . . . . . . . . . . . . . . 160
A.2.4. Tćnica de expansiń . . . . . . . . . . . . . . . . . . . .
e o . . . . . . . . . . . . . . 166
A.2.5. Comparaciń entre la tćnica misionera y la de expansiń
o e o . . . . . . . . . . . . . . 168
A.2.6. An´lisis de escalabilidad . . . . . . . . . . . . . . . . . . .
a . . . . . . . . . . . . . . 172
A.2.7. An´lisis de la influencia de la heur´
a ıstica . . . . . . . . . . . . . . . . . . . . . . . . 172
A.2.8. An´lisis de las penalizaciones . . . . . . . . . . . . . . . .
a . . . . . . . . . . . . . . 174

B. Validaciń estad´
o ıstica de resultados 177
B.1. Planificaciń de proyectos software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 178
B.2. Generaciń de casos de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 179
B.3. B´squeda de violaciones de propiedades de seguridad en sistemas concurrentes . . . . . .
u 187

C. Bibliotecas 201
C.1. La biblioteca JEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
C.1.1. El problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
C.1.2. Individuos y poblaciń . . .
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
C.1.3. Operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
C.1.4. Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
C.1.5. Condiciń de parada . . . .
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
C.1.6. Puesta en marcha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
C.2. La biblioteca MALLBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
C.2.1. Arquitectura de MALLBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
C.2.2. Interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
C.2.3. Interfaz de comunicaciń .
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
C.2.4. Interfaz de hibridaciń . . .
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

D. Relaciń de publicaciones que sustentan la tesis doctoral
o 211

E. Summary of this thesis in English 215
E.1. Organization of this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
E.2. Software Engineering optimization problems . . . . . . . . . . . . . . . . . . . . . . . . . . 217
E.3. Tackled problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
E.3.1. Project scheduling problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
E.3.2. Test case generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

´
INDICE GENERAL xiii

E.3.3. Search for safety property violations in concurrent systems . . . . . . . . . . . . . 219
E.4. Metaheuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
E.4.1. Utilized metaheuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
E.5. Methodological issues in this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
E.5.1. Software project scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
E.5.2. Test case generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
E.5.3. Search for safety property violations in concurrent systems . . . . . . . . . . . . . 231
E.6. Application of genetic algorithms to software project scheduling . . . . . . . . . . . . . . . 234
E.7. Application of metaheuristics to test case generation . . . . . . . . . . . . . . . . . . . . . 235
E.8. Application of ACOhg to the search for safety property violations in concurrent systems . 235
E.9. Conclusions and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Bibliograf´
ıa 239
´
Indice de tablas 259
´
Indice de ﬁguras 261
´
Indice de t´rminos
e 265

Cap´
ıtulo 1

Introducciń
o

1.1. Planteamiento
El diseõ de algoritmos cada vez m´s eficientes para resolver problemas complejos (tanto de opti-
n a
mizaciń como de b´squeda) ha sido tradicionalmente uno de los aspectos m´s importantes de la in-
o u a
vestigaciń en Inform´tica. El objetivo perseguido en este campo es, fundamentalmente, el desarrollo de
o a
nuevos m´todos capaces de resolver los mencionados problemas complejos con el menor esfuerzo computa-
e
cional posible, mejorando as´ a los algoritmos existentes. En consecuencia, esto no s´lo permite afrontar
ı o
problemas actuales de forma m´s eficiente, sino tambiń tareas vedadas en el pasado debido a su alto
a e
coste computacional. En este contexto, la actividad investigadora tanto en algoritmos exactos como en
heur´ısticos ad hoc y metaheur´ ısticos para resolver problemas complejos de optimizaciń est´ creciendo
o a
de forma evidente en estos d´ La razń es que continuamente se estń afrontando nuevos problemas
ıas. o a
de ingenier´ mientras que, al mismo tiempo, cada vez se dispone de mejores recursos computacionales,
ıa,
como nuevos tipos de ordenadores, redes, y entornos como Internet.
La principal ventaja de la utilizaciń de algoritmos exactos es que garantizan encontrar el ´ptimo
o o
global de cualquier problema, pero tienen el grave inconveniente de que en problemas reales (que suelen
ser NP-duros en la mayor´ de los casos) su tiempo de ejecuciń crece de forma exponencial con el
ıa o
tamaõ del problema. En cambio, los algoritmos heur´
n ısticos ad hoc son normalmente bastante r´pidos,
a
pero la calidad de las soluciones encontradas est´ habitualmente lejos de ser ´ptima. Otro inconveniente
a o
de los heur´ ısticos ad hoc es que no son fćiles de definir en determinados problemas. Las metaheur´
a ısticas1
ofrecen un equilibrio adecuado entre ambos extremos: son m´todos gen´ricos que ofrecen soluciones de
e e
buena calidad (el ´ptimo global en muchos casos) en un tiempo moderado.
o
La Ingenier´ del Software, a pesar de su corta edad, es en la actualidad una importante fuente de
ıa
problemas de optimizaciń. Los ingenieros y gestores de proyectos software se enfrentan diariamente a
o
diversos problemas de optimizaciń en los que las tćnicas exactas no tienen cabida por el corto intervalo
o e
de tiempo en que se requiere una respuesta. Cabe la posibilidad, por tanto, de aplicar a estos problemas
algoritmos metaheur´ ısticos que ofrezcan al ingeniero una soluciń de cierta calidad en un breve periodo
o
de tiempo: un compromiso entre calidad de la soluciń y rapidez.
o
1 Algunos autores consideran los algoritmos metaheur´ısticos una subclase de los algoritmos heur´
ısticos. Por ese motivo
usamos el t´rmino “heur´
e ıstico ad hoc” para referirnos a los algoritmos aproximados pensados espec´ ıficamente para un
problema concreto.

1

2 CAP´ ´
ITULO 1. INTRODUCCION

Es en este contexto donde se enmarca esta tesis doctoral. Nos proponemos aplicar tćnicas meta-
e
heur´ısticas a problemas de optimizaciń surgidos en el seno de la Ingenier´ del Software, analizando
o ıa
distintas posibilidades para sacar el m´ximo partido a dichas tćnicas y ofrecer as´ soluciones de gran
a e ı
calidad con recursos computacionales al alcance de cualquier instituciń. Los problemas abordados son
o
concretamente la planificaciń de proyectos software, la generaciń autom´tica de casos de prueba y la
o o a
b´squeda de violaciones de propiedades de seguridad en sistemas concurrentes.
u
Adem´s, estas metaheur´
a ısticas han sido diseãdas e implementadas utilizando, a su vez, tćnicas y
n e
herramientas propias de la Ingenier´ del Software con el objetivo de crear software de calidad. De esta
ıa
forma, cerramos el c´ırculo: Ingenier´ del Software para desarrollar herramientas que resolverń problemas
ıa a
de Ingenier´ del Software.
ıa

1.2. Objetivos y fases
Los objetivos principales de esta tesis doctoral son: aplicar tćnicas metaheur´
e ısticas a problemas de
optimizaciń de Ingenier´ del Software, analizar los resultados para comprender el comportamiento de
o ıa
estos algoritmos y proponer nuevos m´todos para resolver los problemas de manera m´s eficaz y eficiente.
e a
Estos objetivos globales han sido descompuestos en objetivos parciales m´s concretos:
a

Identificaciń de problemas de optimizaciń en Ingenier´ del Software.
o o ıa
Descripciń y formalizaciń de varios de estos problemas de optimizaciń.
o o o
Descripciń y formalizaciń de las tćnicas metaheur´
o o e ısticas propuestas.
Aplicaciń de tćnicas metaheur´
o e ısticas a problemas de optimizaciń de la Ingenier´ del Software y
o ıa
an´lisis de resultados.
a

Para conseguir estos objetivos se siguen las fases resumidas en la Figura 1.1. Inicialmente revisamos
la literatura en busca de problemas de optimizaciń en Ingenier´ del Software. Posteriormente, selec-
o ıa
cionamos tres problemas que, de acuerdo a la revisiń bibliogr´fica realizada, representan a los dominios
o a
de mayor inter´s en el campo de la optimizaciń de problemas de Ingenier´ del Software. Estos problemas
e o ıa
son la planificaciń de proyectos software, la generaciń autom´tica de casos de prueba y la b´squeda
o o a u
de violaciones de propiedades de seguridad en sistemas concurrentes. En el siguiente paso estudiamos las
tćnicas metaheur´
e ısticas y seleccionamos para cada problema aqu´llas que puedan resultar m´s intere-
e a
santes desde el punto de vista de la comunidad cient´ ıfica. Las tćnicas seleccionadas son los algoritmos
e
evolutivos, la optimizaciń basada en c´mulos de part´
o u ıculas y la optimizaciń basada en colonias de
o
hormigas. Por ultimo, escogidos los problemas y las tćnicas, aplicamos los algoritmos metaheur´
´ e ısticos a
los problemas de optimizaciń y analizamos los resultados obtenidos.
o

1.3. Contribuciones
En este apartado se listan las contribuciones de la presente tesis. De forma esquem´tica, estas con-
a
tribuciones se pueden resumir como sigue:

Modelo formal de metaheur´ ısticas secuenciales que extiende al propuesto por Gabriel Luque en su
tesis doctoral [183] para hacerlo m´s operativo desde un punto de vista te´rico.
a o

1.3. CONTRIBUCIONES 3

Revisión de Revisión de
problemas técnicas
Desarrollo de
nuevos modelos
algorítmicos
Selección de Selección de
problemas técnicas

Aplicación de
técnicas a problemas

Análisis de
resultados

Figura 1.1: Fases seguidas durante la elaboraciń de esta tesis.
o

Estudio de la utilidad de las metaheur´
ısticas para la planificaciń de proyectos software con ayuda
o
de un generador de instancias.

Aplicaciń por primera vez de dos tćnicas metaheur´
o e ısticas a la generaciń de casos de prueba:
o
estrategias evolutivas y optimizaciń basada en c´mulos de part´
o u ıculas. Estas tćnicas resultan ser
e
m´s eficaces que los algoritmos gen´ticos, ampliamente utilizados en la literatura.
a e

Estudio detallado de metaheur´
ısticas con poblaciń descentralizada para la generaciń autom´tica
o o a
de casos de prueba y comparaciń con metaheur´
o ısticas con poblaciń centralizada.
o

Desarrollo de un nuevo modelo algor´
ıtmico de optimizaciń basado en colonias de hormigas que
o
permite trabajar con problemas en los que el grafo de construcciń tiene tamaõ desconocido o
o n
suficientemente grande para que no quepa en la memoria de una m´quina.
a

Aplicaciń del nuevo modelo algor´
o ıtmico al problema de b´squeda de violaciones de propiedades de
u
seguridad en sistemas concurrentes con un enfoque basado en model checking. Se realiza un an´lisis
a
detallado de la aplicaciń explorando alternativas.
o

Combinaciń del nuevo modelo algor´
o ıtmico con una tćnica propia de model checking, la reducciń
e o
de orden parcial, para el problema mencionado en el punto anterior.

Diseõ e implementaciń de los algoritmos utilizados en esta tesis siguiendo el paradigma de la orien-
n o
taciń a objetos. Estos algoritmos se han incorporado en dos bibliotecas p´blicamente disponibles:
o u
JEAL y MALLBA.

Adem´s de los puntos m´s importantes arriba mencionados, se ha realizado una revisiń y clasificaciń
a a o o
de trabajos para identificar problemas de optimizaciń en Ingenier´ del Software. Tambiń se ha diseãdo
o ıa e n
e implementado un generador de instancias para el problema de planificaciń de proyectos software. Este
o

4 CAP´ ´

generador ha permitido analizar los resultados obtenidos con las tćnicas metaheur´
e ısticas en proyectos
software ficticios autom´ticamente generados con diferentes caracter´
a ısticas.
Finalmente, se ha llevado a cabo una importante labor de diseminaciń del contenido de las investi-
o
gaciones desarrolladas en este trabajo. Para tal fin, adem´s de las publicaciones aparecidas en revistas
a
y congresos tanto nacionales como internacionales, se han desarrollado p´ginas web de dominio p´blico
a u
con la descripciń de los problemas, el generador de instancias y los resultados de las investigaciones.
o

1.4. Organizaciń de la tesis
o
Este documento de tesis se estructura en cuatro partes. En la primera se presentan los preliminares de
las metaheur´ ısticas y la Ingenier´ del Software, detallando los problemas y las tćnicas que se utilizan en
ıa e
la tesis. En la segunda parte se presentan las propuestas metodol´gicas y los resultados de la aplicaciń
o o
de las metaheur´ ısticas a los problemas de Ingenier´ del Software seleccionados. En la tercera parte
ıa
mostramos las principales conclusiones que se desprenden de este trabajo, as´ como las l´
ı ıneas de trabajo
futuro inmediatas que surgen de nuestro estudio. Finalmente, la cuarta parte contiene los apńdices con
e
resultados y estudios secundarios que pueden ser de inter´s tan s´lo a algunos lectores. A continuaciń
e o o
describimos detalladamente el contenido de los cap´ ıtulos.

Parte I: Fundamentos de las metaheur´
ısticas y la Ingenier´ del Software
ıa
El Cap´ ıtulo 2 introduce los conceptos b´sicos de Ingenier´ del Software. Tras esto, ofrece una breve
a ıa
revisiń de problemas de optimizaciń que surgen en el seno de la Ingenier´ del Software y que han
o o ıa
sido abordados en la literatura con tćnicas de optimizaciń.
e o
El Cap´ıtulo 3 detalla los tres problemas de optimizaciń pertenecientes al campo de la Ingenier´
o ıa
del Software que se han resuelto con tćnicas metaheur´
e ısticas en la presente tesis.
El Cap´ ıtulo 4 proporciona una introducciń gen´rica sobre el campo de las metaheur´
o e ısticas. Poste-
riormente describe con mayor nivel de detalle las tćnicas metaheur´
e ısticas concretas que se usan a
lo largo de la tesis.

Parte II: Resoluciń de los problemas de Ingenier´ del Software seleccionados
o ıa
El Cap´ıtulo 5 describe las propuestas metodol´gicas empleadas para resolver los problemas selec-
o
cionados. Se detallan los algoritmos empleados y las modificaciones a ´stos, as´ como los nuevos
e ı
modelos desarrollados especialmente para resolver los problemas.
El Cap´ıtulo 6 presenta los resultados obtenidos al resolver el problema de planificaciń de proyectos
o
software. Se resuelven distintas instancias del problema con diferentes caracter´ ısticas y se discuten
los resultados para llegar a una comprensiń profunda del problema que pueda servir a jefes de
o
proyectos en su trabajo diario.
El Cap´ıtulo 7 muestra y discute los resultados obtenidos tras la aplicaciń de las tćnicas meta-
o e
heur´
ısticas al problema de generaciń de casos de prueba. Se analizan distintos algoritmos y se
o
comparan los resultados con la literatura.
El Cap´ıtulo 8 estudia los resultados obtenidos para el problema de b´squeda de violaciones de
u
propiedades de seguridad en sistemas concurrentes. Se analizan distintas configuraciones de los
algoritmos y se evalán sobre un gran conjunto de sistemas concurrentes.
u

´
1.4. ORGANIZACION DE LA TESIS 5

Parte III: Conclusiones y trabajo futuro
Terminamos esta tesis con unas conclusiones sobre todo lo expuesto en el resto del documento.
Asimismo, se describen tambiń las principales l´
e ıneas de trabajo futuro que surgen del presente
estudio. Esta parte est´ redactada tanto en espaõl como en ingl´s para cumplir los requisitos
a n e
exigidos por la Universidad de M´laga para optar a la menciń de Doctorado Europeo.
a o
Parte IV: Apńdices
e
El Apńdice A presenta un an´lisis de par´metros de algunas de las tćnicas empleadas en la tesis
e a a e
doctoral. Los resultados de este an´lisis se utilizaron para decidir la configuraciń de los algoritmos.
a o
El Apńdice B describe el tratamiento estad´
e ıstico utilizado para validar las observaciones realizadas
en los experimentos de la tesis y muestra los resultados de dicha validaciń.
o
El Apńdice C ofrece una r´pida descripciń de las bibliotecas de algoritmos metaheur´
e a o ısticos que
se han usado y diseãdo durante el desarrollo de la tesis.
n
El Apńdice D presenta la publicaciones del doctorando realizadas durante la elaboraciń de la
e o
tesis. Estas publicaciones sustentan la calidad de la presente tesis doctoral.
El Apńdice E contiene un resumen en ingl´s de la tesis doctoral, necesario para optar a la menciń
e e o
de Doctorado Europeo.

6 CAP´ ´

Parte I

Fundamentos de las metaheur´ısticas
y la Ingenier´ del Software
ıa

7

Cap´
ıtulo 2

Problemas de optimizaciń en
o
Ingenier´ del Software
ıa

El diccionario de la Real Academia Espaõla [231] define software como un “conjunto de programas,
n
instrucciones y reglas inform´ticas para ejecutar ciertas tareas en una computadora” mientras que en el
a
estńdar IEEE 610.12-1990 [150] se define la Ingenier´ del Software como “la aplicaciń de un m´to-
a ıa o e
do sistem´tico, disciplinado y cuantificable al desarrollo, operaciń y mantenimiento de software”1 . La
a o
Ingenier´ del Software2 tiene una corta historia debido a que su existencia est´ ligada a la de los com-
ıa a
putadores digitales, que hicieron apariciń en la dćada de 1940. Al comienzo de la era de los ordenadores
o e
el software era relativamente simple y, por tanto, no resultaba complicado asegurar la calidad del mismo.
Con el aumento de las prestaciones de los ordenadores, se abr´ la posibilidad al desarrollo de software
ıa
cada vez m´s complejo apoyado en todo momento por lenguajes de programaciń y herramientas de m´s
a o a
alto nivel. A lo largo de su historia, el desarrollo de software ha pasado de ser una tarea realizada por
una sola persona en pocas horas a convertirse en un conjunto de actividades interrelacionadas que deben
realizarse en grandes equipos de trabajo durante meses. Los procesos de desarrollo de software o ciclos de
vida del software surgieron como una herramienta para poner orden en este conjunto de actividades. Se
han propuesto diversos procesos de desarrollo de software en las ultimas dćadas entre los que destacan
´ e
el ciclo de vida en cascada [239] y el ciclo de vida en espiral [39]. Estos procesos de desarrollo de software
determinan un conjunto de actividades y un orden entre ellas.
Un problema de optimizaciń consiste en escoger una opciń de entre un conjunto de ellas que sea
o o
mejor o igual que las dem´s (váse el comienzo del Cap´
a e ıtulo 4). Los problemas de optimizaciń surgen
o
en cualquier ´mbito desde la vida cotidiana hasta la industria. A lo largo de la historia se ha dedicado
a
mucho esfuerzo a encontrar tćnicas que permitan resolver tales problemas. Es un factor comń a todas
e u
las ingenier´ la existencia de problemas de optimizaciń. Un ejemplo son los problemas de diseõ de
ıas o n
componentes (ala de aviń, tuber´ antena de telecomunicaciones, etc.). La Ingenier´ del Software, a
o ıa, ıa
pesar de ser una ingenier´ joven, no es una excepciń. De hecho, en la actualidad existe un creciente
ıa o
inter´s por aplicar tćnicas de optimizaciń a problemas de Ingenier´ del Software. Una muestra palpable
e e o ıa
1 Traducciń
o tomada de la wikipedia en la entrada “Ingenier´ de software”.
ıa
2 El t´rmino Ingenier´ del Software fue utilizado por primera vez por Fritz Bauer en la primera conferencia sobre
e ıa
desarrollo de software patrocinada por el Comit´ de Ciencia de la OTAN que se celebr´ en Garmisch, Alemania, en Octubre
e o
de 1968.

9

10 CAP´
ITULO 2. PROBLEMAS DE OPTIMIZACION EN INGENIER´ DEL SOFTWARE
´ IA

de este inter´s ha sido la creaciń del t´rmino Search Based Software Engineering, abreviado SBSE, por
e o e
parte de Harman y Jones [132] para referirse a este nuevo campo de investigaciń.
o
En este cap´ıtulo se presenta una breve descripciń de un conjunto de problemas surgidos dentro de la
o
Ingenier´ del Software que han sido planteados en la literatura como problemas de optimizaciń. No se
ıa o
trata de una revisiń exhaustiva de trabajos sino, m´s bien, de un escaparate en el que se puede apreciar
o a
la diversidad de los problemas que pueden definirse dentro de la Ingenier´ del Software. La mayor´
ıa ıa
de los trabajos presentados han sido tomados del repositorio de publicaciones sobre SBSE mantenido
por el doctor Afshin Mansouri como parte del proyecto SEBASE (www.sebase.org). Para presentar este
conjunto de problemas de forma ordenada, proponemos una clasificaciń de los mismos cuyos detalles,
o
junto con la descripciń de los problemas, se encuentran en la siguiente secciń.
o o

2.1. Clasificaciń de los problemas de optimizaciń en Ingenier´
o o ıa
del Software
La clasificaciń que proponemos para los problemas de optimizaciń en Ingenier´ del Software se basa
o o ıa
en la fase en la que aparece dicho problema dentro del proceso de desarrollo de software. Las fases que
consideramos son: an´lisis de requisitos, diseõ, implementaciń, pruebas, implantaciń, mantenimiento
a n o o
y gestiń. Todas estas son fases que, bien con el mismo nombre o bien con otro, aparecen en todo proceso
o
de desarrollo de software. A veces no est´ claro dńde colocar un problema en concreto; existen algunos
a o
problemas que se encuentran en el borde entre dos fases y, por tanto, podr´ aparecer en ambas. Dentro
ıan
de las categor´ de mantenimiento y gestiń hemos realizado una segunda clasificaciń de problemas,
ıas o o
ya que la diversidad de ´stos suger´ tal divisiń. En la Figura 2.1 mostramos la clasificaciń completa
e ıa o o
aqu´ propuesta.
ı

Diseño

Implementación

Análisis

Problemas de optimización
Pruebas
Modelos de calidad en ingeniería del software

Estimación de costes Gestión

Implantación
Planificación de proyectos Mantenimiento

Análisis de software Transformación

Figura 2.1: Clasificaciń de problemas de optimizaciń en Ingenier´ del Software.
o o ıa

2.1 CLASIFICACION DE LOS PROBLEMAS DE OPT. EN INGENIER´ DEL SOFTWARE
´ IA 11

2.1.1. An´lisis de requisitos
a
En la fase de an´lisis de requisitos es donde el ingeniero software y el cliente discuten sobre lo que
a
tiene que hacer el producto software. Es una etapa fundamental del desarrollo en la que se recoge la
informaciń del cliente y se plasma en un conjunto de requisitos para la aplicaciń.
o o
En los procesos de desarrollo software utilizados actualmente se tiende a desarrollar y entregar el
software de forma incremental. Del conjunto total de requisitos se seleccionan algunos y se realiza una
iteraciń del proceso de desarrollo para, finalmente, entregar al usuario un producto software que cumpla
o
dichos requisitos. Tras esto, se vuelven a seleccionar algunos de los requisitos no cubiertos y se realiza
otra iteraciń del proceso de desarrollo. Se sigue de esta forma hasta que el usuario est´ completamente
o e
satisfecho con el producto. La decisiń de qu´ requisitos deben cubrirse en una iteraciń concreta del
o e o
proceso no es algo trivial. Existen numerosas restricciones y prioridades entre los requisitos que afectan
al coste del producto y a la satisfacciń del usuario. Por ejemplo, un requisito puede necesitar que
o
otro requisito previo est´ ya cubierto en el software, o que otro requisito se cubra a la vez que ´l. Es
e e
decir, existen dependencias entre requisitos. Por su parte, el usuario puede necesitar varios requisitos con
urgencia mientras que otros son menos importantes para ´l. A esto se suma el hecho de que cada requisito
e
tiene un coste de implementaciń asociado. En definitiva, la elecciń de requisitos a implementar en una
o o
iteraciń concreta del proceso de desarrollo software es una tarea no trivial que puede beneficiarse de las
o
tćnicas de optimizaciń existentes.
e o
Greer y Ruhe abordan el problema de la selecciń de requisitos para cada iteraciń del proceso de
o o
desarrollo software en [116]. Baker et al. [30] resuelven el problema de la “siguiente versiń”, que consiste
o
en seleccionar los requisitos que van a implementarse en la siguiente iteraciń del proceso de desarrollo.
o
Una versiń multiobjetivo de este ultimo problema, planteada por Zhang, Harman y Mansouri, puede
o ´
encontrarse en [297].

2.1.2. Dise˜ o
n
En la fase de diseõ los ingenieros software desarrollan una soluciń que cumple los requisitos recolec-
n o
tados en el an´lisis. En esta fase se decide el diseõ arquitectńico y de comportamiento del software con
a n o
suficiente detalle como para que pueda ser implementado, pero sin llegar a ser una implementaciń. o
Cuando, en el desarrollo del software, se usa el paradigma de orientaciń a objetos, uno de los objetivos
o
de la fase de diseõ consiste en proponer el conjunto de clases que formarń la aplicaciń. Las clases son
n a o
entidades con cierta autonom´ que colaboran entre ellas. En un buen diseõ, se espera que el acoplamiento
ıa n
(dependencia) entre clases sea bajo y la cohesiń de cada clase (relaciń entre las tareas de los miembros
o o
de la clase) sea alta. Persiguiendo estos objetivos, Simons y Parmee [256] plantean el diseõ conceptual
n
del software como un problema de optimizaciń. Partiendo de un conjunto de m´todos con par´metros
o e a
y atributos que han sido identificados mediante los casos de uso, los autores abordan el problema de
encontrar una asignaciń de los m´todos a clases que minimize el acoplamiento y maximize la cohesiń.
o e o
Durante el desarrollo del software se generan distintos componentes, clases o m´dulos que deben ser
o
integrados conjuntamente para formar el producto final. Estos componentes son testados de forma aislada
(prueba unitaria o unit testing) conforme se desarrollan y, tras integrarlos con el resto de componentes
ya terminados, se prueban de nuevo para comprobar si la interacciń entre ellos es correcta (prueba de
o
integraciń o integration testing). En este ultimo caso, es posible que un componente necesite otro que ań
o ´ u
no est´ completo, siendo necesario sustituir el componente incompleto por un componente temporal que
a
tiene la misma interfaz, conocido como stub. La implementaciń de estos stubs es costosa y puede evitarse
o

12 CAP´
´ IA

o reducirse si se implementan los componentes siguiendo un orden adecuado, que depender´ fundamen-
a
talmente del grafo de interrelaciones de componentes. La determinaciń de este orden es un problema de
o
optimizaciń que ha sido abordado en [45]. Hemos colocado este problema en la secciń de diseõ, a pesar
o o n
de estar a caballo entre el diseõ y la implementaciń, porque el objetivo del problema no es mejorar
n o
ningń aspecto de la implementaciń, sino m´s bien ahorrar costes del proyecto.
u o a

2.1.3. Implementaciń
o
En la fase de implementaciń es donde el diseõ previamente creado se convierte en c´digo fuente.
o n o
Los ingenieros tienen que hacer realidad el diseõ desarrollado en la fase anterior.
n
Los problemas de optimizaciń que se han planteado en la fase de implementaciń tienen que ver con
o o
la mejora o creaciń de herramientas que ayuden al programador en su labor. Por ejemplo, Reformat et
o
al. [235] plantean el problema de la generaciń autom´tica de clones. Este problema consiste en generar
o a
autom´ticamente un fragmento de c´digo fuente (una funciń por ejemplo) que sea equivalente a otro
a o o
dado. Esta tćnica tiene aplicaciones en el desarrollo de software tolerante a fallos.
e
Los compiladores son herramientas imprescindibles en la implementaciń del software y, a su vez, una
o
fuente de gran cantidad de problemas de optimizaciń que deben abordarse de algń modo a la hora de
o u
generar el c´digo objeto. La forma habitual de resolver estos problemas es mediante una heur´
o ıstica ad
hoc que, si bien no ofrece una soluciń ´ptima en todos los casos, su tiempo de ejecuciń es corto, lo cual
o o o
es una propiedad deseable para poder incorporarla en un compilador. Stephenson et al. [259] plantean el
problema de optimizar estas heur´ ısticas.
En general, las optimizaciones que aplica un compilador no son conmutativas, es decir, diferentes
secuencias de optimizaciń dan lugar a distintos resultados (c´digo objeto). Cooper et al. [63] abordan el
o o
problema de encontrar una secuencia de optimizaciń ´ptima para reducir el espacio que ocupa el c´digo
o o o
resultante, lo cual tiene una importante aplicaciń en el desarrollo de software para sistemas empotrados.
o
Otro problema resuelto de forma no ´ptima es la gestiń de memoria din´mica. Del Rosso [74] aborda
o o a
el problema de ajustar la configuraciń del mont´
o ıculo (heap) para reducir la fragmentaciń interna en
o
listas libres segregadas mientras que Cohen et al. [60] aplica tćnicas de clustering a las hebras con el
e
objetivo de identificar grupos de hebras que accedan a los mismos objetos. Estos grupos compartirń un a
mont´ ıculo, haciendo que el recolector de basura no tenga que detener todas las hebras para llevar a cabo
su labor, sino tan s´lo las del grupo afectado.
o
Otro interesante problema planteado en el seno de los compiladores es la generaciń autom´tica de
o a
c´digo paralelo ´ptimo a partir de c´digo secuencial. Este problema ha sido abordado por Nisbet [220],
o o o
Williams [290] y Ryan [241].
Dada una unidad de c´digo fuente (funciń, clase, etc.) es posible aplicar una secuencia de trans-
o o
formaciones a dicho c´digo que preserva la semńtica pero que altera la sintaxis. Esta secuencia de
o a
transformaciones podr´ reducir el n´mero de l´
ıa u ıneas de c´digo. El problema de encontrar la secuencia de
o
transformaciones que minimice la longitud del c´digo resultante ha sido abordado en [97] y [98].
o

2.1.4. Pruebas
En la fase de pruebas es donde el software implementado es testado para descubrir errores y, en caso
contrario, comprobar que se comporta de acuerdo a las especificaciones.
Para testar un m´todo o funciń del software es necesario decidir los valores de sus argumentos de
e o
entrada. Un caso de prueba es una combinaciń concreta de valores de para dichos argumentos. La labor
o

´ IA 13

del ingeniero de pruebas es crear un conjunto de casos de prueba y testar el software con ´l. Este conjunto
e
de casos de prueba debe ser tal que maximice la probabilidad de descubrir los posibles errores del objeto
de la prueba. El enfoque m´s popular para conseguir conjuntos de casos de prueba adecuados es usar
a
criterios de cobertura: un conjunto de casos de prueba se considera adecuado si consigue cubrir una gran
cantidad de elementos (instrucciones, ramas, predicados at´micos, etc.) del objeto de prueba. El problema
o
de la generaciń autom´tica de casos de prueba es, con diferencia, el m´s estudiado de todos los problemas
o a a
de optimizaciń relacionados con la ingenier´ el software. Desde el primer trabajo de Miller y Spooner
o ıa
de 1976 [207] hasta nuestros d´ se han propuesto diversas formas de abordar esta tarea. Uno de los
ıas,
paradigmas empleados, el paradigma estructural, hace uso de informaciń estructural del programa para
o
generar los casos de prueba [5, 19, 20, 34, 194, 206]. Esta informaciń proviene generalmente del grafo de
o
control de flujo. En numerosos trabajos se han estudiado y propuesto diferentes funciones objetivo [33,
41, 55, 180, 274]. As´ mismo, para aumentar la eficiencia y eficacia del proceso de generaciń de casos
ı o
de prueba, se han combinado las estrategias de b´squeda con otras tćnicas tales como slicing [131],
u e
transformaciń de c´digo [130, 137, 166, 197], an´lisis de dependencia de datos [165], uso de medidas
o o a
software [169, 170, 243], b´squeda en dominios variables [244], y otros [198, 200, 292]. Se han propuesto
u
soluciones para algunos de los problemas principales que surgen en la generaciń de casos de prueba: la
o
presencia de flags [31, 32, 40, 129], la existencia de estados internos en el programa [199, 201, 296], las
particularidades del software orientado a objetos [279, 280] y la presencia de excepciones [271]. Entre
las tćnicas m´s populares para la resoluciń del problema se encuentran los algoritmos gen´ticos [103,
e a o e
152, 153, 191, 224, 237, 238, 261, 291], la b´squeda tab´ [70], la b´squeda dispersa [246] y los algoritmos
u u u
de estimaciń de distribuciones [242, 245]. Tambiń se han desarrollado herramientas para la generaciń
o e o
autom´tica de casos de prueba usando un enfoque basado en optimizaciń [71, 267, 268, 269, 281]. La
a o
generaciń autom´tica de casos de prueba usando informaciń estructural del software se ha usado con
o a o
´xito para detectar desbordamientos de buffers [72, 73] y comprobar software cr´
e ıtico [272].
Un segundo paradigma de generaciń de casos de prueba, denominado funcional, considera el software
o
como una caja negra [193, 247, 283]. Tambiń se ha estudiado la generaciń de casos de prueba para
e o
realizar pruebas de conformidad de m´quinas de estado finitas [76, 77, 124, 125, 126, 138, 177]. Se han
a
usado tćnicas de programaciń con restricciones [62] y se han evaluado los conjuntos de casos de prueba
e o
usando mutantes [1, 95, 252, 295]. Los mutantes son programas que contienen pequeãs variaciones con
n
respecto al objeto de la prueba. Normalmente, las variaciones que se incluyen en los mutantes representan
los errores m´s comunes que se cometen al programar. En este contexto, un conjunto de casos de prueba
a
es adecuado si es capaz de distinguir entre el programa original y los mutantes observando unicamente
´
la salida de ambos programas. La evaluaciń de conjuntos de casos de prueba con esta tćnica constituye
o e
otro criterio de adecuaciń alternativo a los criterios de cobertura.
o
Las pruebas de interacciń consisten en comprobar todas las combinaciones posibles de entornos de
o
ejecuciń del software: distintos sistemas operativos, distintas configuraciones de memoria, etc. Cuantos
o
m´s factores se consideren mayor es el n´mero posible de combinaciones, creciendo ´ste de forma expo-
a u e
nencial. Por este motivo, se han propuesto estrategias basadas en optimizaciń para reducir este enorme
o
conjunto de combinaciones [47, 48, 61].
Por otro lado, existe un conjunto de trabajos en el que se comprueban aspectos no funcionales del
software. La mayor´ de ellos se centran en el tiempo de ejecuciń, con aplicaciones a los sistemas en
ıa o
tiempo real [46, 79, 215, 228, 266, 284, 285, 286]. Algunos trabajos extienden las tćnicas para abordar
e
software orientado a objetos y basado en componentes [123, 120]. Tambiń se han definido medidas que
e
permiten conocer, tras un examen del c´digo fuente del programa, si la aplicaciń de tćnicas basadas en
o o e
computaciń evolutiva es adecuada o no para comprobar las restricciones temporales [119, 121, 122].
o

14 CAP´
´ IA

Cuando el software es modificado, es necesario volver a aplicar algunas pruebas para comprobar que
no se han introducido nuevos errores. Esto es lo que se conoce como pruebas de regresiń (regression
o
testing). Muchas de estas pruebas pueden reutilizarse de una etapa anterior, cuando el software pas´ por
o
primera vez la fase de pruebas. El problema de seleccionar las pruebas que se van a aplicar de nuevo ha
sido planteado como un problema de optimizaciń en dos recientes trabajos de Yoo y Harman [293] y Li
o
et al. [178].
Por ultimo, el problema de verificar software concurrente ha sido tradicionalmente resuelto mediante
´
model checkers. Este tipo de tćnicas suele reservarse exclusivamente a modelos de software concurrente
e
cr´
ıtico, y no se aplica al software que se desarrolla en un proyecto de mediana o gran envergadura
por su escasa escalabilidad. Sin embargo, existen algunos trabajos en la literatura que, basńdose en la
a
exploraciń que realizan los model checkers, tratan de buscar errores en software concurrente planteando
o
dicho problema como una b´squeda en un grafo [13, 15, 16, 17, 92, 93, 94, 111]. Este enfoque tiene la
u
ventaja de que puede escalar m´s fćilmente que el model checking cl´sico, permitiendo su aplicaciń al
a a a o
software producido normalmente en la compa˜´ En otros trabajos, el objetivo no es buscar errores,
nıas.
sino generar casos de prueba para sistemas concurrentes [294].

2.1.5. Implantaciń
o
Tras desarrollar y probar el software, procede la fase de implantaciń en la que el sistema software es
o
instalado y desplegado en su entorno definitivo, donde ser´ utilizado.
a
Monnier et al. [214] abordan el problema de la planificaciń de tareas en un sistema distribuido de
o
tiempo real. Dado un conjunto de tareas cuyo tiempo de ejecuciń est´ acotado y con dependencias entre
o a
ellas, el problema consiste en asignar a cada tarea una m´quina para su ejecuciń y planificar los instantes
a o
de tiempo en los que se comunicarń las tareas usando la red.
a

2.1.6. Mantenimiento
La fase de mantenimiento es donde el software se modifica como consecuencia de las sugerencias de
los usuarios o, simplemente, con el objetivo de mejorar su calidad. Al igual que ocurr´ en la fase de
ıa
pruebas, existen muchos trabajos que afrontan problemas surgidos en la fase de mantenimiento usando
tćnicas de optimizaciń. Para realizar un clasificaciń m´s fina de todos estos trabajos, los dividimos en
e o o a
dos grupos: an´lisis de software y transformaciń.
a o

An´lisis de software
a
Una de las tćnicas usadas durante la fase de mantenimiento para llegar a una r´pida comprensiń de
e a o
la estructura y los objetivos de un determinado fragmento de c´digo fuente es la vinculaciń de conceptos
o o
(concept binding). Esta tćnica consiste en asignar autom´ticamente a cada segmento del c´digo fuente
e a o
una palabra o concepto perteneciente a un mapa conceptual previamente definido. Durante una primera
etapa, se asigna a cada l´ ınea o instrucciń del c´digo fuente un indicador. Estos indicadores seãlan la
o o n
posible vinculaciń de un determinado concepto al segmento de c´digo en el que se encuentra el indicador.
o o
La siguiente etapa consiste en asignar conceptos a segmentos de c´digo en funciń de los indicadores que
o o
se encuentren. Esta segunda etapa ha sido planteada como problema de optimizaciń por Gold et al. [113].
o
Otras tćnicas utilizadas para extraer autom´ticamente una estructura de alto nivel del software a
e a
partir del c´digo fuente son las tćnicas de software clustering. La idea detr´s de ellas es agrupar distintos
o e a
elementos del software (clases, funciones, etc.) en m´dulos o subsistemas de acuerdo a su cohesiń y
o o

´ IA 15

acoplamiento. Este problema, originalmente propuesto por Mancoridis et al. en [188], ha sido investigado
en profundidad en numerosos trabajos [90, 128, 133, 185, 186, 187, 210]. Mitchell et at. [211, 212] proponen
un procedimiento completo de ingenier´ inversa compuesto por una primera etapa en la que se aplican
ıa
tćnicas de software clustering seguida de una segunda etapa de reconocimiento de estilos de interconexiń
e o
entre los subsistemas inferidos en la primera etapa.
La detecciń de clones consiste en descubrir fragmentos del c´digo fuente que son idńticos o similares
o o e
sintćtica o semńticamente. Sutton et al. [262] resuelven el problema de detecciń de grupos de clones
a a o
en el c´digo fuente.
o

Transformaciń
o
Basados en la idea del software clustering, Seng et al. [250] plantean el problema de mejorar la
descomposiciń del software en subsistemas. Se trata de encontrar una particiń de los elementos del
o o
software (clases o funciones) formando subsistemas de manera que se optimicen una serie de par´metros
a
como la cohesiń, el acoplamiento o la complejidad.
o
Slicing es una tćnica usada para extraer autom´ticamente un fragmento no contiguo del c´digo que
e a o
resulta de valor para una acciń concreta. Una forma de realizar esta extracciń es seleccionar un conjunto
o o
de variables y obtener una proyecciń del software (un subconjunto de instrucciones) que posea la misma
o
semńtica que el original con respecto a esas variables. Una variante de esta tćnica, denominada slicing
a e
amorfo (amorphous slicing), consiste en generar un fragmento de c´digo que preserve la semńtica del
o a
programa con respecto a las variables seleccionadas pero sin necesidad de preservar la sintaxis. En [96],
Fatiregun et al. abordan el slicing amorfo como un problema de optimizaciń. o
Refactoring es una tćnica para reestructurar el c´digo fuente, cambiando su estructura interna, sin
e o
modificar la semńtica. La base de esta tćnica se encuentra en una serie de pequeãs transformaciones
a e n
del c´digo que preservan el comportamiento del software. El objetivo del refactoring es encontrar una
o
secuencia de transformaciones que den lugar a una estructura m´s clara, legible y fćil de mantener. Este
a a
problema se ha resuelto utilizando tćnicas de optimizaciń en numerosas ocasiones [42, 134, 222, 251].
e o

2.1.7. Gestiń
o
La gestiń de un proyecto software es una tarea que debe llevarse a cabo durante todo el proceso de
o
desarrollo, controlńdolo en todo momento y realizando los ajustes pertinentes. Para ello, es necesario
a
medir diversos aspectos del producto y del proceso, y tratar de predecir otros como la calidad del soft-
ware. Asimismo, entre las labores de gestiń se encuentra la asignaciń de personal a tareas. De nuevo
o o
aqu´ dividimos los trabajos en tres categor´ modelos de calidad, estimaciń de costes y planificaciń
ı ıas: o o
de proyectos.

Modelos de calidad
Uno de los problemas planteados en la gestiń de un proyecto software es el de la predicciń de la
o o
calidad del software. Bouktif et al. [43] plantean el problema de encontrar un modelo preciso capaz de
predecir la calidad del software en base a una serie de atributos externos e internos de ´ste.
e
Al equipo encargado de garantizar la calidad de un proyecto software le puede interesar la posibilidad
de obtener una lista de los m´dulos del software ordenados de acuerdo a su calidad, para as´ acometer
o ı
las acciones de mejora adecuadas. El problema de ajustar un modelo para la obtenciń de estas listas de
o
m´dulos es abordado por Khoshgoftaar et al. en [160] y [159].
o

Metaheurísticas e ingenieria del software

Metaheurísticas e ingenieria del software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Similar a Metaheurísticas e ingenieria del software

Similar a Metaheurísticas e ingenieria del software (20)

Metaheurísticas e ingenieria del software