Professional Documents
Culture Documents
Septiembre 2002
II
ndice general
Gua de estudio de la asignatura
Presentacin y objetivos . . . . . .
Contexto y conocimientos previos
Esquema y resumen de contenidos
Material y medios de estudio . . .
VII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
2
2
2
3
3
4
4
7
9
9
10
10
14
15
15
17
17
19
20
20
20
22
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
28
28
29
30
30
32
3. Fase de requisitos
3.1. Obtencin de requisitos . . . . . . . . . . .
3.1.1. Introduccin . . . . . . . . . . . .
3.1.2. Tcnicas de obtencin de requisitos
3.2. Anlisis de requisitos . . . . . . . . . . . .
3.3. Representacin de requisitos . . . . . . . .
3.4. Anlisis orientado a objetos . . . . . . . . .
3.5. Validacin de requisitos . . . . . . . . . . .
3.6. Bases de documentacin . . . . . . . . . .
Ejercicios y actividades . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
36
36
36
44
44
44
44
45
48
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
III
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
VII
VII
VIII
IX
ndice general
IV
4. Fase de diseo
4.1. Conceptos y elementos del diseo . . . .
4.2. Diseo estructurado . . . . . . . . . . . .
4.3. Diseo orientado a objetos . . . . . . . .
4.4. Validacin y confirmacin del diseo . . .
4.4.1. Revisin del diseo . . . . . . . .
4.4.2. Verificacin del diseo . . . . . .
4.4.3. Validacin del diseo . . . . . . .
4.5. Documentacin: especificacin del diseo
Ejercicios y actividades . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
50
50
50
50
50
50
51
51
52
5. Fase de implementacin
5.1. Guas de estilo de codificacin . . . . . . . . . . .
5.1.1. Traduccin del diseo a la implementacin
5.1.2. Estilo de programacin orientado a objetos
5.1.3. Normas para programadores en C . . . . .
5.1.4. Normas para programadores en C++ . . . .
5.1.5. Normas para programadores en Java . . .
5.2. Tcnicas de depuracin . . . . . . . . . . . . . . .
5.3. Documentacin del cdigo . . . . . . . . . . . . .
5.3.1. Tipos de comentarios . . . . . . . . . . . .
5.3.2. Consideraciones generales . . . . . . . . .
Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
54
54
57
59
61
67
69
70
70
70
71
6. Fases de pruebas
6.1. Verificacin y validacin a lo largo del ciclo de vida
6.2. Tcnicas y mtodos de prueba . . . . . . . . . . .
6.3. Documentacin de pruebas . . . . . . . . . . . . .
Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
73
73
74
74
75
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
77
77
78
78
78
79
79
79
80
80
81
82
84
85
8. Metodologas de desarrollo
8.1. Introduccin a las metodologas de desarrollo . . . . . . . . . . . .
8.2. Proceso unificado de Rational . . . . . . . . . . . . . . . . . . . .
8.2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.2. Las cuatro P: Personas, Proyecto, Producto y Proceso . .
8.2.3. Proceso dirigido por casos de uso . . . . . . . . . . . . . .
8.2.4. Proceso centrado en la arquitectura . . . . . . . . . . . . .
8.2.5. Proceso iterativo e incremental . . . . . . . . . . . . . . . .
8.2.6. Captura de requisitos . . . . . . . . . . . . . . . . . . . . .
8.2.7. Diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.8. Implementacin . . . . . . . . . . . . . . . . . . . . . . . .
8.2.9. Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3. Mtodo extreme programming . . . . . . . . . . . . . . . . . . . .
8.3.1. Historias de usuario . . . . . . . . . . . . . . . . . . . . . .
8.3.2. Plan de publicacin de versiones . . . . . . . . . . . . . .
8.3.3. Tarjetas CRC: Clases, Responsabilidades y Colaboraciones
8.3.4. Planificacin de cada iteracin . . . . . . . . . . . . . . . .
8.3.5. Integracin . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.6. Codificacin de cada unidad . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
87
88
88
88
90
90
91
91
92
96
98
99
100
101
101
102
102
103
103
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ndice general
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
104
105
105
105
105
106
114
119
119
119
121
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
123
124
124
124
124
124
126
126
127
127
129
129
130
130
130
131
131
132
132
132
133
133
A. Glosario de trminos
135
Bibliografa
141
ndice alfabtico
143
VI
ndice general
Presentacin y objetivos
En esta asignatura de Anlisis, Diseo y Mantenimiento del Software se van a estudiar los mtodos, herramientas y elementos que nos permiten analizar y definir los requisitos incluidos en las especificaciones para producir un programa o aplicacin
informtica. Este proceso se realizar mediante la utilizacin de tcnicas, metodologas y herramientas que en general se componen de un conjunto de fases comunes: extraccin de requisitos, diseo, implementacin, pruebas y mantenimiento. Para entender
cmo se aplican estas fases, se desarrollarn a lo largo del temario unos ejemplos de aplicacin que se utilizarn para ilustrar
cmo se aplican y cul es el resultado de estas fases en casos particulares. Una vez que se conocen los elementos del desarrollo,
es necesario aglutinar estas fases en forma de metodologas que las aplican con diferentes criterios de secuenciacin. Al mismo
tiempo es conveniente conocer algunas de las herramientas disponibles que ayudan en la aplicacin de las tcnicas descritas.
Esta asignatura est orientada en una doble vertiente: por un lado est la ingeniera del software clsica y por otro la orientada a
objetos, hacindose ms incapi en esta ltima. A lo largo de todos los temas existe un doble tratamiento de estas dos vertientes.
ndice general
VIII
nmero de crditos) y se estudia en el cuarto curso de la titulacin. Los descriptores generales de esta asignatura simultnea son:
Anlisis de aplicaciones. Gestin de configuraciones. Planificacin y gestin de proyectos informticos..
Esa asignatura simultnea est estructurada por cuatrimestres. El primer cuatrimestre est dedicado al Proceso Software
Personal (PSP). El objetivo del PSP es adquirir una correcta disciplina personal para el desarrollo de un software de calidad en
los plazos y costes comprometidos. El segundo cuatrimestre est dedicado a la gestin global del proceso de desarrollo software
en el que intervienen decenas o centenares de ingenieros. Tambin es un objetivo obtener un software de calidad en los plazos y
costes planificados. Sin embargo en este caso es muy importante la problemtica y las tcnicas de trabajo en equipo.
Dicha asignatura y la asignatura objeto de esta gua se complementan para dar una visin general del proceso completo
de la produccin de software (Ingeniera de Software), tanto desde el punto de vista tcnico del propio software como de su
integracin con el equipo humano, igual que en cualquier proceso productivo industrial. Por tanto, es evidente que la relacin
con esta asignatura ser muy importante en cuanto al estudio en paralelo de ambas. Ya que los conceptos estudiados en esa
asignatura son aplicados o evaluados sobre los conceptos estudiados en la que es objeto de esta gua.
Como ya se ha comentado en el apartado anterior, simultneamente se cursa tambin la asignatura Inteligencia Artificial e
Ingeniera del Conocimiento que est ms relacionada con esta por la va de la frontera entre la Ingeniera del Conocimiento y
la Ingeniera del Software.
Esquema:
Tema 1: Contexto de la Asignatura en la IS
Necesidad de una metodologa
Ciclo de vida del software
Notaciones de especificacin y diseo
Sistemas Informticos I coincide parcialmente en el tiempo (2o cuatrimestre) con esta asignatura.
ndice general
IX
Obtencin de requisitos
Anlisis de requisitos
Representacin de requisitos
Validacin de requisitos
Bases de documentacin
Herramientas CASE
CVS (Concurrent Versioning System)
Entornos de desarrollo de interfaces
edicin anterior (4a ed. de 1997) tambin es utilizable, puesto que los cambios son pequeos.
Adems al final del libro base [Pre01] hay un apndice que recopila todas las siglas en ingles y castellano usadas profusamente en Ingeniera del Software.
ndice general
Medios Adicionales
Adicionalmente a esta gua, el alumno dispondr de los medios de comunicacin habituales con su Profesor Tutor en el Centro
Asociado o a travs de los Cursos Virtuales de la UNED http://virtualdb.uned.es/, y tambin con el Equipo Docente en
la Sede Central (en las direcciones, telfonos y horarios indicados en la Gua de Curso). Esto se complementa con los canales de
comunicacin y recopilacin de informacin tanto en soporte fsico (CDROM) como en lnea a travs de la pgina de Internet de
la asignatura en la UNED http://www.ii.uned.es/superior/cuarto/ADMSoft.html. En todos estos medios se incluir la
informacin particular de referencias y contenidos que se detallan en los captulos de esta gua, con la ventaja adicional de que en
los medios en lnea los enlaces de direcciones en Internet y otros materiales se irn ampliando y actualizando ms frecuentemente.
Adems del libro base (que contiene al final de cada captulo otras lecturas y fuentes de informacin) y del material incluido
en esta gua, tambin se recomiendan como bibliografa complementaria general los libros [Som98] (o la edicin en ingls ms
reciente [Som01]) y [RBP 96]:
Evaluacin
La evaluacin oficial de la asignatura se har por medio de las pruebas presenciales habituales de la UNED. Se harn dos
pruebas parciales, una para cada cuatrimestre. Las pruebas subjetivas consistirn en una parte de preguntas (1 2) tericas breves
sobre aspectos relevantes del temario correspondiente, ms otra parte prctica compuesta de 1 2 ejercicios con supuestos
prcticos que describirn parcialmente un problema de diseo de software sobre el cual se pedir al alumno completar o extender
algunos aspectos relacionados con el temario correspondiente. La puntuacin correspondiente a cada pregunta se especificar en
el enunciado. En la nota final se tendr en cuenta la compensacin entre preguntas dentro de un mismo examen parcial as como
la compensacin de ambos parciales.
En algunos captulos puede haber propuestas para realizar prcticas por el propio alumno, estas sern totalmente voluntarias
(y que por tanto no podrn ser tenidas en cuenta para la puntuacin de la nota final), pero se recomienda al alumno su realizacin
para ayudarle a una mejor comprensin de los temas.
Captulo 1
Para los ciclos de vida se da una descripcin de en qu consiste cada uno y una lista de ventajas e inconvenientes. Tambin
este apartado est en esta gua y, se puede aadir el estudio en el libro base [Pre01, secs. 2.3 a 2.12].
Notaciones de especificacin y diseo (UML): La mejor forma de asimilar esta parte consiste en ir haciendo ejemplos.
En esta gua se incluye este apartado a estudiar junto con el apartado del libro base [Pre01, sec. 22.5]. Tambin puede ser
conveniente una lectura somera del captulo 20 en el mismo [Pre01, cap. 20] (o bien [Pre97, cap. 19] en la 4 a edicin).
1.1.1. Sistemas
La Ingeniera de Sistemas es el contexto genrico en el que se pueden situar las herramientas y metodologas usadas para
crear sistemas. Un sistema puede estar formado por subsistemas de diferentes tipos. La ingeniera de sistemas es el primer paso
que se da y proporciona una visin global del sistema en su conjunto, posteriormente, se analiza cada subsistema con la rama de
la ingeniera adecuada. Una de esas ramas es la ingeniera del software.
La Ingeniera del Software trata, segn Bauer [Bau72], del establecimiento de los principios y mtodos de la ingeniera,
orientados a obtener software econmico, que sea fiable y funcione de manera eficiente sobre mquinas reales.
El sistema es un conjunto de elementos que cooperan entre s para proporcionar una funcionalidad. En el caso de un sistema
informtico hay dos tipos de elementos: Hardware y Software.
Procesos
Flujos de datos
Almacenes de datos
Los procesos individuales se pueden a su vez descomponer en otros DFD de nivel superior.
Especificaciones de procesos: Es lo que se escribe para uno de los procesos definidos en el DFD cuando no se puede
descomponer ms. Puede hacerse en pseudocdigo, con tablas de decisin o en un lenguaje de programacin.
Diccionario de datos: Son los nombres de todos los tipos de datos y almacenes de datos junto con sus definiciones. La
informacin que se incluye en l se puede ver en [Pre01, sec. 12.7].
Diagramas de transicin de estados: Modelan procesos que dependen del tiempo
Diagramas entidad-relacin: Los elementos del modelo E/R se corresponden con almacenes de datos en el DFD. En este
diagrama se muestran las relaciones entre dichos elementos
Los lenguajes de programacin tambin reflejan esta dicotoma que existe entre la metodologas, as existen lenguajes para la
programacin estructurada. Los ms famosos son: Cobol, Fortran, C, Pascal y Modula 2.
Metodologa orientada a objetos
Es una aproximacin posterior.La orientacin a objetos al ser ms reciente cuenta con mayor nmero de adeptos y es previsible que termine sustituyendo a la anterior. Adems cuenta con una serie de ventajas:
1. Estn basadas en componentes, lo que significa que es ms fcil reutilizar cdigo hecho por terceras personas.
2. Es fcil de mantener debido a que los cambios estn ms localizados.
La mentalidad que subyace al diseo estructurado es: Cmo se puede dividir el sistema en partes ms pequeas que puedan ser
resueltas por algoritmos sencillos y qu informacin se intercambian?. En el diseo orientado a objetos la idea es sin embargo:
Cuales son los tipos de datos que hay que utilizar, que caractersticas tienen y como se relacionan?.
La orientacin a objetos supone un paradigma distinto del tradicional (no necesariamente mejor o peor) que supone focalizar
la atencin en las estructuras de datos. El concepto de objetos tuvo sus orgenes en la inteligencia artificial como un modo de
representacin del conocimiento. El primer lenguaje orientado a objetos fue Simula67, desarrollado por Kristen Nggaard y OleJohan Dahl en el centro de clculo noruego, pero el que se considera el primer lenguaje orientado a objetos puro fue Smaltalk,
donde todos los elementos del lenguaje son objetos. El lenguaje C++ fue una ampliacin de C para que soportara objetos, result
muy eficiente y tambin muy complejo. Java es otro lenguaje orientado a objetos derivado del C++ pero con la idea de ser ms
sencillo.
Objetos y clases Un objeto consta de una estructura de datos y de una coleccin de mtodos (antes llamados procedimientos
o funciones) que manipulan esos datos. Los datos definidos dentro de un objeto son sus atributos. Un objeto solo puede ser
manipulado a travs de su interfaz, esto es, una coleccin de funciones que implementa y que son visibles al exterior.
Las clases y objetos tienen muchas caractersticas:
1. Herencia: Es una relacin de generalizacin, cuando varias clases comparten caractersticas comunes, estas se ponen en
una clase antecesora.
2. Polimorfismo: Es la capacidad de un objeto de presentar varios comportamientos diferentes en funcin de como se utilice,
por ejemplo, se pueden definir varios mtodos con el mismo nombre pero diferentes argumentos.
Durante la etapa de anlisis se identifican los objetos del dominio del problema. En el diseo se definen cuales son las caractersticas de los objetos.
Etapa
Salida
5
Analisis
Diseo
Codificacion
Pruebas
Mantenimiento
Si se comete un error en la fase de anlisis no lo descubrimos hasta la entrega, con el consiguiente gasto intil de
recursos.
El cliente no ver resultados hasta el final, con lo que puede impacientarse .
No se tienen indicadores fiables del progreso del trabajo (sndrome del 90 %). 1
Es comparativamente ms lento que los dems y el coste es mayor tambin.
Tipos de proyectos para los que es adecuado
Aquellos para los que se dispone de todas las especificaciones desde el principio, por ejemplo, los de reingeniera.
Se est desarrollando un tipo de producto que no es novedoso.
Proyectos complejos que se entienden bien desde el principio.
1 Consiste en creer que ya se ha completado el 90 % del trabajo, pero en realidad queda mucho ms porque el 10 % del cdigo da la mayor parte de los
problemas
Como el modelo en cascada ha sido muy popular ha generado algunas variantes. Ahora veremos algunas.
Ciclo de vida en V
Propuesto por Alan Davis, tiene las mismas fases que el anterior pero se considera el nivel de abstraccin de cada una. Una
fase adems de utilizarse como entrada para la siguiente, sirve para validar o verificar otras fases posteriores. Su estructura est
representada en la figura 1.3.
Validacion
Analisis
Nivel de
abstraccion
Diseo
Verficacion
Mantenimiento
Pruebas
Codificacion
Tiempo
Analisis
Diseno
preliminar
Iteracion 1
Iteracion n
Diseno
detallado
Diseno
detallado
Codificacion
y pruebas
. . . .
Mantenimiento
Codificacion
y pruebas
Mantenimiento
Analisis de riesgos
Analisis de riesgos
Prototipo 4
Prototipo 3
Analisis de riesgos
Prototipo 2
Analisis
de riesgos
Prototipo 1
Plan del ciclo de vida
Plan de requisitos
Plan de desarrollo
Validacion de
requisitos
Diseno
Producto Sw.
Codigo
Prueba de
aceptacion
Diseno detallado
Pruebas
unitarias
Integracion
y prueba
Restricciones:
Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc.
Desde el punto de vista organizativo: Coste, tiempo, personal, etc.
Dnde es adecuado
Sistemas de gran tamao.
Proyectos donde sea importante el factor riesgo.
Cuando no sea posible definir al principio todos los requisitos.
Fases
Mejora 1
Planificacion
ConstruccionLiberacion
del negocio
Actividades
Planificacion
ConstruccionLiberacion
del negocio
Mejora 2
Planificacion
ConstruccionLiberacion
del negocio
10
1.3.1. Introduccin
Modelos
Cuando alguien intenta resolver un problema complejo lo primero que hace es estudiarlo: Ver cuales son sus componentes,
establecer relaciones entre las partes, comprender sus propiedades e imaginar como funciona de un modo dinmico. Pero como
la mente humana es perezosa, no estarn todos los detalles, slo los esenciales. Esto no es importante, con tal de que la representacin mental funcione igual que el problema real los detalles se pueden abstraer. El resultado de este proceso es un modelo. Por
tanto, modelo es una representacin de la realidad donde se abstrae lo no esencial. Para un mismo sistema se puede establecer
ms de un modelo diferente en funcin de que aspecto interese resaltar o del nivel de detalle que se quiera conseguir.
UML son las siglas de Unified Modeling Language y como su nombre indica es un lenguaje de modelado, es decir, su
utilidad est en que sirve para expresar modelos. No es nada ms que eso, no indica cmo se debe hacer el anlisis o el desarrollo
orientados a objetos y en consecuencia, no es una metodologa de desarrollo, tan solo es una notacin, ahora bien, es la notacin
que se ha convertido en el estndar de facto de la mayor parte de las metodologas de desarrollo orientado a objetos que existen
hoy en da.
Su utilidad est en la especificacin, visualizacin, construccin y documentacin. De esta frase, la palabra visualizacin es
la ms importante; UML es un lenguaje basado en diagramas y est pensado para entrar por los ojos, tanto a los desarrolladores
como a los clientes.
Este captulo no pretende ser exhaustivo, debe entenderse ms bien como una introduccin inicial abreviada.
Historia
Grady Booch, Jim Rumbaugh e Ivar Jacobson (los tres amigos) desarrollaron las tres metodologas de desarrollo orientado a
objetos ms seguidas de la industria. Rumbaugh con su OMT (Object Modeling Technique) y Booch unificaron sus mtodos, de
ello naci la primera versin del UML en el ao 1994. Posteriormente, Jacobson, creador del mtodo OOSE (Object-Oriented
Software Engineering) se uni al grupo. Actualmente el UML va por la versin 1.3 y la 2.0 est en preparacin.
Ascensor
<<Info de identificacion>>
Estereotipo
marca:String = SYBSA
modelo:String
numeroSerie:String
<<Info de posicionamiento>>
Restriccion
pisoActual:integer
estadoActual:String
Clase abreviada
Alcance
...
Publico
+ Mover(int,int)
Protegido
# CalcularRuta(integer)
Privado
AlarmaExcesoPeso()
...
Mueve gente de un piso a otro
Responsabilidades
Calcula ruta que optimiza tiempo
{estadoActual=subiendo,
bajando, parado
11
a) Tipo: Atributo:Tipo
b) Valor predeterminado: Atributo:Tipo=Valor Atributo=Valor
c) Restricciones: Las restricciones se pueden poner como se ha visto en el grfico, pero UML cuenta con un mtodo
an ms formal que es el lenguaje OCL.
d) Alcance: Un atributo puede ser pblico(+), protegido(#) o privado(-).
e) mbito: Hay dos tipos
Instancia: Cada objeto tiene su propio valor.
Archivador: Solo hay un valor en todas las instancias de una clase (como las variables static en Java). Estos
atributos aparecen subrayados.
Toda esta informacin es opcional, de hecho la mayora de las veces se pone slo el nombre del atributo.
3. Mtodos: Al igual que los atributos tambin pueden especificar su alcance o mbito. Adems pueden indicar el tipo de
los argumentos que reciben y el tipo del valor devuelto. Tanto si tienen parmetros como si no deben llevar un parntesis
abierto y otro cerrado al final del nombre.
4. Responsabilidades: Es una descripcin de lo que hace la clase en su conjunto. Est informacin casi nunca est en los
diagramas.
La informacin que se ha puesto en la figura de ejemplo es mucho ms de la que se suele mostrar, una clase puede representarse
con un simple rectngulo con su nombre, como se ve en la figura 1.9.
Nombre de la clase
AWT
Button
Canvas
Label
Checkbox
Ascensor
No se tiene en cuenta
el coeficiente de seguridad
del cable
Objetos
Los objetos son instancias de clases (sus atributos tienen valores especficos) y, como se indica en la figura 1.12, se representan poniendo el nombre de la instancia a la izquierda, dos puntos y el nombre de la clase de la que deriva a la derecha.
12
AscensorA : Ascensor
Trabaja para
Empresa
Empleador
Programador
Empleado
matriculado en
1..*
Alumno
*
1..11
Asignatura
0,1
Profesor
13
Navegabilidad Es una propiedad del rol. Indica la posibilidad de ir desde el objeto fuente al objeto destino. Significa visibilidad,
o sea que generalmente se ven los atributos. Por defecto la navegabilidad es bidireccional, pero a veces no ser posible viajar
en ambas direcciones. Por ejemplo, en el caso de la figura 1.15 no es posible la bidireccionalidad debido a que dado un password
no se puede conocer el usuario al que pertenece (al menos en principio).
1
Login
Password
Calificacin Cuando se tiene una relacin uno a muchos existe el problema de la bsqueda, es decir, localizar la instancia
correcta en el lado muchos. Para reducir el nmero de instancias a uno se utiliza un atributo de la relacin, representado como
se ve en la figura 1.16.
Estudiante
1..*
Cursa
1..11
1
Estudiante
Asignatura
Cursa
N. Matricula
1..11
Asignatura
Agregacin Es un tipo de relacin del tipo todo/parte y se representa como se muestra en la figura 1.17. Sirve para modelar
elementos que se relacionan utilizando expresiones como: es parte de, tiene un, consta de, etc. Todo lo que se ha dicho
antes acerca de la multiplicidad es vlido aqu.
Continente
1
1..*
Pais
Composicin Es un tipo de agregacin donde cada componente pertenece a un todo y slo a uno (en el ejemplo anterior no se
cumple esto, por ejemplo, la antigua Unin Sovitica tena una parte europea y una parte asitica). En la figura 1.18 vemos un
ejemplo de este tipo de relacin.
Herencia y generalizacin Indica que una subclase o clase secundaria hereda los mtodos y atributos definidos en una superclase o clase principal. La superclase es ms genrica que la subclase. Este tipo de conexin se lee como es un tipo de.
En UML se utiliza el trmino generalizacin en vez de herencia, pero es lo mismo. En la figura 1.19 se muestra un ejemplo de
representacin.
Dependencias Es un tipo de relacin en la que una clase usa a la otra. Por ejemplo: Una interfaz de un programa de dibujo
tiene varios objetos en la pantalla. La clase Pantalla tiene el mtodo DibujarObjetoGrafico(o:OG) y dibujar una recta, un
punto, etc en funcin de lo que sea ese objeto. Esta relacin se representa como en la figura 1.20.
Interfaces Son un conjunto de operaciones que especifican parte de la funcionalidad proporcionada por una clase. Una interfaz
es como una clase pero sin atributos. Se representa de dos formas como se muestra en la figura 1.21. En una como una clase con
el estereotipo interfaz y en otra abreviada, sin mostrar los mtodos. Entre los interfaces tambin existe herencia. Una clase puede
implementar varios interfaces, y un interfaz puede ser implementado por ms de una clase. Todos los mtodos de un interfaz son
pblicos.
14
Motor
Ascensor
Cable
1
1
Cabina
Profesor
P.Asociado
P.Ayudante
P.Interino
P.Titular
Catedratico
T.Completo
T.Parcial
Figura 1.19: Herencia. Las clases abstractas van en cursiva
Pantalla
ObjetoGrafico
DibujarObjeto
15
Dibujable
<<Interfaz>>
Dibujable
ObjetoGrafico
ObjetoGrafico
Dibujar()
Portada
1..1
Titulo
Autor
Paginas
Ver
Idioma
Texto
1..1
Ver
*
referencia a
Consultar
Abrir
Leer
Cerrar
1..1
1..1
> traducido en
> citado en
Libro
traducido
Diccionario
Libro hipermedia
Leer pagina
*
Diccionario
multivolumen
1..1
1 . . 1000
Anexo
video
CDROM
Anexo
Editorial
Anexo
Sonido
Enlace
Contenido
Pagina
destino
Escuchar
Volumen
Rango (AZ)
Activar
hiperenlace
16
: Motor
miCoche : Coche
matricula = WWW 1234
modelo = Citroen ZX 1.9 D
color = verde
: AsientoDelantero
: AsientoDelantero
: AsientoTrasero
: Carroceria
: Salpicadero
LLamar ascensor
Comprobar
producto
<<extend>>
<<include>>
Relizar venta
producto
1. Include: Es el concepto de subrutina. Si por ejemplo tenemos dos casos de uso A y B que tienen una serie de pasos en
comn se ponen esos pasos en un tercer caso de uso C y A y B lo incluyen para usarlo.
2. Extends: Significa que un caso de uso B es igual al A al cual extiende aadiendo algunos pasos.
3. Comunicates: Comunica un actor con un caso de uso o con otro actor.
Modelado del contexto Hay que modelar la relacin que tiene el sistema con los elementos externos. Los pasos a seguir son:
1. Identificar los actores que interactan con el sistema.
2. Organizar los actores.
3. Especificar las vas de comunicacin con el sistema.
Modelado de requisitos Esto significa incorporar los casos de uso necesarios, tanto los que son visibles externamente como
los que no. Para ello las actividades a seguir son:
1. Establecer su contexto.
2. Identificar las necesidades de los elementos del contexto.
3. Nombrar esas necesidades y darles nombre de casos de uso.
17
4. Identificar que casos de uso pueden ser especializaciones de otros y buscar especializaciones comunes para los casos de
uso ya encontrados. Los casos de uso se vern con detalle ms adelante.
Las transiciones entre estados pueden tener parmetros. Cada transicin tiene un evento asociado. Cuando se terminan las actividades de un estado hay una transicin.
Por ejemplo, supongamos que tenemos un ascensor que cuando est en el stano (rea restringida a la que slo se puede
acceder con llave) sube a los pocos segundos para evitar que si alguien se ha colado pueda acceder a las viviendas. Por otra parte
el ascensor puede estar subiendo, bajando o parado. Cuando se est bajando al stano se considera como un estado especial y el
hecho de estar en el stano tambin. Esto se puede representar como en la figura 1.26.
Sotano
llegar
subir
Bajando
al sotano
Subiendo
subir
llegar
Bajando
llegar
bajar
Parado
timeout
18
3. Mensaje: Un mensaje es un objeto que invoca el mtodo de otro. La notacin es una flecha horizontal desde la lnea de
vida de un objeto hasta otro.
4. Tiempos de transicin: Es el tiempo que hay entre un mensaje y otro.
5. Condicionales: Si se desea representar una alternativa o threads. El mensaje slo se enva si la condicin es verdadera. La
condicin se escribe entre corchetes y puede referenciar a otro objeto (ver figura 1.27).
obj 1: Clase A
obj 2: Clase B
obj 3: Clase C
[X] msg
[no X] msg
:Lista
*[hayMasElementos()]siguiente():Elemento
obj2:Clase 1
obj3:Clase 2
mensaje 1
mensaje 2
create
mensaje self
obj4:Clase 3
destroy
Las boundary classes, o clases de frontera, sirven para capturar y documentar los requisitos de interfaz. Muestran la interaccin
con el usuario o con un sistema externo. Las clases de entidad son las inherentes al modelo del dominio y las de control son las
que gestionan el caso de uso asociado al diagrama de secuencias.
Reglas a seguir:
La primera columna debe corresponder al actor que inicia el caso de uso.
La segunda columna debe ser un objeto de frontera, que se comunica con el actor.
19
La tercera columna debe ser un objeto de control que gestiona el caso de uso.
Los objetos de control son creados por el objeto de frontera que inicia el caso de uso.
Los objetos de frontera son creados por objetos de control.
Los objetos de entidad son accedidos por objetos de control y frontera.
Los objetos de entidad nunca tienen acceso a los objetos de frontera o control. De esta forma estos objetos pueden ser
reutilizados en varios casos de uso distintos.
Ducha
Desayuno
Ver tele
Cerrar puerta
Esperar 30
segundos
[quiero andar]
Ir andando
Abrir puerta
abrir(puerta)
abrir(puerta)
Conducir
1.
2.
3.
4.
5.
20
Componente
Interface
<<library>>
listas.dll
1. Identificar los componentes, particiones del sistema, cuales son factibles de ser reutilizadas, agruparlas por nodos y realizar
un diagrama por cada nodo que se quiera modelar.
2. Identificar cada componente con su estereotipo correspondiente (executable, library, etc).
3. Relacionar los componentes entre s.
Cdigo fuente Podemos usar estos diagramas (ver ejemplo en la figura 1.33) para expresar las dependencias que existen entre
los mdulos para formar libreras o programas ejecutables.
<<file>>
A.h
<<file>>
B.h
<<file>>
Agenda.h
<<file>>
Agenda.exe
21
Jugador
1:r1:=lanzar()
2:r2:=lanzar()
d1:Dado
d2:Dado
Servidor
BD
Oracle
Cliente
Palencia
Ap. Ventas
Cliente
Madrid
Cliente
Barcelona
Ap. Ventas
Ap. Ventas
Tutorial posterior
Resumen de contenidos
ste es el captulo introductorio donde se aborda cmo es la divisin en fases de un proyecto (ciclos de vida), las caractersticas de las metodologas que ordenan esas fases y una notacin muy habitual actualmente que se utiliza a lo largo de todo el ciclo
de vida de un proyecto.
1. Metodologas: Es una justificacin del porqu de la ingeniera del software. Se define lo que se entiende por sistema y
por metodologa (una forma podra decirse burocrtica de producir un sistema con costes y tiempos controlados). Se
establece tambin una clasificacin de las metodologas que, al igual que como se ver con los ciclos de vida, pertenecen
a dos tipos principales: estructurada y orientada a objetos.
2. Ciclos de vida: Se explica lo que es un ciclo de vida, las fases de las que se compone y la forma en la que se ordenan estas
fases. Hay una clasificacin de los distintos ciclos de vida que se pueden dar en un proyecto. Bsicamente, hay dos tipos
principales que son: el ciclo de vida en cascada (el ms antiguo y preferido en la metodologa estructurada) y el ciclo de
vida en espiral (el ms nuevo, preferido en la metodologa orientada a objetos) que se dividen a su vez en varios subtipos
para cumplir diferente propsitos. Los ciclos de vida son:
a) Ciclo de vida en cascada. Subtipos: ciclo de vida en V, Sashimi, cascada con subproyectos, cascada incremental y
cascada con reduccin de riesgos.
b) Ciclo de vida en espiral. Subtipos: Fuente y adems los subtipos cascada incremental y cascada con reduccin de
riesgos que tambin se pueden considerar como ciclos de vida en espiral.
3. Notaciones de especificacin y diseo (UML): Se da una introduccin breve a la notacin UML. Existen libros muy
completos al respecto, aqu solo se dan nociones bsicas para comprender un diagrama. El motivo de explicarlo en este
tema es que se trata de una notacin que se puede seguir a lo largo de todas las fases del ciclo de vida.
Previamente se definen los elementos de los que constan los diagramas. Despus se detallan los diagramas que lo componen.
a) Diagrama de casos de uso: Es la forma en la que se lleva a cabo la especificacin, que puede servir tanto para
metodologas clsicas (estructuradas) como orientadas a objetos. A partir de este diagrama se pueden sacar un esbozo
de las clases de las que consta el sistema y las relaciones entre ellas.
22
b) Diagrama de clases: Es el ms importante, muestra las clases en las que se divide el sistema o subsistema, informacin acerca de las mismas (atributos y mtodos), notas (comentarios) y las relaciones que existen entre ellas
(herencia, asociacin, agregacin). El diagrama de clases junto con el de casos de uso es la piedra angular del resto
de diagramas.
c) Diagrama de estados: Bsicamente es un autmata finito como los que se estudiaron en la asignatura Teora de
autmatas I y II. Consiste en una serie de estados y transiciones entre ellos. Usados para representar el cambio de
estado de una clase en funcin de eventos.
d) Diagrama de objetos: Muestra objetos (instancias de clases) en un momento concreto de la ejecucin de un programa, como si de una foto se tratara.
e) Diagrama de secuencias: Muestra los objetos y los intercambios de mensajes entre ellos teniendo en cuenta la
temporalidad con la que ocurren.
f ) Diagrama de actividades: Modelan el comportamiento interno de una clase.
g) Diagrama de componentes: Un componente es algn tipo de documento del sistema, como por ejemplo cdigo
fuente, una tabla, etc. Este diagrama modela la organizacin y dependencias entre ellos.
h) Diagrama de colaboracin: Dibuja las interacciones entre objetos organizadas a travs de los objetos y los enlaces
que hay entre ellos. Es equivalente a los diagramas de secuencia.
i) Diagrama de distribucin: Refleja la organizacin del hardware. El elemento principal es el nodo. Uno nodo puede
o no ejecutar componentes. Los enlaces entre nodos representan lneas de comunicaciones.
Extensin de conocimientos
Este tema tambin se puede estudiar en [Som98, cap. 1], [Haw98, caps. 1 al 3] [Sch92, caps. 1 y 2]. Se pueden refrescar
conocimientos previos en [CCEG00] y otros libros especficos de asignaturas previas o simultneas sobre Ingeniera del Software,
por ejemplo en [Hum95] [Hum01].
La revista en lnea Software Development http://www.sdmagazine.com/, puede ser una buena fuente para encontrar
artculos (en ingls) sobre temas de IS en general. Para una extensa coleccin clasificada y con buscador de bibliografas (mayoritariamente en ingls) sobre Ingeniera del Software en general, se puede consultar la pgina http://liinwww.ira.uka.de/
23
bibliography/SE/ dentro de The Collection of Computer Science Bibliographies. Tambin puede ser interesante la gua al
SWEBOK (Software Engineering Body of Knowledge) en http://www.swebok.org/ que es una iniciativa conjunta del IEEE y
la ACM para expresar el conjunto de conocimientos bsicos en Ingeniera del Software.
Sobre el lenguaje UML se pueden extender conocimientos en varios libros especficos del tema como [JBR00a, JBR00b,
Fow97] [Sch01b], o bien a travs de las pginas de Internet: http://www.omg.org/technology/uml/ del Object Managenemt Group (OMG). En la pgina http://usuarios.lycos..es/oopere/uml.htm se puede encontrar una introduccin a
UML de Pere Martra muy interesante.
Hay una herramienta de libre distribucin para la representacin mediante diversos mtodos (incluido UML) en http://
wwwhome.cs.utwente.nl/~tcm/ llamada TCM (Toolkit for Conceptual Modeling). En http://www.argouml.org/ se puede
encontrar A RGO UML que es una herramienta libre (implementada en Java y licencia BSD) especfica para la representacin
en UML. Tambin se puede encontrar informacin en http://uml.sourceforge.net/index.php sobre el programa UML
Object Modeller (para KDE en GNU/Linux) para dibujar diagramas de UML.
24
Captulo 2
26
gestin comercial de la empresa para simplificar el problema, pero por otro lado aporta suficientes dificultades que se han de ir
desentraando en cada una de las fases del desarrollo.
Uno de los requisitos de la aplicacin es que sea segura, es decir, que no puedan existir terceras personas escuchando, para
ello se puede utilizar el protocolo https. La aplicacin tiene dos partes:
Oferta
1. Cada producto tiene: Foto, descripcin, Cdigo, PVP.
2. Ofertas (p. ej.: Lleve dos y pague tres, etc): Las ofertas son diferentes en funcin de que el cliente sea una persona o una
empresa, y tambin dependiendo de si es o no un buen cliente, por tanto hay que guardar toda la informacin relativa a
cada venta.
3. Forma de hacer pedidos: Se rellena un formulario. Si es la primera vez que se hace el pedido, el cliente rellena un formulario
de datos personales y bancarios que se almacenan en una base de datos.
Demanda
1. Hay una lista de artculos demandados con el mximo nmero de unidades que se admiten y que los mayoristas pueden
consultar.
2. La oferta de un mayorista consiste en una lista de:
a) Nombre de artculo.
b) Precio unitario.
c) Cantidad de artculos a partir de la cual se tiene ese precio unitario. (Cuantos ms artculos se compren menor es ese
precio)
3. Una vez hecha una oferta se almacena en una base de datos.
4. Existe la posibilidad de que el mayorista ofrezca artculos que no estn en la base de datos (novedades).
Cada una de estas ofertas es un lote de productos que el mayorista vende juntos. Un mayorista puede hacer mltiples ofertas. En
funcin de las ofertas de los proveedores se toman las decisiones de seleccionar uno u otro. Las ofertas pueden ser complejas,
pudiendo ofertar un mismo artculo a precios diferentes en funcin de la cantidad de artculos o en ofertas que consisten en un
lote de productos.
27
28
Base de datos
Servidor
Clientes
Una aplicacin en el lado del proveedor que dialoga con la nuestra
En el cliente estaran todos los formularios y se mandara el contenido en la forma de los objetos adecuados al servidor.
Personas
29
Empresa
chips
Aptitudes
Productos
Tareas
Produccion
Pedidos
Clientes
Produccion
Productos
Tareas
Gestion
Almacen
1
Gestion
Personas
2
Pedidos
Clientes
Aptitudes
Personas
30
Adems se va a dividir la informacin en dos tipos: Pblica y privada. La informacin pblica est a la vista de cualquier persona
que utilice el programa. La informacin privada slo la puede recuperar la persona que la ha introducido, para lo cual ser
necesario que cada persona tenga un login y un password (slo si esa persona quiere introducir o leer informacin en un rea
privada). Esto significa que hay que hacer una gestin de usuarios.
Se desea tambin que exista algn mecanismo para dividir los tipos de personas en categoras, de forma que se distinga entre
compaeros del trabajo, amigos, familiares, etc. Esto puede implementarse como un atributo ms de los relativos a la persona,
pero debe usarse tambin de algn modo en la interfaz de usuario de tal forma que sea fcil seleccionar entre los diferentes tipos
de personas (el usuario no sabe SQL ni similares).
Se cuenta tambin con la posibilidad de recuperar elementos borrados. Cada vez que se borra un elemento no queda borrado
del todo, se almacena en un rea conocida como limbo, del cual se puede recuperar. Si un elemento es eliminado del limbo
desaparece definitivamente.
Los datos se pueden guardar de dos formas: en una base de datos o en ficheros. Ambos mtodos tienen sus ventajas e
inconvenientes. En cualquier caso los datos que se guarden como secretos deben ser cifrados (usando alguno de los algoritmos
criptogrficos que hay publicados) con la clave que se pide al usuario para de esa forma evitar cualquier tipo de intrusin.
En algn lugar de la interfaz de usuario hay que poner un reloj (no se especifica si analgico o digital) y la fecha. El reloj
tiene precisin de segundos.
31
Como estos dos casos de uso son prcticamente idnticos podramos pensar en utilizar la parte comn.
Divisin del sistema
Veamos cmo sera la divisin del sistema. Las entidades externas seran los usuarios (ver figura 2.3). Los procesos que hay
que hacer son:
Insercion
Consulta
Borrado
Modificacion
Agenda
Usuario
Creacion
Borrado
Acceder como
32
Insercion
Gestion
Libros
Consulta
Borrado
Gestion
Musica
Borrado
Modificacion
Modificacion
Nuevo Usuario
Borrar Usuario
Gestion
Usuarios
Usuario
Acceder Como
Insercion
Insercion
Consulta
Gestion
Videos
Consulta
Gestion
Personas
Borrado
Borrado
Modificacion
Modificacion
Tutorial posterior
Resumen de contenidos
Este captulo consiste simplemente en un conjunto de tres ejemplos que se plantean, tanto en su descripcin, como en el
diseo o preparacin de plantillas de su posible solucin. Estos ejemplos podrn ser utilizados a lo largo del resto de los temas
para ilustrar algunos aspectos de los mismos.
Los ejemplos elegidos son: una aplicacin de comercio en Web, la gestin de proceso en una fbrica de productos elctricos
y una agenda electrnica personal.
33
Extensin de conocimientos
En [Pre01, sec. 28.5] se encuentra una descripcin de un sistema de comercio electrnico, que puede usarse para extraer ms
informacin y descripciones para el primer ejemplo de este captulo. En el apndice A.3 del libro [Som98], se puede encontrar
un conjunto de ejemplos gua alternativos desarrollados en las diferentes fases que pueden resultar muy tiles.
Hay una aplicacin para tienda electrnica de libre distribucin (fuentes incluidos), desarrollado en modo open source (licencia GPL) por O NRICA por encargo de BANESTO, en http://www.cibertienda.org/ que puede servir de gua para el ejemplo
aqu presentado.
34
Captulo 3
Fase de requisitos
Tutorial previo
Introduccin
El primer paso para atacar un problema es conocer cul es el problema y por tanto se necesita saber cules son los requisitos del problema. La extraccin u obtencin de requisitos es el primer paso que va seguido del anlisis de esos requisitos en
base a un modelo del problema. De ese anlisis obtendremos una especificacin de requisitos que debemos validar frente a las
especificaciones iniciales.
Esta fase es la primera que se acomete en el desarrollo del proyecto y es la ms importante, sobre todo, si se tienen en cuenta
las consecuencias de una mala obtencin de requisitos: hacer un sistema que no hace lo que el cliente espera de l. Ocurre que
no es tan sencillo como se puede pensar en un principio, pues muchas veces el propio cliente no tiene una imagen clara del
sistema final o surgen nuevas necesidades a mitad del desarrollo. Para hacer frente a estos problemas hay que: comunicarse de
forma efectiva con el cliente para obtener los requisitos, comprender el problema a resolver, crear un modelo del problema real
y, por ltimo, revisin de la especificacin. Todos estos pasos deben dejar un rastro que se pueda seguir en caso de problemas
posteriores, por lo cual se debe empezar a guardar registro, documentar, ya desde el principio.
36
Fase de requisitos
3.1.1. Introduccin
Un requisito es una capacidad que el sistema debe tener porque el cliente lo ha pedido explcita o implcitamente, lgicamente, la determinacin del conjunto de requisitos es el primer paso a dar en la construccin de una aplicacin. Existen dos subtareas
en la obtencin de los requisitos antes de pasar a la fase de diseo:
Anlisis: El problema a resolver es la comprensin del problema del cliente y que caractersticas debe tener el producto.
Especificacin: Traducir los requisitos a un documento con un formato concreto que pueda servir de entrada a la fase
siguiente.
La obtencin de requisitos es difcil por varias razones:
La naturaleza de los requisitos es cambiante.
Surgen nuevos requisitos en cualquier momento.
El cliente puede no tenerlos claros.
Pueden existir malos entendidos debidos a:
Anlisis
La clave es la comunicacin con el cliente. Para facilitar esta comunicacin se han desarrollado varias tcnicas: entrevistas,
prototipos, desarrollo conjunto de aplicaciones (Joint Application Development, JAD), planificacin conjunta de requisitos (Joint
Requirements Planning, JRP) y casos de uso del UML.
Especificacin
Lo que se consigue aqu es un documento que especifica todos los requisitos, este documento tiene que tener estas propiedades:
Completitud: Estn todos los requisitos.
Concisin: Es importante no hacer una novela, hay que contar lo que hay pero pensando que quien se lea el documento
cobra por horas.
Legibilidad: Es similar al punto anterior, pero el sentido de este es la claridad.
Consistencia: No existen contradicciones internas.
Facilidades de prueba: De algn modo se debe poder comprobar cada uno de los requisitos.
Facilidades de cambio: Es bastante probable que el documento cambie a lo largo del ciclo de vida.
Facilidades de seguimiento: Debe ser posible comprobar si se van cumpliendo los objetivos.
Factibilidad: Los objetivos definidos deben ser conseguibles a un coste razonable.
Tipos de requisitos
Requisitos funcionales: Dicen qu debe hacer el sistema, en el sentido de servicios proporcionados al usuario.
Requisitos no funcionales: Hablan de caractersticas del sistema, como pueda ser la fiabilidad, mantenibilidad, sistema operativo, plataforma hardware, etc.
37
Entrevistas
Todo el mundo pasa por una entrevista en algn momento de su vida ya sea para un proceso de seleccin de personal, un
examen de oposicin o incluso una conversacin con el jefe se podra considerar como una entrevista. Aunque tambin existan
otras tcnicas, esta siempre la tendremos, al menos al inicio del proyecto. Una entrevista tiene tres fases: Preparacin, Desarrollo
y Anlisis.
Preparacin
1. Documentacin: El entrevistador se informa acerca del tema a tratar. Puede hacerlo de varias formas:
Estudiar la bibliografa sobre el tema.
Estudiar documentos sobre proyectos similares.
Inmersin dentro de la organizacin para la que se desarrolla el proyecto
2. Personal: Se seleccionan las personas a las que se va a entrevistar.
Directivos: Dan una imagen de alto nivel de la empresa. Puede ser til para determinar la estructura arquitectnica
de la aplicacin.
Empleados: Dan una imagen de un grano ms fino. Son los que pueden concretar las funciones a implementar.
3. Determinar el objetivo de la entrevista. Previamente a la entrevista se pueden distribuir a los entrevistados cuestionarios
sobre el tema a tratar y una introduccin.
4. Logstica: Temas prcticos acerca de como discurre la entrevista: lugar, hora, minimizar interrupciones, encontrar un
momento en el que todos puedan ir, etc.
Desarrollo Hay tres etapas [PV96]:
1. Apertura: El entrevistador se presenta e informa al entrevistado de cuales van a ser los puntos tratados en la entrevista.
2. Desarrollo: No debe durar ms de dos horas. El entrevistado debera hablar el 80 % del tiempo.
Tcnicas utilizadas:
Preguntas abiertas, tambin conocidas como de contexto libre. No se pueden contestar con Si o No. Por ejemplo: Cul es la lista de pasos para dar de baja un producto?. Ms tarde se pasa a preguntas ms concretas.
Forma de expresarse: Se deben evitar los tecnicismos que el entrevistado pueda no conocer.
Psicologa: El problema fundamental de las entrevistas es que se trata con personas en vez de con mquinas, por eso la
comunicacin es de peor calidad. Hay que tener en cuenta las siguientes reglas entre muchas otras de la comunicacin
no verbal.
No insinuar que el entrevistado debera saber algo que no sabe para que no se ponga a la defensiva. Tambin
hay que dejar claro que los intereses del entrevistador son nicamente la adquisicin de requisitos, no hacer un
examen de conocimientos, y por tanto las lagunas que pueda tener no trascendern a sus superiores.
Lenguaje del cuerpo: Dicen los psiclogos que el 90 % de la comunicacin es no verbal. Se debe estar atento a
los signos que puedan denotar inseguridad en algunos temas para preguntar a otras personas.
Usar tcnicas para mantener la atencin del entrevistado.
3. Terminacin: Se hace un resumen de la informacin recogida (para validar que es correcta) y, de ser necesario, se cita
para la siguiente entrevista. En cualquier caso se debe poder contactar de nuevo con el interesado, por ejemplo para aclarar
algunos puntos. Se agradece al entrevistado que nos haya dedicado su tiempo.
Anlisis
Se trata de ver como utilizar los conocimientos adquiridos. Para ello las actividades son:
38
Fase de requisitos
39
40
Fase de requisitos
Prototipos
Un prototipo es una versin reducida de la aplicacin final. Se puede construir con dos filosofas[Som98]:
1. Prototipos de desarrollo rpido. Sirven para obtener y validar requisitos. Cuando han cumplido esta finalidad se desechan.
2. Prototipo inicial: Se desarrolla el sistema de un modo incremental partiendo de una versin inicial.
El segundo caso se ha discutido ya en el captulo dedicado a ciclos de vida. El primer caso sigue el proceso indicado en la figura
3.1.
Requisitos
iniciales
Desarrollo
prototipo
Evaluacion
Especificacion
Desarrollo
sistema
Validacion
41
1. No existen todos los componentes necesarios para el prototipo que se quiere desarrollar, con lo que hay que desarrollarlos.
2. Los componentes existen, pero no son exactamente lo que se necesita y hay que adaptarlos.
El desarrollo de prototipos con reutilizacin se puede hacer a dos niveles:
1. Nivel de aplicacin: Los sistemas que componen la aplicacin pueden ser compartidos por otras aplicaciones, por ejemplo
se puede insertar un grfico desarrollado con una aplicacin en otra. Las aplicaciones actan como si estuvieran conectadas
entre si al estilo de las tuberas de Unix.
2. Nivel de componente: Los componentes estn integrados en un armazn estndar, como puede ser un lenguaje de desarrollo de componentes, por ejemplo: P YTHON o P ERL o algo ms general como CORBA, DCOM o JAVA B EANS.
JAVA B EANS es un ejemplo de componentes reutilizables. Son un tipo de componentes escritos en Java, que generalmente tienen
algn tipo de interfaz grfica (Enterprise-JavaBeans sin embargo no es as, pues se ocupa ms de la lgica de la aplicacin). Sus
caractersticas son:
1. Tienen un constructor predeterminado sin parmetros (es decir, un bean es una clase que cumple una serie de restricciones)
2. Son persistentes. La persistencia es la capacidad de un objeto de convertirse en un flujo de bytes para por ejemplo poder
ser escrito en disco o recuperado del mismo.
3. No son nunca clases abstractas, es decir, siempre se pueden crear instancias de ellos.
4. Para escuchar un evento se usan estas dos funciones:
public void addEventListenerType(EventListenerType evento)
public void removeEventListenerType(EventListenerType evento)
5. La forma de dar valor o conocer el valor de una propiedad es con mtodos de la forma: getX() y setX(Propiedad
propiedad). Si la propiedad es booleana en vez de getX() se usa isX(). Si la propiedad es indexada se utiliza: getX(int
index) getX() que devuelve un array y los mtodos para asignar valor seran: setX(int index, propiedad)
setX(Propiedad[] propiedad).
Casos de uso
Son una forma de especificar los requisitos de un sistema, un caso de uso consiste en una interaccin de algo externo al
sistema y el sistema. Fueron introducidos por Jacobson en 1992. Aunque es una tcnica definida dentro del ambiente del anlisis
orientado a objetos no tiene que ver con objetos, se podra utilizar perfectamente dentro del anlisis estructurado. Ms adelante
veremos la tcnica de los casos de uso con el ejemplo gua (ver tema 2) de la aplicacin web. Un caso de uso:
Describe la interaccin entre un actor externo al sistema y el sistema con texto en lenguaje natural.
Representa los requisitos funcionales desde el punto de vista del usuario y por lo tanto produce un resultado observable
por l.
Es iniciado por un nico actor.
Realiza una funcionalidad concreta.
Los objetivos de los casos de uso son:
Comprender la funcionalidad del sistema.
Discutir con el usuario nuestra visin de esa funcionalidad.
Identificar conceptos del sistema, clases, atributos y operaciones.
Validar el anlisis y el modelo del diseo.
Proporcionar informacin para las pruebas del sistema y de aceptacin.
Existen dos tipos de elementos:
1. Actores: El actor puede ser tanto una persona como otro sistema que juega un rol en la interaccin con el mismo. Un
mismo rol puede ser desempeado por varias personas y una persona puede desempear ms de un rol. Un usuario no es
un actor, sino que asume un rol cuando interacta con el sistema y por lo tanto funciona como un tipo de actor.
2. Caso de uso: Es la interaccin que se quiere modelar. Pueden agruparse en paquetes y tener relaciones entre ellos.
Identificar actores Un caso de uso se compone de actores y de interacciones de esos actores sobre el sistema. por lo tanto, lo
primero es buscar actores. Teniendo en cuenta lo que es un actor, hay que encontrar la siguiente informacin:
1. Identificar los usuarios del sistema. Para ello tener en cuenta para quien se est diseando o con que personas va a
interactuar de un modo directo (actores principales) y quienes va a tener un papel de supervisin o mantenimiento del
sistema (actores secundarios).
2. Identificar los roles que juegan esos usuarios desde el punto de vista del sistema. Hay varios tipos, gestores de alto nivel,
gente que introduce datos, etc.
3. Identificar otros sistemas con los cuales exista comunicacin. Estos sistemas tambin se consideran como actores dado
que son algo externo a nuestro sistema.
42
Fase de requisitos
Identificar operaciones Una vez que se tienen los actores se trata de encontrar los casos de uso, como lo que tenemos en este
momento son los actores, partimos de esta base para encontrar la informacin que falta. Los actores interactuaran con el sistema
realizando un conjunto de tareas que tendremos que enumerar y manejarn informacin, tanto la que suministren al sistema
como la que el sistema les suministre a ellos. Una vez que se dispone de los actores y de los casos de uso hay que encontrar las
relaciones que hay entre ellos. Las relaciones que hay entre casos de uso son de dos tipos:
Aquellas en las que uno extiende a otro: Son muy parecidos (comparten muchos pasos) pero tienen ligeras diferencias
adaptadas a la forma particular en la que se realiza una tarea.
Aquellas en las que uno usa a otro: En esta situacin un caso de uso es similar a una funcin o subrutina que es llamada
por otro.
Otra forma de hallar casos de uso es hacer una lista de eventos. Un evento es una ocurrencia a la que el sistema tiene que
responder. No supone un dilogo como un caso de uso porque ocurre de un modo atmico. Los pasos a seguir en este caso son
por un lado identificar todos los eventos a los que el sistema tiene que responder y luego relacionarlos con los actores adecuados.
Una vez identificados estos casos de uso podemos sacar otros nuevos de varias formas:
1. Por variaciones respecto a casos de uso existentes si:
Existen diferentes actores que puedan utilizar un mismo caso de uso pero con variaciones significativas.
Existen diferentes versiones del mismo caso de uso con variaciones significativas.
2. Buscando el caso de uso opuesto a uno dado, por ejemplo, si tengo dando de alta cliente podra existir el caso de uso dando
de baja cliente
3. Preguntarnos que tiene que ocurrir para que se cumplan las precondiciones de un caso de uso, por ejemplo, para hacer un
pedido es necesario que el cliente entre con su password, con lo que tiene que existir un caso de uso para dar de alta.
Dar detalle a los casos de uso descritos Esto que se ha descrito hasta ahora es la forma de construir un armazn de casos de
uso, veamos como se pueden concretar un poco ms. Para cada caso de uso hay que:
Describir la informacin de entrada y de salida.
La descripcin detallada del caso de uso contiene:
43
Extiende
Extiende
Actualizando contenidos
Cliente
Proveedor
Solicitando reposicion
Gestor
Seleccionador de
proveedor
Proveedor
44
Fase de requisitos
caso de uso hay que definirlo con ms detalle (caso de uso de implementacin o trazo fino).
Casos de uso temporales Son aquellos iniciados no por un actor, sino por un evento de reloj. Se debe indicar el momento en
el que esto ocurre, p. ej.: cada 500 milisegundos. La notacin consiste en poner el caso de uso en un valo con lnea de puntos o
con smbolo de reloj.
Casos de uso primarios y secundarios
Los casos de uso secundarios son aquellos que existen por que son necesarios para
que el sistema funcione pero que no son inherentes a su funcionalidad.
Definicin
La validacin de los requisitos comprueba que estos son correctos. Esta fase debe realizarse o de lo contrario se corre el
riesgo de implementar una mala especificacin, con el costo que eso conlleva.
Los parmetros a comprobar por la especificacin son [Som01]:
1. Validez: No basta con preguntar a un usuario, todos los potenciales usuarios pueden tener puntos de vista distintos y
necesitar otros requisitos.
2. Consistencia: No debe haber contradicciones entre unos requisitos y otros.
3. Completitud: Deben estar todos los requisitos. Esto es imposible en un desarrollo iterativo, pero, al menos, deben estar
disponibles todos los requisitos de la iteracin en curso.
4. Realismo: Se pueden implementar con la tecnologa actual.
5. Verificabilidad: Tiene que existir alguna forma de comprobar que cada requisito se cumple.
El contenido de este apartado se completa con [Pre01, sec. 11.6].
45
a
b
Para cada producto se debe incluir: Nombre, Mnemnico, Nmero de versin y Fabricante.
Para cada interfaz se debe desarrollar en: Motivos para interactuar con el producto y Definicin de la interfaz
acerca de contenido de los mensajes y formatos.
3) Interfaces de comunicaciones. Por ejemplo protocolos de comunicaciones.
c) Restricciones de memoria.
d) Operaciones normales y especficas tales como:
1) Modos de operacin en la empresa del usuario.
2) Operaciones interactivas y no interactivas.
46
Fase de requisitos
47
4. Gestin del cambio del proceso: Seleccionar la gestin del proceso de cambio que deba ser usada para identificar, registrar,
evaluar y actualizar el SRS para que refleje el alcance de los cambios en el proyecto y sus requisitos.
5. Aprobacin del documento: Identificar a las personas que deben dar su visto bueno. Deben constar su nombre, firma y
fecha.
6. Informacin de soporte. Hace que este documento sea ms fcil de usar. Incluye ndice y apndices.
Tutorial posterior
Resumen de contenidos
En este captulo se ven las formas de captura de requisitos y de su representacin. La finalidad de esta fase es producir un
documento que represente los requisitos y que sirva de entrada para la fase de diseo. El anlisis es la forma de conseguir los
requisitos y la especificacin la forma de representarlos.
Tcnicas de obtencin de requisitos
1. Entrevistas: Consiste en hablar con el cliente. Hay que tener sobre todo conocimientos de psicologa.
2. JAD: Consiste en un tipo de entrevista muy estructurada aplicable a grupos de personas. Cada persona juega un papel
concreto y todo lo que se hace est reglamentado.
3. JRP: Es un subconjunto de JAD.
4. Brainstorming: Es un tipo de entrevista que se caracteriza precisamente por lo contrario que la anterior. No tiene ningn
tipo de estructura.
5. Prototipos: Se trata de construir una mini-aplicacin inicial para clarificar algunos puntos y luego tirarla o bien para usarla
como base para aadir ms cosas.
6. Casos de uso: Es la tcnica definida en UML. No est necesariamente asociada a la programacin orientada a objetos,
puede usarse tambin con metodologas ms clsicas.
Anlisis de requisitos
Caractersticas del anlisis antes de la existencia de tcnica alguna del tema: Monoltico, ambiguo, difcil de mantener y
redundante. Posteriormente (aos 70 y 80) surge el anlisis estructurado moderno que es grfico y soluciona algunos de los problemas anteriores. Su objetivo es modelar por separado los datos, procesos y el control usando como nexo comn el diccionario
de datos.
Tcnicas de representacin de requisitos
1. Diagramas de flujo de datos: Se describen los elementos de los que consta, lo que es el diagrama de contexto y heursticas
para desarrollarlo.
2. Diagramas de flujo de control: Es similar a los DFD.
3. Diagramas de estados: Son un tipo de modelizacin matemtica usada tambin en diseo de circuitos, compiladores, etc.
4. Modelo Entidad / Relacin: Usado para representar los datos y la forma en la que se relacionan entre ellos.
5. Diccionario de datos: Se puede definir como el pegamento que mantiene unido a todo lo anterior. Es una descripcin
detallada de los datos.
Anlisis orientado a objetos
Es la otra forma de ver el problema. Se representa el mundo en funcin sobre todo de los datos, caractersticas e interrelaciones entre ellos en vez de en funcin de los algoritmos o funciones.
Propiedades de un sistema orientado a objetos: Abstraccin, Encapsulamiento, Modularidad, Jerarqua, Polimorfismo, Persistencia.
Conceptos importantes: Clase, Objeto y Atributos.
Sesin CRC: Es una simulacin hecha por personas del funcionamiento dinmico de un sistema orientado a objetos. Se basa
en que cada persona representa una clase y su interaccin con las dems. Cada clase tiene escritas sus propiedades en una
tarjeta.
Identificacin de clases, atributos y relaciones entre clases.
Refinamiento del modelo: Consiste en otro conjunto de heursticas para eliminar elementos sobrantes o identificar otros nuevos
en el modelo anterior.
48
Fase de requisitos
Validacin de requisitos
Es la comprobacin de que todo el trabajo anterior se ha realizado bien.
Bases de documentacin
Es el documento que resulta de todo lo anterior pero orientado al cliente, es decir, a las obligaciones contradas con l, la idea
no consiste en usar este documento como entrada para otra fase. Se ha tomado la plantilla de documento definida por el estndar
IEEE 830.
Extensin de conocimientos
Sobre la obtencin, anlisis y representacin de requisitos tambin se puede estudiar en [Som98, cap. 2 y 3], [Haw98, caps.
5 al 10] [Sch92, caps. 3 y 4]. Sobre el anlisis orientado a objetos tambin se puede ver [RBP 96].
El libro [GW89] completo es especfico sobre requisitos.
O UTREACH P ROJECT T OOL es una plataforma de libre distribucin para gestin de proyectos a travs de Web muy orientada
al manejo de los requisitos y la comunicacin entre desarrolladores y clientes. Ver en http://outreach.sourceforge.net/
(hay enlace a una demo interactiva).
Captulo 4
Fase de diseo
Tutorial Previo
Introduccin
Una vez que se han identificado los requisitos para el problema, es necesario idear y componer la forma de la solucin para
el problema. El diseo es la fase en la que se estudia el problema, se identifican las caractersticas que tendra una solucin y
se analiza a su vez cada una de esas caractersticas. En la fase de diseo es ms efectivo utilizar patrones y modelos conocidos
para ir resolviendo partes del problema, es decir modularizar el problema y proyectarlo en mdulos en la solucin. Aunque, el
proceso de diseo es en gran medida ad hoc, es decir, no est tan formalizado como las otras fases y por tanto se apoya bastante
en la experiencia e intuicin de los diseadores.
En este tema se van a proponer las formas de diseo convencionales, una comparacin de los ms utilizados y la validacin
o comprobacin de su adecuacin, junto con la parte correspondiente de documentacin de todo el proceso. Principalmente hay
dos tipos de diseo:
Diseo funcional: Parte de una vista de alto nivel que se va refinando progresivamente. En este caso la atencin se focaliza
en la forma de procesar los datos.
Diseo orientado a objetos: Se entiende el sistema como un conjunto de objetos. Para distinguirlos se identifican los tipos
de datos, sus operaciones y atributos asociados. Los objetos se comunican entre ellos envindose mensajes.
La validacin del diseo comprueba si se siguen las especificaciones del diseo y se cumplen requisitos de calidad. La mejor
forma de redactar la documentacin consiste en seguir una plantilla de un documento estndar rellenando varias secciones.
50
Fase de diseo
Validacin y confirmacin del diseo. Este apartado se incluye en esta misma gua.
Documentacin: especificacin del diseo. Este apartado est contenido en [Pre97, sec. 13.8].
51
Tutorial posterior
Resumen de contenidos
El diseo es la fase que sigue a la especificacin y el anlisis. Consiste en aadir a la representacin anterior los detalle
necesarios para pasar a la implementacin. Al igual que en el captulo anterior, existen 2 tipos de diseo: orientado a objetos y
estructurado. Tambin existen diferentes formas de realizarlo en funcin de caractersticas del sistema (tiempo real, distribuido,
etc.)
Diseo arquitectnico: Independientemente del tipo de diseo (estructurado u orientado a objetos) hay una primera fase que
consiste en la divisin del sistema en subsistemas. Los apartados a tener en cuenta son:
1. Descomposicin estructural: Descomposicin en subsistemas
2. Intercambio de informacin entre subsistemas: Hay dos opciones: con una base de datos central o por medio de
mensajes.
3. Forma de realizar el control: Centralizado o basado en eventos.
Sistemas distribuidos: Son un tipo especial de sistema que merece un tratamiento aparte debido a que parece ser la tendencia
actual. Hay varios tipos de arquitecturas:
1. Arquitectura cliente-servidor: Puede ser de dos o de tres capas.
2. CORBA: Es un sistema de objetos distribuidos. Utiliza IDL como lenguaje de definicin de interfaces.
Diseo estructurado
Es el anlisis clsico. Esta basado en el flujo de los datos a travs del sistema. En una primera fase se hace un diseo
preliminar y posteriormente un diseo detallado. Objetivos: Comprensin, mantenibilidad, facilidad de pruebas e integracin
con otras aplicaciones. Principios: Abstraccin, modularizacin, independencia, arquitectura, ocultamiento de la informacin y
refinamiento paso a paso. Sus elementos importantes son:
1.
2.
3.
4.
5.
Diseo detallado: Es una especificacin con mayor nivel de detalle de las estructuras de datos y algoritmos.
Otras notaciones que forman parte de metodologas pensadas en torno al diseo estructurado son:
1. Diagramas HIPO: Muestran entradas, salidas y funciones. Muestran lo que hace el sistema pero no el cmo.
2. Diagramas de Warnier-Orr: Son una representacin jerrquica de los programas, sistemas y estructuras de datos. Puede
representar iteraciones, secuencias y alternativas.
3. Diagramas de Jackson: Produce un programa a partir de su especificacin. Las entradas y salidas son secuenciales al
igual que el proceso.
52
Fase de diseo
Cules son las principales diferencias entre el diseo estructurado y el orientado a objetos?
Por qu el diseo arquitectnico es el primer paso?
Cules son los tipos de modelos cliente-servidor de tres capas?
Qu es necesario para que un objeto pueda invocar los servicios de otro en CORBA?
Cul es la secuencia de pasos que ocurre cuando un cliente utiliza los servicios de un servidor en CORBA? Podra el
servidor ser cliente de su cliente?
6. Qu nivel de acoplamiento hay entre dos mdulos A y B donde A utiliza una funcin de B pero ambos manipulan el
mismo conjunto de variables globales?
Extensin de conocimientos
Los contenidos de este tema tambin pueden estudiarse en [Som98, cap. 4], [Haw98, caps. 11 al 14] [Sch92, caps. 5 al 8].
Se puede profundizar en el diseo orientado a objetos, por ejemplo, en los libros [RBP 96, Mey98, Boo94, Jac92, WBWW90].
En http://www.nist.gov/dads/ se puede encontrar una recopilacin en forma de diccionario (en ingls) de descripciones
y enlaces sobre algoritmos, estructuras de datos y problemas.
Captulo 5
Fase de implementacin
Tutorial Previo
Introduccin
Una vez que se dispone de un diseo para la solucin del problema, incluso en una fase temprana o provisional del diseo,
ya se puede comenzar a plasmar ese diseo en el cdigo que permita realizarlo o implementarlo. En esta fase el programador
recibe las especificaciones del diseo y transforma esas especificaciones, que pueden estar en formatos mezclados formales,
semiformales o manuales, en un programa o mdulo que las efecte. Esta tarea de modificacin puede estar semi-automatizada
en algunos casos o realizarse de forma completamente manual. En cualquiera de los casos se requiere que esa transformacin
se haga de manera sistemtica y coherente. Las particularidades propias de lenguajes de programacin concretos se estudian en
otras asignaturas y por tanto no se incluirn en este tema. Lo que s se estudiarn son las tcnicas o estilos de codificacin formal.
Durante la implementacin se escribe el cdigo de la aplicacin. Existen una serie de "vicios" en el estilo de codificacin que
pueden hacer que el cdigo sea confuso para terceras personas y en consecuencia difcil de mantener; adems, algunas prcticas
pueden inducir errores. Es especialmente recomendable para esta parte seguir las recomendaciones del PSP (Personal Software
Process). Para realizar el trabajo este debe ser dividido en pequeos mdulos que se reparte entre individuos o pequeos grupos
atendiendo a un grfico de dependencias entre tareas y con la idea en mente de paralelizar tanto trabajo como sea posible. A
medida que se van haciendo los mdulos hay que comprobar que cumplen con una cierta calidad, para ello existen varios tipos de
pruebas. En este capitulo se estudia la necesidad de comprobar la ejecucin correcta del mdulo, por tanto interesan las pruebas
que se hacen a nivel de mdulo, tambin llamadas pruebas unitarias. Adems de todo ello hay dos tipos de manuales importantes
que hay que producir en esta etapa: el manual de usuario y el manual tcnico.
54
Fase de implementacin
Tcnicas de depuracin. El contenido de este apartado se encuentra en [Pre01, cap. 17] (o bien [Pre97, cap. 16] en la 4 a
edicin).
Documentacin del cdigo. El contenido se encuentra en esta gua.
Casos de uso
Los casos de uso son una descripcin del funcionamiento de un sistema. No se les puede aplicar la ingeniera directa o
inversa para generar cdigo o para obtener casos de uso a partir del cdigo como al resto de diagramas en UML, pero veremos
un conjunto de instrucciones para averiguar cules son los casos de uso de un sistema a partir de su comportamiento (ingeniera
inversa).
Se identifican los actores que interactan con el sistema.
Se investiga la forma en la que el actor interacta con el sistema. Puede cambiar su estado o el de su entorno o responde a
un evento.
Se traza el flujo de eventos de un sistema relativos a cada actor. Primero se consideran los flujos principales y luego los
alternativos.
Identificar casos de uso que se puedan fusionar y los que tengan relaciones de uso o de extensin entre ellos.
Se representan los actores y casos de uso identificados en un diagrama.
Definiciones de clases
Es el primer paso para implementar el diseo. En general, para convertir un diagrama de clases en su equivalente en un
lenguaje, lo primero es identificar las reglas de correspondencia al lenguaje de programacin. Puede ocurrir que no exista una
forma de hacer la correspondencia, por ejemplo, en Java no existe la herencia mltiple, con lo que, o bien se prohibe a los
diseadores usarla, o bien se busca algn subterfugio para poder implementar esa caracterstica, lo que aadir complejidad. Los
atributos y operaciones que se han definido en el diseo se tienen que definir dentro de la clase correspondiente como pblicos,
privados o protegidos, aunque este aspecto es probable que se haya definido en el diseo. Hay que definir tambin su tipo.
Definicin de clases en C++
class Punto
{
private:
// Aqu se definen las variables y mtodos privados.
55
56
Fase de implementacin
p.DesplazarHorizontalmente(10);
Uso de la herencia
La herencia es esttica si se determina en el momento de la compilacin, como ocurre en la mayora de los lenguajes, es
implcita si el comportamiento de un objeto depende de su clase y no se puede cambiar y es por grupos si las caractersticas de
herencia se especifican para una clase, no para objetos concretos.
Herencia en C++ Una clase puede heredar de varias clases que se especifican en la declaracin. La subclase se llama derivada.
La forma de heredar puede ser privada, protegida o pblica. El resultado de esto es que los mtodos y variables de la clase
antecesora se heredan con el tipo de acceso de menor grado, por ejemplo, una variable pblica que pertenece a una clase que se
hereda de modo protected se convierte en protected. Ejemplo de la sintaxis:
class Punto: public ObjetoGrafico { ... }
Herencia en Java Est mucho ms limitada. Slo existe herencia simple, aunque una clase puede implementar mltiples
interfaces y las interfaces pueden heredar de mltiples interfaces. Ejemplo:
class Punto extends ObjetoGrafico { ... }
Implementacin de asociaciones
Existen dos formas: punteros y objetos de asociacin. Lo normal es que el lenguaje no tenga definida esta ltima opcin.
Ejemplo: Supongamos que tenemos definido un objeto Recta, que se forma a partir de dos objetos Punto que define el usuario
pinchando en la pantalla, y queremos asociar los dos puntos a la recta. El objeto recibe los dos puntos en su constructor (ver
figura 5.1).
Recta
Consta de
1
Punto
Implementacin en C++
objetos Punto recibidos:
En la implementacin del constructor se copian a los dos punteros de la clase las direcciones de los
class Recta {
private:
Punto *p1,*p2;
public:
Recta(Punto *p1,Punto *p2) {this->p1=p1; this->p2=p2; };
...
}
57
Implementacin en java El puntero est en el lado de la asociacin que necesita acceder a la otra clase, es decir, si es
navegable en ambos sentidos estar en ambas clases:
class Recta {
Punto p1,p2;
Recta(Punto p1,Punto p2) this->p1=p1; this->p2=p2; }
...
}
El problema ahora es: Qu se hace si se tiene una relacin con una cardinalidad indeterminada, o lo que es lo mismo, puede
haber muchos objetos en el otro lado relacionados con una clase dada?.
La respuesta es que si la cardinalidad es alta pero est acotada se puede implementar con un array de punteros. Si no est
acotada se puede tener un conjunto de punteros en una clase contenedora que puede crecer de forma arbitraria.
Reusabilidad
La ventaja de la reutilizacin es que la cantidad de cdigo se reduce por lo que la comprensin del mismo tambin es ms
sencilla. Es ms sencillo reutilizar cdigo en lenguajes orientados a objetos debido a que los mdulos son ms cohesivos y menos
acoplados. El inconveniente es que escribir cdigo reutilizable es ms difcil y siempre va a requerir un esfuerzo adicional.
Existen dos tipos de reutilizacin:
Dentro de un mismo proyecto pueden existir partes redundantes, se trata de descubrirlas y compartirlas por los mdulos
que las usen.
Reutilizar cdigo de un proyecto antiguo en proyectos nuevos. Es ms complicado que el punto anterior, requiere que el
cdigo haya sido escrito siguiendo una pautas que ahora veremos.
Reglas generales de estilo para escribir cdigo reutilizable:
Construir mtodos cohesivos. Un mtodo es cohesivo si realiza una nica funcin o varias ntimamente relacionadas. En
caso contrario hay que dividirlo.
Mtodos pequeos. Un mtodo es grande si sobrepasa una o dos pginas, en cuyo caso habr que dividirlo, con lo que
adems de hacerlo ms sencillo puede que uno de los trozos sea reutilizable.
Mantener la congruencia de los mtodos. Un mtodo se dice que es congruente si tiene un nombre similar a mtodos
similares, condiciones, orden de argumentos, valor proporcionado y condiciones de error.
Separar la poltica de la implementacin. Los mtodos de poltica son los de alto nivel y toman decisiones de control.
Son dependientes de la aplicacin, se entienden y se escriben fcilmente. Son los mdulos que deben comprobar el estado
y los errores. Los mtodos de implementacin son los que hacen el trabajo sucio, es decir, son los que tienen definidos
los algoritmos, pero no son los que toman la decisin de ejecutar o no esos algoritmos. Si encuentran un error durante la
ejecucin deben dar un informe a los mdulos superiores, pero no deben tomar acciones por su cuenta, como son mtodos
autocontenidos son fcilmente reutilizables.
Proporcionar una cobertura uniforme. Consiste en redactar mtodos que sean capaces de tratar todas las combinaciones
de las posibles entradas que se puedan dar, y no slo las actuales.
Generalizar los mtodos. Es similar al punto anterior pero en referencia al modo de funcionamiento y al contexto. Cuando
los valores estn vacos o sean extremos o estn un poco ms all del lmite.
Evitar el acoplamiento. Por ejemplo, el que se da cuando se accede a objetos globales y hay que tener conocimiento de
los mismos para poder utilizarlos.
Evitar los modos. Una operacin con modos tiene una forma de funcionamiento segn el modo en el que est. Lo aconsejable es tener un mtodo distinto para cada modo.
Herencia
Otra forma de reutilizar es escribir cdigo de forma que se pueda heredar. Las reglas de estilo en este sentido son:
Mtodos comunes: Se pone el cdigo comn en un mtodo al que invocan los diferentes mtodos. Si ese cdigo comn
est en varias clases se pone en un mtodo de una clase antecesora.
Factorizacin. Cuando tenemos dos mtodos muy parecidos de clases diferentes se puede utilizar otra aproximacin: El
cdigo comn se pone en un mtodo distinto de una clase antecesora, y es ese mtodo el que, en funcin de la clase en la
que estemos llama a un mtodo u otro. Es corriente utilizar la factorizacin con clases abstractas. En el siguiente ejemplo
de C++, los mtodos A y C son comunes, pero el B es propio de cada clase:
58
Fase de implementacin
class Comun {
public:
A() { ... }
C() { ... }
virtual B() { ... }
MetodoComun() {
A();
B();
C();
}
}
class X:public Comun {
B() { ... }
}
class Y:public Comun {
B() { ... }
}
Delegacin. Si se tiene que ejecutar un mtodo en una clase A que ya est implementado en la clase B, heredar de B slo
para poder utilizar su mtodo es un error, en vez de eso se delega enviando la operacin a B desde A.
Cdigo externo encapsulado. Si se utiliza cdigo de otra aplicacin con una interfaz diferente, en vez de hacer llamadas
directas a ese cdigo es mejor hacer un mtodo o una clase que se encargue de ello. De esta forma, si hay que hacer
modificaciones, estas estarn ms localizadas.
Extensibilidad
Consiste en aadir nuevas funcionalidades al cdigo. Veamos un conjunto de normas a seguir para facilitarla.
Encapsular las clases. Esto significa que slo una clase puede acceder a sus propios datos e implementacin.
Ocultar las estructuras de datos. El motivo es que las estructuras de datos son propias de los algoritmos. Si se hacen
pblicas ser ms difcil cambiar el algoritmo ms adelante.
Ley de Demeter : Evitar recorrer mltiples enlaces o mtodos. Si a travs de las asociaciones un mtodo llega a una clase
vecina, no deben utilizar los enlaces de sta para acceder a una tercera clase, ms bien debera utilizar un mtodo de su
clase vecina para esta operacin, de esta forma no es necesario que el mtodo tenga conocimiento de todas las asociaciones
del modelo, slo de las clases relacionadas con la propia.
Evitar sentencias case basadas en el tipo de objeto. En su lugar se pueden utilizar mtodos. Solo se deben usar esas
sentencias si van a tener en cuenta los atributos de cada objeto.
Distinguir los mtodos pblicos de los privados. Se debe minimizar el nmero de mtodos pblicos para disminuir la
complejidad de la interfaz y porque si se modifican esto afectar a las clases que los utilicen, por eso deben ser diseados con ms cuidado. Los mtodos privados aaden modularidad, dependen de la implementacin de la clase y pueden
modificarse sin que cause efectos secundarios fuera de la clase.
Robustez
Un mtodo es robusto si no falla incluso ante parmetros incorrectos. Directrices para construir programas robustos:
Proteccin contra errores. Debe tenerse en cuenta que el usuario puede producir entradas incorrectas. El sistema debera
dar un mensaje de error y no colgarse. El sistema operativo, el hardware u otra librera pueden contener errores tambin,
para lo cual se deben instalar comprobaciones internas. Las comprobaciones de errores aumentan el tamao y la lentitud
del cdigo. Las relativas al usuario deberan estar siempre, las dems pueden eliminarse en la versin final que se entregue.
Optimizar despus de que funcione el programa.
Evitar los lmites predefinidos. Es decir, utilizar memoria dinmica en vez de estructuras de datos de tamao fijo. Esto da
ms flexibilidad (y algn que otro error).
Disponer el programa para la depuracin y la monitorizacin del rendimiento. En funcin de las facilidades suministradas por la herramienta de programacin, tendremos que aadir sentencias de depuracin, que se ejecutan en funcin
de una variable que indique el nivel de depuracin. Tambin es posible aadir cdigo que recoja estadsticas sobre por
ejemplo el nmero de invocaciones a una funcin.
Grandes sistemas
No es lo mismo trabajar solo que en un grupo, hay que pensar en que son otras personas las que van a utilizar, depurar,
modificar o mantener el cdigo. Las directrices que se indican son aplicables tambin para un proyecto unipersonal.
No empezar a programar de forma prematura. Es decir, antes de empezar el proceso de implementacin hay otras cosas
como la especificacin o el diseo.
59
Crear mtodos comprensibles. Un mtodo es comprensible si terceras personas pueden entender lo que hace.
Hacer que los mtodos sean legibles. Esto significa:
Que los nombres de las variables sean significativos (mejor no utilizar abreviaturas).
Evitar un nivel de anidamiento excesivo.
No utilizar una misma variable temporal para diferentes propsitos en lugares diferentes.
Comprobar la ortografa de los nombres.
60
Fase de implementacin
3. Las cabeceras que definen funciones o variables externas deben ser incluidas en los ficheros que las definen para de esta
forma hacer comprobacin de tipos y que las variables externas siempre sean consistentes con la definicin.
4. No se deben definir variables en un fichero de cabecera.
5. No debera haber ficheros de cabecera anidados. Si es as, se debe poner en el prlogo que ficheros de cabecera son
necesarios.
6. Para evitar incluir la misma cabecera ms de una vez se debe usar la siguiente estructura:
#ifndef EJEMPLO_H
#define EJEMPLO_H
/* Cuerpo de EJEMPLO.H */
#endif
Otros ficheros
El fichero README debe tener una descripcin del proyecto completo. Puede tambin explicar detalles tcnicos acerca
del Makefile, una lista de ficheros dependientes del hardware especfico de la mquina, etc.
Comentarios
Cuando el cdigo y los datos se contradicen probablemente ambos estn mal - Norm Schryer
1. Los comentarios deben describir qu est pasando, cmo se est haciendo, qu significan los parmetros, qu variables
globales se estn usando y cualquier restriccin o error. Los comentarios cortos (una lnea) son para expresar el qu. El
cmo se escribe en unas cuantas lneas que preceden al algoritmo.
2. Los comentarios deben justificar el cdigo que parezca errneo o poco razonable.
3. Las descripciones de estructuras de datos o algoritmos deben hacerse en bloques de comentario de esta forma:
/*
* Comentario
*/
4. Los comentarios dentro de una funcin deben estar correctamente indentados con el cdigo que comentan. Pueden usarse
tanto comentarios de una lnea como de varias. Si el comentario es muy corto se puede poner seguido a una lnea de cdigo,
y si aparecen varios comentarios de este tipo deben estar a la misma altura.
Declaracin de variables
1. Las declaraciones globales se ponen en la primera columna. Las declaraciones externas de datos deben ir precedidas por
la palabra extern. Los lmites de los arrays hay que repetirlos en la declaracin extern.
2. El * de la declaracin de punteros debe estar junto a la variable y no en el tipo.
Mal: char* s,t,v;
Bien: char *s, *t, *v;
3. Las declaraciones de cosas que no tengan que ver entre s deben hacerse por separado.
4. Las llaves para abrir { deben ir en la misma lnea que en los struct typedef y la llave para cerrar } en la lnea
siguiente. Ejemplo:
struct complejo {
real a, b;
};
5. Las variables que deban tener un valor inicial se deben inicializar todas de forma explcita.
6. Cuando un fichero es parte de un todo en vez de ser un programa autocontenido se debe utilizar la palabra static para hacer
las funciones y las variables locales a los ficheros. Una variable debe poder ser accedida desde otro fichero slo cuando
sea realmente muy necesario y se deber comentar.
7. Los tipos ms importantes deben ser remarcados usando typedef.
8. El tipo de retorno se debe declarar siempre.
Declaracin de funciones
Cada funcin debe llevar un prlogo que indique lo que hace la funcin y cmo usarla. Tambin es conveniente aclarar
decisiones de diseo no triviales.
Se debe poner un tipo de retorno para cada funcin. No usar el tipo int por defecto. Si hay que explicar ese tipo, se hace en
el prlogo.
61
Dar siempre nombre de ficheros que sean nicos en un contexto tan grande como sea posible.
El nombre de un fichero include de una clase debera ser: NombreClase + extensin. Respetar las maysculas y minsculas
del nombre de la clase en el nombre del fichero.
1 Utilidad para programadores en C en UNIX que permite detectar declaraciones no usadas, inconsistencias entre tipos, uso de variables antes de su definicin,
cdigo no alcanzable, caminos de ejecucin sin retorno, etc
62
Fase de implementacin
Comentarios
Reglas:
Cada fichero con cdigo fuente debe tener una introduccin con informacin sobre el contenido de ese mdulo.
Todos los ficheros deben tener copyright.
Todos los comentarios se deben escribir en Espaol.
Recomendaciones:
Escribir un breve comentario antes de cada funcin.
Es mejor usar // para los comentarios.
Hay que tener en cuenta que los comentarios de los ficheros include van dirigidos a los usuarios de las funciones o clases, y los
de los ficheros de implementacin a los que mantienen el cdigo.
Ficheros include
Reglas:
Todos los ficheros include tienen que contar con algn medio que impida mltiples inclusiones de ese archivo.
Los siguientes tipos de definiciones deben estar en ficheros include separados:
Clases que se usan como clases base.
Clases que se usan como variables miembro.
Clases que aparecen como tipos de retorno o como tipos de argumento en prototipos de funciones o funciones
miembro.
Prototipos de funciones para funciones o funciones miembro usados en funciones inline miembro que estn definidas
en el fichero.
Las definiciones de clases a las que slo se accede va puntero (*) o referencia (&) no sern incluidas como include.
Nunca especificar las rutas completas en las directivas #include.
Cada fichero de implementacin deber incluir:
Recomendaciones:
Usar la directiva #include nombre_de_fichero.hh para los include definidos por el usuario.
Usar la directiva #include <nombre_de_fichero.hh> para los include de las libreras.
Cada fichero de implementacin debera declarar una constante con una variable de cadena que describa el fichero, as, en
un sistema UNIX el comando what podr ser usado para obtener informacin del fichero.
Nunca incluir otros ficheros en un fichero inline.
Asignacin de nombres
Un identificador consta de: Prefijo, Nombre y Sufijo. El prefijo y el sufijo son opcionales. El sufijo suele ser utilizado por
herramientas que generan cdigo. Reglas:
El identificador de cada clase, tipo enumerado, funcin, constante o variable globales en una librera de clases debe empezar
con un prefijo que sea nico para cada librera.
Los nombres de las variables, constantes y funciones deben empezar en minsculas.
Los nombres de los tipos abstractos de datos, estructuras, typedef y tipos enumerados deben empezar en maysculas
Los nombres que consistan en ms de una palabra, las palabras deben ir juntas y la inicial de cada palabra debe ir en
maysculas.
No usar identificadores que comienzan con _.
Si un nombre comienza por mayscula aparece despus de un prefijo.
Si un nombre no empieza por mayscula estar separado de su prefijo por _.
Recomendaciones:
No usar nombres que slo difieran en que una letra sea mayscula o minscula.
Los nombres no deben incluir abreviaturas que no sean aceptadas por todo el mundo.
Una variable visible en un trozo grande de cdigo debe tener un nombre largo.
Los nombres de las variables deberan recordar para qu sirven.
Se debe escribir el cdigo de forma que sea fcil cambiar los prefijos de los identificadores globales.
Encapsular en una clase: las variables y constantes globales, tipos enumerados y typedef.
63
Estilo
Clases
Reglas:
Las partes de una clase de declaran en este orden: Pblico, protegido y privado. Este es adems el orden que interesa a
la gente. La parte privada la va a leer cualquiera que use la clase, la parte protegida quien quiera heredar y la privada en
general nadie.
No se definen funciones miembro dentro de la definicin de la clase.
Funciones
Recomendaciones:
Recomendacin: Los corchetes que delimitan el comienzo ({) o el final (}) de un bloque deben ir en lneas aparte.
Sentencias de control de flujo Recomendacin: Todas las sentencias de control de flujo (if, else, while, for) deben ir
seguidas de un bloque incluso aunque sea vaco. Ejemplo:
for (char *c=charCadena; *c!=A && *c; c++)
{
}
Punteros y referencias Recomendacin: Los operadores * y & deben estar conectados directamente con el tipo de la
variable y no con la variable misma. Ntese que la recomendacin para el lenguaje C es justamente la contraria.
Miscelnea Recomendacin: No usar espacios alrededor de . -> ni entre operadores u operandos unarios.
Clases
Derechos de acceso Regla: No especificar nunca un dato como pblico o protegido. Los motivos son que:
Slo la propia clase podr manipular esa variable (encapsulacin).
Cualquier funcin del programa podra cambiar ese valor provocando errores.
Evitando que se modifique externamente una variable, se evita tambin que quien modifique esa variable deba tener en
cuenta la implementacin de la clase.
Funciones inline Una funcin inline es aquella cuyo cdigo compilado se sita donde se utiliza, de esta forma no se hace la
llamada y se consigue ms eficiencia. Recomendaciones:
Las funciones de acceso deben ser inline. (Una funcin de acceso slo devuelve un valor de un dato miembro).
Las funciones que slo llaman a otra funcin deben ser inline.
Los constructores y destructores no deben ser inline.
Funciones friend
de la clase.
Recomendacin: Las funciones amigas estn para proporcionar funciones adicionales que estn mejor fuera
64
Fase de implementacin
Constructores y destructores
Reglas:
Una clase que use new para crear instancias gestionadas por la clase debe definir un constructor de copia. Excepciones: Si
una clase tiene un rea de datos compartida no es necesario tener un constructor de copia, tan slo hay asegurarse de que
no se destruya el rea mientras haya punteros que la referencien.
Todas las clases que sean usadas como clase base y que tengan funciones virtuales deben definir un destructor virtual.
No usar objetos globales en constructores y destructores.
Operadores de asignacin
Reglas:
Una clase que usa new para crear instancias gestionadas por la clase debe definir un operador de asignacin. Excepcin:
Si los objetos de una clase tienen un rea de datos compartida no es necesario definir un operador de asignacin. Hay que
asegurarse de que el rea de datos no se destruye mientras haya punteros que la referencien.
Un operador de asignacin que hace una operacin destructiva debe protegerse de realizar esta accin en el objeto en el
que est operando.
Recomendacin: Un operador de asignacin debe devolver una referencia const al objeto que est siendo asignado.
Sobrecarga de operadores
Recomendaciones:
Regla: Los nombres de los argumentos de las funciones tienen que ser los mismos en la definicin y
65
No escribir cdigo que dependa de funciones que usen conversiones implcitas de tipos.
Nunca convertir punteros a objetos de una clase derivada a punteros a objetos de una clase base virtual. Excepcin: Si
una clase base virtual contiene una funcin virtual pura que convierte un puntero a clase base virtual a un puntero a clase
derivada, esto puede funcionar definiendo la funcin en la clase derivada. Esto significa que todas las clases derivadas
deben ser conocidas en la clase base virtual.
Nunca convertir un const a un no const.
66
Fase de implementacin
for: Se usa cuando hay una variable que se incrementa en una cantidad constante cada iteracin y la terminacin
depende de una expresin constante.
while: Cuando la condicin de terminacin se evala al principio de la iteracin.
do-while: Si la condicin de terminacin es mejor evaluarla al final.
Usar siempre unsigned para las variables que no pueden tener valores negativos.
Usar lmites inferiores incluyentes (>=) y lmites superiores excluyentes (<).
Evitar el uso de continue.
Usar break para salir de un bucle si esto evita usar flags.
No usar expresiones lgicas del tipo if(test) if(!test) cuando test es un puntero.
Expresiones
Recomendacin: Usar parntesis para clarificar el orden de evaluacin de los operadores en las expresiones.
Reserva de memoria
Reglas:
No usar malloc, realloc o free.
Usar siempre corchetes ([ ]) cuando se liberan arrays con delete.
Recomendaciones:
Evitar usar datos globales.
No liberar memoria, esperar que algn otro lo libere ms tarde.
Asignar siempre un nuevo valor a un puntero que apunte a memoria liberada.
Manejo de errores
Recomendaciones:
Asegurarse de que el manejo de fallos se ha hecho de tal modo que sea fcil convertirlo al manejo de excepciones.
Comprobar los cdigos de fallo que se pueden recibir de funciones de librera incluso si esas funciones parecen seguras.
Cdigo portable (multiplataforma)
Abstracciones de datos Recomendacin: No usar directamente los tipos de datos predefinidos en las declaraciones.
Tamao de los tipos Recomendaciones:
No suponer que un int y un long tienen el mismo tamao.
No suponer que un int tiene 32 bits (quizs tiene slo 16).
No suponer que un char es signed o unsigned.
Poner siempre unsigned char si se usa ASCII de 8 bits.
Conversiones de tipo Recomendaciones:
Sea cuidadoso cuando haga conversiones de tipo desde uno corto a uno ms largo.
No suponer que los punteros y los enteros tienen el mismo tamao.
Usar conversiones explcitas de tipo para operaciones aritmticas usando valores con signo y sin signo.
67
68
Fase de implementacin
Bien:
x = MetodoLargo (Par1, Par2,
MetodoBajoNivel(Par31,Par32,Par33)
Mal:
x = MetodoLargo (Par1, Par2, MetodoBajoNivel(Par31,
Par32,Par33)
Alinear la nueva lnea al comienzo de la anterior. Si esto pudiera causar confusin indentar (sangrar) con 8 espacios.
Comentarios
En Java hay dos tipos de comentarios: De documentacin y de implementacin. Los comentarios de documentacin tienen la
forma: /* ... */. Existe una herramienta llamada Javadoc que genera pginas HTML partiendo de este tipo de comentarios.
El tema de los comentarios se trata en profundidad en el tercer apartado de este captulo.
Declaraciones
La recomendacin en este sentido es que no se declare ms de una variable por lnea, poniendo el nombre de la variable
indentada y con un comentario. Deben estar localizadas al principio del bloque. Ejemplo:
int numPuntos = 3; // Puntos que definen la figura
Es conveniente inicializar las variables en el lugar en el que se declaran, a menos que esta inicializacin dependa de un clculo
posterior.
Las clases e interfaces deben usar la siguiente convencin:
No se ponen espacios entre el nombre de los mtodos y el parntesis (.
La llave de apertura { aparece en la misma lnea que el nombre del mtodo o clase.
La llave de cierre de bloque } aparece en una lnea a parte del bloque, excepto cuando el bloque est vaco.
Los mtodos se separan por una lnea en blanco.
Ejemplo:
class Punto extends ObjetoGrafico {
int x;
int y;
Punto(a,b) {
x=a;
y=b;
}
Sentencias
Debe haber una y slo una sentencia por lnea. Si hay un bloque de sentencias, ste debe ser sangrado con respecto a la
sentencia que lo genera y debe estar entre llaves aunque slo tenga una sentencia para de este modo evitar errores cuando
se aaden otras sentencias al bloque. Ejemplo:
if (x>1) {
y++;
z=CalcularZ(x,y);
}
else {
y=y-2;
}
Sentencias if-else, if else-if else. A los bloques definidos por estas sentencias se les aplican las normas definidas en puntos
anteriores. Todos los bloques tienen el mismo nivel de sangrado.
Bucles. Definen un bloque, que sigue las normas anteriores. Si el bucle es vaco (no tiene sentencias) no se abren ni se
cierran llaves.
Las sentencias return no deben usar parntesis.
69
Separaciones
Incrementan la legibilidad del cdigo. La regla general es que cuanto ms importante sean las partes a separar tanto mayor
debe ser la separacin. En este sentido el criterio es:
Dos lneas: Entre clases e interfaces.
Una lnea: Entre mtodos, declaraciones de variables y la primera instruccin, secciones lgicas diferentes de un mtodo
y antes de un comentario de lnea o de bloque.
Un carcter en blanco: Entre una palabra y un parntesis, despus de una coma, los operadores binarios menos el ., las
expresiones del for, y entre un cast y la variable.
Ejemplo:
class X {
...
}
class Y extends X{
/* Declaraciones */
int x;
int y;
/** Desplaza la figura pixel a pixel horizontalmente */
int desplazarHorizontal(int h) {
int inc;
if (h<0) {
h = -h;
inc = -1;
}
else {
inc = 1;
}
for (int i=0; i<h; i++) {
x = x + inc;
if (!Dibujar()) {
return -1;
}
}
return 0;
}
/** Desplaza la figura pixel a pixel verticalmente */
int desplazarVertical(int h) {
...
Nombres
Las normas de asignacin de nombres son:
Paquetes: Nombres en minsculas separados por puntos. Ejemplo: java.io.
Clases e interfaces: Dos o tres nombres con la primera letra en maysculas, sin usar abreviaturas. Ejemplo: ObjetoGrafico.
Mtodos: La primera palabra debera ser un verbo y en minsculas. Ejemplo: desplazarHorizontal.
Variables: Deben ser cortas (pueden ser de una letra) y significativas. Si son varias palabras la primera en minscula.
Ejemplos: i, j, k, unTriangulo.
Constantes: Se escriben en maysculas y si son varias palabras van unidas por un carcter de subrayado. Ejemplo:
MAX_LONG = 1000
70
Fase de implementacin
Tutorial posterior
Resumen de contenidos
La implementacin en teora se puede hacer de un modo totalmente automatizado a partir del diseo. Pero como esto en
realidad no es as, se dan una serie de consejos para pasar el diseo a cdigo y como redactar este cdigo en un conjunto de
lenguajes.
Traduccin del diseo a la implementacin
Ingeniera inversa: Consiste en averiguar las especificaciones de un sistema a partir de su funcionamiento. Se dan algunas heursticas para averiguar los casos de uso de un sistema: definiciones de clases, creacin y destruccin de objetos, invocacin
de mtodos, herencia e implementacin de asociaciones.
71
Estilo de programacin orientado a objetos: Son un conjunto de consejos para conseguir: reusabilidad, reconocer la herencia,
construir mtodos extensibles, cdigo robusto y trabajo en grupo eficaz.
Normas para programadores en C: Son un conjunto de normas que cubren todos los apartados de la codificacin, tanto del
tamao de los ficheros, como de la eleccin de nombres (quizs lo ms importante), indentacin, etc.
Normas para programadores en C++: Es una recopilacin similar para el lenguaje C++. Es ms extenso debido a la complejidad del lenguaje. Estas normas fueron compiladas por Ellmentel Telecomunications System Laboratories.
Normas para programadores en Java: Es un resumen de las normas publicadas por S UN para el lenguaje Java.
Tcnicas de depuracin
Consiste en un conjunto de tcnicas para descubrir errores de codificacin. Incluye tambin un pequeo apartado para procesos concurrentes.
Documentacin del cdigo
Al igual que el diseo el anlisis producen documentos segn una plantilla estndar, el cdigo tiene que tener una documentacin interna. Se distinguen los tipos de comentarios (Directorio, prlogo y explicativo), donde se colocan, que informacin se
incluye en cada uno de ellos y la forma de redaccin de la informacin.
Extensin de conocimientos
Tambin se puede estudiar parte de los contenidos de este tema en [Som98, caps. 5 y 6], [RBP 96], [BMP87, caps. 10 al 15]
[Sch92, caps. 9 y 10].
En la pgina http://www.bagley.org/~doug/shootout/ se puede encontrar una recopilacin comparativa de ejemplos
de implementacin (con fuentes) para varias funciones sencillas conocidas en muchos lenguajes de programacin diferentes.
Como curiosidad anecdtica, otro tipo de pgina similar, aunque menos formal, es http://internet.ls-la.net/mirrors/
99bottles/, que recopila el mismo programa ilustrativo simple en ms de 400 lenguajes distintos. Usando cualquier buscador estndar de Internet (como p. ej. http://google.com/) se pueden encontrar infinidad de pginas relacionadas con
cualquier lenguaje de programacin. La herramienta de anlisis y modelado de software A LMA http://www.memoire.com/
guillaume-desnoix/alma/, permite el anlisis de cdigo fuente orientado a objetos para su representacin y modelado o su
transformacin a otros lenguajes. Esta herramienta, A LMA, es muy interesante y al estar implementada en Java es fcilmente
instalable en cualquier entorno.
Es interesante hacer notar que existen ciertos lenguajes de programacin que facilitan y promueven con su sintaxis una
codificacin ms clara, ordenada, sistemtica y autodocumentada. Tal es el caso, por ejemplo, del lenguaje P YTHON que,
normalmente, es interpretado pero que auto-precompila cada fichero fuente ejecutado y reutiliza esa versin precompilada
72
Fase de implementacin
(preanalizada) si no cambia el fuente. Este lenguaje es muy til para hacer prototipos rpidos, pero tambin para aplicaciones ms grandes (por ejemplo vase Z OPE http://www.zope.org/). Prcticamente todas las implementaciones de P YTHON son de libre distribucin. Se puede ver ms informacin en las siguientes pginas Web: http://www.python.org/,
http://www.freenetpages.co.uk/hp/alan.gauld/spanish/ es una traduccin al espaol del libro [Gau01] (un tutorial
bsico), el libro de libre distribucin (licencia FDL) [DEM02] en http://www.ibiblio.org/obp/thinkCSpy/ o un libro en
lnea http://diveintopython.org/es/ (traduccin al castellano de Dive into Python) con varias referencias a otra informacin en espaol, aparte de la pgina http://users.servicios.retecal.es/tjavier/python/Un_poco_de_Python.html
sobre P YTHON de Toms Javier Robles Prado.
Existe una tcnica de escribir la documentacin incluida dentro del cdigo fuente, conocida por el nombre en ingls de
Literate Programming. Se puede encontrar extensa informacin sobre este tema en la FAQ especfica: http://shelob.ce.
ttu.edu/daves/lpfaq/faq.html. Adems hay algunas otras herramientas de ayuda en la generacin de referencias cruzadas
y documentacin a partir del cdigo fuente, como por ejemplo C XREF http://www.gedanken.demon.co.uk/cxref/, la ms
reciente y completa D OXYGEN http://www.doxygen.org/ (que se puede utilizar para otros lenguajes adems de C). Tambin
es interesante ver el ejemplo de cmo un proyecto enorme, como es el kernel del sistema operativo Linux, tiene un sistema de
referencias cruzadas: http://lxr.linux.no/.
Captulo 6
Fases de pruebas
Tutorial Previo
Introduccin
Este tema incluye en su denominacin Fases, en plural, debido a que realmente no hay una nica fase de pruebas, sino que
las pruebas se van realizado en todas las dems fases. Las pruebas en este caso consisten en la comprobacin de que la salida
obtenida en cada fase corresponde a las especificaciones de entrada correspondientes. Las pruebas consumen mucho tiempo,
pero deben hacerse de un modo sistemtico para asegurar que el resultado cumple con el grado de calidad exigido (densidad
de errores por KLDC, etc). Para medir esta calidad existen algunas mtricas. En esta parte del desarrollo se trata de encontrar
errores, no slo de codificacin, sino tambin los relativos a la especificacin o el diseo, en este sentido se puede distinguir entre
verificacin y validacin. La verificacin trata de comprobar si se est construyendo el producto correctamente, la validacin si
es el producto correcto. Las pruebas que se van haciendo durante el ciclo de vida son: ingeniera del sistema (prueba del sistema),
especificacin (prueba de validacin), diseo (prueba de integracin) y codificacin (prueba de unidad). Los tipos de pruebas
tienen naturaleza diferente y en consecuencia, las tcnicas para cada una de ellas son diferentes; tambin se har un recorrido por
cada una de ellas. Inevitablemente tambin hay que aadir la correspondiente documentacin de las pruebas realizadas.
74
Fases de pruebas
El contenido de este apartado se estudia en [Pre01, cap. 18] (o bien [Pre97, cap. 17] en la 4 a edicin).
Plan de pruebas
Son un conjunto de actividades que pretenden demostrar que el producto cumple con lo estipulado en el contrato. En el plan
de pruebas se especifica:
1. Identificador del plan: Debera ser una palabra que lo identificase con su alcance. Hay que incluir adems la versin y
fecha.
2. Alcance: Tipo de prueba y propiedades del software a ser probado.
3. Items a probar: Configuracin a probar y condiciones que se deben satisfacer para ello.
4. Estrategia: Tcnica y herramientas a utilizar. Hay que indicar el nmero mnimo de casos de prueba a realizar y el grado
de automatizacin tanto en la generacin de casos de prueba como en la ejecucin
5. Categorizacin de la configuracin: Condiciones bajo las cuales el plan debe ser:
Suspendido: Si se presentan demasiados defectos o fallos.
Repetido.
Dado por terminado: Si se cumple el nmero mnimo de casos de prueba.
6. Documentacin: Segn el estndar IEEE 829-1983 hay que producir los siguientes documentos:
Plan de prueba.
Especificacin de los requerimientos para el diseo de los casos de prueba.
Casos de prueba. Para cada uno se especifican: Descripcin del procedimiento de prueba y Descripcin del tem a
probar.
Bitcora de pruebas.
Informe de incidentes de prueba.
Resumen de pruebas.
7. Procedimientos especiales: Grafo de las tareas necesarias para preparar y ejecutar las pruebas, as como habilidades
necesarias.
8. Recursos: Pueden ser muy variados
Caractersticas de hardware y software.
Software necesario para hacer las pruebas.
El software a ser probado.
Configuracin del software de apoyo.
Recursos humanos necesarios para el proceso.
Requerimientos especiales: Actualizacin de licencias, espacio de oficina, tiempo de mquina, seguridad, etc.
9. Calendario: Hitos del proceso y grafo de dependencias.
10. Riesgos: Riesgos del plan, acciones para mitigarlos y planes de contingencia.
11. Responsables: Lista de personas y tareas asignadas.
Existen cuatro tipos de pruebas que deben superarse
Pruebas funcionales: Se realizan con los datos de entrada normales en el uso diario del sistema. Se comprueban sobre
todo valores en los lmites de las variables y un poco ms all de los lmites. Tambin algunos valores especiales.
75
Pruebas de desempeo: Miden el rendimiento del sistema. Tiempos de respuesta, utilizacin de la memoria, trfico
generado en las comunicaciones, etc. Estas pruebas nos van a indicar donde estn los cuellos de botella del sistema.
Pruebas de tensin: Se trata de sobrepasar los lmites de tolerancia del sistema de varias maneras: Conectar ms usuarios
al sistema de los permitidos, si tiene que gestionar x mega-bits por segundo de una lnea de comunicaciones probar a
aumentar ese ancho de banda, etc.
Pruebas estructurales: Es un anlisis de la lgica interna de un programa.
Tutorial posterior
Resumen de contenidos
Verificacin y validacin
La Verificacin y validacin se debe llevar a cabo a lo largo de todo el ciclo de vida. Verificacin es comprobar si el producto se
est construyendo correctamente. Validacin es comprobar si estamos construyendo el producto que se nos ha pedido. Se abordan
un conjunto de actividades y tareas para garantizar que se da una respuesta positiva a esas dos cuestiones. Uno de los puntos
importantes es que la V&V debe ser independiente, es decir, no pueden hacerlo las mismas personas que estn construyendo el
producto. Esta independencia se debe dar tanto en la gestin como en la financiacin. Las tareas de V&V se contemplan desde
tres perspectivas: sistemas genricos, sistemas expertos y software reutilizado, y en todas y cada una de las etapas del ciclo de
vida.
Tcnicas y mtodos de prueba
Se trata en esta seccin de realizar las pruebas que den una garanta acerca del cdigo. Se introducen los conceptos de Error,
Defecto y Fallo. Se definen un conjunto de principios que debe seguir toda prueba:
Casos de prueba: Es un conjunto de entradas y salidas esperadas para ellas. Existen dos tipos de pruebas: de caja blanca y de
caja negra. Existe un mtodo para crear casos de prueba para casos de uso.
Pruebas de caja blanca. Tcnicas y medidas: grafo de flujo, complejidad ciclomtica y criterios de cobertura del grafo.
Pruebas de caja negra. Tcnicas: particiones o clases de equivalencia y anlisis de valores lmite.
Cleanroom: Es una metodologa de desarrollo pensada para producir software muy fiable.
Revisiones sin ejecucin de cdigo: wallthroughs, inspecciones y auditoras,
Calidad del software: El modelo de McCall tiene en cuenta una serie de factores de calidad.
Documentacin de pruebas
Como en los dems captulos este es el apartado donde se pone sobre el papel el trabajo realizado con un documento llamado
plan de pruebas que es un documento que pretende demostrar que el producto cumple con lo estipulado en el contrato.
Ejercicios
1. Cules son los motivos por los que es conveniente que las actividades de V&V sean realizadas por un equipo independiente?
2. Cundo es mejor hacer la V&V, despus de construir el producto, antes, despus de una etapa concreta, ...?
3. En el programa de la figura 6.1:
Represntelo en algn lenguaje de programacin.
Halle los valores de a y b para cobertura de sentencias, decisiones, condiciones y decisin/condicin.
Hay algn bucle? De qu tipo? Cuntas veces conviene ejecutarlo?
Extensin de conocimientos
Este tema tambin se puede consultar en [Som98, cap. 7] [BMP87, cap. 16 y 17].
Sobre calidad, pruebas y evaluacin del software, el NIST en Estados Unidos mantiene una pgina muy interesante: http:
//hissa.nist.gov/.
76
Fases de pruebas
a=a3*b
si
a>1000
no
a<100
no
b<3
si
si
msg="a es pequeo y b da igual"
no
Write(msg)
Captulo 7
78
4.
5.
6.
7.
7.1.1. Aceptacin
Se dice que el proyecto ha finalizado cuando todas las actividades tcnicas han terminado o se ha agotado su plazo y se han
facturado todos los conceptos al cliente (se hayan cobrado o no). Para evitar problemas en el momento en el que se pide que al
cliente su aceptacin se debe redactar un documento que especifique claramente los requisitos (lgicamente este documento se
redacta en la fase de especificacin). Una vez que el cliente lo firma acepta que est conforme.
Informe econmico.
Informe de situacin final. Se redacta en lenguaje no tcnico. Incluye:
Datos del proyecto: Nombre, duracin, etc.
Resumen de las incidencias: Modificaciones, problemas, soluciones, sugerencias futuras, etc.
2. Indicadores financieros
79
Porcentaje de endeudamiento externo (ajeno): Es el montante que hay que afrontar en caso de impago. Es el porcentaje dedicado a subcontrataciones, suministros, viajes y gastos varios.
Porcentaje de endeudamiento interno (propio): Son los gastos que en caso de impago la empresa debera satisfacerse
a si misma. Es el complementario del anterior. Porcentaje de endeudamiento externo + Porcentaje de endeudamiento
propio = 1.
Valor actual neto del proyecto:
n
Fi
(7.1)
VA
1
r n
i 1
Donde: Fi son los flujos monetarios del proyecto, n es el nmero de aos o meses desde que se produjo el flujo
monetario y r es la inflacin anual o mensual acumulada desde entonces.
Tasa de rendimiento (R) interno del proyecto.
Ingresos Costes
Costes Tiempo
Margen
Tiempo
(7.2)
3. Indicadores de ocupacin laboral. Indican la cantidad de personal para cada proyecto, su tasa de ocupacin y como consecuencia si sobra o falta gente.
Carga de trabajo: Nmero de horas para realizar un trabajo.
Nmero de personas necesarias para el proyecto.
ndice de ocupacin.
4. Indicadores de gestin. Hay cuatro indicadores de la calidad de este apartado:
Plazo de ejecucin.
Coste (global y por partidas)
Margen.
Contingencias.
80
81
9. Especificaciones del programa: Es otro documento dirigido a los desarrolladores. Son los requisitos, entorno operativo y
caractersticas de diseo de cada uno de los ejecutables.
10. Especificaciones de la base de datos: Descripcin fsica y lgica de la base de datos junto a las especificaciones de
seguridad y control.
11. Pruebas: Estrategia de pruebas del sistema, con especificaciones detalladas, descripciones y procedimientos, as como
datos de prueba y criterios de evaluacin.
12. Manual de usuario: Describe las funciones del sistema. No debe usar jerga tcnica.
13. Manual de operacin: Descripcin del software y del entorno operativo para que pueda funcionar el software.
14. Manual de mantenimiento: Informacin acerca del cdigo fuente, sistemas y subsistemas para que el equipo de mantenimiento pueda entender el funcionamiento del programa y hacer cambios.
15. Plan de instalacin: Una vez que el sistema haya superado todas las pruebas est listo para ser instalado. Este manual
describe como se realiza el proceso en diferentes entornos.
16. Anlisis de la prueba e informe de evaluacin de seguridad: Son el resultado de las pruebas. Se muestran las fortalezas
y debilidades del sistema. Debe incluir un informe de evaluacin de seguridad para certificar el sistema.
Que el usuario sepa introducir los datos de entrada y obtener los de salida.
Que el usuario pueda interpretar correctamente los mensajes de error.
Es deseable que una parte del mismo pueda servir como tutorial del sistema.
Una parte debe ser un manual de referencia.
Es importante tener en cuenta a qu personas va dirigido el manual, no se redacta igual para un directivo, que probablemente
est ms interesado en una visin general del sistema que no va a usar directamente que a un empleado de base que se dedica
a introducir algunos datos o que un miembro administrativo que usar el sistema para por ejemplo sacar estadsticas de ventas.
Como existen diferentes perfiles de utilizacin el manual de usuario deber reflejar esto estructurndose en mdulos dirigidos a
tipos diferentes de personas.
Dentro de cada uno de los mdulos deberan existir procedimientos especficos para funcionalidades concretas. Un procedimiento sera una lista ordenada de acciones para conseguir algo. Las posibles bifurcaciones de cada procedimiento respecto al
camino principal debern documentarse igualmente.
Existen estndares de documentacin que especifican el ndice del manual (y algunos como el de GNU incluso el formato,
que debe ser T EXINFO para as poder ser traducido automticamente a otros formatos). En cualquier caso, el ndice deber
contener los siguientes puntos:
1. Instalacin del producto. Se indicarn los requisitos, tanto software como hardware.
2. Configuraciones posibles, teniendo en cuenta los diferentes perfiles de usuario.
3. Si el manual tiene varios mdulos en funcin de los perfiles de usuario, para cada uno de ellos:
Se indica un procedimiento para obtener cada funcionalidad. Debe indicarse la secuencia en la que se ejecutan las
acciones y las posibles bifurcaciones.
Cada procedimiento se entiende mucho mejor si tiene ejemplos.
82
Objetivos
Documentar en forma detallada las caractersticas de cada componente de la arquitectura tcnica del sistema.
Servir como base para el mantenimiento futuro de los procesos y programas del sistema.
Contenidos
1. Descripcin general del sistema
Identificacin del sistema: Nombre y siglas que lo identifican.
Objetivos: Descripcin breve del objetivo general del nuevo sistema, incluyendo referencia a las funciones del negocio
(planificacin, gestin, etc) qu cubre y cmo lo hace.
Alcance: Diagrama de contexto que muestre la interaccin del sistema con el resto de los sistemas de la organizacin.
Caractersticas generales. Descripcin breve de las siguientes especificaciones funcionales y/o tcnicas:
83
Polticas relacionadas con su uso. Siguiendo las polticas, normas y estndares vigentes, se debern adjuntar:
Principales funciones: Narrativa breve que describa las principales funciones del sistema. Se podr acompaar de un
esquema donde se identifiquen las actividades del negocio cubiertas por el sistema y sus necesidades de informacin.
Observaciones: Cualquier informacin que no haya sido especificada antes y que se considere de inters.
2. Arquitectura general del sistema
Requisitos funcionales: Expresar los requisitos funcionales que debe satisfacer el sistema
Eventos del sistema: Extraer del modelo de eventos una lista conteniendo todas aquellas funciones ejecutadas por los
distintos usuarios que originan una entrada al sistema. Indicando:
a)
b)
c)
d)
e)
Nmero de evento.
Descripcin.
Origen de la informacin.
Destino de la informacin.
Flujo de datos.
Procesos del sistema: Contiene el inventario y la descripcin general de cada una de las opciones de la aplicacin,
incluyendo imgenes de las pantallas utilizadas.
Dilogo del sistema: Muestra la comunicacin entre las distintas pantallas de la aplicacin identificando las condiciones que provocan la navegacin entre las mismas.
Modelo de procesadores: Muestra de manera grfica los distintos dispositivos fsicos requeridos, la asignacin de
tareas y la conectividad entre ellos.
Esquema de mdulos:Esquema donde se visualice el sistema como un conjunto de bloques, cada uno de los cuales
representa un mdulo o subsistema del mismo.
3. Especificaciones de los mdulos. Por cada mdulo deber tenerse la siguiente informacin:
Nombre del mdulo.
Descripcin detallada del mdulo y sus funciones.
Diagrama general del mdulo.
Flujo de pantallas (si corresponde)
Lista de componentes que lo implementan.
Lista de bases de datos.
Lista de archivos y tablas que utiliza.
Lista de las vistas lgicas de los datos.
Lista de los informes que genera.
4. Especificaciones de los procesos
Inventario general de procesos del sistema: Es una lista de todos los procesos, la cual contendr los siguientes datos:
Nombre del proceso, Descripcin breve y Mdulo al que pertenece mdulos que incluye.
Dejar documentado que para obtener informacin particular de cada proceso se deber relacionar este manual con el
manual de operaciones.
5. Especificaciones de programacin: Para cada componente de programacin del sistema (dependiendo del lenguaje a
utilizar: programa, subrutina, procedimiento o funcin), deber incluirse la siguiente informacin:
Nombre del componente.
Descripcin y objetivos.
Diagrama general del componente.
6. Especificaciones de los datos
84
Modelo conceptual de datos: Permite visualizar las entidades de datos requeridas por el sistema y sus relaciones. Se
debern adjuntar:
Diagrama general.
Diagrama de las distintas vistas (si fuese necesario).
Definicin de las entidades.
Diccionario de datos.
Diseo lgico de base de datos: Documenta la base de datos segn la perspectiva de los desarrolladores de aplicaciones y los usuarios finales, sin preocuparse por su implementacin fsica en un DBMS (Database Management
System) particular. Se debern adjuntar:
Diseo fsico de base de datos: Contiene las definiciones detalladas de todos los archivos y/o bases de datos del sistema y cada uno de sus componentes (tablas, columnas, claves, ndices, integridad referencial, triggers, etc). Adjuntar
la forma en que cada programa los accede y procesa sus datos, su localizacin fsica y la descripcin de su sistema de
backup. Para aquellos que tengan proceso de mantenimiento independiente del sistema, se deber adjuntar la forma
de acceso al men correspondiente y las instrucciones para su uso.
Tutorial posterior
Resumen de contenidos
Finalizacin del proyecto
El objetivo llegados a este punto consiste en entregar el producto al cliente y ponerlo en condiciones de funcionar. La
aceptacin ocurre cuando han terminado todas las actividades. Se adjunta una plantilla para el informe de cierre del proyecto.
Los indicadores del proyecto son un conjunto de medidas para evaluar de un modo objetivo los resultados. Son de varios tipos:
econmicos, financieros, de ocupacin laboral y de gestin.
85
Extensin de conocimientos
Los contenidos de este tema tambin se puede estudiar en [Som98, cap. 8], [Haw98, cap. 19] [Sch92, cap. 11].
86
Captulo 8
Metodologas de desarrollo
Tutorial Previo
Introduccin
Una vez que hemos visto las fases ms habituales del proceso de anlisis, diseo y mantenimiento del software, es necesario
estudiar algunas formas de agrupar, organizar, secuenciar y distribuir temporalmente las tareas estudiadas, segn los detalles de
diferentes metodologas. Una metodologa constituye, en definitiva, el manual o gua que realmente se pone en prctica al abordar
la construccin de un sistema. Las metodologas de desarrollo puede decirse que consisten en poner orden en todo lo que se
ha ido viendo hasta ahora, es decir, utilizan un ciclo de vida determinado y siguen las fases de especificacin, diseo, etc. de un
modo concreto; algunas incluso estn apoyadas por herramientas hechas a medida (por ejemplo el mtodo Rational).
El tipo de metodologas que se van a ver estn orientadas a objetos que son del tipo que demanda el mercado actualmente
y adems dan buenos resultados. Se estudia en primer lugar el Proceso Unificado de Rational por su amplia difusin y consideracin de metodologa tradicional. A continuacin se presenta una metodologa alternativa muy reciente, llamada Extreme
Programming, que tiene caractersticas muy interesantes. A continuacin se presenta la metodologa de planificacin, desarrollo y mantenimiento de sistemas de informacin del Ministerio de las Administraciones Pblicas denominada Mtrica (versin
3). Finalmente se hace una aproximacin hacia nuevos enfoques de desarrollo de software surgidos a raz del movimiento del
Software Libre.
87
88
Metodologas de desarrollo
8.2.1. Introduccin
Toda esta seccin es un resumen de los 11 primeros captulos del libro [JBR00c]. El Proceso Unificado de Rational es
una metodologa de desarrollo de software orientada a objetos creada por Rational Software Corporation. Los creadores de
la metodologa son los mismos que los del UML: Ivar Jacobson, Grady Booch y James Rumbaugh, que respectivamente eran
autores de las metodologas: Process Objectory, el mtodo Booch y la metodologa OMT. Como toda metodologa de desarrollo
software su finalidad es convertir las especificaciones que da el cliente en un sistema software. Las caractersticas que tiene el
R.U.P. son:
1.
2.
3.
4.
5.
Est basado en componentes. Estos componentes a su vez estn conectados entre s a travs de interfaces.
Utiliza el UML como notacin bsica.
Dirigido por casos de uso.
Centrado en la arquitectura.
Ciclo de vida iterativo e incremental.
89
Version 1
Ciclo 1
Inicio
Version 2
Ciclo 2
Elaboracion
Version n
. . .
Ciclo n
Construccion
Transicion
Requisitos
Analisis
Diseno
Implementacion
Prueba
Iter.
1
Iter.
2
. . .
. . .
. . .
. . .
. . .
Iter.
n
90
Metodologas de desarrollo
Es una abstraccin semnticamente cerrada del sistema, es decir, para poder interpretarlo no se necesita informacin de otros modelos.
Siempre identifica al sistema que est modelando.
El sistema est formado a parte de sus modelos por las inter-relaciones que se establecen entre estos.
4. Proceso:
Un proceso es una plantilla que sirve para hacer proyectos igual que de una clase se derivan instancias.
Las actividades relacionadas conforman flujos de trabajo, en UML se representan como estereotipos de colaboracin
en el cual los trabajadores y los artefactos son los participantes.
El proceso unificado se adapta en funcin de las necesidades del proyecto segn factores: organizativos, de dominio,
del ciclo de vida y tcnicos.
Las herramientas: El RUP est soportado por herramientas CASE. Es mejor esto al proceso manual para evitar trabajo repetitivo. La herramienta escogida deber dar soporte a todo el ciclo de vida y usar UML. Las herramientas son importantes
porque influyen en el proceso, el cual a su vez dirige a las herramientas.
91
variantes, muchas de ellas pueden ser recogidas en un nico caso de uso. Durante el anlisis y el diseo el modelo de casos de
uso se transforma en un modelo de diseo a travs de un modelo de anlisis. Motivacin de los casos de uso:
1. Proporcionan un medio sistemtico de capturar requisitos funcionales centrndose en el valor aadido para el usuario.
2. Dirigen el proceso de desarrollo porque el anlisis, diseo y prueba se planifican en trminos de casos de uso.
3. Para idear la arquitectura (cada iteracin implementa un conjunto de casos de uso proporcionando un incremento).
Para integrar todas estas necesidades primero se hace un diseo de alto nivel para la arquitectura, a modo de arquitectura de
capas (una capa es una parte bien definida de un sistema a partir de paquetes o subsistemas). Despus formamos la arquitectura
en un par de construcciones (Versin ejecutable del sistema o de una parte del mismo). Todo esto dentro de la primera iteracin.
Al principio se trabaja con las partes generales de la aplicacin y requisitos generales no funcionales. En esta primera pasada se
trata de tener una visin general.
Segunda construccin: Se trabaja con requisitos especficos a base de escoger unos cuantos casos de uso relevantes. Se
implementan subsistemas a travs de una serie de iteraciones. Al final de debera conseguir una arquitectura estable. Con una
arquitectura estable se implementan los casos de uso que quedan para proporcionar toda la funcionalidad.
92
Metodologas de desarrollo
2. La arquitectura se establece en la fase de elaboracin y eso permite cambiarla si se considera necesario en una etapa
temprana del desarrollo, por tanto con pocos costes. En el ciclo de vida en cascada esto se descubre ms tarde.
3. Gestin de requisitos cambiantes: Gracias a que se hace una integracin continua los usuarios disponen desde las primeras
iteraciones de versiones ejecutables que permiten un cambio de impresiones en este sentido.
4. Fallos: Al igual que en los puntos anteriores, la ventaja de este ciclo de vida es que los fallos se van descubriendo a medida
que se implementan nuevas funcionalidades; esto significa que no hay una avalancha de problemas al final.
5. Aprendizaje: Con un par de iteraciones es suficiente para que todo el mundo comprenda los diferentes flujos de trabajo.
Gestin de riesgos
Un riesgo es cualquier cosa que pone en peligro el xito del proyecto. Las iteraciones se organizan para reducir riesgos. Tipos
de riesgos:
1. Tcnicos:
a) Relacionados con nuevas tecnologas:
Distribuir procesos en muchos nodos
Tcnicas an incompletas como reconocimiento de lenguaje natural.
b) Relativos a la arquitectura. Una arquitectura robusta se adapta a los cambios y muestra donde encajan los componentes reutilizables.
c) Identificar los requisitos correctos.
d) Mal rendimiento.
2. No tcnicos: La direccin es responsable de ellos.
Tratamiento de los riesgos
Para cada riesgo hay cuatro alternativas, a saber:
Evitarlo: Replanificando o cambiando los requisitos.
Limitarlo: Que solo afecte a una parte del proyecto.
Atenuarlo: Mediante pruebas se aisla y se aprende sobre l.
Controlarlo: Si no se puede evitar se disea un plan de contingencia.
Iteraciones
Cuando una iteracin termina se analiza para ver si han aparecido nuevos requisitos. Se examinan tambin los riesgos que
quedan. Las pruebas de regresin comprueban que no se han introducido errores sobre partes anteriores a las de la iteracin
en curso. La planificacin de cada iteracin solo se puede hacer en detalle para la prxima iteracin a la actual y con menos
detalle para las siguientes.
Secuenciacin: Los casos de uso establecen una meta y la arquitectura un patrn. Con esto en mente se planifica la secuencia
de iteraciones. Las primeras se centran en los requisitos, problemas y riesgos y las siguientes en la visin externa. Es posible que
las iteraciones se solapen un poco en el tiempo. El orden de las iteraciones es el que permita que las decisiones importantes se
tomen antes.
El conjunto de modelos que representa al sistema en un momento dado se llama lnea base. En la fase de elaboracin se
identifican los casos de uso que tienen un impacto sobre la arquitectura y se representan como colaboraciones. De esta forma se
construye la lnea base. El resultado de una iteracin es un incremento, y consiste en la diferencia entre dos lneas base sucesivas.
Cada fase termina con un hito, el desarrollo iterativo supone un cambio de actitud: Es necesario dejar de valorar tanto las lineas
de cdigo y valorar ms la reduccin de riesgos y la lnea base.
93
a) Modelado del dominio: Describir los objetos importantes del contexto como objetos del dominio (clases) y enlazarlos. Se modela en UML. Estos objetos se pueden educir gracias a reuniones con expertos del dominio. Los productos
son: Un glosario de trminos y los objetos. Tipos de objetos: Objetos del negocio (p. ej: pedidos, cuentas, contratos),
Objetos del mundo real y Sucesos.
El glosario y los objetos se usarn al descubrir casos de uso y describir la interfaz de usuario y para sugerir clases
internas del sistema en desarrollo.
b) Modelado del negocio: Describir los objetos para comprenderlos. No es exclusivo de los negocios, es una forma de
llamar a este tipo de modelado. Est soportado en UML por el modelo de casos de uso y el modelo de objetos (modelo
interno). Lo que hace es describir los procesos en trminos de casos de uso y actores del negocio. Se desarrolla en
dos pasos:
1) Se crea un modelo de casos de uso que identifique a los actores.
2) Se desarrolla un modelo de objetos del negocio que realiza los casos de uso anteriores compuesto por trabajadores, entidades del negocio y unidades de trabajo.
Bsqueda de casos de uso a partir de un modelo del negocio: Un actor es un trabajador o cliente del negocio. Cada
trabajador cumple un papel en cada caso de uso. Despus se buscan los casos de uso de los actores del sistema.
3. Capturar requisitos funcionales: Se hace con casos de uso. Aparte de esto hay que especificar como ser la interfaz de
usuario.
4. Capturar requisitos no funcionales. Por ejemplo:
Requisito de interfaz: Especifica como se relaciona con un elemento externo.
Requisito fsico: Caractersticas como forma, tamao, peso, etc.
Restriccin de diseo: Extensibilidad, mantenibilidad o reutilizacin.
Restriccin de implementacin: Normas de codificacin, lenguaje, etc.
En la fase de inicio se capturan los casos de uso para delimitar el sistema y el alcance del proyecto. En la fase de elaboracin se
capturan los requisitos para delimitar el esfuerzo. Al finalizar esta fase se deben haber capturado el 80 %.
Artefactos
Veamos los artefactos utilizados en la captura de requisitos.
1. Modelo de casos de uso: Es un modelo con actores, casos de uso y relaciones entre ellos. Pueden agruparse en paquetes y
se puede ver desde distintos puntos de vista.
2. Actor: Un actor es cualquier cosa externa al sistema, desde un usuario hasta otro sistema. El conjunto de actores delimitan
todo lo externo. Puede jugar varios roles y para cada uno de ellos tendr un caso de uso.
3. Caso de uso: Cada uno es una especificacin, una secuencia de acciones que el sistema lleva a cabo para realizar una
funcionalidad. Puede incluir diagramas de estados, diagramas de actividad, colaboraciones y diagramas de secuencia. Cada
caso de uso tiene atributos. Una instancia de caso de uso es la ejecucin de un caso de uso, que estar desencadenada por
un evento o por la instancia de un actor. El flujo de sucesos de un caso de uso especifica cmo interacta el sistema con
los actores. Consta de secuencias de acciones.
4. Descripcin de la arquitectura: Es una vista de los casos de uso significativos para la arquitectura. Usada para decidir
que casos de uso se implementan en cada iteracin.
5. Glosario: Conjunto de trminos comunes en el sistema. Sirve para evitar confusiones. Sale del modelo de negocio o del
modelo del dominio.
6. Prototipo de interfaz de usuario: tiles para depurar los casos de uso.
Trabajadores
Entendemos por trabajador como una persona real que desempea una funcin dentro del proyecto. Una misma persona
puede ser varios trabajadores. Tipos de trabajadores:
1. Analista de sistemas: Modela los casos de uso, encuentra los actores y redacta el glosario. Tambin es la persona que se
encarga de capturar los requisitos.
2. Especificador de casos de uso: Es un asistente del anterior. Realiza cada caso de uso en detalle trabajando con el usuario.
3. Diseador de interfaz de usuario: Se suelen usar prototipos, uno por cada actor.
4. Arquitecto
94
Metodologas de desarrollo
Flujo de trabajo
Se representa mediante un diagrama (ver figura 8.2). El diagrama tiene calles, en la cabecera se sitan los actores y en las
calles las actividades. Cuando un trabajador ejecuta una actividad crea y modifica artefactos. Se representa el flujo lgico, pero
las actividades reales no tienen porque ser secuenciales. Veamos las actividades una a una.
Analista
de sistemas
Encontrar actores
y casos de uso
Estructurar el modelo
de casos de uso
Priorizar
los casos de uso
Arquitecto
Detallar
un caso de uso
Especificador
de casos de uso
Diseador
de interfaces de usuario
Prototipar
la interfaz de usuario
1. Encontrar actores y casos de uso: Se realiza por un equipo de analistas y usuarios. La actividad consta de cuatro pasos:
a) Encontrar los actores. Hay dos estrategias para ello:
Encontrar un usuario que represente al actor.
Encontrar roles iguales y fusionarlos en un nico actor.
b) Encontrar los casos de uso: Si se parte del modelo del negocio cada rol de cada trabajador se corresponder con un
caso de uso. En otro caso se identifican hablando con los usuarios. Por otra parte, los casos de uso se caracterizan por
proporcionar algn servicio de utilidad al actor y es mejor que el actor sea una persona real.
c) Describir brevemente cada caso de uso: Una vez identificados los casos de uso se les da una descripcin breve o con
los pasos a seguir.
d) Describir el modelo de casos de uso completo: Se trata de dar una visin general de los casos de uso. Se puede utilizar
cualquier conjunto de diagramas que se consideren oportunos.
2. Priorizar casos de uso: Se trata de ver qu casos de uso se hacen en qu iteraciones, para ello hay que tener en cuenta
consideraciones econmicas y en general no tcnicas. El resultado se pone en la vista del modelo de casos de uso.
3. Detallar un caso de uso. Para ello hay tres actividades a realizar:
Estructuracin de la descripcin de casos de uso: Un caso de uso incluye estados y transiciones entre ellos y el grfico
resultante puede ser complicado. Se puede describir primero el camino bsico (el ms normal) de principio a fin y
luego el resto de caminos alternativos.
La descripcin debe incluir: Estado inicial como precondicin, posibles estados finales como postcondicin, la primera accin a ejecutar, orden (si existe) numerada de la acciones, caminos de ejecucin no permitidos, descripcin
de caminos alternativos, la interaccin con los actores, utilizacin de recursos y acciones ejecutadas.
Formalizacin de la descripcin: Un caso de uso se puede representar como una mquina de estados y si es demasiado
complejo se puede utilizar alguno de los diagramas de UML: diagramas de estados, de actividad o de interaccin.
4. Prototipar la interfaz de usuario: Se trata de crear una interfaz que permita la interaccin del usuario para poder realizar
los casos de uso. Se hace en dos pasos:
Crear el diseo lgico: Se identifican todos los elementos de la interfaz con los que va a interactuar el usuario. Cada
elemento puede jugar varios roles porque puede estar en varios casos de uso.
Crear el diseo y prototipo fsico: Se identifican los elementos necesarios y su configuracin.
5. Estructurar el modelo de casos de uso: La finalidad es extraer descripciones de funcionalidad de dos tipos:
95
Generales y compartidas: Se buscan funcionalidades de casos de uso compartidas. La reutilizacin en los casos de
uso supone un tipo de herencia, porque es necesario que exista una instancia tanto del caso que reutiliza como del
que es reutilizado
Adicionales y opcionales: La relacin de extensin entre casos de uso consiste en que un caso de uso A aade una
secuencia de acciones a un caso de uso B. La extensin se ejecuta en funcin de que se cumpla una condicin.
Anlisis
Durante el anlisis se estructura el conocimiento que se ha conseguido de los usuarios por clases y paquetes en vez de casos
de uso, de modo que no contenga inconsistencias. El anlisis est pensado para dar la visin interna del sistema (en vez de la
externa de los casos de uso) a los desarrolladores y por eso est descrito con su lenguaje. Es una primera aproximacin al diseo
y define realizaciones de casos de uso. El resultado del anlisis es el modelo de anlisis. Se debe hacer anlisis cuando:
1.
2.
3.
4.
El modelo de anlisis describe los resultados del anlisis y mantiene la consistencia de este modelo durante el ciclo de vida. En
las primeras iteraciones se hace nfasis en este modelo, ms adelante se deja de actualizar.
Artefactos
1. Modelo del anlisis: Consiste en una jerarqua de paquetes, que son abstracciones de subsistemas o capas de diseo. Los
paquetes contienen clases del anlisis y realizaciones de casos de uso.
2. Clase del anlisis: Es una abstraccin de una o varias clases y/o subsistemas del diseo del sistema. Se centra en los
requisitos funcionales. Su comportamiento en vez de con interfaces se define con responsabilidades, que son una descripcin textual. Estas clases tienen atributos del dominio del problema, que en el diseo pueden pasar a ser clases. Se pueden
corresponder con tres estereotipos: de interfaz, de control o de entidad.
3. Realizacin de caso de uso-anlisis: Explica como se lleva a cabo un caso de uso. Utiliza para ello diagramas de clases,
diagramas de interaccin y una descripcin textual del flujo de sucesos.
4. Paquete del anlisis: Incluye clases del anlisis, realizaciones de casos de uso y posiblemente otros paquetes de anlisis.
Los paquetes deben tener cohesin fuerte y acoplamiento dbil. Cada paquete representa cosas distintas, reconocibles por
los conocedores del dominio.
5. Paquete de servicio: Es un tipo de paquete de anlisis, pero indivisible. Un servicio es un paquete de funcionalidad que
puede ser utilizado en varios casos de uso y los casos de uso funcionan utilizando varios servicios. Un paquete de servicio
puede contener una o ms clases relacionadas funcionalmente.
6. Descripcin de la arquitectura: Es la vista del modelo de anlisis. Contiene la descomposicin del modelo y sus dependencias, las clases de entidad, de interfaz, de control y las de anlisis. Tambin las realizaciones de casos de uso.
Trabajadores
1. Arquitecto: Es el responsable de la integridad del modelo de anlisis y de la descripcin de la arquitectura. Un modelo de
anlisis es correcto si realiza la funcionalidad de los casos de uso.
2. Ingeniero de casos de uso: Es responsable de que cada caso de uso responda a la funcionalidad requerida, tanto en el
anlisis como en el diseo.
3. Ingeniero de componentes: Comprueba que cada clase del anlisis cumpla los requisitos que se esperan de ella. Mantiene
la integridad de los paquetes del anlisis. El ingeniero de componentes de un paquete lo es tambin de las clases del anlisis
contenidas en l.
Flujo de trabajo
Diagrama del flujo de trabajo en el anlisis (ver figura 8.3) que muestra las actividades, los artefactos y los participantes.
Veamos las actividades:
1. Anlisis de la arquitectura: Para esbozar la arquitectura se realizan tres tareas:
a) Identificar los paquetes de anlisis. Una forma es asignar casos de uso a un paquete y realizar esa funcionalidad en el
paquete. Si hay clases comunes entre diferentes paquetes se pueden sacar a otro paquete o fuera de cualquier paquete.
Los paquetes de servicio se identifican cuando el anlisis ya est avanzado. La forma de identificarlos es:
Hay uno por cada servicio opcional.
Por cada servicio que pueda hacerse opcional o por clases que estn relacionadas funcionalmente.
96
Metodologas de desarrollo
Arquitecto
Analisis
de la arquitectura
Analizar un
caso de uso
Ingeniero
de casos de uso
Analizar
una clase
Ingeniero
de componentes
Analizar
un paquete
8.2.7. Diseo
La entrada del diseo es la salida de la fase anterior y la salida del diseo es un modelo directamente implementable. Debido
a esta proximidad con la implementacin hay que comprender aspectos no funcionales como lenguajes de programacin, sistema
operativo, etc. Tambin es necesario tener el sistema dividido en trozos manejables por equipos de trabajo. Los interfaces entre
los diferentes subsistemas deberan estar claros. La implementacin debera seguir la misma estructura que el diseo y de esta
forma se podra hacer un camino de ida y vuelta automatizado.
Papel del diseo en el ciclo de vida
Se realiza sobre todo en las fases de elaboracin y de construccin. Los artefactos son:
1. Modelo de diseo: Es un modelo de objetos que describe como los casos de uso influyen en el sistema. Es tambin una
abstraccin de la implementacin. Cada subsistema o clase del diseo representa una abstraccin con una correspondencia
con la implementacin. Los casos de uso se realizan por clases de diseo, lo cual se representa por colaboraciones en el
modelo del diseo.
2. Clase del diseo: Tiene una correspondencia directa con una clase en la implementacin. Se utilizan caractersticas del
lenguaje de programacin para describirlas.
3. Realizacin de caso de uso-diseo: Es una colaboracin que describe como se realiza un caso de uso del diseo, el
cual tiene una relacin directa con un caso de uso del anlisis. Se compone de: Descripcin textual del flujo de eventos,
diagrama de clases de diseo, diagramas de interaccin y requisitos de implementacin.
4. Subsistema de diseo: Representa una parte del sistema. Debe tener alta cohesin y bajo acoplamiento. Consta de clases del diseo, realizaciones de casos de uso, interfaces y posiblemente otros subsistemas. Un subsistema de servicio se
corresponde con un paquete de servicio del anlisis que ofrece sus servicios en trminos de interfaces y tiene en cuenta
requisitos no funcionales.
97
5. Interfaz: Una interfaz separa la especificacin de la funcionalidad en trminos de sus implementaciones. Son importantes
porque describen las interacciones entre subsistemas.
6. Vista de la arquitectura del modelo de diseo. Consta de los siguientes elementos:
Descomposicin del modelo de diseo en subsistemas, interfaces e interdependencias.
Clases importantes del diseo.
Realizaciones de caso-de-uso-diseo importantes.
7. Modelo de despliegue: Describe como se reparte la funcionalidad entre los nodos fsicos. Tiene nodos, que son procesadores o recursos hardware, relaciones entre ellos que son los modos de comunicacin (intranet, bus, etc). Describe la
configuracin de la red. La funcionalidad de un nodo depende de los componentes que estn en l.
8. Vista de la arquitectura del modelo de despliegue: Muestra los artefactos relevantes para la arquitectura, como la correspondencia entre los componentes y los nodos.
Trabajadores
1. Arquitecto: Es responsable de la integridad y de la arquitectura de los modelos de diseo y de despliegue. Un modelo es
correcto si realiza la funcionalidad descrita en los casos de uso y nada ms. La arquitectura es correcta si estn presentes
sus partes significativas.
2. Ingeniero de casos de uso: Responsable de la integridad de las realizaciones de casos de uso-diseo y su comportamiento.
Tambin es responsable de las descripciones textuales de los casos de uso.
3. Ingeniero de componentes: Garantiza que las clases del diseo estn correctamente definidas, as como el los subsistemas
y sus interrelaciones.
Flujo de trabajo
Las actividades y sus relaciones de precedencia temporal estn reflejadas en el grfico de la figura 8.4:
Arquitecto
Diseo
de la arquitectura
Disear un
caso de uso
Ingeniero
de casos de uso
Ingeniero
de componentes
Disear
una clase
Disear
un subsistema
98
Metodologas de desarrollo
Identificar operaciones.
Identificar atributos.
Identificar asociaciones y agregaciones.
Identificar las generalizaciones.
Describir los mtodos.
Describir estados.
Tratar requisitos especiales.
4. Diseo de un subsistema. Las actividades para ello son:
Mantener las dependencias entre subsistemas.
Mantener interfaces proporcionadas por el subsistema.
Mantener los contenidos de los subsistemas.
8.2.8. Implementacin
La implementacin tiene como finalidades:
Planificar las integraciones. Se sigue un enfoque incremental.
Distribuir el sistema entre los nodos.
Implementar clases y subsistemas del diseo.
Probar los componentes individuales hasta donde sea posible.
Artefactos
1. Modelo de implementacin: Describe la implementacin de las clases y la organizacin de los componentes. Se compone
de un sistema de implementacin, que a su vez consta de varios subsistemas. Cada sistema o subsistema consta de interfaces
y componentes.
2. Componente: Es el empaquetamiento fsico de los elementos de un modelo. Algunos estereotipos son: < <executable> >,
< <file> >, < <library> >, < <table> >, < <document> >. Un stub es el esqueleto de un componente de propsito especial
utilizado para desarrollar o probar otro componente.
3. Subsistema de implementacin: Es una forma de organizar los artefactos del modelo de implementacin. El mecanismo
de empaquetamiento depende de la herramienta de implementacin. Cada subsistema de implementacin se puede trazar
hasta un subsistema de diseo (dependencias, interfaces, clases de diseo y subsistemas de diseo).
4. Interfaz: Los componentes y subsistemas de implementacin pueden utilizar las mismas interfaces y tener dependencias
de uso sobre ellas. Cuando un componente proporciona una interfaz debe implementar todas sus operaciones.
5. Vista de la arquitectura del modelo de implementacin. Consta de los siguientes elementos:
Descomposicin del modelo de implementacin, subsistemas e interfaces.
Componentes clave.
6. Plan de integracin de construcciones: La forma de hacer la integracin es incremental. El plan describe la funcionalidad
implementada en cada construccin y las partes del modelo de implementacin que estn afectadas por la construccin.
Trabajadores
1. Arquitecto: Responsable de la integridad del modelo de implementacin, que es correcto si implementa la funcionalidad
descrita en el modelo de diseo. Tambin es responsable de la arquitectura del modelo de implementacin y de la asignacin
de componentes a nodos.
2. Ingeniero de componentes: Se encarga del cdigo fuente de uno o varios componentes y de uno o varios subsistemas de
implementacin y de los elementos del modelo contenidos en l.
3. Integrador de sistemas: Planifica la secuencia de construcciones necesarias en cada implementacin y la integracin de
cada construccin.
Flujo de trabajo
La figura 8.5 es una representacin dinmica de las actividades con sus respectivos trabajadores. Vemoslas una a una.
1. Implementacin de la arquitectura: Esboza el modelo de implementacin identificando componentes significativos y
asignndolos a nodos
2. Integrar el sistema: Se crea un plan de integracin de construcciones y se integra cada construccin antes de que sea
sometida a pruebas de integracin.
Arquitecto
Integrador
de sistema
99
Implementacion
de la arquitectura
Integrar
sistemas
Implementar
una clase
Ingeniero
de componentes
Implementar
un subsistema
Realizar prueba
de unidad
8.2.9. Prueba
La finalidad de esta fase es planificar, disear, implementar las pruebas de cada iteracin.
Artefactos
1. Modelo de pruebas: Especifica cmo son las pruebas de integracin y de sistema para los ejecutables. Pueden probarse
tambin componentes como manuales de usuario o interfaces.
2. Caso de prueba: Especifica la prueba que se hace sobre un requisito o conjunto de requisitos de un caso de uso o de una
realizacin de un caso de uso-diseo.
3. Procedimiento de prueba: Especifica cmo se lleva a cabo una realizacin de un conjunto de casos de prueba.
4. Componente de prueba: Es la automatizacin de un caso de prueba.
5. Plan de prueba
6. Defecto
7. Evaluacin de prueba
Trabajadores
1. Diseador de pruebas: Responsable de la integridad del modelo de pruebas, de los objetivos y la planificacin de las
pruebas.
2. Ingeniero de componentes: Responsable de la automatizacin de algunos procedimientos de prueba.
3. Ingeniero de pruebas de integracin: Las pruebas de integracin verifican que los componentes integrados funcionan
bien juntos.
4. Ingeniero de pruebas de sistema: Realiza las pruebas sobre el resultado de una iteracin y documenta los defectos
encontrados.
100
Metodologas de desarrollo
Flujos de trabajo
En la figura 8.6 se representa el diagrama de actividades:
Ingeniero
de pruebas
Planificar
prueba
Disear
prueba
Evaluar
prueba
Ingeniero
de pruebas
de integracion
Realizar prueba
de integracion
Ingeniero
de pruebas
de sistema
Realizar prueba
de sistema
Ingeniero
de componentes
Implementar
pruebas
101
Escenarios de test
Historias de usuario
Requisitos
Prototipo
arquitectonico
Metafora
del sistema
Plan de
entrega de
versiones
Estimacion
mala
Plan de
liberacion
Iteracion
Estimacion
mejor
Errores
Ultima
version
Test de
aceptacion
Aprobacion
del usuario
Pequenas
entregas
Proxima iteracion
Ptototipo
Los desarrolladores estiman cuanto tiempo es necesario para implementar cada una. Si ese tiempo supera en alguna las
tres semanas se debe desglosar en otras ms pequeas. Si es inferior a una semana, la historia de usuario ha descendido a
un nivel de detalle excesivo y habr que combinarla con otra.
Una historia de usuario debe durar idealmente entre una y tres semanas. Idealmente significa no tener distracciones,
saber exactamente lo que hay que implementar y sin otras asignaciones.
Diferencias entre las historias de usuario y la especificacin tradicional:
Nivel de detalle: En principio, el usuario solo cuenta lo necesario para poder hacer una estimacin del tiempo que va a
tomar la implementacin. Cuando llega el momento de implementar se vuelve a preguntar.
La atencin se centra en las necesidades del usuario, no se usa tecno-jerga.
102
Metodologas de desarrollo
La cuarta est condicionada por las tres primeras y es inversamente proporcional al coste del proyecto.
Proxima
iteracion
Errores
Tareas no
terminadas
Historias
de usuario
Velocidad
del proyecto
Plan de
Aprender y
comunicar
Nueva
funcionalidad
Plan de
iteracion
Desarrollo
iteraciones
Test de aceptacion
fallidos
Ultima
version
Correccion
de errores
Dia a dia
103
8.3.5. Integracin
En la integracin se juntan los pequeos mdulos de software que tenemos y que parece que funcionan, pero resulta que esos
pequeos trozos solo han superado pruebas de unidad donde no han tenido que interactuar con otros mdulos. El problema es
que existen errores que solo surgen en esa interaccin, y ese es precisamente el problema de la integracin. Formas de afrontarlo:
1. Cada desarrollador es propietario de algunas clases y se responsabiliza de corregir los errores que surjan en la integracin.
2. Tener un equipo que se dedique a eso.
Adems lo tpico es hacer la integracin una sola vez al final. En extreme programming se hace una integracin secuencial. En
un mismo momento slo puede existir una pareja de programadores integrando su cdigo. Para que otra pareja pueda hacer lo
mismo le tienen que pasar el testigo. El cdigo est todo l en el almacn (repository) y la pareja que est integrando es la que
puede hacer test y publicar los cambios al almacn. Tambin es posible que una pareja pueda integrar su trabajo en la ltima
versin en el momento que quiera con tal de que exista un mecanismo de bloqueo (p.ej. un token que se pasen de unos a otros).
La integracin debe hacerse cada poco tiempo, idealmente, cada pocas horas hay que dejar cdigo nuevo en el almacn.
Todo el mundo debe hacer integraciones con la ltima versin disponible, de esta forma se evita trabajar con cdigo obsoleto.
Haciendo muchas mini-integraciones los problemas que surgan al final cuando se haca la nica integracin se van resolviendo
sobre la marcha.
Mover a la gente
Cambiar
pareja
Problema
complejo
Proxima tarea o
Test de aceptacion
fallido
Asignar pareja
Crear una
prueba de unidad
Test de
unidad
fallido
Test de
unidad
pasado
Se necesita
ayuda
Programacion
por parejas
Codigo
sencillo
Nuevos
test de unidad
Nueva
funcionalidad
Codigo
complicado
Integracion
continua
Se pasan el 100%
de las pruebas
de unidad
Correr los
test de aceptacion
fallidos
Test de aceptacion
pasado
Rehacer
sin piedad
Se crea una prueba de unidad pequea que refleja parte de los requisitos.
Se hace el cdigo que satisface ese test.
Se crea una segunda prueba.
Se aade el cdigo correspondiente.
...
Prueba de unidad
Veamos ahora como se hace una prueba de unidad. Hay tres pasos a seguir:
1. Se crea un armazn o patrn para poder hacer partiendo de l las pruebas de unidad de un modo automatizado.
2. Se hace un test de todas las clases del sistema.
3. Se debe escribir el test antes de codificar el mdulo.
La idea de hacer el test antes del cdigo es importante, porque si se deja para el final, es posible que se encuentren problemas
inesperados y se necesite ms tiempo del inicialmente previsto. Adems, en realidad el test no se hace antes sino durante porque
se construye de forma incremental, pero siempre el test antes del cdigo.
Cuando se publica un mdulo al almacn debe ir obligatoriamente acompaado del test correspondiente, y no se puede
publicar cdigo que no haya pasado todos los tests. Como el cdigo no tiene un propietario fijo y todo el mundo puede hacer
modificaciones, esta norma es bastante razonable, cualquiera puede modificar una lnea de cdigo que haya escrito otra persona,
ahora bien, la modificacin tiene que pasar todos los tests asociados a la unidad.
104
Metodologas de desarrollo
Los tests de unidad permiten tambin rehacer el cdigo porque pueden comprobar si un cambio en la estructura supone un
cambio en la funcionalidad. Un pequeo problema es que los tests en si mismos pueden tener errores. Por otra parte, una de las
cosas deseables es poder hacer frecuentemente integraciones de todo el cdigo. Si se construye un conjunto de tests globales para
comprobar el producto final, ser posible comprobar rpidamente si los cambios hechos en una unidad se integran bien y de esta
forma no dejarlo todo para el final.
Test de aceptacin
El test de aceptacin tambin se conoce como test funcional en otros sitios. Los tests de aceptacin son cajas negras que
comprueban el funcionamiento del sistema. Son escritos por el cliente, y es el cliente el responsable de que sea correcto. Tambin
es el cliente el que decide la prioridad de cada test fallido. Tambin se usan como test de regresin. Para que se pueda comprobar
con rapidez y muchas veces si las historias de usuario cumplen con los tests de aceptacin, estos deberan estar automatizados.
Los resultados se comunican al grupo, que debe gestionar el tiempo para corregir errores.
A partir de las historias de usuario se hacen los tests de aceptacin y a cada una le puede corresponder uno o varios. No
se considera que una historia ha sido completada hasta que no pase todos sus tests de aceptacin. Al igual que con los tests de
unidad, los tests de aceptacin deben hacerse antes de empezar a depurar. La diferencia entre un test de aceptacin y un test
de unidad est clara: un test de aceptacin comprueba los requisitos expresados en las historias de usuario y un test de unidad
comprueba que el cdigo de una unidad es correcto.
Errores
Si se encuentra un error lo que se hace es crear un test de aceptacin para ese error. De esta forma es fcil para el equipo
saber cuando se ha corregido. Un error en un test de aceptacin puede verse en varios mdulos diferentes en sus tests de unidad.
Cuando todos los tests de unidad funcionan perfectamente se puede correr otra vez el test de aceptacin para comprobar si el
error ha sido realmente corregido.
8.4 Mtrica 3
105
1. Reuniones diarias: Todos los das por la maana se hace una reunin de 15 minutos en la que se da cita todo el personal
desarrollador. Lo que se busca es promover la comunicacin entre todos los miembros del grupo. La gente cuenta los
problemas que se han encontrado y cualquiera puede proponer soluciones. Este tipo de reuniones tiene algunas ventajas:
a) Como todo el mundo asiste es ms fcil encontrar soluciones.
b) Se pueden evitar otras reuniones.
2. Propiedad compartida del cdigo: Cualquiera puede corregir errores, aadir funcionalidades, etc de cualquier parte del
proyecto (no slo de su cdigo, sino tambin del de los dems). Lo que se pretende es que cualquiera pueda aportar algo.
Esto significa que la arquitectura del sistema en cierto modo la decide el equipo en su conjunto, lo cual resulta chocante
para la mentalidad de la programacin estructurada. Ventajas:
a) El cdigo es ms fiable.
b) Si una persona se atasca en un problema, se le ayuda y su parte no se convierte en un problema para otros.
3. Programacin por parejas (pair programming): Est basado en el principio de que dos personas trabajando juntas pueden
hacer ms que por separado. El resultado de esto es una mejora en la calidad del cdigo, adems no supone tardar ms
tiempo. La forma de ponerla en prctica es: Dos personas se sientan juntas ante el mismo ordenador. Una teclea y piensa
en el problema desde el punto de vista tctico. La otra piensa desde el punto de vista estratgico.
4. Mover a la gente: No se puede permitir que todo el equipo dependa de que la nica persona que conoce algo est disponible
o no. Puede ocurrir que esa persona deje la empresa o que est sobrecargada en un momento dado. Lo que se hace es
que la gente trabaje en una parte del sistema distinta en cada iteracin (o en parte de ella). Esto en combinacin con la
programacin en parejas permite que no se pierda productividad en la parte que se deja. Ventajas:
a) Se evitan las islas de conocimiento
b) El equipo es ms flexible
c) Si una parte del proyecto tiene problemas es posible reasignar gente a esa parte.
8.4. Mtrica 3
8.4.1. Introduccin
Mtrica 3 es la metodologa oficial de desarrollo de aplicaciones informticas en la administracin. Caractersticas 1 :
1.
2.
3.
4.
5.
8.4.2. Objetivos
Como toda metodologa lo que se hace es sistematizar todas las actividades del ciclo de vida y las que no son parte del ciclo de
vida pero influyen de algn modo en ste (como puede ser la planificacin) para de esa forma conseguir los siguientes objetivos:
1. Dar un marco estratgico para el desarrollo de los sistemas de informacin dentro de las organizaciones.
2. Enfatizar el anlisis de requisitos para que de esta forma los productos satisfagan las necesidades de los usuarios.
3. Mejorar la productividad del departamento de sistemas de informacin permitiendo una mayor adaptabilidad a los cambios
y reutilizacin.
4. Que los procesos que permitan una comunicacin ms fluida entre todos los miembros involucrados en la produccin de
software.
5. Facilitar la operacin y mantenimiento de los productos obtenidos.
8.4.3. Estructura
Mtrica 3 se divide por una parte en procesos principales, que son los relativos a la planificacin, desarrollo y mantenimiento
e interfaces, que son procesos asociados al desarrollo (gestin de la configuracin, de proyectos y aseguramiento de la calidad).
Cada proceso se divide en actividades y cada actividad tiene una descripcin y una tabla de tareas propias de la actividad. Cada
tarea tiene la correspondiente descripcin y define los productos que necesita de entrada, los que produce de salida, las prcticas
necesarias para llevar a cabo la tarea y los participantes.
Mtrica 3 es flexible en su estructura (ver figura 8.10) porque no es obligatorio seguir todos los procesos o actividades,
se adapta en funcin de las necesidades de cada proyecto. Tampoco es necesario seguir las actividades secuencialmente, en
1
106
Metodologas de desarrollo
Planficacion (PSI)
Estudio de viabilidad (EVS)
Analisis del S.I. (ASI)
Desarrollo Diseo del S.I. (DSI)
Construccion del S.I. (CSI)
Implant. y acept. del sistema (IAS)
Mantenimiento (MSI)
Gestion de la configuracion (GC)
Gestion de proyectos (GP)
Aseguramiento de la calidad (CAL)
Seguridad (SEG)
Procesos
Metrica V3
Interfaces
Entradas externas
Solicitud formal del PSI
Estructura organizativa
Informacion relevante
Entorno tecnologico
actual y estandar
P.S.I.
* Modulo de sistemas
de informacion
* Modulo de informacion
*Arquitectura tecnologica
Plan de accion
* Plan de proyectos
* Plan de mantenimiento
8.4.4. Procesos
Planificacin de sistemas de informacin (PSI)
El objetivo es obtener un marco de referencia para desarrollar el sistema de informacin (ver figura 8.11). El marco de
referencia consta de:
1. Descripcin de la situacin actual, que incluye:
Un anlisis tcnico de puntos fuertes y riesgos.
Un anlisis de servicio a los objetivos de la organizacin.
2. Un conjunto de modelos que constituyen la arquitectura de informacin.
3. Una propuesta de proyectos a realizar en los prximos aos con:
Sus prioridades.
Un calendario.
Estimacin de los recursos necesarios para cada proyecto, que ser ms detallada cuanto ms cercano en el tiempo.
Un plan de seguimiento de los proyectos.
El plan de sistemas de informacin se disea a partir de consideraciones de tipo estratgico, y no tcnico. Debido a esto es
necesario la implicacin de la alta direccin en el proceso. El plan se elabora en funcin de las necesidades de informacin de los
procesos afectados, con estas necesidades se elaboran modelos conceptuales de informacin. El PSI se divide en las siguientes
actividades y tareas:
1. Inicio del plan de sistemas de informacin.
Anlisis de la necesidad del PSI.
Identificacin del alcance del PSI.
Determinacin de responsabilidades.
2. Definicin y organizacin del PSI.
Especificacin del mbito y alcance.
Organizacin del PSI.
8.4 Mtrica 3
107
108
Metodologas de desarrollo
8.4 Mtrica 3
109
110
Metodologas de desarrollo
En el diseo orientado a objetos el diseo detallado se realiza en paralelo con la actividad de diseo de la arquitectura de
soporte (DSI 2). Las actividades que lo realizan son:
Diseo de casos de uso reales (DSI 3).
Diseo de clases (DSI 4)
Cuando se tiene el modelo de clases se comienza el diseo fsico de datos (DSI 6) segn el enfoque del diseo estructurado.
El ltimo paso de este bloque es la actividad de verificacin y aceptacin de la arquitectura del sistema (DSI 7).
2. Completar el proceso de diseo. Se generan las siguientes especificaciones:
Generacin de especificaciones de construccin (DSI 8).
Diseo de migracin y carga inicial de datos (DSI 9).
Especificacin tcnica del plan de pruebas (DSI 10).
Establecimiento de requisitos de implantacin (DSI 11).
El proceso de diseo puede parecer un tanto catico con la mezcla de procesos orientados a objetos y estructurados y con la
divisin en las dos fases. El grfico de actividades en la figura 8.12 puede que aclare un poco esta estructura. Actividades y tareas
relacionadas:
DSI 1
Definicion de la
Arquitectura del sistema
Actividad
comun
DSI 2
Diseo de la
Arquitectura de Soporte
DSI 3
Diseo de casos
de uso reales
DSI 4
Diseo de clases
Actividad
solo estructurado
Actividad solo
orientada a objetos
DSI 8
Generacion de
especificaciones
de construccion
DSI 7
Verificacion y aceptacion
de la arquitectura
del sistema
DSI 9
Diseo de migracion
y carga inicial
de datos
DSI 12
Aprobacion del
diseo
DSI 10
Especificacion
tecnica del plan
de pruebas
DSI 5
Diseo de la arquitectura
de modulos del sistema
DSI 11
Establecimiento
de requisitos
de implantacion
DSI 6
Diseo fisico de datos
1. Definicin de la arquitectura del sistema: Se establecen las particiones fsicas, la descomposicin lgica en subsistemas
de diseo y la ubicacin de cada subsistema en cada particin, as como la especificacin detallada de la infraestructura
tecnolgica. Las tareas a realizar son:
Definicin de niveles de arquitectura.
Identificacin de requisitos de diseo y construccin.
Especificacin de excepciones.
Especificacin de estndares y normas de diseo y construccin.
Identificacin de subsistemas de diseo.
Especificacin del entorno tecnolgico.
Especificacin de requisitos de operacin y seguridad.
2. Diseo de la arquitectura de soporte.
Diseo de subsistemas de soporte.
Identificacin de mecanismos genricos de diseo.
3. Diseo de casos de uso reales (diseo orientado a objetos).
Identificacin de clases asociadas a un caso de uso.
Diseo de la realizacin de los casos de uso.
Revisin de la interfaz de usuario.
8.4 Mtrica 3
111
112
Metodologas de desarrollo
8.4 Mtrica 3
113
114
Metodologas de desarrollo
8.4.5. Interfaces
Gestin de proyectos (GP)
El objetivo de la gestin de proyectos es el control de recursos humanos y materiales. Existen tres grupos de actividades: de
inicio del proyecto, de seguimiento y control y de finalizacin del proyecto.
Actividades de inicio del proyecto Tienen dos objetivos: Estimar el esfuerzo identificando los elementos a desarrollar y
planificar las actividades (recursos, planificacin de tareas y calendario). Lista de tareas:
1. Estimacin de esfuerzo. Tareas:
Identificacin de elementos a desarrollar.
Clculo del esfuerzo.
2. Planificacin. Tareas:
Seleccin de la estrategia de desarrollo.
Seleccin de la estructura de actividades, tareas y productos.
Establecimiento del calendario de hitos y entregas.
Planificacin detallada de actividades y recursos necesarios.
Presentacin y aceptacin de la planificacin general del proyecto.
Actividades de seguimiento y control El objetivo es vigilar todas las actividades de desarrollo. El jefe de proyecto vigila cada
tarea, centrndose en las que estn retrasadas, caso de que esto ocurra se averiguan las causas. Estas actividades de seguimiento
se llevan a cabo a lo largo de todo el ciclo de vida. Actividades:
1. Asignacin detallada de tareas.
Asignacin de tarea.
2. Comunicacin al equipo del proyecto.
Informar al equipo de proyecto.
3. Seguimiento de tareas.
Seguimiento de tareas.
Gestin de incidencias: Es un grupo de actividades de seguimiento y control. Una incidencia es un hecho inesperado que
produce desviaciones respecto a lo planificado. Un caso especial son los cambios de requisitos.
4. Anlisis y registro de la incidencia. Tarea:
Analizar impacto.
Propuesta de solucin de la incidencia.
Registrar la incidencia.
Gestin de cambios en los requisitos: Es mejor que estos cambios no ocurren, pero si as es, se plantean al comit de
seguimiento. El impacto del cambio del requisito en trminos de plazos y presupuestos se debe pactar con el cliente.
Deber existir un registro de cambios que refleje para cada cambio:
Formulario de peticin de cambio.
Catlogo de necesidades.
Anlisis funcional del cambio.
Estimacin de esfuerzo.
Variaciones en coste y plazos.
El control y seguimiento de los cambios forma parte de las actividades de seguimiento y control de todo el proyecto.
8.4 Mtrica 3
115
116
Metodologas de desarrollo
8.4 Mtrica 3
117
118
Metodologas de desarrollo
Seguridad (SEG)
La palabra seguridad hace referencia a la gestin de riesgos. Esta interfaz pretende dotar a Mtrica 3 de mecanismos de
seguridad adicionales a los que tiene de por si la metodologa. Hay dos tipos de actividades diferenciadas:
1. Actividades relacionadas con la seguridad intrnseca del sistema de informacin.
2. Actividades relacionadas con la seguridad del proceso de desarrollo.
Planificacin de sistemas de informacin Si la organizacin no tiene definida una poltica en materia de seguridad habr que
hacerlo. Esa poltica influir en las decisiones adoptadas en el proceso de planificacin de sistemas de informacin.
1.
2.
3.
4.
Estudio de viabilidad del sistema En funcin de la seguridad requerida se selecciona el equipo de seguridad, que se basar en
la poltica de seguridad de la organizacin.
1.
2.
3.
4.
5.
6.
Anlisis del sistema de informacin Las funciones de seguridad son un servicio que garantiza la seguridad del sistema de
informacin. Un mecanismo de seguridad el la lgica o algoritmo que lo implementa. Actividades:
1.
2.
3.
4.
Diseo del sistema de informacin Se minimizan los riesgos intrnsecos al sistema de informacin. Determinar el entorno
tecnolgico es importante porque sobre el se implementan las medidas de seguridad.
1.
2.
3.
4.
5.
Construccin del sistema de informacin Se debe evitar que se filtren datos relativos al sistema de informacin. Se verifica el
resultado de las pruebas de las funciones y mecanismos adicionales de seguridad. Tambin se completa la definicin de formacin
a usuarios finales. Actividades:
1.
2.
3.
4.
Implantacin y aceptacin del sistema Se especifican las actividades que tienen que ver con la seguridad del sistema construido, tanto intrnseca como las que tienen que ver con la seguridad del proceso. Asegura que se cubran los requisitos de seguridad
a travs de las pruebas de implantacin. Lista de actividades:
1.
2.
3.
4.
5.
119
8.5.1. La catedral
Es el mtodo tradicional y seguido por la mayor parte de los fabricantes de software hoy en da. Caractersticas:
1. El software de gran tamao se construye como las catedrales, es decir, cuidadosamente planificado por equipos de expertos
que se comunican lo justo entre s.
2. Hay poco personal y bien escogido. Aumentar mucho el nmero de personas es caro y pasado cierto punto no acelera el
desarrollo, sino que lo ralentiza.
3. No se publican versiones beta hasta poco antes de terminar.
4. El motivo de que las versiones se publiquen tarde en este modelo es que de lo contrario estaran plagadas de errores.
5. Los errores son difciles de encontrar, requieren una fase de pruebas que se hace al final.
6. El cdigo fuente se guarda a cal y canto.
7. Subyace a l una estructura organizativa piramidal.
8. El jefe de proyecto debe tener gran talento para el diseo.
8.5.2. El bazar
Es diferente al anterior en todos los puntos anteriores:
1.
2.
3.
4.
En un principio hay una idea, pero no se tiene una imagen clara de en que se convertir al final.
Existe una ingente cantidad de personas en su elaboracin y cuantos ms mejor.
En el momento en el que se puede publicar una versin se hace, aunque est muy incompleta.
Los errores se encuentran con facilidad porque hay muchas personas trabajando simultneamente en ello. Su descubrimiento se pone en marcha desde el principio.
5. El cdigo es abierto, o lo que es lo mismo, cualquiera puede leerlo y modificarlo.
6. La estructura organizativa es difusa, hay una serie de normas para participar pero no una jerarqua claramente definida.
Una persona puede contribuir durante toda la vida del proyecto o de un modo fugaz.
7. El coordinador del proyecto ms que tener talento tiene que tener olfato para ver cuando una idea de otro es buena e
incorporarla.
El kernel de Linux es el paradigma nmero uno que sigue la filosofa del bazar. Es un software de gran tamao y complejidad,
iniciado en principio como un pequeo proyecto por Linus Torvalds tomando como base el sistema operativo Minix (un antiguo
120
Metodologas de desarrollo
UNIX para clnicos de IBM-PC). El proyecto sigue en la actualidad mas vivo que nunca y cada da va ganando cuota de mercado
a sus competidores (a algunos los ha dejado atrs ya, p. ej: SCO-Unix. Segn Eric S. Raymond en su libro [Ray99]: La Catedral
y el Bazar, las conclusiones que se sacan del mtodo bazar son:
1. Todo trabajo de software comienza a partir de las necesidades personales del programador. No es lo mismo trabajar para
un proyecto a cambio de un salario que trabajar gratis en algo en lo que se encuentra una satisfaccin personal o se cubre
una necesidad. Lo segundo motiva ms.
2. Los buenos programadores saben que escribir. Los mejores que reescribir (y reutilizar). Es ms fcil partir de una solucin
aunque sea incompleta y mala que de cero. Linus lo que hizo no fue construir un sistema operativo desde la primera lnea
de cdigo hasta el final (probablemente an estara en ello), en lugar de eso, tom como punto de partida Minix. Por tanto,
una forma de iniciar un proyecto puede ser buscar un proyecto similar ya hecho y tomarlo como gua.
3. Contemple desecharlo, de todas formas tendr que hacerlo. Al final todo el cdigo de Minix fue reemplazado, pero mientras
existi fue un armazn a partir del cual pudo ir cambiando partes. El cdigo de partida no es importante, de hecho seguro
que tiene un montn de errores y no es adecuado a nuestras necesidades, solo sirve para comprender el problema.
4. Si tienes la actitud adecuada, encontrars problemas interesantes.
5. Cuando se pierde el inters en un programa, el ltimo deber es dejarlo en herencia a un sucesor competente.
6. Tratar a los usuarios como colaboradores es la forma ms apropiada de mejorar el cdigo, y la ms efectiva de depurarlo.
7. Publique rpido y a menudo, y escuche a sus clientes.
8. Dada una base suficiente de desarrolladores asistentes y beta-testers, casi cualquier problema puede ser caracterizado
rpidamente, y su solucin ser obvia al menos para alguien.
9. Las estructuras de datos inteligentes y el cdigo burdo funcionan mucho mejor que en el caso inverso.
10. Si usted trata a sus analistas (beta-testers) como si fueran su recurso ms valioso, ellos le respondern convirtindose en
su recurso ms valioso.
11. Lo ms grande despus de tener buenas ideas es reconocer las buenas ideas de sus usuarios. Esto ltimo es a veces lo
mejor.
12. Frecuentemente, las soluciones ms innovadoras y espectaculares provienen de comprender que la concepcin del problema era errnea.
13. La perfeccin (en diseo) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay algo que quitar.
14. Toda herramienta es til emplendose de la forma prevista, pero una gran herramienta es la que se presta a ser utilizada
de la manera menos esperada.
15. Cuando se escribe software para una puerta de enlace de cualquier tipo, hay que tomar la precaucin de alterar el flujo de
datos lo menos posible, y nunca eliminar informacin a menos que los receptores obliguen a hacerlo.
16. Cuando su lenguaje est lejos de uno Turing-completo, entonces las ayudas sintcticas pueden ser su mejor amigo.
17. Un sistema de seguridad es tan seguro como secreto. Cudese de los secretos a medias.
18. Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante.
Tutorial posterior
Resumen de contenidos
Una metodologa es una forma de concretar todo lo que se ha visto hasta ahora, que es ms que nada una enumeracin
ordenada de tcnicas. Las metodologas tienen un ciclo de vida concreto, son o bien orientadas a objetos o estructuradas, realizan
las pruebas de un modo, etc.
Extreme Programming
Es otra metodologa de desarrollo orientado a objetos pensada para proyectos de tamao pequeo o mediano donde se
tiene contacto muy directo con el cliente. Contiene conceptos muy interesantes: la programacin por parejas, la publicacin de
versiones cada muy poco tiempo, la codificacin de las pruebas para cada unidad antes que la propia unidad, breves reuniones
diarias, la integracin secuencial prcticamente a diario, la propiedad compartida del cdigo (todo el mundo puede modificar
cualquier parte del cdigo).
121
Mtrica 3
Es la metodologa definida oficialmente en este pas por el Ministerio de Administraciones Pblicas, por lo tanto, es especialmente recomendada para aquellas personas que tengan pensado hacer oposiciones. Su punto de partida es la versin anterior
(2.1). Es en parte orientada a objetos y en parte estructurada. Su ciclo de vida es el definido en la norma ISO-12.207. Incluye
un conjunto de procesos que no forman parte del ciclo de vida a los que llama interfaces. Tiene en cuenta la tecnologa cliente
servidor y el desarrollo de interfaces grficas de usuario (IGU).
Mtodos de software libre: Cathedral vs. Bazaar
Este apartado es ms que nada una comparacin entre las metodologas de desarrollo seguidas por empresas que ocultan el
cdigo fuente (cathedral) y el fenmeno del software libre (bazaar) donde el cdigo est a la vista de todos (open source) y
puede contribuir mucha gente.
Extensin de conocimientos
Uno de los libros ms recomendables sobre el Proceso Unificado de Rational es el de los autores originales [JBR00c].
Tambin se puede acceder a otra informacin adicional a travs de las pginas de R ATIONAL en http://www.rational.com/
products/rup/.
El proyecto sobre la metodologa Extreme-Programming tiene una pgina muy didctica en http://www.c2.com/cgi/
wiki?ExtremeProgramming, y otra con bastantes descripciones en http://www.extremeprogramming.org/. Tambin se puede encontrar mucha informacin y enlaces relativos al mismo tema en http://www.xprogramming.com/, desde donde adems
se puede descargar el libro [JAH00] en formato PDF (de la seccin publications). Tambin se pueden consultar, adems del
primero [Bec99], otro libro ms reciente [BF00].
El Ministerio de las Administraciones Pblicas mantiene la informacin relativa a la metodologa Mtrica 3 para la planificacin, desarrollo y mantenimiento de los sistemas de informacin en la pgina http://www.map.es/csi/metrica3/.
La direccin donde se pueden encontrar los textos originales y traducciones sobre el libro The Cathedral & the Bazaar
es http://tuxedo.org/~esr/writings/cathedral-bazaar/ que corresponde con el libro de Eric S. Raymond del mismo ttulo [Ray99]. Adicionalmente se pueden visitar algunos centros de desarrollo de software libre como: http://www.
gnu.org/, http://savannah.gnu.org/,http://sourceforge.net/, http://www.gnome.org/, http://www.kde.org/
http://www.mozilla.org/ donde se puede conseguir una visin de los mtodos usados en el desarrollo del software de libre
distribucin y de cdigo abierto.
122
Metodologas de desarrollo
Captulo 9
123
124
9.2.1. Introduccin
Suponga que tiene un proyecto de 1.000.000 de horas donde trabajan 1.000 ingenieros en distintos pases. La pregunta es:
Cmo se puede gestionar esto?. Pueden surgir muchos problemas, por ejemplo: un equipo necesita un mdulo que otro equipo
est haciendo pero que an no ha terminado, y lo necesita para probar el suyo. Como no lo tienen todava lo simulan, pero puede
ocurrir que esta simulacin no se comporte igual al mdulo del otro equipo. Pueden surgir tambin inconsistencias entre los
diferentes subsistemas debidas a malos entendidos acerca de los servicios que ofrecen unos a otros, etc.
La gestin de la configuracin se realiza desde que comienza el proyecto hasta que termina e involucra la recoleccin y el
mantenimiento de toda la informacin sobre hardware y software de los sistemas que se usen. Forma parte de un proceso ms
general de gestin de la calidad del software, de hecho, la misma persona o grupo que se encarga de la calidad del software
puede encargarse tambin de este apartado. La finalidad de todo esto es tener controlados todos los cambios que se hacen sobre
el software y tener toda la informacin necesaria en el momento del mantenimiento.
Es conveniente que la gestin de configuracin est basada en algn estndar como el IEEE 828-1983. El problema que
plantean la mayora de los estndares publicados es que estn pensados para gestionar un sistema que siga el ciclo de vida en
cascada. Para realizar esta gestin existen en el mercado varias herramientas especficas y en muchas herramientas CASE esta
actividad tambin est soportada.
La primera parte de esta seccin es un resumen del documento de Gestin de configuracin por Anglica de Antonio, que
se encuentra en http://www.ls.fi.upm.es/udis/docencia/plani/G_Configuracion.pdf.
9.2.3. Terminologa
Configuracin del software es el conjunto de elementos de configuracin software (ECS) controlados. Cada uno puede tener
varias versiones que se suceden en el tiempo.
125
Lnea base es un conjunto de puntos de referencia o hitos que quedan marcados por la aprobacin de uno o varios elementos de
configuracin del software mediante una revisin tcnica formal.
Versin es un elemento de configuracin en un instante dado.
Revisiones son las distintas versiones que van apareciendo. Si una versin y sus revisiones se representan con un grafo, forman
una cadena de revisin (ver figura 9.1).
3.0.0
3.0.1
3.0.2
Cadena de revision
3.1.0
3.1.1
Variante
126
127
2. Especificaciones de gestin
a)
b)
c)
d)
Organizacin.
Responsabilidades.
Implantacin del plan de gestin de configuracin.
Polticas, directivas y procedimientos aplicables.
Identificacin de la configuracin.
Control de la configuracin.
Contabilidad de estado de la configuracin.
Auditora de la configuracin.
4. Control de suministradores
5. Recogida y retencin de registros
128
Repositorio CVS
Red
129
cvs rtag: Es lo mismo que el punto anterior pero sobre las copias maestras (las que estn en el repositorio). Ejemplo: cvs rtag
ETIQ fuentes. Recorre de forma recursiva los directorios del repositorio bajo fuentes y aade el tag ETIQ a cada
fichero.
cvs history: Da informacin sobre los repositorios CVS. Por defecto slo da toda la informacin que corresponda al usuario.
Con la opcin -a da informacin sobre todos los usuarios.
cvs -H: Sistema de ayuda. Con cvs -H comando se obtiene la informacin sobre un comando especfico.
130
9. La licencia no establece restricciones para otro software: El resto del software que se distribuya no ser afectado por
las restricciones del GPL.
Los servicios gratuitos que proporciona SourceForge son: repositorio CVS, listas de correo, seguimiento de errores, foros, gestin
de tareas software, backups y administracin basada en web.
9.3.1. Introduccin
A continuacin se describen algunas herramientas freeware de creacin de interfaces. El contenido de esta seccin ser
familiar para aquellas personas que hayan desarrollado algn proyecto con compiladores con nombre ms comercial como Visual
Basic, Delphi o C++ Builder. La razn por la que se incluye este apartado es que las interfaces constituyen el 50 % de las lneas
de cdigo de muchos proyectos (la presentacin es importante) y al ser un tipo de actividad susceptible de reutilizar cdigo y
al ser bastante mecnica existen herramientas pensadas para acelerar su desarrollo. La idea en la que se basan estos entornos es
muy parecida:
1. Se tiene una librera extensa de componentes grficos (etiquetas, editores, botones, etc) que se muestran en una ventana. En
cualquier caso, si se necesita un componente que no est es casi seguro que se puede encontrar en algn lugar de internet.
2. Se tiene otra ventana que representa la interfaz grfica que se est construyendo donde se depositan los componentes del
punto anterior. El modo de hacerlo puede ser arrastrar y soltar.
3. Los componentes tienen variables que se manipulan en tiempo de diseo en la ventana correspondiente.
4. El entorno genera el cdigo que produce la interfaz con un aspecto como el que se est diseando, encargndose de
manipular los componentes de forma adecuada pero sin que el programador tenga que escribir el cdigo.
5. El entorno puede ir solo o integrado en un entorno de desarrollo con editor, compilador, etc.
9.3.2. Componentes
Un componente es un objeto, que como todo objeto consta de cdigo y datos. De ellos nos importan tres cosas:
1. Propiedades: Son los valores de las variables pblicas. Son un conjunto de variables que se pueden manipular en tiempo
de diseo y de ejecucin y que controlan el aspecto externo de dicho componente.
2. Eventos: Son sucesos como puede ser la pulsacin de una tecla o el movimiento del ratn. Existe un gestor de eventos
que captura estos sucesos y manda una seal al objeto adecuado, por ejemplo, si se pulsa el ratn sobre un botn el gestor
de eventos invoca el mtodo OnClick de ese botn.
3. Mtodos: Son las funciones del objeto. Se pueden escribir en el diseo, es decir, el desarrollador escribe lo que quiere
que ocurra cuando se invoca el mtodo, por ejemplo, que cuando se pulsa un botn (se invoca OnClick) el ttulo del botn
cambie.
Los componentes estn estructurados en jerarquas, de modo tal que cuando hay que crear un nuevo componente lo mejor
es derivarlo de uno antiguo reutilizando tanta funcionalidad como sea posible. Tipos de componentes. La forma de escribir
componentes, la forma en la que se comunican con el resto del software e incluso el sitio donde pueden ejecutarse definen una
taxonoma muy interesante al respecto.
1. ActiveX: Es un tipo de componente que se distribuye como binario, as que puede estar escrito en cualquier lenguaje de
programacin. El objeto tiene una interfaz estndar para que otros objetos se comuniquen con l. Los programas que usan
controles ActiveX se llaman contenedores. El contenedor de un control es una aplicacin capacitada para el manejo de
ActiveX que acta como soporte de interfaz de usuario para dicho control. Se puede por ejemplo, presentar un botn que,
una vez pulsado, enve un mensaje al control. O tambin responder a diversos sucesos o mensajes especiales que se manden
desde el control al contenedor. Un ejemplo de contenedor es un navegador, que puede mostrar controles ActiveX en una
pgina web incluso aunque el control provenga de un ordenador remoto.
2. VCL (Visual Component Library): Son componentes grficos para la interfaz de usuario. Constan de propiedades, mtodos
y eventos. El cdigo que maneja cada evento es escrito en un mtodo. Las propiedades se pueden editar en modo de diseo,
de modo que no es necesario escribir lneas de cdigo para inicializar cada componente. Las propiedades y mtodos pueden
tener los siguientes tipos de acceso:
Privado: El cdigo que no pertenece al componente no puede acceder a esta parte.
Protegido: Slo pueden acceder a esta parte los componentes que hereden de este.
131
Publico: Se puede acceder libremente a estos mtodos y propiedades pero no para depuracin.
Publicado: Se puede acceder tanto para manipulacin como para depuracin.
9.
10.
9.3.4. Metodologa
Se puede entender una interfaz como una aplicacin en s misma, y por tanto, es razonable que sigamos los mismos pasos que
en la construccin de cualquier sistema, esto es, definir una serie de etapas para su construccin. Esas etapas son las de siempre:
Especificacin, diseo, codificacin y en lugar de pruebas lo llamaremos test de usabilidad, porque es eso lo que se pretende
comprobar.
El test de usabilidad valida el diseo de la interfaz de usuario. La forma de realizarlo es sentar a un usuario delante de la
mquina con una lista de tareas y pedirle que exprese verbalmente lo que va pensando mientras tanto. De esta forma se puede ver
cuales son los problemas que se encuentra la gente
La forma de definir una interfaz del sistema para un sistema basado en casos de uso tiene una serie de pasos y subpasos:
1. Dibujar las pantallas de interaccin para los distintos actores-usuarios. Para ello:
Copiar el modelo mental del usuario.
Revisar los elementos del modelo del mundo interesantes para el actor-usuario.
Visualizacin tpica de los elementos del modelo del mundo.
Informacin relevante para el actor.
Metforas de interaccin vlidas.
2. Especificar el dilogo que da solucin a cada caso de uso que se soluciona con la interaccin con esta interfaz. Puede
especificarse este dilogo de varias maneras, dependiendo de la complejidad de la interfaz definida (en esta etapa se
sugiere escoger el mnimo nivel de detalle posible, para dar ms libertad de diseo en las etapas posteriores):
Por medio de una descripcin textual de su funcionamiento
Por medio de diagramas de interaccin que muestren la secuencia de operaciones entre los objetos de interfaz y los
actores involucrados.
Por medio de diagramas de estados, donde se muestre claramente los estados de la interfaz.
Por medio de un prototipo funcional, en trminos de la interaccin con el usuario.
3. Definir restricciones para la comunicacin con actores y sistemas.
132
9.3.6. Glade
Glade es un programa gratuito de desarrollo de interfaces. Usa las libreras de GTK+ y de GNOME. Genera el cdigo que
crea la interfaz en varios lenguajes: C, C++ Ada, Perl y Eiffel (con lo que puede considerarse como una herramienta CASE).
Tambin es capaz de crear interfaces dinmicas usando libglade. La herramienta se compone de tres ventanas:
1. Ventana principal: Barra de men, la barra de herramientas y una lista de ventanas de alto nivel.
2. El editor de propiedades.
3. La paleta: En ella estn desplegados los elementos que se pueden poner en la interfaz de usuario. Estn divididos en tres
categoras: GTK+ Bsico, GTK+ Avanzado y Gnome.
La forma de utilizar la herramienta es: Primero se escoge el elemento ventana y entonces se pueden poner otros elementos sobre
ella. Para organizar los elementos Glade utiliza cajas. Para poner ms de un elemento en la ventana hay que poner primero
cajas. Las hay de seis tipos: caja horizontal, caja vertical, tabla, posiciones ajustables, caja de botones horizontal, caja de botones
vertical y las cajas a su vez se pueden anidar. Cuando se crean cajas horizontales y verticales hay que especificar el nmero de
filas y columnas.
Cuando se selecciona un componente la ventana de propiedades muestra sus propiedades. Existe un rbol de componentes
que se puede ver seleccionando: View y Show widget tree. Tambin hay un editor de mens, tanto los normales como los
emergentes, que pueden ser anidados. El editor tambin crea manejadores de seales para cada opcin, que son las funciones
invocadas cuando una opcin de men es seleccionada.
Un evento es un tipo de suceso, como puede ser presionar seleccionar una opcin de men o pulsar un botn. Cuando ocurre
un evento el sistema llama a una funcin que lo trata y es en esa funcin donde se escribe el cdigo con las instrucciones que se
deben ejecutar para responder al evento. Por ejemplo, si se pulsa una opcin de men File->Save en un editor de texto, habr
que guardar el texto en un fichero. Glade genera automticamente los nombres de las funciones que responden a los eventos y al
menos cada elemento tiene uno.
9.3.7. GTK+
GTK+ (GIMP ToolKit) es una librera en lenguaje C para crear interfaces grficas de usuario. Tiene licencia GPL, lo cual
significa que es open source y de libre distribucin. Fue diseado originalmente como una herramienta de desarrollo del GIMP
(General Image Manipulation Program) y est construido sobre GDK (GIMP Drawing Kit) que es un aadido de las libreras
Xlib.
GTK+ es un interfaz de programacin de aplicaciones orientadas a objetos (API). Aunque est escrito en lenguaje C, fue
pensado con la idea de las clases y los punteros a funciones.
Al igual que el anterior permite usar gran variedad de componentes (botones, cajas, etc), pero tiene una flexibilidad mayor
en el sentido de que los componentes estn formados a su vez partiendo de otros componentes, que lgicamente pueden ser
133
reemplazados. Por ejemplo, un botn puede tener como hijo un componente etiqueta para representar el texto, pero se puede
sustituir por un bitmap. Por ltimo, GTK+ define un conjunto de tipos dinmico propio con reglas nuevas acerca de como
gestionarlos.
9.3.8. Anjuta
Es un entorno de desarrollo escrito por un estudiante de informtica de ltimo curso llamado Kh. Nabakumar Singh (Anjuta
es el nombre de su novia). Esta pensado para proyectos en C/C++ para GTK+/GNOME, es decir, para GNU/Linux. Anjuta es
libre y su cdigo fuente est disponible en la red. Proporciona una IGU (interfaz grfica de usuario) dividida en tres partes:
Editor: Muestra el texto coloreado. Tiene las funciones estndar de Crear, Salvar, Buscar, etc.
Proyecto.
Mensajes.
Las funcionalidades ofrecidas son accedidas a travs de un sistema de mens que se pueden desmontar de su lugar original. Las
funciones ms comunes pueden encontrarse en las cuatro barras de herramientas. Desde el entorno se puede compilar y ejecutar
el programa. Puede asimismo configurarse para especificar rutas de ficheros include, rutas de libreras, libreras para enlazar,
macros, tipos de alertas del compilador, optimizaciones del cdigo, etc. El entorno consta asimismo de algunas utilidades para
gestionar proyectos. Existe tambin la posibilidad de depurar el programa, o lo que es lo mismo, de ejecutarlo paso a paso, poner
puntos de ruptura, evaluar expresiones, ver los registros de la CPU, etc.
Tutorial posterior
Resumen de contenidos
En captulo se han colocado todos aquellos temas que no tienen entidad suficiente como para ser un captulo por s mismos,
es decir, el captulo es una recopilacin de conceptos interesantes y prcticos acerca de la ingeniera del software.
Herramientas CASE
Una herramienta CASE es una aplicacin diseada para facilitar tareas mecnicas que se realizan en las diferentes etapas del
ciclo de vida. Hay varios tipos y las mejores son las que cubren todas las etapas del ciclo de vida y pensadas adems para una
metodologa concreta. Se incluye una clasificacin de herramientas CASE.
Gestin de la configuracin
Es el conjunto de prcticas y tcnicas que ayudan a gestionar todos los documentos (cdigo, manuales, etc.) que se generan a
lo largo del ciclo de vida del proyecto. Existen herramientas que lo soportan, como CVS del que se hace una pequea descripcin.
Los temas que importan en la gestin de la configuracin son: cules son los documentos que hay que guardar, cmo se almacenan, cmo se relacionan entre s y cmo se gestionan los cambios. El plan de gestin de la configuracin es un documento
que define la poltica a seguir. Se da una plantilla de dicho documento. CVS es una herramienta de libre distribucin para la
gestin de la configuracin que se puede encontrar en cualquier sistema de tipo UNIX GNU/Linux. Se describe brevemente
por estar muy extendida. Sourceforge http://sourceforge.net/ es un ejemplo de almacn centralizado en Internet para el
desarrollo de software de libre distribucin. Se hace un listado de sus caractersticas ms relevantes y se define lo que se entiende
por software libre.
Entornos de desarrollo de interfaces
El desarrollo de interfaces es importante por el porcentaje tan elevado de lneas de cdigo que suponen en un proyecto (en torno al 50 %). Para este fin se han desarrollado herramientas CASE concretas que facilitan el trabajo mecnico. Los componentes
son mdulos de software reutilizable, sobre todo en interfaces grficas. Tipos de componentes: ActiveX y VCL. En la creacin
de interfaces de usuario se define un conjunto de objetivos que tiene que cumplir toda interfaz, todos ellos estn orientados a
usuarios, una metodologa para el desarrollo de interfaces y heursticas de usabilidad. Se ve una somera descripcin de algunas
herramientas de libre distribucin para desarrollo de interfaces: Glade, Gtk y Anjuta.
134
Extensin de conocimientos
La mayor fuente alternativa para extender conocimientos en este tema es Internet. Todas las herramientas y entornos explicados tienen pginas Web propias.
En particular sobre herramientas CASE se recomiendan las direcciones: http://www.cs.queensu.ca/FAQs/SE/ que contiene enlaces a un extenssimo catlogo con herramientas CASE clasificadas y que forma parte de la FAQ del grupo de foros
USENET news://comp.software-eng, hay una copia en http://www.faqs.org/faqs/software-eng/, y ver tambin en
http://sdt.cern.ch/ la pgina del Software Development Tool Service del CERN.
Sobre el sistema CVS se puede consultar directamente el manual en lnea http://www.cvshome.org/docs/manual/ en
el propio dominio del proyecto, o bien la parte en linea de libre distribucin del libro [FB00] en http://cvsbook.red-bean.
com/cvsbook.html. Actualmente est en desarrollo (bastante avanzado) una nueva herramienta de gestin de versiones con
el objetivo de sustituir a CVS, se trata de S UBVERSION cuya pgina de desarrollo es: http://subversion.tigris.org/.
Tambin podemos incluir en este apartado A EGIS que es un entorno de gestin de desarrollo para proyectos y utiliza una interfaz
Web (aparte de lnea de comandos), con ms informacin en la pgina http://aegis.sourceforge.net/.
Para las diferentes herramientas de desarrollo propuestas se pueden visitar directamente las paginas correspondientes: http:
//glade.gnome.org/ sobre G LADE (y tambin de A NJUTA http://anjuta.sourceforge.net/ que utiliza G LADE), http:
//www.wxwindows.org/ sobre WX W INDOWS, http://www.kdevelop.org/ sobre K DEVELOP.
Apndice A
Glosario de trminos
Abstraccin: Separar las caractersticas que interesan para un modelo de las irrelevantes.
Acoplamiento: Medida de la complejidad de los interfaces de los mdulos.
ActiveX: Tipo de componente distribuido como binario.
Actividad: Cada una de las partes en las que se divide una fase.
Actividades, diagrama: Grfico de UML que modela el comportamiento interno de una clase.
Actividades, diagrama de: Grfico UML que muestra el comportamiento y la participacin de las clases en el mismo. til para
flujos de trabajo.
Actor: Persona o sistema que juega un papel en la interaccin con un sistema.
Agregacin: Relacin entre dos clases en la que una es parte de la otra.
Alcance: Visibilidad de un atributo. Puede ser pblico, protegido o privado.
Almacn: Es un conjunto de datos esttico. Puede ser un archivo o una base de datos.
Alto nivel, lenguajes: Son lenguajes con alto nivel de abstraccin. Hacen lo mismo que un lenguaje de bajo nivel pero con
menos lneas.
mbito: Nmero de veces que existe el objeto. De instancia: Una por cada instancia de la clase. Archivador: Una nica vez,
como las variables static de Java.
Anlisis: Etapa donde el problema es la comprensin de las necesidades.
Anlisis crtico: Actividad que se realiza desde el principio del proyecto para localizar los problemas de alto riesgo.
Anlisis de valores lmite: Tcnica de generacin de casos de prueba conjunta con particiones de equivalencia que genera casos
de prueba cercanos al mximo o mnimo tamao de un array o al mximo o mnimo nmero de iteraciones de un bucle.
rboles de decisin: Grfico en forma de rbol para escribir una especificacin de procesos cuando se tiene un conjunto de
unas pocas variables y se toman decisiones en funcin de los valores que tomen.
Asociaciones: Relacin que se establece entre dos o ms clases.
Atributo: Variable de una clase.
Auditora: Examen del sistema preferiblemente por parte de una organizacin no involucrada en el proceso de desarrollo. Tipos:
regulares, especiales, sorpresa, de seguimiento, financiera, operacional, de gestin e informtica.
Brainstorming: Tcnica poco estructurada de obtencin de requisitos en una reunin.
Caja blanca, pruebas: Pruebas que tienen en cuenta la estructura lgica del programa.
Caja de cristal, pruebas: Ver caja blanca.
Caja negra, pruebas: Pruebas que tienen en cuenta las especificaciones.
Calificacin: Atributo que rebaja la cardinalidad de una parte de la asociacin entre dos clases.
Cardinalidad: Nmero de entidades que estn asociadas con otra(s) en una relacin.
Cascada: Ciclo de vida lineal.
135
136
Glosario de trminos
CASE: (Computer Aided Software Engineering) Herramienta para automatizar o facilitar parte o todo el trabajo mecnico (no
creativo) de parte o todo el ciclo de vida.
Casos de prueba: Conjunto de entradas y de salidas esperadas para esas entradas.
Casos de uso: Mtodo de anlisis para una interaccin del sistema con el usuario u otro sistema.
Ciclo de vida: Conjunto de etapas por las que pasa un sistema informtico desde su concepcin hasta su retirada.
Clase: Estructura de datos con las operaciones relativas a esos datos.
Clases, diagrama: Principal tipo de diagrama en UML que muestra las clases y las relaciones que tienen.
Clases de equivalencia: Agrupaciones de las entradas iguales a efectos de las pruebas.
Cleanroom: Tcnica de generacin de software basada en mtodos formales para minimizar el nmero de errores.
Cliente-servidor: Arquitectura de sistemas distribuidos con una parte que funciona como interfaz (cliente) y otra que gestiona
recursos y realiza el trabajo (servidor).
Codificacin: Etapa del ciclo de vida en la que se escribe el cdigo fuente.
Cdigo heredado: (legacy code) Cdigo de aplicaciones antiguas posiblemente muy remendado y sin documentacin.
Cohesin: Caracterstica de un mdulo. Un mdulo tiene cohesin si sus tareas son independientes del resto del sistema pero
estn relacionadas entre s.
Colaboracin, diagrama: Indica interacciones entre objetos a travs de los enlaces que hay entre ellos. Similar al diagrama de
secuencia.
Complejidad ciclomtica: Medida de la complejidad de un programa, igual al nmero de caminos independientes que tiene.
Componentes: Software pensado para ser reutilizable. Consta de cdigo y datos.
Componentes, diagrama: Grfico de UML que muestra la organizacin y dependencias entre componentes.
Composicin: Es un tipo de agregacin en la que cada componente pertenece a un todo y slo a ese.
Congruencia: Un mtodo es congruente si tiene un nombre similar a mtodos similares, condiciones, orden de argumentos,
valor proporcionado y condiciones de error.
Contexto, diagrama: Representacin del sistema y entidades externas que interaccionan con l.
CORBA: (Common Object Request Broquer Architecture) Sistema distribuido multiplataforma basado en objetos. Cada uno
puede ser cliente y servidor.
CRC: Mecanismo para representar clases e interacciones entre ellas.
Crisis del software: La consecuencia de escribir cdigo sin plantear seriamente metodologas para el anlisis, diseo y mantenimiento.
CVS: (Concurrent Versioning System) Almacenamiento de ficheros con capacidad de trazar las aportaciones de cada persona y
la historia de cada archivo.
Defecto: El sistema hace algo de forma equivocada. Es la consecuencia de un error y se manifiesta a travs de un fallo.
DFD: (Diagrama de Flujo de Datos) Herramienta del diseo estructurado para modelar la transformacin o transaccin de la
informacin.
Diccionario de datos: Descripcin detallada de los flujos de datos
Diseo: Etapa del ciclo de vida en la que se divide el sistema en subsistemas y posteriormente se decide cmo sern las estructuras de datos y algoritmos.
Distribucin, diagrama: Grfico de UML que refleja la organizacin del hardware.
Encapsulamiento: Propiedad por la que un objeto o mdulo proporciona al exterior las funciones necesarias para su manejo y
no los detalles internos.
Entidad-Relacin: Modelo de datos del diseo estructurado.
Entidades externas: Personas o sistemas que interaccionan con el sistema.
Entrada/Salida, pruebas: Ver caja negra.
137
138
Glosario de trminos
Mantenibilidad: Cualidad de una aplicacin que hace que el mantenimiento sea ms fcil.
Metodologa: Modo sistemtico de fabricar un producto.
Mtricas: Medidas numricas sobre alguna cualidad de un programa.
Modelo: Abstraccin de la realidad donde se omite lo no esencial.
Mdulo: Cada una de las partes con entidad propia en las que se divide un sistema.
Modularidad: Propiedad del software. Un programa es modular si est dividido en partes con tareas definidas.
Multiplicidad: Nmero de elementos que estn en los lados de una relacin.
Navegabilidad: Posibilidad de moverse de una clase a otra utilizando las relaciones que hay entre ellas.
Normalizacin: Algoritmos que convierten una base de datos en otra equivalente pero sin anomalias de insercin, borrado y
modificacin, ms eficiente y menos redundante.
Notas: Explicaciones de los elementos de notacin de UML.
Objeto: Instancia de una clase.
OCL: (Object Constraint Languaje) Lenguaje formal para expresar restricciones.
Paquetes: Conjunto de clases relacionadas entre si.
Patrones: Prototipos de soluciones para problemas conocidos. Los hay de anlisis, arquitectnicos, de diseo, de codificacin y
de organizacin.
Persistencia: Caracterstica de un objeto que se puede escribir en disco para posteriormente ser recuperado.
Polimorfismo: Capacidad de un conjunto de objetos de responder a un mensaje con el mismo nombre o a un objeto de poder
responder a un mismo mensaje con distintos parmetros.
Privado: Tipo de alcance ms restrictivo posible. Una propiedad de este tipo solo puede ser accedida dentro de la clase en la
que est declarada.
Proceso: Subsistemas o funciones en las que se divie el sistema.
Protegido: Tipo de alcance que restringe el acceso a la clase en la que se ha declarado y a sus descendientes.
Prototipo: Versin reducida de la aplicacin final. Se construye para obtener requisitos o para partiendo de l hacer incrementos
hasta el sistema final.
Pruebas: Batera de test que el sistema tiene que superar para ser considerado operativo.
Pblico: Tipo de alcance que permite el acceso a cualquier otra clase.
Reduccin de riesgos, cascada con: Ciclo de vida cascada con iteraciones en el anlisis y diseo global.
Reingeniera: Reconstruccin completa de una aplicacin antigua utilizando tcnicas modernas.
Requisitos funcionales: Lo que el sistema hace para el usuario.
Requisitos no funcionales: Caractersticas del sistema (fiabilidad, mantenibilidad, etc). Se tienen en cuenta en la fase de diseo.
Responsabilidades: Descripcin de lo que hace una clase.
Revisin: Las distintas versiones de un elementos software que van surgiendo.
Sashimi, ciclo: Ciclo de vida en cascada con solapamiento entre las fases.
Secuencias, diagrama: Grfico de UML que muestra los mensajes intercambiados entre objetos teniendo en cuenta el tiempo.
Sistema: Conjunto de elementos que cooperan entre si para proporcionar servicios.
Sistemas, ingeniera de: Herramientas y metodologas para crear sistemas.
Software, ingeniera del: Herramientas y metodologas para crear software.
Tarea: Una etapa (p.ej. el diseo) se descompone en tareas. Una tarea puede realizarse a lo largo de varias etapas, por ejemplo
la documentacin.
Tablas de decisin: Forma de escribir una especificacin de procesos cuando hay muchas variables y en funcin de su valor se
toman decisiones.
139
Transicin de estados: Diagrama de UML que refleja los cambios que esperimenta una clase como si fuera un autmata finito.
UML: (Unified modeling languaje) Notacin de facto para el modelado de sistemas orientados a objetos.
V, ciclo de vida en: Ciclo de vida similar al de cascada pero que toma en consideracin el nivel de abstraccin de cada una. El
anlisis valida el mantenimiento y el diseo verifica las pruebas.
Validacin: Comprobacin de que el sistema cumple con las especificaciones funcionales y no funcionales.
Variante: Versin de un elemento software que cohexiste con otra con algunas diferencias.
VCL: (Visual Component Library) Componente grfico.
Verificacin: Comprobacin de que el sistema funciona correctamente.
Versin: Un elemento software en un momento dado.
Walkthrough: Revisin del cdigo sin ejecutarlo. Realizado por un equipo.
Warnier, diagramas: Representacin jerrquica de la estructura de los programas y estructuras de datos.
140
Glosario de trminos
Bibliografa
[Bau72]
[Bec99]
[BF00]
Kent Beck and Martin Fowler. Planning Extreme Programming. Addison-Wesley, 2000.
[BMP87]
Doug Bell, Ian Morrey, and John Pugh. Software Engineering: A Programming Approach. Prentice Hall, 1987.
[Boo94]
[CCEG00]
J. A. Cerrada, M. Collado, J. F. Estvaliz, and S. R. Gmez. Introduccin a la Ingeniera de Software. Ceura, 2000.
[DEM02]
Allen Downey, Jeff Elkner, and Chris Meyers. How to Think Like a Computer Scientist: Learning with Python.
Green Tea Press, 2002. http://thinkpython.com.
[FB00]
Karl Fogel and Moshe Bar. Open Source Development With CVS. The Coriolis Group, 2000.
[Fow97]
[FW94]
Neville J. Ford and Mark Woodroffe. Introducing Software Engineering. Prentice-Hall, 1994.
[Gau01]
[GW89]
Donald A. Gause and Gerald M. Weinberg. Exploring Requirements: Quality Before Design. Sei Series in Software
Engineering. Dorset House, 1989.
[Haw98]
[Hum95]
[Hum01]
[Jac92]
[JAH00]
Ron Jeffries, Ann Anderson, and Chet Hendrickson. Extreme Programming Installed. Addison-Wesley, 2000.
ftp://ftp.xprogramming.com/ftp/xpinstall.pdf.
[JBR00a]
Ivar Jacobson, Grady Booch, and James Rumbaugh. El lenguaje unificado de modelado. Addison Wesley, 2000.
[JBR00b]
Ivar Jacobson, Grady Booch, and James Rumbaugh. El lenguaje unificado de modelado. Manual de referencia.
Addison Wesley, 2000.
[JBR00c]
Ivar Jacobson, Grady Booch, and James Rumbaugh. El proceso unificado de desarrollo de software. Addison
Wesley, 2000.
[Mey98]
[Pre97]
[Pre01]
[PV96]
Mario G. Piattini Velthuis. Anlisis y diseo detallado de aplicaciones informticas de gestin. RAMA, 1996.
[Ray99]
Eric S. Raymond.
The Cathedral & the Bazaar.
http://tuxedo.org/esr/writings/cathedral-bazaar/.
[RBP 96]
James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen. Modelado y diseo
orientado a objetos. Metodologa OMT y OMT II. Prentice Hall, 1996.
[Sch92]
[Sch01a]
Stephen R. Schach. Object oriented and classical software engineering. Mc GrawHill, 2001.
141
142
Bibliografa
[Sch01b]
[Som98]
[Som01]
[WBWW90] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener. Designing Object-Oriented Software. Prentice Hall,
1990.
ndice alfabtico
Aceptacin, 78
ActiveX, 130
Actividades, 105
Actor, 93
Adecuacin, 3
Almacn, 119
Anlisis, 36, 118
Clase, 95
Modelo, 95
Paquete, 95
Paquete de servicio, 95
RUP, 95
Anlisis costo-beneficio, 80
Anlisis de riesgo, 80
Anlisis de sistema de informacin, 116
Anlisis de sistemas de informacin, 108
Anjuta, 133
Argumentos, 64
Arquitecto, 98
Arquitectura
Anlisis, 95
Descripcin, 93, 95
Diseo, 97
Implementacin, 98
Arquitectura de capas, 91
Arquitectura de mdulos
Diseo, 109
Arquitectura de soporte
Diseo, 109
Arquitectura del sistema
Definicin, 110
Artefactos, 95, 98
Aseguramiento de la calidad, 115
Asignacin, 64
Asociaciones, 56
C++, 56
Java, 57
Ayuda, 132
Bazaar, 119
Biblioteca de software, 126
Biblioteca de backup, 126
Biblioteca de integracin, 126
Biblioteca de produccin, 126
Biblioteca de soporte, 126
Biblioteca de trabajo, 126
Biblioteca maestra, 126
Repositorio de software, 126
Bibliotecario, 126
Bloques, 63
Brainstorming, 39
C++, 3
Cdigo
Propiedad compartida, 105
143
Cdigo externo, 58
Cambios de estado, 126
Capa intermedia, 91
Carga inicial, 110
Caso de prueba, 99
Caso de uso, 93
Anlisis, 96
Diseo, 97
Instancia, 93
Realizacin, 96
Casos de uso, 41, 42, 54, 88
Actor, 41
Rol, 41
Actores abstractos, 43
Casos de uso abstractos, 43
Casos de uso de implementacin, 43
Casos de uso esenciales, 43
Casos de uso primarios, 44
Casos de uso secundarios, 44
Casos de uso temporales, 44
Comunicates, 16
Detallar, 94
Diseo, 110
Estructura, 94
Extends, 16
Include, 16
Priorizar, 94
Realizacin, 95
Cast, 65
Cathedral, 119
Check out, 128
Ciclo de vida, 4
Cascada con reduccin de riesgos, 7
Cascada con subproyectos, 6
Cascada incremental, 7
Ciclo de vida en cascada, 4
Ciclo de vida en V, 6
Diseo, 96
Espiral, 7
Fuente, 9
Sashimi, 6
Cierre, 78
Clase, 10
Abreviada, 11
Abstracta, 10
Anlisis, 96
Asociacin, 12
Agragacin, 13
Calificacin, 13
Composicin, 13
Dependencia, 13
Herencia y generalizacin, 13
Interfaces, 13
Multiplicidad, 12
144
Navegabilidad, 13
Reflexiva, 12
Rol, 12
Atributos, 10
Diseo, 97
Estereotipo, 11
Implementacin, 99
Mtodos, 11
Nombre, 10
Notas, 11
Objeto, 11
Paquete, 11
Responsabilidades, 11
Clase del diseo, 96
Clases, 63
Diseo, 110
Java, 69
ClearCase, 128
Cliente, 104
Cliente/Servidor, 105
code-and-fix, 2
Codificacin
Estndares, 104
Prueba de unidad, 103
Unidad, 103
Comentarios, 60, 62
Java, 68
Componente, 98
Componente de prueba, 99
Componentes, 130
Configuracin del software, 124
Congelar, 125
Const, 63
Constantes
Java, 69
Construccin, 118
Construccin de sistemas de informacin, 111
Constructores, 64
Control de cambios, 126
Control de flujo, 63, 66
Contruccin del sistema de informacin, 116
Correccin, 3
Creacin de objetos, 55
C++, 55
Java, 55
CVS, 127
Declaracin, 60
Funciones, 60
Variables, 60
Declaraciones
Java, 68
Defecto, 99
Definicin de clases, 54
C++, 54
Java, 55
Delegacin, 58
Delta, 125
Delta directo, 125
Delta inverso, 125
Demeter, 58
Destruccin de objetos, 55
C++, 55
Java, 55
ndice alfabtico
Destructores, 64
DFD, 3
Diagrama de actividades, 19
Actividades, 19
Actividades concurrentes, 19
Bifurcaciones, 19
Indicaciones, 19
Punto final, 19
Punto inicial, 19
Transiciones, 19
Diagrama de casos de uso, 15
Diagrama de clases, 14
Diagrama de colaboracin, 20
Diagrama de componentes, 20
Diagrama de distribucin, 20
Nodo, 20
Diagrama de estados, 17
Do, 17
Entry, 17
Exit, 17
Diagrama de objetos, 15
Diagrama de secuencias, 17
Activacin, 17
Boundary classes, 18
Condicionales, 18
Creacin, 18
Destruccin, 18
Iteracin, 18
Lnea de vida, 17
Mtodos recursivos, 18
Mensaje, 18
Tiempos de transicin, 18
Diccionario de datos, 3
Directorio, 70
Diseador de pruebas, 99
Disear prueba, 100
Diseo, 118
Revisin, 50
RUP, 96
Subsistema, 96
Validacin, 51
Verificacin, 50
Diseo de detalle, 109
Diseo de sistemas de informacin, 109
Diseo del sistema de informacin, 116
Diseo fsico de datos, 109
Disponibilidad, 3
Documentacin, 70, 132
Eficiencia, 3
Entrevistas, 37
Fases, 37
Errores, 66, 104, 132
Especificacin, 36
Especificacin de procesos, 3
Especificaciones de construccin, 110
Especificaciones de la base de datos, 81
Especificaciones de sistema, 80
Especificaciones de subsistema, 80
Especificaciones del programa, 81
Estudio de la viabilidad, 107
Estudio de viabilidad, 80, 115, 118
Etapas ciclo de vida, 4
Anlisis, 4
ndice alfabtico
145
Codificacin, 4
Diseo, 4
Mantenimiento, 4
Pruebas, 4
Evaluacin de prueba, 99
Evaluar prueba, 100
Eventos, 130
Excepciones, 66
Explicativo, 70
Expresiones, 66
Extensibilidad, 58
Extreme programming, 100
Java, 69
Interfaz, 97, 98
Interfaz de usuario
Diseador, 93
Prototipo, 93, 94
Invocacin de mtodos, 55
C++, 56
Java, 56
Islas de conocimiento, 105
Iteracin
Planificacin, 92, 102
Iteraciones, 92
Fiabilidad, 3
Finalizacin, 77, 115
Flujo de sucesos, 93
Flujo de trabajo, 94, 95, 97, 98
Flujos de trabajo, 100
Friend, 63
Funciones, 63
JAD, 37
Java, 3
JRP, 39
146
OMT, 10
OOSE, 10
Optimizaciones, 104
Overflow, 67
Pblico, 131
Pair programming, 105
Paquete
Anlisis, 96
Paquetes
Java, 69
Personal, 104
Plan de instalacin, 81
Plan de integracin de construcciones, 98
Plan de proyecto, 80
Plan de prueba, 99
Plan de pruebas, 74
Especificacin tcnica, 110
Plan de publicacin, 101
Plan de sistemas de informacin, 106
Planificacin, 106, 118
Planificar prueba, 100
Prcticas, 105
Prlogo, 70
Privado, 130
Procedimiento de prueba, 99
Procedimientos, 82
Procedimientos de migracin y carga de datos, 112
Procedimientos de operacin, 111
Procedimientos de seguridad, 111
Procesos, 105, 106
Protegido, 130
Prototipos, 40
Componentes reutilizables, 40
Nivel de aplicacin, 41
Nivel de componente, 41
Desarrollo rpido de prototipos, 40
Lenguajes de alto nivel, 40
Programacin de bases de datos, 40
Prueba, 99
Prueba de integracin, 100
Prueba de sistema, 100
Prueba de unidad, 99, 103
Pruebas, 81
Modelo, 99
Pruebas de desempeo, 75
Pruebas de tensin, 75
Pruebas estructurales, 75
Pruebas funcionales, 74
Pruebas de integracin, 112
Pruebas de regresin, 92
Pruebas de sistema, 112
Pruebas unitarias, 112
Publicado, 131
Punteros, 63, 65
RCS, 128
Registros, 127
Rehacer, 104
Release, 125
Repositorio, 128
Requisito, 36
Requisitos
Requisitos funcionales, 93
ndice alfabtico
Requisitos no funcionales, 93
Requisitos cambiantes, 92
Requisitos de datos, 80
Requisitos de implantacin, 110
Requisitos funcionales, 36, 80, 91
Requisitos no funcionales, 36
Reuniones, 105
Reusabilidad, 57
Revisin, 125, 128
Riesgos, 91
Gestin, 92
Tratamiento, 92
Robustez, 58
RUP, 88
Construccin, 89
Elaboracin, 89
Inicio, 88
Transicin, 89
SCO-Unix, 120
Secuenciacin, 92
Seguimiento y control, 114
Gestin de inicidencias, 114
Sentencias
Java, 68
Separaciones
Java, 69
Simula67, 3
Sistema, 2
Smaltalk, 3
Sobrecarga, 64
Funciones, 64
Operadores, 64
Software libre, 129
Sourceforge, 129
SRS, 45
Subsistema
Diseo, 98
Implementacin, 99
Subsistema de implementacin, 98
Subsistemas, 109
Tabla de tareas, 105
Tarjetas CRC, 102
Templates, 64
Test de aceptacin, 104
Test de unidad, 104
Trabajadores, 93, 95, 9799
Analista de sistemas, 93
Arquitecto, 93, 95, 97
Diseador de interfaz de usuario, 93
Especificador de casos de uso, 93
Ingeniero de casos de uso, 95, 97
Ingeniero de componentes, 95
Tutoriales, 82
UML, 10, 54, 88
Underflow, 67
Unix, 120
Usabilidad, 3
Variables, 65
Java, 69
Variante, 125
Experimental, 125
ndice alfabtico
Permanente, 125
Pruebas, 125
Temporar, 125
Variantes de plataforma, 125
Variantes de requisitos de usuario, 125
VCL, 130
Versin, 125
versin delta, 89
Visibilidad, 132
Vistas, 91
147