Programación.
Short Description
Descripción: Informática...
Description
Programación.
Índice general 1
Programación
1
1.1
Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Léxico y programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.3
Programas y algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.4
Compilación
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.5
Programación e ingeniería del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.6
Referencias históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.7
Objetivos de la programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.8
Ciclo de vida del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.9
Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.10 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.11 Enlaces externos
4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
Portal:Programación
5
3
&
6
4
5
6
3.1
Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.2
Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.3
Enlaces externos
7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Acoplamiento secuencial
8
4.1
Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
4.2
Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
Adobe Director
9
5.1
Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
5.2
Timeline
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
5.3
Director y Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
5.4
Shockwave / Shockwave 3D
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
5.5
Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
5.6
Enlaces externos
10
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anidamiento (informática)
12
6.1
12
En las planillas de cálculo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
ii
7
8
9
ÍNDICE GENERAL 6.2
En programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
6.3
Véase también
12
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Antipatrón de diseño
13
7.1
Algunos antipatrones de desarrollo de software . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
7.1.1
Antipatrones de gestión
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
7.1.2
Antipatrones de gestión de proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
7.1.3
Antipatrones generales de diseño de software
. . . . . . . . . . . . . . . . . . . . . . . .
14
7.1.4
Antipatrones de programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
7.1.5
Antipatrones metodológicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
7.1.6
Antipatrones de gestión de la configuración
. . . . . . . . . . . . . . . . . . . . . . . . .
16
7.2
Algunos antipatrones organizacionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
7.3
Relación alfabética de otros antipatrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
7.4
Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
7.5
Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
Archivo de cabecera
21
8.1
Motivación
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
8.2
Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
8.3
Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
8.4
Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Aserción (informática)
24
9.1
Uso de las aserciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
9.1.1
Aserciones en el diseño por contrato . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
9.1.2
Aserciones en tiempo de ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
9.1.3
Aserciones durante el ciclo de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
9.1.4
Aserciones estáticas
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
9.2
Desactivación de las aserciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
9.3
Comparación con los manejadores de errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
9.4
Enlaces externos
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 Automatización de tareas
27
11 Base de código
28
11.1 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12 Bean
28 29
12.1 Bean en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
12.2 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
13 Beta tester
30
13.1 Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
13.2 Alfa tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
ÍNDICE GENERAL
iii
13.3 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
13.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
14 Bifurcación (sistema operativo)
31
14.1 UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
14.2 Véase también
31
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15 Binding
32
15.1 Psicología y educación
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
15.2 Informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
15.3 Derecho mercantil
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
15.4 Enlaces externos 16 Bloqueo mutuo
33
16.1 Representación de Bloqueos Mutuos usando grafos . . . . . . . . . . . . . . . . . . . . . . . . . .
33
16.2 Condiciones necesarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
16.3 Evitando bloqueos mutuos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
16.5 Livelock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
16.4 Prevención
17 Bodyshopping
35
17.1 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
18 BrookGPU
36
19 Caja blanca (sistemas)
37
19.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Caja negra (sistemas)
37 38
20.1 Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
20.2 Caja negra y programación modular
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
20.3 Pruebas de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
20.4 Caja negra vs 'Cajanegrizar' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
20.5 Véase también
38
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21 CamelCase
40
21.1 Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
21.2 Enlaces externos
40
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22 Caml 22.1 Ejemplos
41 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22.1.1 Hola Mundo
41
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
22.1.2 Función factorial (recursividad y programación puramente funcional) . . . . . . . . . . . .
41
22.1.3 Derivación numérica (funciones de alto orden) . . . . . . . . . . . . . . . . . . . . . . . .
41
22.1.4 Transformada Wavelet discreta (concordancia de patrones) . . . . . . . . . . . . . . . . .
42
iv
ÍNDICE GENERAL 22.2 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
22.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
22.4 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
22.4.1 Libros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
23 Cierre de exclusión mutua
43
23.1 Primitivas y uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
23.2 Bloqueos en bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
24 Clase utilidad
44
24.1 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
25 Clear.gif
45
26 CMake
46
26.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
26.2 Documentación y tutoriales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
26.3 Principales funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
26.4 CTest, CPack, CDash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
26.5 Aplicaciones que utilizan CMake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
26.6 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
26.7 Enlaces externos 27 Codecademy
48
27.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
27.2 Code Year
48
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27.3 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
27.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
27.5 Enlaces externos
49
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28 Código cerrado 28.1 Véase también
50 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
29 Código compilado
51
30 Código mutante
52
31 Código objeto
53
31.1 Código objeto en lenguajes de programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
31.2 Errores comunes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
31.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
31.4 Enlaces externos
53
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32 Ofuscación 32.1 Informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54 54
ÍNDICE GENERAL
v
32.1.1 Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
32.2 Otros objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
32.3 Enlaces externos
55
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33 ColdFusion
56
33.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
33.2 Versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
33.3 Ejemplos de código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
33.4 Enlaces externos
57
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34 Coloreado de sintaxis
58
34.1 Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
34.2 Programas con coloreado de sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
34.3 Véase también
58
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35 Comentario (informática)
59
35.1 Información general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
35.2 Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
35.2.1 Planeación / Revisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
35.2.2 Descripción de código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
35.2.3 Descripción algorítmica
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
35.2.4 Inclusión de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
35.2.5 Depuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
35.2.6 Generación de documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
35.3 Estilos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
35.3.1 Etiquetas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
35.4 Curiosidades
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.5.1 Ensamblador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.5.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.5.3 C/C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.5.4 Delphi
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.5.5 Lua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.5.6 Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.5.7 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.5.8 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.5.9 Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.5.10 código HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.5.11 SQL
62
35.5 Ejemplos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35.5.12 Visual Basic
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.5.13 Pauscal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.5.14 PHP
62
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
ÍNDICE GENERAL 35.5.15 Cobol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.6 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
35.7 Enlaces externos
63
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36 Compatibilidad (informática)
64
36.1 Problemas de compatibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
36.2 Emulación
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
36.3 OpenSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
36.4 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
36.5 Enlaces externos
37 Competición Internacional Universitaria ACM de Programación
66
37.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
37.2 Reglas de la competición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
37.3 Competiciones locales, regionales y final mundial
. . . . . . . . . . . . . . . . . . . . . . . . . .
67
37.4 Lista de competiciones regionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
37.5 Ganadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
37.6 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
37.7 Enlaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
37.7.1 Jueces en Línea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
38 Computación parasitaria
69
38.1 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
38.2 Enlaces externos
69
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39 Conectiva lógica
70
39.1 Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
39.1.1 Lenguaje natural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
39.1.2 Lenguajes formales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
39.2 Lista de conectivos lógicos comunes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
39.2.1 Lista de conectivos lógicos comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
39.2.2 Historia de las notaciones
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
39.4 Propiedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
39.5 Ciencias de la computación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
39.6 Conectivas por el número de argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
39.6.1 Sin argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
39.6.2 Con un argumento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
39.6.3 Con dos argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
39.3 Redundancia
39.7 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
39.8 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
39.9 Enlaces externos
73
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ÍNDICE GENERAL
vii
40 Configuración regional
74
40.1 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
40.2 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
40.3 Enlaces externos
74
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41 Conteo de referencias 41.1 Véase también
75 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42 Convención de Nombres (Programación)
75 76
42.1 Beneficios potenciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
42.2 Desafíos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
42.3 El valor del negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
42.4 Elementos comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
42.4.1 Longitud de identificadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
42.4.2 Mayúsculas, minúsculas y números
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
42.4.3 Identificadores de varias palabras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
42.5 Metadatos y convenciones híbridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
42.5.1 Notación húngara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
42.5.2 Notación posicional
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
42.5.3 Esquema de palabra compuesta (del lenguaje) . . . . . . . . . . . . . . . . . . . . . . . .
78
42.6 Convenciones específicas del lenguaje
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
42.6.2 Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
42.6.3 C y C++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
42.6.4 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
42.6.5 JavaScript
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
42.6.6 Lisp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
42.6.7 .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
42.6.8 Objective-C
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
42.6.9 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
42.6.10 Python y Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
42.6.1 ActionScript
42.7 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
42.8 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
42.9 Enlaces externos
80
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43 Cracking (software) 43.1 Véase también
81 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
44 Cuaderno de carga
82
45 Currificación
83
45.1 Nomenclatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
45.2 Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
viii
ÍNDICE GENERAL 45.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
45.4 Enlaces externos
83
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46 Código enhebrado
84
46.1 Historia que llevó al código enhebrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
46.2 Desarrollo del código enhebrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
46.3 Modelos de enhebrado
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
46.3.1 Enhebrado directo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
46.3.2 Enhebrado indirecto
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46.3.3 Enhebrado de subrutina
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
46.3.5 Enhebrado de Huffman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
46.3.6 Enhebrados menos usados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
46.4 Bifurcaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
46.5 Amenidades comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
46.6 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
46.7 Lectura adicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
46.8 Véase también
88
46.3.4 Enhebrado de token
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47 Código inalcanzable 47.1 Causas
89
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
47.2 Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
47.3 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
47.3.1 Profiling
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
47.5 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
47.6 Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
47.7 Enlaces externos
90
47.4 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48 Código muerto
91
48.1 Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
48.2 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
48.3 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
48.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
48.5 Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
48.6 Enlaces externos
91
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49 Código redundante 49.1 Ejemplos
93
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
49.2 Eliminación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
49.3 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
49.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
ÍNDICE GENERAL
ix
50 Dato
94
50.1 Véase también 50.2 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
51 Depuración de programas
95
51.1 Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
51.2 Aplicación
95
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51.3 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52 Desarrollador de software 52.1 Véase también
95 96
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53 Desarrollo en cascada
96 97
53.1 Fases del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
53.1.1 Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
53.1.2 Diseño del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
53.1.3 Diseño del Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
53.1.4 Codificación
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
53.1.5 Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
53.1.6 Verificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
53.1.7 Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
53.2 Variantes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
53.3 Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
53.4 Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
53.5 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
53.6 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
53.7 Enlaces externos
99
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54 Desarrollo en espiral 54.1 Introducción
100
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
54.2 Ciclos o Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 54.2.1 Tareas
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
54.3 Mecanismos de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 54.4 Variaciones del Modelo En Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 54.5 Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 54.6 Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 54.7 Inconvenientes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
54.8 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
54.9 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 54.10Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
55 Desarrollo iterativo y creciente 55.1 Concepto de desarrollo iterativo y creciente
103 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
x
ÍNDICE GENERAL 55.2 Ciclo de vida
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
55.2.1 Consideraciones sobre el momento de aplicación
. . . . . . . . . . . . . . . . . . . . . . 103
55.2.2 Etapa de inicialización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 55.2.3 Etapa de iteración
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
55.3 Caso práctico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 55.4 Características
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
55.5 Ventajas del desarrollo incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 55.6 Ventajas del desarrollo iterativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 55.7 Debilidades de este modelo de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 55.8 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
55.9 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 56 Detección dinámica de invariantes
107
56.1 Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 57 Diagrama de colaboración
108
57.1 Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 57.2 Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 57.3 Mensajes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
57.4 Flujos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 57.5 Cambios en versiones recientes de UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 58 Diagrama de flujo
110
58.1 Normas de trabajo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
58.2 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 58.3 Tipos de diagramas de flujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 58.4 Simbología y significado
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
58.5 Cursograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 58.5.1 Simbología y normas del cursograma
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
58.6 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 58.7 Ventajas de los diagramas de flujo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
58.8 Software para diseño de diagramas de flujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 58.9 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
58.10Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 58.11Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
59 Diagrama Nassi-Shneiderman
114
59.1 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 59.2 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 59.3 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
59.3.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 60 diff
115
ÍNDICE GENERAL
xi
60.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 60.2 Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 60.3 Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 60.4 Variantes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
60.4.1 Edit script
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
60.5 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 60.6 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
60.7 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
61 Dirección de retorno
118
62 Diseño estructurado
119
62.1 Etapas del Diseño estructurado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 62.1.1 Descomposición
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
62.1.2 Jerarquía de módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 62.1.3 Independencia
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
62.2 Evaluando el diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 62.2.1 Acoplamiento
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
62.2.2 Cohesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 62.2.3 Fan-In y Fan-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 62.3 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
63 Distancia de Damerau-Levenshtein
122
63.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 63.2 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
63.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 64 Distancia de Levenshtein
123
64.1 El algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 64.2 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 64.2.1 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 64.2.2 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 64.2.3 C#
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
64.2.4 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 64.2.5 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 64.2.6 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 64.2.7 Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 64.2.8 PHP 64.2.9 Delphi
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
64.2.10 VB.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 64.2.11 ActionScript 3.0
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
64.2.12 ColdFusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 64.2.13 JavaScript (NodeJS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
xii
ÍNDICE GENERAL 64.3 Aplicaciones
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
64.4 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
64.5 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 65 DLO
126
65.1 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 66 Driver Chain Manager
127
66.1 ¿Qué hace? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 66.1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 66.1.2 Capacidades de DCM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
66.1.3 Cuestiones fuera del alcance de DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 66.2 Sotrware que utiliza DCM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
66.2.1 Aplicaciones que utilizan DCM 66.2.2 Empresas desarrolladoras
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
66.2.3 Sistemas operativos que soportan ʻDCM . . . . . . . . . . . . . . . . . . . . . . . . . . 128 66.3 Funcionamiento de la cadena de drivers 66.3.1 El problema
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
66.3.2 Forma de solucionarlo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 66.4 Otras aplicaciones que utilizan DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 66.5 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
66.6 Fuentes y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 67 Dublin Core
129
67.1 Descripción general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 67.2 Clasificación y elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 67.3 Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 67.4 Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 67.5 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 68 eAthena 68.1 Enlaces externos
132 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
69 Efecto Hover
133
69.1 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 69.2 Enlaces de interés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 70 Emtp
134
70.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 70.2 ATP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 70.3 Método de solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 70.4 Distribución de EMTP-ATP 70.5 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
70.6 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
ÍNDICE GENERAL
xiii
71 Enlace dinámico
135
72 Enlace estático
136
73 Enlazado
137
74 Entrada chapuza
138
74.1 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
74.2 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
75 Error de software
139
75.1 Orígenes del término . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 75.2 Defectos de diseño de programas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 75.3 Errores de programación comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 75.4 Defectos de instalación o programación
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
75.5 Códigos de errores de lenguajes de programación 75.6 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . 140
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
75.7 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 75.8 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
76 Estilo de programación
142
76.1 Características del estilo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
76.1.1 Nombres de variable apropiadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 76.1.2 Estilo de indentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 76.1.3 Valores booleanos en estructuras de decisión . . . . . . . . . . . . . . . . . . . . . . . . . 142 76.1.4 Bucles y estructuras de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 76.1.5 Espaciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 76.2 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
76.3 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
76.3.1 Convenciones de código en castellano . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 76.3.2 Convenciones de código en inglés
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
76.3.3 Convenciones de código de proyectos 77 Eventos del ratón 77.1 Véase también
144 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
78 Exclusión mutua (informática) 78.1 Véase también 79 Expresión regular
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
145
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 146
79.1 Construcción de expresiones regulares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 79.2 Aplicaciones
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
79.3 Las expresiones regulares en programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 79.4 Descripción de las expresiones regulares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
xiv
ÍNDICE GENERAL 79.4.1 El punto ".” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 79.4.2 La admiración "!"
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
79.4.3 La barra inversa o antibarra "\" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 79.4.4 Los corchetes "[ ]" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 79.4.5 La barra "|" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 79.4.6 El signo de dólar "$" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 79.4.7 El acento circunflejo "^" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 79.4.8 Los paréntesis "()" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 79.4.9 El signo de interrogación "?" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 79.4.10 Las llaves "{}" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 79.4.11 El asterisco "*" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 79.4.12 El signo de suma "+" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 79.4.13 Grupos anónimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 79.5 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
80 Flag
153
80.1 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
81 Front-end y back-end
154
81.1 Informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 81.2 Tecnología
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
81.3 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 81.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 82 Fuga de memoria 82.1 RAII
156
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
82.2 Fugas de memoria en lenguajes con recolector de basura . . . . . . . . . . . . . . . . . . . . . . . 156 82.3 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 83 Generación de código
158
83.1 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
84 Generador de números aleatorios 84.1 Algoritmos
159
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
84.2 Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 84.3 Enlaces externos 85 Gledplay
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 161
85.1 Dispositivos Soportados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 85.2 GledDraw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 85.3 GledVideo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
85.4 GledSave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 85.5 GledApplication
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
85.6 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
ÍNDICE GENERAL
xv
86 GPGPU
163
86.1 Modelo de programación GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 86.2 Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 86.3 Críticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 86.4 Otros
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
86.5 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
86.6 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
87 Hackathon
165
87.1 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 87.2 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
88 Hacker
166
88.1 Otros significados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 88.2 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 88.2.1 ARPANET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 88.2.2 UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 88.2.3 GNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 88.2.4 LINUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 88.3 Ética hacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 88.4 Controversia
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
88.4.1 Ambigüedad y debate
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
88.5 Activismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 88.6 Terminología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 88.6.1 OverHat
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
88.6.2 White hat y black hat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 88.6.3 Samurái
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
88.6.4 Phreaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 88.6.5 Lamer o script-kiddie
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
88.6.6 Newbie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 88.7 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
88.8 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 88.9 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 88.10Enlaces externos 89 Heisenbug
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 172
89.1 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 89.2 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 90 Hoja de estilo 90.1 Véase también 90.2 Enlaces externos
173 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
90.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
xvi
ÍNDICE GENERAL
91 Hola mundo 91.1 Véase también
174 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
91.2 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
91.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 92 Homebrew
175
92.1 Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 92.2 Homebrew en diferentes consolas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 92.2.1 Sega Dreamcast
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
92.2.2 Nintendo Entertainment System (NES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 92.2.3 Super Nintendo Entertainment System (SNES) . . . . . . . . . . . . . . . . . . . . . . . . 176 92.2.4 Nintendo DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 92.2.5 Sony PSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 92.2.6 Microsoft Xbox
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
92.2.7 Microsoft Xbox 360 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 92.2.8 Nintendo Wii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 92.2.9 PlayStation 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 92.3 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
92.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 93 ICONIX 93.1 Ventajas de Iconix
179 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
93.2 Tareas de la metodología Iconix
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
93.2.1 Fase 1: Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 93.2.2 Fase 2: Análisis y diseño preliminar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 93.2.3 Fase 3: Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 93.2.4 Fase 4: Implementación
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
93.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 93.4 Conceptos Relacionados 93.5 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
93.5.1 Fase 2: Análisis y diseño preliminar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 93.5.2 Fase 3: Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 93.5.3 Fase 4: Implementación
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
93.6 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 93.7 Conceptos Relacionados 93.8 Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
94 Anexo:Implementaciones de Smalltalk
181
95 Anexo:Implementaciones para algoritmo de rut
182
95.1 Objective-C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 95.2 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 95.3 Visual Basic MS Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
ÍNDICE GENERAL
xvii
95.4 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 95.5 Perl 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 95.6 Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 95.7 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 95.8 Transact-SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 95.9 MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 95.10PSeInt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 95.11Python 95.12Ruby
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
95.13Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 95.14Pl/pgsql de PostgreSql
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
96 Inanición (informática)
185
97 Indirección
186
98 Infraestructura de lenguaje común
187
98.1 Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
99 Ingeniería de software
189
99.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 99.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 99.3 Recursos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
99.3.1 Recurso humano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 99.3.2 Recursos de software reutilizables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 99.3.3 Recursos de entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 99.4 Implicaciones socioeconómicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 99.4.1 Económicamente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 99.4.2 Socialmente 99.5 Notaciones
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
99.5.1 LUM (lenguaje unificado de modelado) o UML . . . . . . . . . . . . . . . . . . . . . . . 191 99.5.2 BPMN (notación para el modelado de procesos de negocios)
. . . . . . . . . . . . . . . . 191
99.5.3 Diagrama de flujo de datos (DFD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 99.6 Herramienta CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 99.7 Metodología
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
99.7.1 Etapas del proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 99.7.2 Ventajas* [22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 99.8 Modelos y Ciclos de Vida del Desarrollo de Software
. . . . . . . . . . . . . . . . . . . . . . . . 195
99.8.1 Modelo en cascada o clásico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 99.8.2 Modelo de prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 99.8.3 Modelo en espiral
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
99.8.4 Modelo de desarrollo por etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 99.8.5 Modelo Incremental o Iterativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
xviii
ÍNDICE GENERAL 99.8.6 Modelo RAD (rapid application development) . . . . . . . . . . . . . . . . . . . . . . . . 197 99.8.7 Modelo de desarrollo concurrente
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
99.8.8 Proceso unificado del desarrollo de software . . . . . . . . . . . . . . . . . . . . . . . . . 197 99.9 Producto
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
99.10Naturaleza de la Ingeniería de Software
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
99.11Participantes y papeles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 99.11.1 Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 99.11.2 Desarrolladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 99.11.3 Gestores
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
99.11.4 Usuarios finales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 99.11.5 Código ético de un ingeniero de software
. . . . . . . . . . . . . . . . . . . . . . . . . . 199
99.12Educación ética . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 99.12.1 Organizaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 99.13Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
99.14Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 99.15Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 99.16Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
100Instancia (informática) 100.1Etimología
202
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
100.2Programación basada en clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 100.2.1 Clases como objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 100.3Programación basada en prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 100.4Notas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 100.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 101Instrucción (informática)
204
101.1Campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 101.2Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 101.3Repertorio
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
101.4Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
102Interfaz binaria de aplicaciones
206
102.1Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 102.2EABI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 102.3Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
102.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 102.5Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 103Interfaz fluida
208
103.1Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 103.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
ÍNDICE GENERAL
xix
104Invariante (informática)
210
104.1Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
105Jframe 105.1Herencia
211 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
105.2Constructores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 105.3Métodos propios de la clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 105.4Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
106Usuario discusión:Juliasocorro
213
107Kanban (desarrollo)
215
107.1El método Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 107.2Los principios del método Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 107.3Cinco prácticas centrales del método Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 107.4Comportamiento emergente con Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 107.5La implementación del método Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 107.6Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 107.7Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
108Kit de desarrollo de software
218
108.1Incompatibilidad de licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 108.2SDK para añadidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 108.3Términos más específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 108.4Ejemplos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
108.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 108.6Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
108.7Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
109Kommander
220
109.1El editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 109.2El ejecutor
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
109.3Direcciones de Kommander 110Last Error (informática) 110.1Errores personalizados
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 221
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
110.2En DELPHI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 110.3Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
111Línea de código fuente 111.1El uso de medidas de LCF
222 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
111.2Programas para contar líneas de código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 111.2.1 Software Libre/Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 111.2.2 Freeware (software no libre) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
xx
ÍNDICE GENERAL 111.2.3 Comerciales
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
111.2.4 Basados en web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 111.3Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
111.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 111.5Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
112Macintosh Toolbox
225
113Macro
226
113.1Macros de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 113.2Macros en programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 113.3Macros ocultas
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
113.4Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
114Malla de triángulos 3D
227
114.1Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 114.2Obtención de las mallas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 114.3Compresión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 115Mapeo objeto-relacional
229
115.1El problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 115.2Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 115.3Bases de datos distintas a SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 115.4Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
115.5Enlaces relacionados
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
116Máquina de estados
231
117Máquina desnuda
232
118MCML
233
118.1Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
119Metaprogramación
234
119.1Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 120Microformatos Dublin Core
235
121Modelo de prototipos
236
121.1Etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 121.2Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 121.3Inconvenientes 121.4Conclusiones 121.5Véase también 122Modificador
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 238
ÍNDICE GENERAL
xxi
122.1Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
123Modularidad
239
123.1Modularidad en Ciencias de la Computación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 123.2Modularidad en Biología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 123.3Modularidad en Economía y en la Empresa
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
123.4Modularidad en el diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 123.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 123.6Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
124Módulo (informática)
241
124.1Características de un módulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 124.2Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
125Monitor (concurrencia)
242
125.1Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 125.2Exclusión mutua en un monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 125.3Tipos de monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 125.3.1 Tipo Hoare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 125.3.2 Tipo Mesa
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
125.4Verificación de monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 125.4.1 Inicialización de las variables del monitor
. . . . . . . . . . . . . . . . . . . . . . . . . . 244
125.4.2 Monitores tipo Hoare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 125.4.3 Monitores tipo Mesa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 125.5Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
125.6Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 126Anexo:Motores de persistencia
245
126.0.1 ColdFusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 126.0.2 Common Lisp
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
126.0.3 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 126.0.4 JavaScript
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
126.0.5 .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 126.0.6 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 126.0.7 PHP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
126.0.8 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 126.0.9 Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 126.0.10Smalltalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 126.0.11C++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
127Método de depuración del patito de goma 127.1Véase también
248
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
127.2Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
xxii
ÍNDICE GENERAL
127.3Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
128Net Yaroze
249
128.1Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
128.2Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
128.3Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 129Nodo (informática)
251
129.1Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 129.2Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
130Notación Reddick
252
130.1Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 130.2Notación para objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 130.3Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
131Notación húngara 131.1Ejemplos
253
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
131.2Situación actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 131.2.1 Ejemplo notaciones de 1 carácter 131.3Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
132Null
254
133NWNScript
255
133.1Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
134Objeto todopoderoso
256
134.1Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 134.2Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 134.3Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
135Oday
257
136Offset (informática)
258
136.1Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
136.2Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 137OGNL
259
137.1Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 137.2Cadenas (chains) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 137.3Proyectos que usan OGNL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 137.4Enlaces externos 138OpenACS 138.1Arquitectura
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 260
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
ÍNDICE GENERAL
xxiii
138.2Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 138.3Véase también 138.4Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
139Operaciones con archivos (informática) 139.1Véase también
261
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
140Operador
262
140.1Operadores en un espacio vectorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 140.2Operadores bilineales o bivariantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 140.3Tipos generales de operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 140.3.1 Operadores de condición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 140.3.2 Operadores de orden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 140.3.3 Operadores lógicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 140.3.4 Operaciones aritméticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 140.4Otros operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 140.5Temas relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 140.6Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 141Operando
265
141.1En informática
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
141.2Conexiones externas
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
141.2.1 Matemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 141.2.2 Informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 142Paquetes en PL/SQL
266
142.1Especificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 142.2Cuerpo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
143Pascal Casing
268
143.1Enlaces externos 144Patch (Unix)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 269
144.1Contexto de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 144.2Enlaces externos 145Phrogram
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 270
145.1Detalles técnicos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
145.2¡Hola, Mundo! en KPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 145.3Filosofía
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
145.4Otra información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 145.5The Phrogram Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 145.6Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
xxiv
ÍNDICE GENERAL
146Plataforma de desarrollo 146.1Véase también
272
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
147Plataforma virtual didáctica
273
147.1Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 147.2Herramientas que las componen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
147.3Para que sirven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 147.4Autores y contribuyentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 147.5Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 147.6Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 147.7Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 147.8Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
148Polling
275
148.1Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 148.2Polling del registro de Windows
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
148.3Soluciones para el polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 148.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 148.5Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
149Poltergeist (informática) 149.1Consecuencias
277
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
149.2Solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 149.3Véase también 149.4Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
150Portabilidad 150.1Véase también
278 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
150.2Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 151Postcondición
279
151.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 152Pragma
280
152.1Programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 152.2Véase también 152.3Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
153Precondición
281
153.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 154Primitiva de sincronización rendezvous
282
154.1Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 154.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
ÍNDICE GENERAL
xxv
155Proceso (informática)
283
155.1Creación de un proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 155.2Terminación de un proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 155.3Estados de un proceso
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
155.4Tipos de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 155.5Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
155.6Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 155.7Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 156Proceso para el desarrollo de software
286
156.1Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 156.2Actividades del desarrollo de software
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
156.2.1 Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 156.2.2 Implementación, pruebas y documentación
. . . . . . . . . . . . . . . . . . . . . . . . . 286
156.2.3 Despliegue y mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 156.3Modelos de Desarrollo de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 156.3.1 Modelo de cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 156.3.2 Modelo de espiral
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
156.3.3 Desarrollo iterativo e incremental
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
156.3.4 Desarrollo ágil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 156.3.5 Codificación y corrección 156.3.6 Orientado a la Reutilización
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
156.4Modelos de mejora de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 156.5Métodos formales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 156.6Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
156.7Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 156.8Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
157Programa informático
291
157.1Programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 157.1.1 Paradigmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 157.1.2 Compilado o interpretando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 157.1.3 Programas que se auto-modifican
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
157.2Ejecución y almacenamiento de los programas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 157.2.1 Programas empotrados en hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 157.2.2 Programas cargados manualmente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 157.2.3 Programas generados automáticamente
. . . . . . . . . . . . . . . . . . . . . . . . . . . 293
157.2.4 Ejecución simultánea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 157.3Categorías funcionales 157.4Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
157.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 157.6Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
xxvi
ÍNDICE GENERAL
157.7Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
158Programa interactivo
296
158.1Frente a Procesamiento por lotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 158.1.1 Ventajas
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
158.1.2 Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 158.2Ejemplos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
158.2.1 Cajero automático
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
158.2.2 Compresor de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 159Programación lineal paramétrica
297
159.1Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 160Programación visual
298
160.1Programación orientada a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 160.2Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
161Programador
299
161.1Reseña histórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 161.2Funciones del programador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 161.3Especialidades
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
161.4Notas y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 161.5Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
162Pseudocódigo 162.1Aplicaciones
301 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
162.2Sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 162.3Definición de datos del pseudocódigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 162.4Funciones y operaciones
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
162.5Estructuras de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 162.5.1 Estructuras secuenciales
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
162.5.2 Estructuras selectivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 162.5.3 Estructuras iterativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 162.5.4 El anidamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 162.6Desarrollo de algoritmos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
162.7Funciones y procedimientos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
162.8Ventajas del pseudocódigo sobre los diagramas de flujo 162.9Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . 304
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
162.10Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 162.11Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 162.12Véase también 163Puente de aplicación
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 305
ÍNDICE GENERAL
xxvii
164Puntero inteligente
306
164.1Punteros inteligentes en Boost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 164.1.1 Scoped pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 164.1.2 Shared pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 164.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 165Pure data
308
165.1Tipos de objetos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
165.2Objetos más importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 165.3Instalación en GNU posibles problemas y soluciones . . . . . . . . . . . . . . . . . . . . . . . . . 310 165.4Introducción rápida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 165.5Bibliotecas pdp, pidip y opencv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 165.6Patch patrones
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
165.7Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
165.8Material en español . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 165.9Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
166QuadTIN
313
167Query string
314
167.1Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
168Quest3D
315
168.1Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 168.1.1 Lógica de las aplicaciones
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
168.1.2 Orientación a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 168.1.3 Editores
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
168.1.4 Publicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 168.2Requerimientos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 168.3Licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 168.4Aplicaciones
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
168.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 168.6Enlaces externos 169Quine (programa)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 317
169.1Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 169.1.1 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 169.1.2 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 169.1.3 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 169.1.4 Common Lisp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 169.1.5 Ocaml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 169.1.6 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 169.1.7 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
xxviii
ÍNDICE GENERAL 169.1.8 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 169.1.9 BASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 169.1.10Pascal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 169.1.11Brainfuck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 169.1.12HQ9+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 169.1.13DOS Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 169.1.14PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 169.1.15PL/I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 169.1.16PostScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 169.1.17Visual FoxPro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
169.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 170Rebanamiento estático
320
170.1Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 170.2Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
170.3Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 170.4Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 171Recolector de basura
321
171.1Breve reseña histórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 171.2Contexto
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
171.3Cómo funciona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 171.4Ventajas y desventajas
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
171.5Cómo se implementa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 171.6Ejemplos de lenguajes con recolector de basura 171.7Véase también 171.8Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . 322
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
172Recursión
323
172.1Recursión en matemáticas
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
172.1.1 Conjuntos definidos de forma recurrente . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 172.1.2 Funciones definidas de forma recurrente . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 172.1.3 Constantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 172.1.4 Resolución de problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 172.2Recursión en informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 172.3Humor recursivo 172.4Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
172.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 172.6Enlaces externos 173Refactorización
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 326
173.1Refactorización de código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 173.2Refactorización de otros textos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
ÍNDICE GENERAL 173.3Etimología
xxix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
173.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 173.5Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
174Reflexión (informática)
328
174.1Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 174.2Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 174.2.1 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 174.2.2 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 174.3Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
175Relación de compresión (informática)
329
175.0.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 176Resolución de problemas de programación
330
176.1Análisis del problema informático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 176.2Diseño del algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 176.2.1 Acciones elementales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 176.2.2 Secuencia de acciones elementales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 176.2.3 Composición condicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 176.2.4 Composición condicional doble (alternativa) . . . . . . . . . . . . . . . . . . . . . . . . . 331 176.2.5 Composición condicional múltiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 176.2.6 Composición iterativa o bucle 176.3Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
177Instancia (programación)
333
177.1Programación basada en clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 177.1.1 Clases como objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 177.2Programación basada en prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 177.3Notas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 177.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 178Anexo:Scan code
335
179scanf
336 179.0.1 Modificantes de longitud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
179.1Sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 179.2Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 179.3Funciones derivadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 179.3.1 fscanf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 179.3.2 sscanf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 179.4Véase también 179.5Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
xxx
ÍNDICE GENERAL
180SCons 180.1Véase también
340 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
180.2Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
181Screen scraping 181.1Véase también
341 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
182Sección crítica 182.1Véase también
342 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
183Serialización
343
183.1Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 183.2Soporte en los lenguajes de programación 183.3Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
184Sigil
344
185Signatura (informática)
345
186Signum Framework
346
186.1Características
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
186.1.1 Elementos de Signum Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 186.1.2 Entidades primero
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
186.1.3 Generación del esquema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 186.1.4 Herencia de entidades
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
186.1.5 Interfaz de usuario y WCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 186.1.6 LINQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 186.2Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 186.3Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
187Simple Network Library 187.1Origen del nombre
348 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
187.2Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 187.3Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
187.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 187.5Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 187.5.1 Documentación de SNL 187.6Enlaces externos 188Smarty 188.1Características
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 349 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
188.2Críticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 188.3Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 188.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
ÍNDICE GENERAL
xxxi
188.5Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
189Snippet
351
189.1Rich snippets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 189.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 190Stack Overflow
352
190.1Funcionamiento de Stack Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 190.2Reputación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 190.3Moderación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 190.4Estadísticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 191StarBasic
354
191.1Primer virus para OpenOffice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 191.2Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
192Stub
355
192.1Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 192.2Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
193Subalgoritmo
356
193.1Tipos de subalgoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 193.2Ámbito de las variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 193.3Paso de argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 193.4Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
194Tabla de saltos
357
194.1Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 194.2Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 194.3Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
195Tabla de verdad
359
195.1Definiciones en el cálculo lógico
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
195.2Número de combinaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 195.2.1 Para cero variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 195.2.2 Para una variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 195.2.3 Para dos variables 195.3Tablas de verdad
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
195.3.1 Verdad Indeterminada o Contingencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 195.3.2 Contradicción
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
195.3.3 Tautologías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 195.4Tablas de verdad, proposiciones lógicas y argumentos deductivos 195.5Aplicaciones
. . . . . . . . . . . . . . . . . . 362
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
195.5.1 Cálculo lógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
xxxii
ÍNDICE GENERAL 195.5.2 Lógica de circuitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 195.5.3 Desarrollo del algoritmo fundamental en lógica de circuitos . . . . . . . . . . . . . . . . . 363
195.6Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
195.7Notas y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 195.8Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
196Thunk
366
196.1Invocación por «gestionada» a «no gestionada»
. . . . . . . . . . . . . . . . . . . . . . . . . . . 366
196.2Invocación por «no gestionada» a «gestionada»
. . . . . . . . . . . . . . . . . . . . . . . . . . . 366
196.3Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 197Tipo de dato elemental
367
198Triángulo de Floyd
368
198.1Algoritmo computacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 198.2Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
198.3Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 199Tubería (informática)
369
199.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 200Violación de acceso
371
200.1Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
201Waf
372
201.1Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 201.2Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 201.3Ejemplo Waf archivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 201.4Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
201.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 201.6Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
202Win32 Thread Information Block 202.1Contenido del TIB
374
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
202.2Acceso al TIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 202.3Enlaces externos 203Wrapper
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 375
203.1Computación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 203.2Véase también
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
203.3Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 204XAML 204.1Tecnología 204.2Ejemplos
376 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
ÍNDICE GENERAL 204.3Véase también
xxxiii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
204.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 204.5Enlaces externos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
205Zenphp 205.1¿Qué es zenphp?
378 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
205.2¿Qué ventajas ofrece zenphp?
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
205.3Origen del texto y las imágenes, colaboradores y licencias . . . . . . . . . . . . . . . . . . . . . . 379 205.3.1 Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 205.3.2 Imágenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 205.3.3 Licencia del contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Capítulo 1
Programación La programación informática, acortada como programación, es el proceso de diseñar, codificar, depurar y mantener el código fuente de programas computacionales. El código fuente es escrito en un lenguaje de programación. El propósito de la programación es crear programas que exhiban un comportamiento deseado. El proceso de escribir código requiere frecuentemente conocimientos en varias áreas distintas, además del dominio del lenguaje a utilizar, algoritmos especializados y lógica formal. Programar no involucra necesariamente otras tareas tales como el análisis y diseño de la aplicación (pero sí el diseño del código), aunque sí suelen estar fusionadas en el desarrollo de pequeñas aplicaciones.
trivial como multiplicar dos números puede necesitar un conjunto de instrucciones en lenguaje ensamblador, en un lenguaje de alto nivel bastará con solo una. Una vez que se termina de escribir un programa, sea en ensamblador o en algunos lenguajes de alto nivel, es necesario compilarlo, es decir, traducirlo completo a lenguaje máquina.* [1] Eventualmente será necesaria otra fase denominada comúnmente link o enlace, durante la cual se anexan al código, generado durante la compilación, los recursos necesarios de alguna biblioteca. En algunos lenguajes de programación, puede no ser requerido el proceso de compilación y enlace, ya que pueden trabajar en modo intérprete. Esta modalidad de trabajo es equivalente pero se realiza instrucción por instrucción, a medida Del proceso de programación surge lo que comúnmente que es ejecutado el programa. se conoce como software (conjunto de programas), aunque estrictamente este último abarca mucho más que solo la programación.
1.2 Léxico y programación 1.1 Historia
La programación se rige por reglas y un conjunto más o menos reducido de órdenes, expresiones, instrucciones y comandos que tienden a asemejarse a una lengua natural acotada (en inglés); y que además tienen la particularidad de una reducida ambigüedad. Cuanto menos ambiguo es un lenguaje de programación, se dice, es más potente. Bajo esta premisa, y en el extremo, el lenguaje más potente existente es el binario, con ambigüedad nula (lo cual lleva a pensar así del lenguaje ensamblador).
Para crear un programa, y que la computadora lo interprete y ejecute las instrucciones escritas en él, debe escribirse en un lenguaje de programación. En sus inicios las computadoras interpretaban solo instrucciones en un lenguaje específico, del más bajo nivel, conocido como código máquina, siendo éste excesivamente complicado para programar. De hecho solo consiste en cadenas de números 1 y 0 (sistema binario). Para facilitar el trabajo de programación, los primeros científicos, que trabajaban en el área, decidieron reemplazar las instrucciones, secuencias de unos y ceros, por palabras o abreviaturas provenientes del inglés; las codificaron y crearon así un lenguaje de mayor nivel, que se conoce como Asembly o lenguaje ensamblador. Por ejemplo, para sumar se podría usar la letra A de la palabra inglesa add (sumar). En realidad escribir en lenguaje ensamblador es básicamente lo mismo que hacerlo en lenguaje máquina, pero las letras y palabras son bastante más fáciles de recordar y entender que secuencias de números binarios. A medida que la complejidad de las tareas que realizaban las computadoras aumentaba, se hizo necesario disponer de un método sencillo para programar. Entonces, se crearon los lenguajes de alto nivel. Mientras que una tarea tan
En los lenguajes de programación de alto nivel se distinguen diversos elementos entre los que se incluyen el léxico propio del lenguaje y las reglas semánticas y sintácticas.
1.3 Programas y algoritmos Un algoritmo es una secuencia no ambigua, finita y ordenada de instrucciones que han de seguirse para resolver un problema. Un programa normalmente implementa (traduce a un lenguaje de programación concreto) uno o más algoritmos. Un algoritmo puede expresarse de distintas maneras: en forma gráfica, como un diagrama de flujo, en forma de código como en pseudocódigo o un 1
2
CAPÍTULO 1. PROGRAMACIÓN
lenguaje de programación, en forma explicativa, etc. Los programas suelen subdividirse en partes menores, llamadas módulos, de modo que la complejidad algorítmica de cada una de las partes sea menor que la del programa completo, lo cual ayuda al desarrollo del programa. Esta es una práctica muy utilizada y se conoce como “refino progresivo”. Según Niklaus Wirth, un programa está formado por los algoritmos y la estructura de datos.
puede almacenarse solo de forma temporal. Un programa podría tener partes escritas en varios lenguajes, por ejemplo, Java, C, C++ y ensamblador, que se podrían compilar de forma independiente y luego enlazar juntas para formar un único módulo ejecutable.
1.5 Programación e ingeniería del software
Se han propuesto diversas técnicas de programación cuyo objetivo es mejorar tanto el proceso de creación de Existe una tendencia a identificar el proceso de creación software como su mantenimiento. Entre ellas, se pueden de un programa informático con la programación, que es mencionar las siguientes: cierta cuando se trata de programas pequeños para uso personal, y que dista de la realidad cuando se trata de grandes proyectos. • Programación declarativa • Programación estructurada • Programación modular • Programación orientada a objetos
1.4 Compilación El programa escrito en un lenguaje de programación de alto nivel (fácilmente comprensible por el programador) es llamado programa fuente y no se puede ejecutar directamente en una computadora. La opción más común es compilar el programa obteniendo un módulo objeto, aunque también puede ejecutarse en forma más directa a través de un intérprete informático. El código fuente del programa se debe someter a un proceso de traducción para convertirlo a lenguaje máquina o bien a un código intermedio, generando así un módulo denominado “objeto”. A este proceso se le llama compilación.
El proceso de creación de software, desde el punto de vista de la ingeniería, incluye mínimamente los siguientes pasos: 1. Reconocer la necesidad de un programa para solucionar un problema o identificar la posibilidad de automatización de una tarea. 2. Recoger los requisitos del programa. Debe quedar claro qué es lo que debe hacer el programa y para qué se necesita. 3. Realizar el análisis de los requisitos del programa. Debe quedar claro qué tareas debe realizar el programa. Las pruebas que comprueben la validez del programa se pueden especificar en esta fase. 4. Diseñar la arquitectura del programa. Se debe descomponer el programa en partes de complejidad abordable.
5. Implementar el programa. Consiste en realizar un Habitualmente la creación de un programa ejecutable (un diseño detallado, especificando completamente totípico.exe para Microsoft Windows o DOS) conlleva dos do el funcionamiento del programa, tras lo cual la pasos. El primer paso se llama compilación (propiamente codificación (programación propiamente dicha) dedicho) y traduce el código fuente escrito en un lenguaje bería resultar inmediata. de programación almacenado en un archivo de texto a 6. Probar el programa. Comprobar que pasan pruebas código en bajo nivel (normalmente en código objeto, no que se han definido en el análisis de requisitos directamente a lenguaje máquina). El segundo paso se llama enlazado en el cual se enlaza el código de bajo ni7. Implantar (instalar) el programa. Consiste en poner vel generado de todos los ficheros y subprogramas que se el programa en funcionamiento junto con los comhan mandado compilar y se añade el código de las funcioponentes que pueda necesitar (bases de datos, redes nes que hay en las bibliotecas del compilador para que el de comunicaciones, etc.). ejecutable pueda comunicarse directamente con el sistema operativo, traduciendo así finalmente el código objeto a código máquina, y generando un módulo ejecutable. La ingeniería del software se centra en los pasos de plaEstos dos pasos se pueden hacer por separado, almace- nificación y diseño del programa, mientras que antiguanando el resultado de la fase de compilación en archivos mente (programación artesanal) la realización de un proobjetos (un típico .o para Unix, .obj para MS-Windows, grama consistía casi únicamente en escribir el código, baDOS); para enlazarlos en fases posteriores, o crear direc- jo solo el conocimiento de los requisitos y con una motamente el ejecutable; con lo que la fase de compilación desta fase de análisis y diseño.
1.8. CICLO DE VIDA DEL SOFTWARE
1.6 Referencias históricas El trabajo de Ada Lovelace, hija de Anabella Milbanke Byron y Lord Byron, realizó para la máquina de Babbage le hizo ganarse el título de primera programadora de computadoras del mundo, aunque Babbage nunca completó la construcción de la máquina. El nombre del lenguaje de programación Ada fue escogido como homenaje a esta programadora.
1.7 Objetivos de la programación
3 • Portabilidad. Un programa es portable cuando tiene la capacidad de poder ejecutarse en una plataforma, ya sea hardware o software, diferente a aquélla en la que se desarrolló. La portabilidad es una característica muy deseable para un programa, ya que permite, por ejemplo, a un programa que se ha elaborado para el sistema GNU/Linux ejecutarse también en la familia de sistemas operativos Windows. Esto permite que el programa pueda llegar a más usuarios más fácilmente.
1.8 Ciclo de vida del software
La programación debe perseguir la obtención de programas de calidad. Para ello se establece una serie de factores El término ciclo de vida del software describe el desaque determinan la calidad de un programa. Algunos de los rrollo de software, desde la fase inicial hasta la fase final, incluyendo su estado funcional. El propósito es definir las factores de calidad más importantes son los siguientes: distintas fases intermedias que se requieren para validar • Correctitud. Un programa es correcto si hace lo que el desarrollo de la aplicación, es decir, para garantizar que debe hacer tal y como se estableció en las fases pre- el software cumpla los requisitos para la aplicación y vevias a su desarrollo. Para determinar si un progra- rificación de los procedimientos de desarrollo: se asegura ma hace lo que debe, es muy importante especifi- que los métodos utilizados son apropiados. Estos métodos car claramente qué debe hacer el programa antes de se originan en el hecho de que es muy costoso rectificar su desarrollo y, una vez acabado, compararlo con lo los errores que se detectan tarde dentro de la fase de implementación (programación propiamente dicha), o peor que realmente hace. aun, durante la fase funcional. El modelo de ciclo de vida • Claridad. Es muy importante que el programa sea permite que los errores se detecten lo antes posible y por lo más claro y legible posible, para facilitar tanto su lo tanto, permite a los desarrolladores concentrarse en la desarrollo como su posterior mantenimiento. Al ela- calidad del software, en los plazos de implementación y borar un programa se debe intentar que su estructu- en los costos asociados. El ciclo de vida básico de un softra sea sencilla y coherente, así como cuidar el es- ware consta de, al menos, los siguientes procedimientos: tilo de programación. De esta forma se ve facilita• Definición de objetivos: definir el resultado del prodo el trabajo del programador, tanto en la fase de yecto y su papel en la estrategia global. creación como en las fases posteriores de corrección de errores, ampliaciones, modificaciones, etc. Fases • Análisis de los requisitos y su viabilidad: recopilar, que pueden ser realizadas incluso por otro prograexaminar y formular los requisitos del cliente y examador, con lo cual la claridad es aún más necesaria minar cualquier restricción que se pueda aplicar. para que otros puedan continuar el trabajo fácilmente. Algunos programadores llegan incluso a utilizar • Diseño general: requisitos generales de la arquitecArte ASCII para delimitar secciones de código; una tura de la aplicación. práctica común es realizar aclaraciones en el código • Diseño en detalle: definición precisa de cada subfuente utilizando líneas de comentarios. Contrariaconjunto de la aplicación. mente, algunos por diversión o para impedirle un análisis cómodo a otros programadores, recurren al • Programación (programación e implementación): es uso de código ofuscado. la implementación en un lenguaje de programación para crear las funciones definidas durante la etapa de • Eficiencia. Se trata de que el programa, además de diseño. realizar aquello para lo que fue creado (es decir, que • Prueba de unidad: prueba individual de cada subsea correcto), lo haga gestionando de la mejor forconjunto de la aplicación para garantizar que se imma posible los recursos que utiliza. Normalmente, plementaron de acuerdo con las especificaciones. al hablar de eficiencia de un programa, se suele hacer referencia al tiempo que tarda en realizar la ta• Integración: para garantizar que los diferentes rea para la que ha sido creado y a la cantidad de módulos y subprogramas se integren con la aplicamemoria que necesita, pero hay otros recursos que ción. Éste es el propósito de la prueba de integración también pueden ser de consideración para mejorar que debe estar cuidadosamente documentada. la eficiencia de un programa, dependiendo de su na• Prueba beta (o validación), para garantizar que el turaleza (espacio en disco que utiliza, tráfico en la software cumple con las especificaciones originales. red que genera, etc.).
4
CAPÍTULO 1. PROGRAMACIÓN • Documentación: se documenta con toda la información necesaria, sea funcional final para los usuarios del software (manual del usuario), y de desarrollo para futuras adaptaciones, ampliaciones y correcciones. • Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).
1.11 Enlaces externos •
Wikimedia Commons alberga contenido multimedia sobre Programación. Commons
•
Wikcionario tiene definiciones y otra información sobre programación.Wikcionario
• Wikiquote alberga frases célebres de o sobre El orden y la presencia de cada uno de estos procedimienProgramación. Wikiquote tos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el Wikilibros equipo de desarrolladores. •
1.9 Véase también • •
Portal:Programación. Contenido relacionado con Programación.
• Wikiproyecto:Informática/Programación • error de software • filosofías del desarrollo de software • historia de la ingeniería del software • ingeniería en computación • Desarrollo De Software • ingeniería en informática • línea de código fuente • lenguaje de programación • programación automática • programación dirigida por eventos • programación estructurada • programación extrema • programación en pareja • programación dinámica • programación orientada a objetos • pruebas de software • software
1.10 Referencias [1] Laboda, Xavier; Josep Galimany, Rosa María Pena, Antoni Gual (1985). «Software». Biblioteca práctica de la computación. Barcelona: Ediciones Océano-Éxito, S.A.
Wikilibros alberga un libro o manual sobre Fundamentos de programación.
Capítulo 2
Portal:Programación
5
Capítulo 3
& El signo en sí es una ligadura ̶combinación de diseño de dos letras en un único grafema, usado primero para aumentar la velocidad de la escritura manual̶desarrollada por Marco Tulio Tirón, secretario del gran orador romano Cicerón. Para poder registrar los discursos y la correspondencia dictada por este último, Tiro, que era un esclavo liberto, inventó varias formas de acelerar la escritura, siendo por ello considerado el padre de la taquigrafía. En la Edad Media o en los primeros tiempos de la imprenta el uso de ligaduras era muy común, en este caso por la economía de espacio, cuando la materia prima ̶pergamino o papel̶añadía mucho al precio de los libros.
«Et» redirige aquí. Para otras acepciones, véase E. T.
Evolución de la ligadura &: 1-3, cursivas romanas de los siglos ii-iv 4-5, minúsculas medievales de los siglos vi-vii 6, minúscula carolingia, s. ix.
También se le conoce como signo tironiano.
El signo &, cuyo nombre en español es et,* [1] es una alternativa gráfica de la conjunción copulativa latina et, que significa y de la que deriva la española «y».
3.1 Historia
Es conocido también por su nombre en inglés ampersand, proveniente a su vez de la expresión and per se and, es decir, «y por sí mismo, y», antiguamente usada como parte de la retahíla para la memorización del alfabeto. Deriva del latín de donde el signo pasó a diversos idiomas, incluido el español. Su uso en nuestra lengua es superfluo, pues no resulta económico (a diferencia de otros idiomas) ya que la conjunción copulativa y tiene una grafía más breve y sencilla. En textos españoles antiguos es frecuente encontrarlo empleado en la expresión latina adoptada et El et latino a la izquierda se encuentra estilizado, pero la forma cetera, en las formas &c. o &cetera. itálica a la derecha revela sus orígenes de la palabra del latín et.
Un uso extendido es el que persiste en la bibliografía académica en inglés, en la enumeración de los autores, in- El símbolo fue usado en el antiguo Imperio romano, y su cluidas la expresión como & al. (del latín et alii, plural uso data del primer siglo d.C. Se adjudica su invención a masculino, o et alia, plural neutro) que se traduce como Marco Tulio Tirón.* [2] «y otros». Para el siglo viii, la caligrafía occidental estaba bien desarrollada, particularmente en la forma uncial, escritura insular y minúscula carolingia. Los calígrafos hicieron un extensivo uso del et, ya que la condensación de una palabra en una sola letra hacía su trabajo más fácil. Durante aquel tiempo, se desarrolló una versión mucho más comprimida del et. Normalmente se le llama ampersand“RoEn la tipografía de la derecha es evidente el origen de la ligadura mana”. et.
En HTML se usa al comienzo de los códigos de entidad Como se observa en la lista de letras de Byrhtferð (año con que se designan los caracteres especiales: los ejem1011), este signo «&» fue considerado a menudo como plos más típicos son > <, y & (>, < y &, una letra más al final del alfabeto latino. respectivamente). 6
3.3. ENLACES EXTERNOS En Internet y direcciones web, & simboliza la separación de variables pasadas mediante GET. En Excel, se usa para concatenar celdas. En la línea de comando (CLI) de Bash (Bourne Again Shell) Zbash, etc. usadas en Unix, GNU/Linux y *BSD se usa & al final de una orden para ejecutarla en segundo plano.
3.2 Referencias [1] Real Academia Española (2001). «Apéndice 4: Lista de símbolos o signos no alfabetizables». Diccionario de la lengua española. Consultado el 25 de septiembre de 2012. [2] «The History of Court Reporting». National Court Reporters Association.
3.3 Enlaces externos •
Wikimedia Commons alberga contenido multimedia sobre &Commons.
•
Wikcionario tiene definiciones y otra información sobre &.Wikcionario
•
Wikcionario tiene definiciones y otra información sobre ampersand.Wikcionario
• Apéndice 4: Lista de símbolos o signos no alfabetizables en la página de la Real Academia Española.
7
Capítulo 4
Acoplamiento secuencial En Programación orientada a objetos el antipatrón de diseño acoplamiento secuencial se refiere a una clase que requiere que sus métodos sean llamados en un orden secuencial particular. Los métodos cuyo nombre comienza por Init, Begin, en Inicio, etc puede indicar la existencia de acoplamiento secuencial. Usando el ejemplo de un coche a modo de analogía, si el usuario sigue los pasos de acelerar sin antes arrancar el motor, el coche no se mueve y envía una Excepción. Las excepciones son aceptables en algunas ocasiones porque los programas (en particular los grandes) necesitan la información para determinar por qué en un objeto no se está realizando el comportamiento esperado cuando uno de sus métodos es llamado. La inicialización de objetos no siempre es posible en el constructor y puede ser necesario retrasarla a un momento posterior. El acoplamiento secuencial puede ser reprogramado con el Template Method (patrón de diseño)* [1] para superar los problemas planteados por el uso de este antipatrón.
4.1 Véase también • Antipatrón de diseño • Patrón de diseño
4.2 Referencias [1] Andriy, Buday. «Refactor: Acoplamiento secuencial => Template Method». The Code Project. Consultado el 23 de abril de 2011.
8
Capítulo 5
Adobe Director Adobe Director Es una aplicación de Desarrollo de Software (o Autoría de Software) Multimedia (que inspiró a Adobe Flash® ) destinado para la producción de programas ejecutables ricos en contenido multimedia. Es considerada una de las herramientas más poderosas de integración y programación de medios digitales, debido a su versatilidad de poder incorporar imágenes, audio, vídeo digital, películas flash, y un engine 3D, en una sola aplicación, y manipularlas a través de un lenguaje de programación (Lingo; Javascript).
Con el lanzamiento de Director 11 y su evolución a la versión 11.5, de la mano de Adobe, se incorporó soporte para DirectX y se extendieron las capacidades en 3D basadas en el engine PhysX de NVIDIA, importación de 3D desde Google SketchUp, así como también filtros de bitmaps, canales de audio 5.1, vídeo en alta definición, soporte para H.264, e integración de Adobe Flash CS3 y Shockwave Player 11. Director 12, lanzado en febrero de 2013, incorporó la posibilidad de publicación para dispositivos iOS, además de otras utilidades como esteDesarrollado a fines de los años 80 por la empresa reoscopía, nuevos efectos, y nuevas potencialidades del Macromedia, es distribuido desde el año 2008 por Adobe engine 3D. Systems Incorporated. Adobe Director, permite crear y publicar juegos interactivos, prototipos, simulaciones y cursos eLearning para la Web, dispositivos iOS, sistemas de escritorio Windows® y Mac, DVDs y CDs. Con Director también es posible programar una amplia gama de aplicaciones basadas en redes, lo que ha permitido crear innumerables sistemas y juegos multiusuario online.
5.1
Interfaz
A lo largo de todas sus versiones, la interfaz de Director ha sido fiel a su concepción inicial, y a su nombre: entregarle al desarrollador un escenario (Stage), para el armado de su Aplicación. Cada uno de los múltiples medios que pueden ser utilizados en Director son considerados“actores”(casts), cuyas características pueden ser manipuladas a través de guiones (o Scripts) escritos en lenguaje Lingo o Javascript. En síntesis, el desarrollador es el director de su propia película, controlando todos sus aspectos.
Director también permite la manipulación de modelos en 3D, gracias a Shockwave 3D. Es así como diversos programas de modelamiento, como 3D Studio MAX (de la empresa Autodesk), permiten exportar sus modelos (incluyendo las animaciones) en formato Shockwave 3D, el que puede ser importado a Director, y manipulado a través de instrucciones. A través de variados Xtras (como Havok), Director también puede manipular propiedades físicas de modelos 3D (como por ejemplo, gravedad, coeficientes de roce, restitución, etc) que permiten lograr simulaciones más realistas, tanto para software de ingeniería avanzada, como para juegos.
5.2 Timeline • 1985: VideoWorks (Disponible para Apple Macintosh) • 1988: Director 1.0
Además del potente lenguaje incorporado (Lingo), una de sus principales ventajas radica en el uso de los llamados xtras. Se trata de “pequeños programas”(plugins) desarrollados en lenguaje C++ por otros usuarios o terceras empresas, que proporcionan al usuario infinidad de utilidades.
• 1993: Macromind Director se convierte en Macromedia Director (v 3.1.3) • 1994: Macromedia Director 4 (Plataformas Windows y Powermac)
Se pueden generar varios tipos de archivos, sin embargo lo más normal es crear un archivo ejecutable para Windows (.exe) o Macintosh (.app). De esta forma puede verse la presentación en cualquier ordenador, sin tener instalado Adobe Director.
• 1996: Macromedia Director 5 (Aparición de Shockwave) • 1997: Macromedia Director 6 (Implementación de Behaviors & y soporte mp3) 9
10 • 1997: Macromedia Director 6.5 (integración de Xtras)
CAPÍTULO 5. ADOBE DIRECTOR
5.4 Shockwave / Shockwave 3D
Desde la aparición de Director 5, Shockwave es el for• 1998: Macromedia Director 7 (Se re-escribió el en- mato exclusivo de publicación para web de Director. El gine) plugin de shockwave permite ejecutar aplicaciones realizadas en Director (archivos DCR), a través de Internet, • 2000: Macromedia Director 8 sin que estas pierdan su calidad ni características, además de aprovechar al máximo las potencialidades de aquellas • 2001: Macromedia Director 8.5 (Aparición de que poseen engine multiusuario. Con la aparición de Director 8.5, Shockwave tuvo un nuevo impulso, al incorShockwave3D) porar capacidades de manipulación de elementos en 3D • 2002: Macromedia Director MX (También conoci- (Shockwave 3D). Esto abrió las puertas a los desarrolladores de Director a un nuevo mundo, a partir del cual fue do como Director 9) posible crear ambientes modelados en 3D (generados en • 2004: Macromedia Director MX 2004 (También Director, o importados como archivos W3D desde aplicaciones externas) y utilizar toda la riqueza del código linconocido como Director 10) go / javascript, para manipular dichos modelos en tiempo real. • 2008: Adobe Director 11 El motor 3D de Shockwave es todavía el líder indiscutible en su mercado, y hace que este plugin sea muy popular entre un gran número de desarrolladores de juegos en línea y de jugadores. Los archivos Flash (swf) pueden ser • 2010: Adobe Director 11.5.8 incorporados a Director y ser ejecutados en Shockwave, • 2013: Adobe Director 12. (Publicación a dispositi- pero no a la inversa. vos iOS, estereoscopía, mejora de Engine 3D) Otras características no incorporadas por Flash incluyen un motor de render mucho más rápido, junto con aceleración 3D por medio de hardware, acceso directo al píxel en imágenes bitmap, diferentes modos de filtrado 5.3 Director y Flash para composiciones en capas de los gráficos y compatibilidad con diversos protocolos de red, incluido Internet Históricamente, la comunidad más cercana a Flash y Relay Chat. Además, a través de los Xtras, los desarrodesconocedora de Director, tiende a preguntarse sobre lladores pueden ampliar la funcionalidad de Shockwave las comparaciones entre ambos programas. Literalmen- con aplicaciones hechas a medida. te, Director y Flash no son competidores. Flash nació en 1996, orientado al desarrollo de aplicaciones multimedia • Macromedia Shockwave Player, instalado en un en Web, y en poco tiempo evolucionó poderosamente de 50% de los navegadores. Ficheros con extensión la mano del lenguaje ActionScript. Director nació varios ".dcr”desarrollados con Adobe Director años antes (1985), y evolucionó como una poderosa herramienta de integración de medios digitales de alta cali• Macromedia Flash Player, instalado en un 98% dad para plataformas de escritorio, y que también generó de los navegadores. Utiliza ficheros con extensión una arista para su incorporación a Web (Shockwave). ".swf”desarrollados con Macromedia Flash, Macro• 2009: Adobe Director 11.5
La evolución de la popularidad de Flash sobre Shockwave tiene varias explicaciones; no solo el plugin de Shockwave fue históricamente más pesado y menos amigable de instalar que Flash, sino también la autoría de Director siempre ha requerido la mano de un desarrollador de software, con conocimientos en programación; en cambio Flash se posicionó rápidamente en el universo de diseñadores Web (sin necesidad de poseer conocimientos de programación), y de hecho ha incentivado con los años el aprendizaje de programación ActionScript a varios “no programadores”, generando una importante sinergia en el mundo del diseño y la programación -antes estrictamente lejanos-. Por otro lado, Macromedia logró acuerdos con empresas como DELL y Apple, para que Flash sea preinstalado en sus sistemas, evitando que los usuarios deban instalar software adicional.
media FreeHand, Generator y otras aplicaciones.
5.5 Referencias 5.6 Enlaces externos • Sitio oficial de Adobe Director • Adobe Director Forum • Director-Online.com Foro temático sobre el programa (en inglés). • Foro de usuarios de Adobe Director (en inglés).
5.6. ENLACES EXTERNOS • Dean's Director Tutorials, sitio web con tutoriales del programa (en inglés). • IEEE History Center: John Thompson, inventor of Lingo Programming Language Biografía de John Thompson, inventor del lenguaje de programación “Lingo”(en inglés).
11
Capítulo 6
Anidamiento (informática) El anidamiento (llamado nesting en inglés) es la práctica de incorporar llamadas (calls) a funciones o procedimientos (unas) dentro de otras, mediante la inclusión de diversos niveles de paréntesis.
linea, ruta as string dim valor_a_devolver as integer ruta="C:\Probar.csv”if FileExists(ruta) then open “C:\Probar.csv”for input as #1 do while not EOF(1) line input #1, linea if left(linea, 3)=cod then 'Realizar Debido a que la potencial acumulación de éstos últimos una acción o varias acciones End if loop close #1 suele hacer que la edición y la detección de errores se BuscarCodigo=valor_a_devolver end function vuelva un proceso engorroso, los entornos de programación modernos -así como los programas de planilla de En este simple ejemplo, la estructura condicional if... cálculo- resaltan en negrita el par correspondiente a la po- then... end if (“si... entonces... fin si”) está anidada sición que está editando el programador o usuario en cada dentro de otra que la contiene, el ciclo do while... loop momento. El control (automático) del balance o equili- (“repetir... mientras”, literalmente “hacer mientras... brio entre los paréntesis de apertura y de cierre se suele bucle”). conocer como brace match checking en inglés. Naturalmente, para la resolución matemática de estas complejas formulas encadenadas, las expresiones deben ser evaluadas desde adentro hacia afuera, ya que los resultados de las más internas sirven, temporalmente, de datos de entrada de las exteriores.
6.3 Véase también • Bucle (programación) • Estructuras de control • Función (programación)
6.1 En las planillas de cálculo
• Procedimiento (programación)
En las hojas de cálculo, se suelen anidar o agrupar funciones unas dentro de otras, derivando en fórmulas relativamente complejas. El programa OpenOffice.org Calc permite, mediante su asistente de funciones (function wizard), navegar a través de los varios o múltiples niveles de anidamiento, permitiendo editar (y eventualmente corregir) cada una de ellas por separado. Tal vez de manera sorprendente, su rival Microsoft Excel no posee esa característica, eventualmente deseable cuando se trabaja en algunas grandes planillas.
6.2 En programación En los lenguajes de programación estructurada, el anidamiento está relacionado a la inclusión de estructuras de control dentro de otras, usualmente indicado mediante la inclusión de distintos niveles de sangría (llamada indentation en inglés) dentro del código fuente, como se muestra en el sencillo código BASIC siguiente: function BuscarCodigo(cod as string) as integer dim 12
• Programación estructurada • Pseudocódigo
Capítulo 7
Antipatrón de diseño Un antipatrón de diseño es un patrón de diseño que invariablemente conduce a una mala solución para un problema. Al documentarse los antipatrones, además de los patrones de diseño, se dan argumentos a los diseñadores de sistemas para no escoger malos caminos, partiendo de documentación disponible en lugar de simplemente la intuición. El término se origina inspirado en el libro Design Patterns, escrito por un grupo de autores conocido como Gang of Four, y que aglutina un conjunto de buenas soluciones de programación. Los autores bautizaron dichas soluciones con el nombre de “patrones de diseño”por analogía con el mismo término, usado en arquitectura. El libro Anti-Patterns (de William Brown, Raphael Malveau, Skip McCormick y Tom Mowbray, junto con la más reciente incorporación de Scott Thomas) describe los antipatrones como la contrapartida natural al estudio de los patrones de diseño. El estudio formal de errores que se repiten permite reconocer y reconducir los elementos involucrados hacia una mejor solución. Los antipatrones no se mencionan en el libro original de Design Patterns, puesto que éste es anterior. Los antipatrones se consideran una parte importante de una buena práctica de programación. Es decir, un buen programador procurará evitar los antipatrones siempre que sea posible, lo que requiere su reconocimiento e identificación tan pronto como sea posible, dentro del ciclo de vida del software. El concepto de antipatrón se puede aplicar a la ingeniería en general, e incluso a cualquier tarea realizada por el hombre. Aunque no se escucha con frecuencia fuera del campo ingenieril, la noción está ampliamente extendida.
7.1 Algunos antipatrones desarrollo de software 7.1.1
de
Antipatrones de gestión
• Productividad a toda costa: La empresa busca la productividad a costa de la calidad del software y de la 13
calidad de vida de sus empleados, intenta homogeneizar los puestos de trabajo quitando en la medida de lo posible los permisos a los programadores para que no dañen los sistemas operativos, monitoriza a los equipos de trabajo y actúa cortando la visibilidad de ciertas páginas o las reuniones de programadores, al final se consigue que se vaya la gente de la empresa cuando la situación es insostenible, esto suele ocurrir en ciclos de uno o dos años. • Responsable ausente (absentee manager): Situación en la que el principal responsable o coordinador se ausenta o permanece en paradero desconocido o no localizable durante importantes períodos de tiempo. • Todo lo que tienes es un martillo (all you have is a hammer): Gestión gris y plana, incapaz de tratar a los subordinados de manera personalizada y acorde con sus necesidades particulares. • Negociador de jaula de acero (cage match negotiator): Se aplica cuando un coordinador, gestor o responsable aplica una filosofía de "éxito a cualquier precio”. • Dos caras (doppelganger): Coordinador o compañero que en un determinado momento puede ser agradable y de trato fácil, pero igualmente puede volverse irracional y despiadado de modo inesperado. • Rodeos improductivos (fruitless hoops): Gestor o coordinador que solicita grandes cantidades de datos (en ocasiones sin relevancia alguna) antes de tomar una decisión. • Niñito de oro (golden child): Situación en la que ciertas responsabilidades, oportunidades, reconocimientos o recompensas van a parar a un determinado miembro del equipo como consecuencia de una relación personal o en clara contradicción con su rendimiento real. • Pollo sin cabeza (headless chicken): Se aplica al gestor, coordinador o responsable que vive en una permanente situación de pánico y medidas desesperadas.
14
CAPÍTULO 7. ANTIPATRÓN DE DISEÑO
• Líder pero no gestor (leader not manager): Un buen líder no tiene por qué ser necesariamente un buen gestor, coordinador o responsable.
• Mala gestión (bad management): Gestionar un proyecto sin tener suficientes conocimientos sobre la materia.
• Gestión clonada (managerial cloning): Situación en la que los coordinadores o gestores son contratados e instruidos para actuar y trabajar todos del mismo modo, a imagen y semejanza de sus propios jefes.
• Software inflado (software bloat): Permitir que las sucesivas versiones de un sistema exijan cada vez más recursos.
• Gestor pero no líder (manager not leader): Un coor- 7.1.3 Antipatrones generales de diseño de dinador brillante en sus deberes administrativos y de software gestión, pero que carece de habilidades de liderazgo. • Base de datos como comunicador de procesos (data• Abuso de la métrica (metric abuse): Utilización mabase as an IPC): Usar una base de datos para comunipuladora o incompetente de las medidas y las ménicar procesos en uno o varios ordenadores, cuando tricas. la comunicación entre procesos directa es más adecuada. • Sr. Amigo de todos (Mr. Nice Guy): Se aplica al gestor que pretende convertirse en amigo de todos. • Blob: Véase Objeto todopoderoso. • Héroe del proletariado (proletariat hero): El “empleado para todo”que siempre es puesto como ejemplo ante sus compañeros, pero que realmente es la excusa perfecta para demandas crecientes y constantes incrementos de expectativas. • Estrellas nacientes (rising upstart): Se aplica a quienes, teniendo potencial, no son capaces de respetar la progresión profesional establecida, y pretenden sortear los plazos y requisitos de aprendizaje y madurez. • Ejecutivo sin carácter (spineless executive): Gestor, coordinador o responsable que no tiene el coraje de enfrentarse a las situaciones, asumir las responsabilidades de los errores, o dar la cara por sus subordinados.
• BOMQ (Batch Over MQ): Abuso en el empleo de integración basada en mensajes en tiempo real para transferencias esporádicas de gran tamaño en segundo plano. • Clase Gorda: Dotar a una clase con demasiados atributos y/o métodos, haciéndola responsable de la mayoría de la lógica de negocio. • Botón mágico (magic pushbutton): Tender, desarrollando interfaces, a programar la lógica de negocio en los métodos de interacción, implementando los resultados de las acciones del usuario en términos no suficientemente abstractos. • Carrera de obstáculos (race hazard): Incapacidad de prever las consecuencias de diferentes sucesiones de eventos.
• Caballero de tres cabezas (three-headed knight): Gestor indeciso, poco firme, dubitativo.
• Entrada chapuza (input kludge): No especificar e implementar el manejo de entradas inválidas.
• Arma definitiva (ultimate weapon): Individuos altamente competentes en los que la organización o sus compañeros confían tanto que se convierten en el canal por el que todo pasa.
• Fábrica de combustible (gas factory): Diseñar de manera innecesariamente compleja.
• Recién llegado (warm body): Trabajador que apenas cubre las expectativas mínimas y por tanto circula de proyecto en proyecto o de equipo en equipo. • Arquitecto a obrero (super builder): Creencia por la que se asigna a un buen diseñador de software al desarrollo de código pensando en que tardara mucho menos en teclearlo.
7.1.2
Antipatrones de gestión de proyectos
• Humo y espejos (smoke and mirrors): Mostrar cómo será una funcionalidad antes de que esté implementada.
• Gran bola de lodo (big ball of mud): Construir un sistema sin estructura definida. • Interfaz inflada (interface bloat): Pretender que una interfaz sea tan potente que resulta extremadamente difícil de implementar. • Inversión de abstracción (abstraction inversion): No exponer las funcionalidades implementadas que los usuarios necesitan, forzando a que se reimplementen a más alto nivel. • Punto de vista ambiguo (ambiguous viewpoint): Presentar un modelo sin concretar ciertos aspectos, postergando así decisiones conflictivas. • Re-dependencia (re-coupling): Introducir dependencias innecesarias entre objetos.
7.1. ALGUNOS ANTIPATRONES DE DESARROLLO DE SOFTWARE
15
• Sistema de cañerías de calefacción (stovepipe sys- 7.1.4 Antipatrones de programación tem): Construir un sistema difícilmente mantenible, • Nomenclatura heroica (heroic naming): Identificar ensamblando componentes poco relacionados. los miembros de un programa (interfaces, clases, propiedades, métodos...) con nombres que provocan que el conjunto aparente estandarización con la inAntipatrones de diseño orientado a objetos geniería del software pero que en realidad oculta una implementación anárquica. • Acoplamiento secuencial (sequential coupling): Construir una clase que necesita que sus métodos se invoquen en un orden determinado. • BaseBean: Heredar funcionalidad de una clase utilidad en lugar de delegar en ella. • Fallo de clase vacía (empty subclass failure): Crear una clase que no supera el test de la subclase vacía, es decir, que se comporta de manera diferente cuando se invoca desde una subclase que no añade modificación alguna. • Llamar a super (callsuper): Obligar a las subclases a llamar a un método de la superclase que ha sido sobrescrito. • Modelo de dominio anémico (anemic domain model): Usar un modelo del dominio sin ninguna lógica de negocio. Esto no es un enfoque orientado a objetos porque cada objeto debería tener tanto propiedades como comportamiento asociado. • Objeto sumidero (object cesspool): Reutilizar objetos no adecuados realmente para el fin que se persigue. • Objeto todopoderoso (god object): Concentrar demasiada funcionalidad en una única parte del diseño (clase). • Poltergeist (informática): Emplear objetos cuyo único propósito es pasar la información a terceros objetos. • Problema del círculo-elipse (circle-ellipse problem): Crear variables de tipo pensando en los valores de posibles subtipos. • Problema del yoyó (yo-yo problem): Construir estructuras (por ejemplo, de herencia) que son difíciles de comprender debido a su excesiva fragmentación. • Singletonitis: Abuso de la utilización del patrón singleton. • YAFL (yet another fucking layer, y otra maldita capa más) o 'Código Lasagna': Añadir capas innecesarias a un programa, biblioteca o framework. Esta tendencia se extendió bastante después de que se publicase el primer libro sobre patrones.
• Acción a distancia (action at a distance): Provocar la interacción no prevista de componentes muy distantes de un sistema. • Acumular y disparar (accumulate and fire): Establecer una colección de variables globales para ser usadas por un conjunto de subrutinas. • Ancla del barco (boat anchor): Retener partes del sistema que ya no tienen utilidad. • Bucle activo (busy spin): Utilizar espera activa cuando existen alternativas. • Código duro (hard code): Hacer supuestos sobre el entorno del sistema en demasiados lugares de la implementación. • Complejidad no indispensable (accidental complexity): Dotar de complejidad innecesaria a una solución. • Código espagueti (spaghetti code): Construir sistemas cuya estructura es difícilmente comprensible, especialmente debido a la escasa utilización de estructuras de programación. • Código ravioli (ravioli code): Construir sistemas con multitud de objetos muy débilmente conectados. • Comprobación de tipos en lugar de interfaz (checking type instead of interface): Comprobar que un objeto es de un tipo concreto cuando lo único que se necesita es verificar si cumple un contrato determinado. • Confianza ciega (blind faith): Descuidar la comprobación de los resultados que produce una subrutina, o bien de la efectividad de un parche o solución a un problema. • Doble comprobación de bloqueo (double-checked locking): Comprobar, antes de modificar un objeto, si es necesario hacer esa modificación, pero sin bloquear para comprobarlo, de manera que dicha comprobación puede fallar. • Fallo de caché (caching failure): Olvidar restablecer una marca de error cuando éste ya ha sido tratado. • Lava seca (lava flow): Código muerto e información de diseño olvidada permanecen congelados en un diseño cambiante. Esto es análogo a un flujo de lava en el que se van endureciendo pedazos de roca. La
16
CAPÍTULO 7. ANTIPATRÓN DE DISEÑO solución incluye un proceso de gestión de la configuración que elimina el código muerto y permite evolucionar o rehacer el diseño para acrecentar la calidad.
• Lógica super-booleana (superboolean logic): Emplear comparaciones o abstracciones de la lógica booleana innecesarias. • Manejo de excepciones (exception handling): Emplear el mecanismo de manejo de excepciones del lenguaje para implementar la lógica general del programa. • Manejo de excepciones inútil (useless exception handling): Introducir condiciones para evitar que se produzcan excepciones en tiempo de ejecución, pero lanzar manualmente una excepción si dicha condición falla. • Momento del código (code momentum) : Establecer demasiadas restricciones sobre una parte del sistema debido a la asunción de muchas de sus propiedades desde otros lugares del propio sistema. • Números mágicos (magic numbers): Incluir en los algoritmos números concretos sin explicación aparente.
• Desfactorización (de-factoring): Eliminar funcionalidad y reemplazarla con documentación. • Factor de improbabilidad (improbability factor): Asumir que es improbable que un error conocido cause verdaderos problemas. • Martillo de oro (golden hammer): Asumir que nuestra solución favorita es universalmente aplicable, haciendo bueno el refrán a un martillo, todo son clavos. • Optimización prematura (premature optimization): Realizar optimizaciones sin disponer de la información suficiente para hacerlo con garantías, sacrificando decisiones de diseño. • Programación de copiar y pegar (copy and paste programming): Programar copiando y modificando código existente en lugar de crear soluciones genéricas. • Programación por permutación (programming by permutation): Tratar de aproximarse a una solución modificando el código una y otra vez para ver si acaba por funcionar.
• Ocultación de errores (error hiding): Capturar un error antes de que se muestre al usuario, y reemplazarlo por un mensaje sin importancia o ningún mensaje en absoluto.
• Reinventar la rueda (reinventing the wheel): Enfrentarse a las situaciones buscando soluciones desde cero, sin tener en cuenta otras que puedan existir ya para afrontar los mismos problemas.
• Packratting: Consumir memoria en exceso debido a no liberar objetos reservados dinámicamente una vez ya han dejado de ser necesarios.
• Reinventar la rueda cuadrada (reinventing the square wheel): Crear una solución pobre cuando ya existe una buena.
• Programación por excepción (coding by exception): Añadir trozos de código para tratar casos especiales 7.1.6 a medida que se identifican. • Secuencia de bucle por casos (Loop-switch sequence): Programar un conjunto de pasos secuenciales usando un bucle en combinación con una estructura de control por casos. • Cadenas mágicas (magic strings): Incluir cadenas de caracteres determinadas en el código fuente para hacer comparaciones, como tipos de eventos, etc.
7.1.5
Antipatrones metodológicos
Antipatrones de gestión de la configuración
• Conflicto de extensiones (extension conflict): Problemas con diferentes extensiones que tratan de gestionar las mismas partes del sistema (específico de Mac OS). • Infierno de dependencias (dependency hell): Escenario de problemas producidos por las versiones de otros productos que se necesitan para hacer funcionar un tercero.
• Bala de plata (silver bullet): Asumir que nuestra solución técnica favorita puede resolver un problema mucho mayor.
• Infierno DLL (DLL hell): Problemas con las versiones, disponibilidad o proliferación de DLLs (específico de Microsoft Windows)
• Desarrollo conducido por quien prueba (tester driven development): Permitir que un proyecto software avance a base de extraer sus nuevos requisitos de los informes de errores.
• Infierno JAR (JAR hell): Problemas con diferentes versiones o ubicaciones de ficheros JAR (Java), típicamente causados por la falta de comprensión del modelo de carga de clases.
7.3. RELACIÓN ALFABÉTICA DE OTROS ANTIPATRONES
7.2 Algunos antipatrones organizacionales • Alcance incremental (scope creep): Permitir que el alcance de un proyecto crezca sin el control adecuado. • Dependencia de proveedor (vendor lock-in): Construir un sistema que dependa en exceso de un componente proporcionado por un tercero. • Diseño en comité (design by committee): Contar con muchas opiniones sobre un diseño, pero adolecer de falta de una visión unificada. • Escalada de compromiso (escalation of commitment): No ser capaz de revocar una decisión a la vista de que no ha sido acertada. • Funcionalitis creciente (creeping featuritis): Añadir nuevas funcionalidades al sistema en detrimento de su calidad. • Gestión basada en números (management by numbers): Prestar demasiada atención a criterios de gestión cuantitativos, cuando no son esenciales o difíciles de cumplir. • Gestión de champiñones (mushroom management): Tratar a los empleados sin miramientos, sin informarles de las decisiones que les afectan (manteniéndolos cubiertos y en la oscuridad, como los champiñones). • Gestión porque lo digo yo (management by perkele): Aplicar una gestión autoritaria con tolerancia nula ante las disensiones. • Migración de costes (cost migration): Trasladar los gastos de un proyecto a un departamento o socio de negocio vulnerable. • Obsolescencia continua (continuous obsolescence): Destinar desproporcionados esfuerzos a adaptar un sistema a nuevos entornos. • Organización de cuerda de violín (violin string organization): Mantener una organización afinada y en buen estado, pero sin ninguna flexibilidad. • Parálisis por análisis (analysis paralysis): Dedicar esfuerzos desproporcionados a la fase de análisis de un proyecto, eternizando el proceso de diseño iterando sobre la búsqueda de mejores soluciones o variantes. • Peligro moral (moral hazard): Aislar a quien ha tomado una decisión a raíz de las consecuencias de la misma.
17 • Sistema de cañerías (stovepipe): Tener una organización estructurada de manera que favorece el flujo de información vertical, pero inhibe la comunicación horizontal. • Te lo dije (I told you so): Permitir que la atención se centre en que la desoída advertencia de un experto se ha demostrado justificada. • Gallina de los huevos de oro (cash cow): Pecar de autocomplacencia frente a nuevos productos por disponer de un producto legacy muy lucrativo.
7.3 Relación alfabética de otros antipatrones • Arrojar al otro lado del muro (thrown over the wall): Cuando un proyecto involucra a varios grupos de trabajo y va pasando secuencialmente de uno a otro, con escasa o nula comunicación entre ellos. • Billete lobo (wolf ticket): Declarar compatibilidad con un estándar cuando ésta no existe, o bien cuando el estándar solo incluye recomendaciones no obligatorias que, de hecho, no se siguen. • Fiesta de los bocazas (Blowhard Jamboree): Cuando se intenta que las decisiones técnicas del proyecto sean las basadas en opiniones de expertos publicadas en prensa. • Cadena sin longitud (string without length). • Cajas de diálogos en cascada (cascading dialog boxes). • Callejón sin salida (dead end): Encontrar un problema que impide continuar trabajando, pero la dirección no permite corregir el problema. El equipo queda estancado. • Caminar por un campo de minas (walking through a mine field): Trabajar con un componente pobremente probado (usualmente inestable), y por tanto poco confiable. • Chivo expiatorio (scape goat): Ante circunstancias de crisis en un proyecto se toma la decisión de dirigir las culpas a una persona o a un conjunto de personas concretas sin analizar si verdaderamente la naturaleza del problema se encuentra en las mismas. • Codificación brutal: Presionar a los programadores a trabajar sobre una arquitectura sin diseñar y sin requisitos evidentes. • Comité designado (appointed team): Crear un comité o grupo de trabajo para resolver un problema y no ocuparse de lograr que el grupo funcione.
18
CAPÍTULO 7. ANTIPATRÓN DE DISEÑO
• Compensación equitativa (egalitarian compensation): Compensar al personal por el trabajo individual hecho.
• El correo electrónico es peligroso (email is dangerous): Peligro de olvidar que detrás de los emails recibidos hay personas de carne y hueso.
• Contenedor mágico (magic container): La implementación de métodos que intentan ser tan flexibles como para adaptar su comportamiento a multitud de circunstancias, sobrepasando el umbral de una mantenibilidad adecuada del mismo.
• El gestor controla el proceso (manager controls process).
• Cuerpos tibios (warm bodies). • Culto al carguero (cargo cult): Consiste en copiar ciertas prácticas que podrían ser consideradas (no siempre) buenas prácticas sin saber muy bien los beneficios o ventajas que proporcionan, provocando esfuerzo innecesario en el proyecto para incorporarlas o problemas. • Cultura del miedo (fear culture)): Ambiente en el que cada empleado tiene miedo de mostrar el resultado de su trabajo por miedo a ser despedido por tener errores. • Cultura del héroe (hero culture): Se produce cuando una o pocas personas toman la responsabilidad del éxito de todo el equipo o proyecto, a menudo trabajando sobretiempo. • Decisión aritmética (decision by arithmetic): En lugar de intentar tomar una decisión con los datos disponibles y basado en el conocimiento y experiencia de nuestros colaboradores y el nuestro, se trata de justificar la misma sobre la base de unos factores presuntamente objetivos. • Desarrollo distribuido geográficamente (geographically distributed development). • Desarrollo marcado por las herramientas (autogenerated stovepipe): Preferir una solución generada automáticamente sobre la mejor solución. • Descomposición funcional (functional decomposition): Traducir un programa de un lenguaje estructurado a uno OO usando una sola clase y muchos métodos privados. • Diseñar por diseñar (design for the sake of design): Realizar un diseño excesivamente complejo sin necesidad real. • Diseño con arquitectura impuesta (architecture as requirement): Imponer que el diseño considere, obligatoriamente, el uso de herramientas o métodos no necesariamente idóneos. • Diseño de fregadero (kitchen sink design). • Diseñadores empíricos (architects don't code): Incapacidad del grupo de diseño para evaluar la complejidad del objeto diseñado.
• El traje nuevo del emperador (emperor's new clothes): Temor a señalar los defectos de un producto o proceso que un gerente o manager cree que funciona bien. • El viejo gran duque de York (the grand old Duke of York): Cuando los arquitectos o analistas no intervienen (uno o los dos), dejando a los programadores (especialistas en la implementación) prácticamente todas las decisiones a nivel e ejecución de las especificaciones del usuario. • Ellos me entendieron (they understood me): Explicar a programadores o diseñadores junior lo que se espera de ellos muy brevemente, y asumir que entendieron lo que se les pidió. • Embudo de excepciones (exception funnel): Atrapar una excepción e ignorarla, sin reportarlo. • Entrenar al entrenador (train the trainer): Contratar una formación sin haber precisado con cierta exactitud la materia sobre la que se desea la misma. Esto puede provocar que la formación no se enfoque de manera adecuada, tratando aspectos que no son necesarios en el proyecto o dejando fuera aspectos fundamentales. Contratar una formación sin tener referencias del formador, ya que lo mismo su nivel de conocimiento no es el adecuado a la naturaleza de la formación a impartir. • Es un problema de operadores (it is an operator problem). • Esconder las armas (cover your assets). • Falsa economía (false economy): Permitir que los recortes de presupuesto afecten la eficiencia de los trabajadores (las pérdidas terminan siendo mayores que lo ahorrado). • Falso punto final subrogado (false surrogate endpoint). • Fechas en punto flotante (floating point times). • Haz tu propia base de datos (roll your own database): Ante la necesidad de persistencia de datos se utiliza una solución que no se basa en un estándar. • Ingenieros compatibles e intercambiables (plug compatible interchangeable engineers). • Introducción de dificultad por analogía (analogy breakdown): Diseñar por analogía con problemas resueltos, posiblemente introduciendo dificultades no inherentes al problema, o descuidando dificultades propias del nuevo caso que se maneja.
7.3. RELACIÓN ALFABÉTICA DE OTROS ANTIPATRONES • Invocar a constructores con nulos (passing nulls to constructors).
19 contingencias del proceso de desarrollo, o cuando no se es flexible ante una planificación inicial, conservándose a lo largo del proyecto pese a que se pueda apreciar que resulta absolutamente irreal.
• La disputa familiar (the feud): Cuando existiendo un conflicto entre gestores de proyectos no se le busca una solución definitiva al mismo.
• Nacionalismo (national ism).
• La experiencia mata el diseño (architecture by implication): Descuidar el diseño por confiar excesivamente en la experiencia previa.
• Navaja suiza (swiss army knife): Intentar crear un producto que solucione varios problemas poco relacionados entre sí.
• Los clientes son tontos (customers are idiots): Pensar que uno sabe más que el cliente, y por tanto no es necesaria una investigación con el cliente.
• No es mi trabajo (Not my job): No solucionar algún problema evidente argumentando que es problema o fallo de otro.
• Maníaco del control (control freak): El deseo de control lleva a la microgestión y ésta a su vez a una pérdida importante de la capacidad de autogestión del equipo, ya que todos los pasos se miden milimétricamente.
• No especificar (specify nothing).
• Máquina de Rube Goldberg (Rube Goldberg machine): Realizar implementaciones muy complejas para tareas sencillas.
• Otra reunión más lo resolverá (yet another meeting will solve it): Ante un problema en la planificación del proyecto, se convocan reuniones para intentar dar una solución al problema. En éstas reuniones participan los miembros del equipo de proyecto que tendrán que dejar su trabajo habitual, produciéndose nuevos retrasos.
• Matar al mensajero (shoot the messenger). • Matar dos pájaros de un tiro (kill two birds with one stone). • Matrimonio sumarísimo (sumo marriage): Suele ocurrir en cualquier situación en la que exista una dependencia de un elemento o de una serie de factores que dificultan el mantenimiento o evolución del sistema. • Mazorca de maíz (corn cob): Mantener personas en el proyecto que resultan difíciles, conflictivas o que funcionan de manera absolutamente al margen de lo que es cualquier trabajo en equipo o de un comportamiento solidario y que rompen con la armonía del grupo. • Mecanismos de recompensa discordantes (discordant reward mechanisms): Un equipo recibe reconocimiento por ser el que más trabajo ejecuta sobre la base de criterios objetivos que no son válidos para medir el nivel de productividad o calidad. • Mezclador de software (software merger).
• No inventado aquí (not invented here): Cuando la organización o uno se niega a utilizar soluciones, metodologías, prácticas, herramientas, etc. externas sólo porque no se nos ocurrió previamente.
• Otro programador más (yet another programmer). • Presunto heredero (heir apparent): Cuando vemos que los posibles huecos que podrían quedar para seguir progresando en nuestra organización tienen ya nombres y apellidos (cuando además sus méritos son más que discutibles), provocará la salida de la organización en busca de otras alternativas o se producirá una pérdida de motivación que impactará directamente en la productividad. • Proceso a prueba de idiotas (idiot proof process). • Programador discordante (net negative producing programmer): Hay proyectos donde el rendimiento de uno o más miembros del equipo es muy inferior al esperado, hasta el punto de ser su productividad neta en el proyecto negativa (el proyecto mejoraría con el simple hecho de prescindir de estas personas, sin necesidad de sustituirlas por otra)
• Miedo al éxito (fear of success): Permitir que las únicas razones de que los trabajos no se completen sean de índole social.
• Proyecto del día de la marmota (ground hog day project): Discutir los mismos temas en todas las reuniones, sólo para llegar a la conclusión de que “algo debe hacerse”.
• Moneda en punto flotante (floating point currency): Utilizar una representación en punto flotante para valores que representan dinero, lo que puede provocar pérdida de precisión.
• Prueba incompleta (asynchronous unit testing): Descuidar en la etapa de pruebas, algunas unidades en todos los casos, o todas las unidades en algunos casos.
• Morir planificando (death by planning): Invertir más esfuerzo (y tiempo) del necesario para establecer un plan que después puede ser destruido por las propias
• Quiero estimaciones ahora (give me estimates now): Dar estimaciones sin tener suficientes datos para hacerlas.
20 • Requisitos esparcidos por la pared (requirements tossed over the wall): Existe un desorden general en los requisitos: se encuentran en distinto grado de terminación, no hay priorización de los mismos o es muy general como para poder hacer una ordenación adecuada por ese criterio, etc. Esto normalmente es provocado por una colaboración inadecuada por parte del área usuaria. • Requisitos ocultos (Hidden requirements): El equipo de proyecto conocedor de la dificultad de implementar un determinado requisito lo obvia dentro del catálogo de requisitos, le asigna una prioridad muy baja o lo engloba dentro de un requisito de mayor nivel quedando difuminado en el mismo. El área usuaria no especifica un requisito o no lo especifica de manera adecuada, solicitando explicaciones a posteriori por la no implementación de ese requisito o por su comportamiento incorrecto. • Si funciona, no lo toques (if it is working don't change):. • Somos tontos (we are idiots): Pensar que el conocimiento interno del problema es peligroso (por riesgo de que sea pobre o equivocado), y pedir validación del cliente para cada característica o decisión mayor. • Tarjetas CRCI (CRCI cards): Cuando se usa la técnica de tarjetas CRC, se aprovecha e incluye en la misma la implementación de la clase, convirtiéndose automáticamente la tarjeta CRC (Class-Responsibility-Collaboration) en CRCI (Class-Responsibility-CollaborationImplementation). • Tormenta de reproches (blame storming): En un equipo de proyecto se llega a la conclusión de que la mejor forma de analizar las causas de la no consecución de los objetivos es que se discuta quiénes internamente han tenido la culpa. • Torre de vudú (tower of voodoo):Se tiene un código que se sabe que funciona (aunque generalmente no se sabe muy bien cómo) y se pretende añadir algún tipo de funcionalidad adicional, en ocasiones no muy cohesionada con la ya implementada y se le coloca un envoltorio (wrapper) proporcionando una nueva interfaz de acceso a ese nuevo componente. • Trampa para osos (bear trap): Invertir mucho en una herramienta poco adaptada o factible, de manera que después es imposible deshacerse de ella. • Único punto de salida de función (single function exit point). • Valor por defecto indefinido (zero means null): Escoger un valor arbitrario para representar la indefinición, sin garantizar que ese valor no puede realmente ocurrir.
CAPÍTULO 7. ANTIPATRÓN DE DISEÑO • Violencia intelectual (intellectual violence): De manera interna en un equipo de trabajo o en una reunión con el cliente y/o con usuarios se utilizan términos, generalmente técnicos, que no son comprendidos o conocidos por la mayoría de los interlocutores.
7.4 Véase también • Patrón de diseño • Crisis del software • Hediondez del código • No hay balas de plata
7.5 Enlaces externos • C2.com (antipatrones) Portland Pattern Repository's Wiki
Capítulo 8
Archivo de cabecera Se denomina header file, al español fichero/archivo (de) cabecera, o include file, al español fichero de inclusión, en ciencias de computación, especialmente en el ámbito de los lenguajes de programación C y C++, al archivo, normalmente en forma de código fuente, que el compilador incluye de forma automática al procesar algún otro archivo fuente. Típicamente los programadores especifican la inclusión de los header files por medio de pragmas al comienzo (head o cabecera) de otro archivo fuente. Un header file contiene, normalmente, una declaración directa de clases, subrutinas, variables, u otros identificadores. Aquellos programadores que desean declarar identificadores estándares en más de un archivo fuente pueden colocar esos identificadores en un único header file, que se incluirá cuando el código que contiene sea requerido por otros archivos. La biblioteca estándar de C y la biblioteca estándar de C++ tradicionalmente declaran sus funciones estándar en header files.
8.1 Motivación En la mayoría de lenguajes de programación modernos, los programadores pueden dividir los programas en componentes de menor tamaño (como pueden ser clases y subrutinas) y distribuir esos componentes entre muchas unidades por traducir (típicamente en forma de archivos), que el sistema puede compilar de forma autónoma. Si una subrutina se tiene que usar al margen de la unidad por traducir donde ha sido definida, se tiene que introducir el concepto de declaración directa o prototipos de funciones. Por ejemplo, una función definida así en un archivo fuente:
Sin embargo en esta simple ilustración se requiere que el programador mantenga la declaración de la función de add en dos sitios ̶en el archivo que contiene su implementación y en el archivo que usa la funcionalidad. Si la definición de la función llega a alterarse, entonces el programador debe actualizar todos los prototipos repartidos a lo largo del programa. Esto es necesario porque la implementación de ambos, C y C++ han de diagnosticar todas las violaciones de lo que en C++ se llama "one definition rule" (ODR), al español “regla de una única definición”. De hecho, la mayoría de ellos se sirven de un enlazador para realizar esta labor. El enlazador, sin embargo, suele conocer, de forma muy limitada los tipos usados en los programas. Por ello, algunas de las violaciones de ODR no se detectan a la hora de implementar el lenguaje. Como resultado, es responsabilidad del programador el mantener la coherencia de todas las declaraciones que cruzan las fronteras de una unidad por traducir. Buscar todas estas declaraciones de una entidad externa y verficar que son compatibles de forma manual es una tarea ardua. (Nótese que C no define el término “one definition rule”̶es específico del lenguaje C++. Si declaraciones de la misma entidad en muchos archivos fuentes de C son diferentes, la función no funcionará de forma adecuada y puede llegarse a un comportamiento impredecible, independientemente de la regla que se esté violando.) Para entender una violación ODR, considérese el siguiente código (correcto): /* File print-heading.c */ #include void print_heading(void) { printf(“standard heading\n”); } /* File main.c */ void print_heading(void); int main(void) { print_heading(); return 0; }
La unidad por traducir representada por el archivo fuente main.c referencia a la función print_heading() que está definida en otra unidad por traducir (print-heading.c). De int add(int a, int b) { return a + b; } acuerdo con las reglas de C99, los programadores deben declarar una función externa antes del primer uso. Para puede declararse (con un prototipo de función) y ser re- cumplir con este requisito el archivo main.c declara la ferida desde un segundo archivo fuente como sigue: función en la primera línea. Esta versión del código funint add(int, int); int triple(int x) { return add(x, add(x, ciona de forma correcta. x)); } Posteriormente, el programador que mantiene el archivo
21
22
CAPÍTULO 8. ARCHIVO DE CABECERA
fuente print-heading.c puede decidir hacer la función más /* File add.c */ #include “add.h”int add(int a, int b) { flexible y dar soporte a cabeceras a gusto del usuario. Una return a + b; } posible implementación podría ser la siguiente: /* File print-heading.c */ #include void Normalmente, los programadores sólo utilizan los heaprint_heading(const char *heading) { printf("%s\n”, der files para especificar los interfaces, y suelen aportar al heading); } menos, una pequeña cantidad de información explicando cómo usar los componentes declarados en el archivo. Al Si el programador olvida actualizar la declaración en igual que en este ejemplo, las implementaciones de sumain.c, se pueden dar resultados devastadores. La fun- brutinas permanecen en un archivo fuente separado, que ción print_heading() espera un argumento y hace uso del continua siendo compilado de forma independiente. (Una valor del mismo, sin embargo la función main() no pro- excepción común entre C y C++ son las "funciones inlivee ningún valor. Al ejecutar este programa se produce un ne", que suelen incluirse en header files porque la mayoría comportamiento impredecible: la aplicación puede im- de implementaciones no pueden expendir funciones inliprimir basura, terminar de forma inesperada o dar pie a ne de forma adecuada sin ver sus definiciones durante el resultados impredecibles en la plataforma en la que es eje- tiempo de compilación.) cutado. ¿Por qué se puede compilar y enlazar este código sin problema alguno? El motivo es que el compilador se guía por la declaración en main.c a la hora de compilar la unidad por traducir main.c. Y esa declaración se ajusta con la forma de la función. Más tarde, cuando el enlazador combina las unidades de traducción ya compiladas main.c y printheading.c (en la mayoría de implementaciones representadas como archivos main.o o main.obj), probablmente podría detectar la inconsistencia ̶pero no en C. Las implementaciones en C referencian las funciones por el nombre al nivel de archivo objeto y archivo binario, esto no incluye el valor de retorno o la lista de argumentos. El enlazador encuentra una referencia a print_heading() en main.o y una función adecuada en print-heading.o. Llegado este punto, toda la información relativa a tipos de argumentos de funciones se pierde. ¿Cómo es entonces posible llevar a cabo declaraciones múltiples sin problema alguno? La solución se llama header file. El header file de un módulo declara cada función, objeto y tipo de dato que forma parte del interfaz público del módulo ̶por ejemplo, en este caso el header file incluiría sólo la delcaración de add. Todo aquel archivo fuente que se refiera a add usa la directiva #include en el header file:
8.2 Alternativas Los header files no son la única solución al problema de acceder identificadores declarados en diferentes archivos. Tienen la desventaja de que los programadores siguen teniendo que realizar cambios en dos sitios diferentes (en el archivo fuente y en el header file) cuando se realiza un cambio en una definición. Algunos lenguajes más jóvenes (como Java) prescienden de los header files y usan, en su lugar, una esquema de nombres que permite al compilador localizar los archivos fuente asociados con implementaciones de clases e interfaces (pero, al hacerlo, se restringe la libertad a la hora de nombrar archivos). En estos lenguajes, el problema de ODR se suele resolver por medio de dos técnicas: la primera, el compilador pone toda la información necesaria sobre los tipos en el código compilado y esta información es accesisble incluso cuando el programa se ejecuta.; la segunda, Java y otros lenguajes modernos tienen la posiblidad de verificar el número y tipo de los argumentos como método de invocación. Todo esto tiene su precio: un exceso en espacio y tiempo de ejecución que no es aceptable para algunas aplicaciones donde el tiempo de respuesta es crítica.
/* File add.h */ #ifndef ADD_H #define ADD_H int COBOL y RPG IV tienen una forma de incluir archivos llamada copybooks. Los programadores“incluyen”éstos add(int, int); #endif /* ADD_H */ en la fuente del programa de forma similar a como se hace con los header files, permitiendo también reemplazar (Nótese que el header file utiliza un "Include guard".) ciertas partes del texto. La palabra clave de COBOL para /* File triple.c */ #include “add.h”int triple(int x) { la inclusión es copy, y el reemplazo se realiza por medio de la cláusula replacing...by. return add(x, add(x, x)); } Esto reduce la carga del mantenimiento: cuando una definición cambia, solo se tiene que actualizar una única copia de la declaración (la del fichero de cabecera). El fichero de cabecera también se puede incluir en el fichero fuente que contiene las correspondientes definiciones, dándole al compilador la oportunidad de comprobar si la declaración y la definición son consistentes.
8.3 Véase también • Application Programming Interface • Interface description language • #pragma once
8.4. ENLACES EXTERNOS
8.4 Enlaces externos • Esta obra deriva de la traducción de Header file de Wikipedia en inglés, publicada por sus editores bajo la Licencia de documentación libre de GNU y la Licencia Creative Commons AtribuciónCompartirIgual 3.0 Unported. • Organizing Code Files (the potential pitfalls and guidelines for using header files in C++) • C++ header file inclusion rules
23
Capítulo 9
Aserción (informática) En programación, una aserción es un predicado (i.e., una 9.1 Uso de las aserciones sentencia verdadero-falso) incluido en un programa como indicación de que el programador piensa que dicho En lenguajes como Eiffel, las aserciones son parte del propredicado siempre se cumple en ese punto del flujo de ceso de diseño, mientras que en otros, como C o Java, programa. solamente son utilizadas para comprobar suposiciones en Por ejemplo, el siguiente código contiene dos aserciones: tiempo de ejecución. x := 5; {x > 0} x := x + 1 {x > 1}
9.1.1 Aserciones en el diseño por contrato x > 0 y x > 1, y las dos son ciertas en dichos puntos de la Las aserciones pueden ser una forma de documentación: ejecución. pueden describir el estado en que el código empieza su Las aserciones suelen ser útiles para especificar prograejecución (precondición), y el estado que el código espera mas y para razonar la corrección de los mismos. Por alcanzar cuando finalice (postcondición); asimismo pueejemplo, una precondición ̶una aserción al comienzo den servir de especificación para los invariantes de clase. de una sección de código ̶determina que se espera que En Eiffel, tales aserciones se integran en el código y son el conjunto de sentencias que la siguen sean ejecutadas. automáticamente extraídas para documentar la clase. EsUna postcondición ̶colocada al final ̶describe el estato supone una parte importante del método de diseño por do que se espera alcanzar al final de la ejecución. contrato. El ejemplo anterior utiliza la notación introducida por C. Esta aproximación también resulta útil en lenguajes que A. R. Hoare en su artículo de 1969 "An axiomatic bano las soportan explícitamente: la ventaja de usar sentensis for computer programming" ("Una base axiomácias de aserción en lugar de aserciones en comentarios es tica para la programación de ordenadores"). Como esta que las primeras pueden ser comprobadas en cada ejecunotación normalmente no es aceptada por los compiladoción; si la aserción no se cumple, puede informarse del res de los lenguajes actuales, los programadores suelen error. Esto previene que el código y las aserciones se desincluir aserciones mediante comentarios. A continuación fasen (un problema que puede ocurrir con las aserciones se incluye un ejemplo en C: comentadas). x = 5; /* {x > 0} */ x = x + 1; /* {x > 1} */ Se han incluido las llaves para distinguir este uso de los comentarios de su uso habitual. Varios lenguajes de programación modernos incluyen una sentencia de aserción, que no es más que una aserción que se comprueba en tiempo de ejecución. Si su evaluación resulta falsa, se produce un “error de aserción”. La intención de estas sentencias de aserción es facilitar la depuración del programa, evitando que dicho fallo quede sin comprobar.
9.1.2 Aserciones en tiempo de ejecución Una aserción puede ser utilizada para verificar que una suposición hecha por el programador durante la implementación del programa sigue siendo válida durante la ejecución del programa. Por ejemplo, considérese el siguiente código en Java: int total = contarUsuarios(); if (total % 2 == 0) { // total es par } else { // total es impar assert(total % 2 == 1); }
El uso de aserciones ayuda al programador en las tareas En Java, % es el operador resto (no módulo) ̶si el pride diseño, desarrollo y razonamiento de un programa. mer operando es negativo, el resultado puede ser también negativo, Aquí, el programador ha asumido que la variable total no es negativa, así que el resto de una división entre 2 siempre será 0 o 1. La aserción explicita esta su24
9.2. DESACTIVACIÓN DE LAS ASERCIONES
25
posición ̶si contarUsuarios devuelve un valor negativo, es probable que haya un fallo en el programa.
9.2 Desactivación de las aserciones
Una gran ventaja de esta técnica es que cuando se produce algún error éste es inmediata y directamente detectado, evitando posibles daños colaterales ocultos. Puesto que un error de aserción normalmente informa de la línea de código donde se produce, se puede localizar el error sin necesidad de una depuración más exhaustiva.
Las aserciones suelen ser implementadas de modo que puedan ser activadas o desactivadas, normalmente en el conjunto del programa. Sin embargo, los lenguajes que distinguen entre distintos tipos de aserciones – p.ej. pre y postcondiciones – suelen permitir activarlas o desactivarlas de forma independiente. Si las aserciones son desactivadas, no se comprueban en tiempo de ejecución. De esta forma el programador puede colocar aserciones en lugares donde en otro caso no tendría sentido ponerlas (p.ej., comprobar que no se accede a un array mediante índices fuera de rango). Puesto que las aserciones son en principio una herramienta de desarrollo, normalmente son desactivadas cuando el programa en cuestión es publicado. Por otra parte, como algunas versiones del programa pueden incluir aserciones y otras no, es primordial que su desactivación no modifique el comportamiento del programa. En otras palabras, las aserciones deben ser libres de efectos colaterales. Una alternativa en el caso de C o C++ es redefinir la macro assert para evaluar la expresión incluso cuando las aserciones están desactivadas.
Las aserciones también suelen colocarse en puntos que se supone que no se alcanzan durante la ejecución. Por ejemplo, las aserciones pueden ser colocadas en la cláusula default de una estructura switch en lenguajes como C, C++ y Java. Los casos que intencionadamente no se manejan pueden provocar errores que aborten el programa.
En Java, las aserciones han sido parte del lenguaje desde la versión 1.4. Los errores de aserción resultan en AssertionError cuando el prorgama es ejecutado con los parámetros correctos, sin los cuales las sentencias de aserción son ignoradas. En C y C++, son añadidas por el fichero de cabeceras estándar assert.h definiendo assert (aserción) como una macro que devuelve un error en caso de fallo y La eliminación de las aserciones del código de producfinaliza el programa. ción es un proceso que se realiza de forma casi automáLas inclusión en los lenguajes de construcciones de aser- tica. Normalmente se realiza mediante compilación conción facilitan el desarrollo guiado por pruebas (Test- dicional, por ejemplo utilizando el preprocesador de C driven Development - TDD) al no necesitar de una libre- o C++ o pasando un parámetro de ejecución, como en ría independiente que implemente dichas aserciones. Java. Algunas personas, sin embargo, se oponen a la eliminación de las aserciones basándose en una analogía que compara la ejecución con aserciones y sin ellas en la fase de desarrollo con la práctica de la natación en una piscina 9.1.3 Aserciones durante el ciclo de desa- con la vigilancia de un socorrista para después nadar solo rrollo en el mar. Asimismo añaden que las aserciones también ayudan a desarrollar un programa a prueba de fallos. Durante el ciclo de desarrollo, el programador normalmente ejecuta su programa con las aserciones activadas. Cuando una aserción resulta falsa y se produce el correspondiente error, el programador automáticamente recibe 9.3 Comparación con los manejaun aviso. Muchas implementaciones además detienen la dores de errores ejecución del programa ̶esto resulta útil ya que si el programa sigue ejecutándose tras la violación de una aserEs importante establecer las semejanzas y diferencias ención, éste entra en un estado corrupto que puede hacer tre las aserciones y las rutinas de control de errores. Las más difícil la localización del problema. Gracias a la inaserciones deberían ser utilizadas para documentar situaformación proporcionada por el error de aserción (punto ciones lógicamente imposibles y descubrir posibles errodel código que ha provocado el fallo, quizás el stack trace res de programación̶si ese“imposible”ocurre, es que o incluso todo el contexto de la aserción violada), el proalgo fundamental está claramente equivocado. Esto difiegramador puede corregir el problema. De este modo, las re del control de errores: la mayoría de las condiciones de aserciones sirven como potente herramienta de depuraerror son posibles, aunque deberían ser muy poco probación. bles en la práctica. El uso de aserciones como mecanismo general de control de errores suele ser algo desacertado: las aserciones no permiten al programa recuperarse de los errores, y un fallo de aserción suele suponer una ter9.1.4 Aserciones estáticas minación abrupta del programa. Asimismo las aserciones Las aserciones que son comprobadas en tiempo de com- no suelen mostrar mensajes de error comprensibles por el pilación reciben el nombre de aserciones estáticas. Este usuario. tipo de aserciones resultan particularmente útiles en la Considérese el siguiente ejemplo de uso de aserciones pametaprogramación de plantillas. ra manejar un error:
26 int *ptr = malloc(sizeof(int) * 10); assert(ptr != NULL); // usar ptr Aquí, el programador advierte que malloc puede devolver un puntero a NULL si no resulta posible realizar la asignación de memoria. Esto es posible: el sistema operativo no garantiza que cada llamada a malloc termine con éxito, y el programa debe estar preparado para manejar el error. Una aserción quizás no es la mejor elección en este caso, ya que un error causado por malloc no es lógicamente imposible ̶es una posibildad legítima, aunque no es muy común que suceda. En este ejemplo, es cierto que la aserción resulta útil, aclarando que el programador ha decidido de forma deliberada no construir una rutina robusta de control de errores de asignación de memoria. El programador también puede decidirse por una utilización mixta de aserciones y rutinas estándar de control de errores para un mismo problema. Esto es útil en situaciones donde el programador quiere recibir aviso inmediato del error, pero con la seguridad de que será manejado de forma correcta en situaciones reales de explotación del programa. En el ejemplo anterior, esto supondría añadir una rutina de control de errores, pero también habría que mantener la aserción para que el programador supiese del fallo de memoria durante el proceso de depuración. Esto permite al programador localizar errores de forma más sencilla, lo que a su vez hará que el usuario final pueda ejecutar el programa sin recibir mensajes de error innecesarios. Esta táctica solamente resulta útil cuando el error especificado no supone la terminación abrupta del programa o afecte a los datos que éste maneja, sino que hará que el programa siga funcionando aunque sea más lentamente o de forma menos eficiente.
9.4 Enlaces externos • Hoare, C. A. R. (2001). «Assertions: a personal perspective». research.microsoft.com. Archivado desde el original el 02 de diciembre de 2015. • «Programming With Assertions in Java». java.sun.com. Archivado desde el original el 02 de diciembre de 2015. • «Using Assertions». java.sun.com. Artículo técnico.
CAPÍTULO 9. ASERCIÓN (INFORMÁTICA)
Capítulo 10
Automatización de tareas La automatización de tareas es, en informática, el conjunto de métodos que sirven para realizar tareas repetitivas en un ordenador. Algunos métodos para la automatización de tareas son la programación simple, los macros, los intérpretes y las bombas lógicas. También hay algunos programas específicos que automatizan tareas. Incluso los virus informáticos utilizados de forma benéfica podrían considerarse otro método para la automatización de tareas para el usuario.
27
Capítulo 11
Base de código El término codebase, o base de código, es usado en el desarrollo de software con el significado de la colección completa de código fuente usada para construir una aplicación o componente particular. Típicamente, el codebase incluye solamente los archivos del código fuente escritos por humanos y no los archivos del código fuente generados por otras herramientas o archivos de biblioteca binaria. Sin embargo, incluye generalmente archivos de configuración y de propiedades. El codebase para un proyecto es típicamente almacenado en un repositorio de control de fuentes. Un repositorio del código fuente es un lugar en donde son guardadas grandes cantidades de código fuente, tanto públicamente como privadamente. Son frecuentemente usados por proyectos de multi-desarrolladores para manejar, de una manera organizada, varias versiones y los conflictos que se presentan con los desarrolladores sometiendo modificaciones conflictivas. Subversion y Mercurial son herramientas populares usadas para manejar este flujo de trabajo, y son comunes en proyectos de fuente abierta. Refiriéndose a múltiples codebases como “distintos”se declara que hay implementaciones independientes sin código fuente compartido y que históricamente, estas implementaciones no evolucionaron de un proyecto común. En el caso de estándares, esto puede ser una manera de demostrar interoperabilidad mostrando dos piezas independientes de software que implementan un estándar dado.
11.1 Véase también • Apache Software Foundation • Bonsai (software) • Codase • Forja (software) • Programas para control de versiones • Control de versiones • SourceForge • Subversion (software)
28
Capítulo 12
Bean Un Bean es un componente software que tiene la particularidad de ser reutilizable y así evitar la tediosa tarea de programar los distintos componentes uno a uno. Se puede decir que existen con la finalidad de ahorrarnos tiempo al programar. Es el caso de la mayoría de componentes que manejan los editores visuales más comunes. Los que hayan utilizado Visual Studio, Eclipse o Delphi por ejemplo, ya estarán familiarizados con ellos. Un Bean puede representar desde un botón, un grid de resultados, un panel contenedor o un simple campo de texto, hasta otras soluciones mucho más complejas como conexiones a bases de datos, etc. Son bastante conocidas las EJB (Enterprise JavaBeans) que ofrecen numerosos Beans para Java.
12.1 Bean en Java Debe cumplir los siguientes criterios: - implementación serializable. - tener todos sus atributos privados (private). - tener métodos set() y get() públicos de los atributos privados. - tener un constructor público por defecto
12.2 Enlaces externos • JavaBeans de Sun
29
Capítulo 13
Beta tester Un Beta tester es un usuario de programas cuyos ejecutables están pendientes de terminar su fase de desarrollo, o alcanzar un alto nivel de funcionamiento, pero que aún no son completamente estables.* [1]
13.1 Generalidades Los beta testers usan sus conocimientos informáticos y su tiempo para detectar errores en la versión beta del software y así poder informar de éstos para que los desarrolladores los corrijan, o corregirlos ellos mismos. Algunas compañías los contratan para asegurarse de que sus programas van a funcionar lo mejor posible en el mercado. Otro tipo de beta testers son los que trabajan desinteresadamente ofreciendo soporte y ayuda a la comunidad GNU. Generalmente el“betatester”comparte una cierta afinidad con la herramienta puesta a prueba en cuestión, de ahí el entusiasmo por probarla, verificar nuevas funcionalidades y detectar anomalías en pos de mejorar el desarrollo de la herramienta en cuestión.
13.2 Alfa tester Es el mismo concepto, pero aplicado a la versión alfa del software, es decir, al software que se encuentra en la fase alfa del desarrollo.
13.3 Véase también • Fases del desarrollo de software
13.4 Referencias [1] S.E. Smith (2003). «What is a Beta Tester?» (en inglés). Consultado el 20 de octubre de 2010.
30
Capítulo 14
Bifurcación (sistema operativo) Este artículo se refiere a la bifurcación de procesos en sistemas operativos, consulta Bifurcación (informática) para otros usos.
Soy el padre con id 1 id proceso original 1 Soy el hijo con id 2 id proceso original 1
Una bifurcación o fork, cuando se aplica en el contexto de un lenguaje de programación o un sistema operativo, hace referencia a la creación de una copia de sí mismo por parte de un programa, que entonces actúa como un "proceso hijo" del proceso originario, ahora llamado "padre". Los procesos resultantes son idénticos, salvo que tienen distinto número de proceso (PID). Más generalmente, una bifurcación en un entorno multihilo significa que un hilo de ejecución se bifurca.
El orden de la salida será determinada por diversos parámetros del núcleo del sistema operativo. Como se puede observar, el valor contenido en la variable idPropio es compartido por proceso padre e hijo; sin embargo, la referencia a la variable no es la misma y su posterior modificación en cada código, ya sea del padre o del hijo, no se verá reflejada en ambos procesos.
14.2 Véase también • Bomba fork • Tubería
14.1 UNIX En el caso de los sistemas operativos derivados de UNIX, la llamada al sistema fork permite realizar una bifurcación del proceso. Esta llamada devuelve el identificador de proceso del proceso hijo al padre y un 0 al proceso hijo. Aquí hay un ejemplo escrito en lenguaje de programación C que muestra el uso de esta llamada. El código que se ejecute depende de si el proceso es padre o hijo. #include #include #include int main(void) { pid_t idHijo; pid_t idPropio; idPropio = getpid(); //Se obtiene el id del proceso actual idHijo = fork(); //Se crea un proceso 'hijo' if (idHijo == −1) { //Si hay un código menor que cero, hubo un error perror(“Error al realizar la bifurcación” ); //Se notifica al usuario return 1; //Se interrumpe la ejecución del proceso con una salida distinta a cero } if (idHijo == 0) //la ejecución de la llamada al sistema fork devuelve un cero al proceso 'hijo' printf(“Soy el hijo con id %ld id proceso original %ld\n”, (long)getpid(), (long)idPropio); else //la ejecución de la llamada al sistema fork devuelve el identificador al proceso 'padre' printf(“Soy el padre con id %ld id proceso original %ld\n”, (long)getpid(), (long)idPropio); return 0; } Este código imprimirá: 31
Capítulo 15
Binding 15.4 Enlaces externos
15.1 Psicología y educación En Psicología, el término binding se refiere a una metodología innovadora (Proyecto Binding) para enseñar a leer que nace de aplicar la evidencia científica en el ámbito del aprendizaje, desarrollada por la Universidad de Barcelona. Saber cómo trabaja nuestro cerebro para realizar una tarea tan complicada como la lectura es esencial para poder crear las mejores técnicas de aprendizaje lector (http://www.binding.es). Aunque todavía queda mucho camino por recorrer en este sentido, hoy en día se sabe que leer (y comprender) es el resultado de una gran cantidad de procesos cognitivos: la memoria de trabajo, el bucle fonológico, la capacidad de inferencia y deducción, entre otros. Así pues, Binding parte de la idea de que la mejor manera de enseñar a leer es entrenar lo que se ha comprobado científicamente que es importante a la hora de adquirir la lectura - decodificación, memoria de trabajo, morfología, léxico −. Los resultados extraídos los últimos años de la aplicación del Binding así lo avalan.
15.2 Informática En informática, un binding es una “ligadura”o referencia a otro símbolo más largo y complicado, y que se usa frecuentemente. Este otro símbolo puede ser un valor de cualquier tipo, numérico, de cadena, etc o el nombre de una variable que contiene un valor o un conjunto de valores. En el campo de la programación, un binding es una adaptación de una biblioteca para ser usada en un lenguaje de programación distinto de aquél en el que ha sido escrita.
15.3 Derecho mercantil En Derecho mercantil, cuando un contrato es “binding” indica que el mismo es vinculante, debiendo estar firmado y no forzar ninguna norma superior. 32
• http://www.binding.es - Información sobre el programa 'Binding'
Capítulo 16
Bloqueo mutuo En sistemas operativos, el bloqueo mutuo (también conocido como interbloqueo, traba mortal, deadlock, abrazo mortal) es el bloqueo permanente de un conjunto de procesos o hilos de ejecución en un sistema concurrente que compiten por recursos del sistema o bien se comunican entre ellos. A diferencia de otros problemas de concurrencia de procesos, no existe una solución general para los interbloqueos.
A
R1
Todos los interbloqueos surgen de necesidades que no pueden ser satisfechas, por parte de dos o más procesos. En la vida real, un ejemplo puede ser el de dos niños que intentan jugar al arco y flecha, uno toma el arco, el otro la flecha. Ninguno puede jugar hasta que alguno libere lo que tomó. En el siguiente ejemplo, dos procesos compiten por dos recursos que necesitan para funcionar, que sólo pueden ser utilizados por un proceso a la vez. El primer proceso obtiene el permiso de utilizar uno de los recursos (adquiere el lock sobre ese recurso). El segundo proceso toma el lock del otro recurso, y luego intenta utilizar el recurso ya utilizado por el primer proceso, por lo tanto queda en espera. Cuando el primer proceso a su vez intenta utilizar el otro recurso, se produce un interbloqueo, donde los dos procesos esperan la liberación del recurso que utiliza el otro proceso.
16.1 Representación de Bloqueos Mutuos usando grafos
R2 B
Ejemplo de representación de Bloqueo Mutuo en grafos de alocación de recursos con dos procesos A y B, y dos recursos R1 y R2.
16.2 Condiciones necesarias También conocidas como condiciones de Coffman por su primera descripción en 1971 en un artículo escrito por E. G. Coffman. Estas condiciones deben cumplirse simultáneamente y no son totalmente independientes entre ellas. Sean los procesos P0 , P1 , ..., Pn y los recursos R0 , R1 , ..., Rm :
El Bloqueo mutuo también puede ser representado usando grafos dirigidos, donde el proceso es representado por un cuadrado y el recurso, por un círculo. Cuando un proceso solicita un recurso, una flecha es dirigida del círculo al cuadrado. Cuando un recurso es asignado a un proceso, una flecha es dirigida del cuadrado al círculo. En la figura del ejemplo, se pueden ver dos procesos diferentes (A y B), cada uno con un recurso diferente asignado (R1 y R2). En este ejemplo clásico de bloqueo mutuo, es fácilmente visible la condición de espera circular en la que los procesos se encuentran, donde cada uno solicita un recurso que está asignado a otro proceso. 33
• Condición de exclusión mutua: existencia de al menos de un recurso compartido por los procesos, al cual sólo puede acceder uno simultáneamente. • Condición de retención y espera: al menos un proceso Pi ha adquirido un recurso Ri , y lo retiene mientras espera al menos un recurso Rj que ya ha sido asignado a otro proceso. • Condición de no expropiación: los recursos no pueden ser expropiados por los procesos, es decir, los recursos sólo podrán ser liberados voluntariamente por sus propietarios.
34 • Condición de espera circular: dado el conjunto de procesos P0 ...Pm (subconjunto del total de procesos original),P0 está esperando un recurso adquirido por P1 , que está esperando un recurso adquirido por P2 ,... ,que está esperando un recurso adquirido por Pm , que está esperando un recurso adquirido por P0 . Esta condición implica la condición de retención y espera.
CAPÍTULO 16. BLOQUEO MUTUO • La condición de espera circular es la más fácil de atacar. Se le permite a un proceso poseer sólo un recurso en un determinado momento, o una jerarquía puede ser impuesta de modo tal que los ciclos de espera no sean posibles.
16.5 Livelock
Un livelock es similar a un deadlock, excepto que el estado de los dos procesos envueltos en el livelock constantemente cambia con respecto al otro. Livelock es una forma de Los bloqueos mutuos pueden ser evitados si se sabe cier- inanición y la definición general sólo dice que un proceso ta información sobre los procesos antes de la asignación específico no está procesando. de recursos. Para cada petición de recursos, el sistema En un ejemplo del mundo real, un livelock ocurre por controla si satisfaciendo el pedido entra en un estado inejemplo cuando dos personas, al encontrarse en un paseguro, donde puede producirse un bloqueo mutuo. De sillo angosto avanzando en sentidos opuestos, y cada una esta forma, el sistema satisface los pedidos de recursos trata de ser amable moviéndose a un lado para dejar a solamente si se asegura que quedará en un estado seguro. la otra persona pasar, pero terminan moviéndose de lado Para que el sistema sea capaz de decidir si el siguiente a lado sin tener ningún progreso, pues ambos se mueven estado será seguro o inseguro, debe saber por adelantahacia el mismo lado, al mismo tiempo. do y en cualquier momento el número y tipo de todos los recursos en existencia, disponibles y requeridos. Existen Livelock es un riesgo con algunos algoritmos que detectan y recuperan los interbloqueos, pues si más de uno tovarios algoritmos para evitar bloqueos mutuos: ma cartas en el asunto, la detección del interbloqueo puede ser disparada continuamente; pudiendo ser arreglado • Algoritmo del banquero, introducido por Dijkstra. asegurándose que sólo un proceso (escogido al azar o por • Algoritmo de grafo de asignación de recursos. prioridad) tome acción. • Algoritmo de Seguridad.
16.3 Evitando bloqueos mutuos
• Algoritmo de solicitud de recursos.
16.4 Prevención Los bloqueos mutuos pueden prevenirse asegurando que no suceda alguna de las condiciones necesarias vistas anteriormente. • Eliminando la exclusión mutua: ningún proceso puede tener acceso exclusivo a un recurso. Esto es imposible para procesos que no pueden ser encolados (puestos en un spool), e incluso con colas también pueden ocurrir interbloqueos. • La condición de posesión y espera puede ser eliminada haciendo que los procesos pidan todos los recursos que van a necesitar antes de empezar. Este conocimiento por adelantado muchas veces es imposible nuevamente. Otra forma es requerir a los procesos liberar todos sus recursos antes de pedir todos los recursos que necesitan. Esto también es poco práctico en general. • La condición de no expropiación puede ser también imposible de eliminar dado que un proceso debe poder tener un recurso por un cierto tiempo o el procesamiento puede quedar inconsistente.
Capítulo 17
Bodyshopping Bodyshopping es un término ligado al mundo empresarial informático o tecnológico que hace referencia a la venta de capital humano. Conlleva la cesión de personal de este tipo a terceras empresas con ánimo de lucro. Término que proviene del inglés que podríamos definir como anglicismo o extranjerismo y que en su traducción literal hace referencia a la compra de cuerpos. Una forma castiza de denominar estas empresas es charcuteras o cárnicas. Esta práctica es muy habitual en el mundo de la consultoría informática y existen multitud de empresas que basan su negocio en esta "venta" de personal actuando prácticamente como empresas de trabajo temporal orientadas a la tecnología. En ocasiones ciertas compañías que tienen esta práctica como núcleo de su negocio, fundamentan sus ingresos en la contratación de este personal, normalmente con poca experiencia y bajo salario, con contratos temporales o por obra, quienes posteriormente son revendidos a terceras empresas como profesionales altamente cualificados y con una gran experiencia, siendo ésta única y exclusivamente la base de su negocio y de su Retorno de la inversión, ya que a menos experiencia y salario del personal, mayor beneficio por las altas tarifas cobradas. La legislación española expone claramente en su Estatuto de los Trabajadores (Artículo 43. Cesión de trabajadores.) que el bodyshopping es ilegal.
17.1 Enlaces externos • Trabajo Basura Directorio con estas empresas y experiencias personales de gente que ha trabajado en ellas. • Trabajungla Experiencias personales y salarios sobre estas empresas revelados de forma anónima. • El Informático Impasible: Outsourcing: OnShore y OffShore • El Sector de la Consultoría Informática en España « Peccata Minuta • Entendiendo el Bodyshopping « Peccata Minuta 35
• Las consultoras informáticas :: LinuxAdicto.org • Podcast monográfico sobre consultoría
Capítulo 18
BrookGPU BrookGPU fue desarrollado por la Universidad de Stanford, es un grupo de compiladores y aplicaciones basadas en el lenguaje Brook para utilizar con unidades de procesamiento gráfico (GPU). la programación con unidades GPU es continuamente abreviada con el nombre de General-purpose computing on graphics processing units (GPGPU). Para usar este programa es necesario una unidad de procesamiento gráfico (GPU) tipo ATI, NVIDIA o Gráficos integrados Intel, capaces de soportar gran paralelismo. BrookGPU compila programas escritos en Brook, una extensión de ANSI C diseñado para incorporar computación de datos paralelos y aritméticos con un eficaz y familiar lenguaje. respecto al modelo general de programación, por flujo de datos tipo por Stream, ofrece 2 grandes ventajas respecto a estos: • Paralelismo de datos: permite al programador especificar cómo realizar las mismas operaciones en paralelo sobre diferentes datos. • Intensidad aritmética: le da a los programadores el poder para minimizar la comunicación global de las operaciones y maximizar la comunicación local de las mismas Muchos de los progresos en este lenguaje se han visto en el proyecto de computación distributiva Folding@home, además con el fin de expandir las nuevas técnicas GPGPU, viene bajo licencia GPL, y así abrir las puertas a nuevos programadores de Direct3D, OpenGL o hasta Close to Metal sin dejar los detalles implementados en estos dichos lenguajes.* [cita requerida]
36
Capítulo 19
Caja blanca (sistemas) En programación, se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. Así como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del módulo, las de caja blanca están dirigidas a las funciones internas. Entre las técnicas usadas se encuentran; la cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecución), pruebas sobre las expresiones lógico-aritméticas, pruebas de camino de datos (definición-uso de variables), comprobación de bucles (se verifican los bucles para 0,1 e interacciones, y luego para las interacciones máximas, máximas menos uno y más uno). Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo concreto, para luego realizar las de caja negra sobre varios subsistemas (integración). En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a los métodos de la clase, pero según varias opiniones, ese esfuerzo debería dedicarse a otro tipo de pruebas más especializadas (un argumento podría ser que los métodos de una clase suelen ser menos complejos que los de una función de programación estructurada). Dentro de las Pruebas de Caja Blanca encontramos las llamadas coberturas (sentencia, decisión, condición y múltiple además de los mencionados caminos ciclomáticos propuestos por McCabe) Este concepto también es utilizado de manera análoga en la teoría general de sistemas.
19.1 Véase también • Pruebas de software • Pruebas de caja blanca • Pruebas de caja negra •
37
Capítulo 20
Caja negra (sistemas) deberá conocer como es la comunicación con los otros módulos (la interfaz), pero no necesitará conocer como trabajan esos otros módulos internamente; en otras palabras, para el desarrollador de un módulo, idealmente, el resto de módulos serán cajas negras. Esquema de una caja negra
En teoría de sistemas y física, se denomina Caja Negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.
20.1 Justificación Un sistema formado por módulos que cumplan las características de caja negra será más fácil de entender ya que permitirá dar una visión más clara del conjunto. El sistema también será más robusto y fácil de mantener, en caso de ocurrir un fallo, éste podrá ser aislado y abordado más ágilmente.
20.2 Caja negra y programación modular
20.3 Pruebas de software En pruebas de software, conociendo una función específica para la que fue diseñado el producto, se pueden diseñar pruebas que demuestren que dicha función está bien realizada. Dichas pruebas son llevadas a cabo sobre la interfaz del software, es decir, de la función, actuando sobre ella como una caja negra, proporcionando unas entradas y estudiando las salidas para ver si concuerdan con las esperadas.
20.4 Caja negra vs 'Cajanegrizar' Este concepto de caja negra utilizado en física, informática y disciplinas técnicas o tecnológicas en general, aunque está relacionado, no debe confundirse con el 'Cajanegrismo'; éste es un concepto más vinculado a la sociología que hace referencia al hecho de que las personas solemos olvidarnos del funcionamiento interno de las cosas (generalmente nuevos dispositivos tecnológicos) a medida que nos familiarizamos con ellos y terminamos por asimilarlos como de uso cotidiano. A este proceso de olvidar el funcionamiento interno de las cosas se le conoce con el nombre de 'cajanegrizar'.
Se podría decir que la principal diferencia entre ambos conceptos es que mientras el primero, el estudio de un sistema como una caja negra, es un proceso de abstracción, En programación modular, donde un programa (o un el segundo, el 'cajanegrismo', es más bien un proceso de algoritmo) es dividido en módulos, en la fase de diseño se olvido. buscará que cada módulo sea una caja negra dentro del sistema global que es el programa que se pretende desarrollar, de esta manera se consigue una independencia en- 20.5 Véase también tre los módulos que facilita su implementación separada por un equipo de trabajo donde cada miembro va a en• Teoría de sistemas cargarse de implementar una parte (un módulo) del pro• Modularidad grama global; el implementador de un módulo concreto 38
20.5. VÉASE TAMBIÉN • Interfaz • Interfaz de usuario • Diseño estructurado • Caja blanca (sistemas) • Abstracto y Abstracción • Cajanegrizar
39
Capítulo 21
CamelCase • En nombres de empresas tales como • BellSouth • CompuServe • LinuxCabal • Microsoft, antiguamente MicroSoft
Ejemplo de CamelCase en un indicador.
• PriceWaterhouseCoopers
CamelCase es un estilo de escritura que se aplica a frases o palabras compuestas. El nombre se debe a que las mayúsculas a lo largo de una palabra en CamelCase se asemejan a las jorobas de un camello. El nombre CamelCase se podría traducir como Mayúsculas/Minúsculas Camello. El término case se traduce como“caja tipográfica”, que a su vez implica si una letra es mayúscula o minúscula y tiene su origen en la disposición de los tipos móviles en casilleros o cajas. Existen dos tipos de CamelCase:
• OmegaSoft • VaxaSoftware • La Sexta • eDreams • En algunos hashtag
21.2 Enlaces externos
• UpperCamelCase, cuando la primera letra de cada una de las palabras es mayúscula. Ejemplo: EjemploDeUpperCamelCase. • lowerCamelCase, igual que la anterior con la excepción de que la primera letra es minúscula. Ejemplo: ejemploDeLowerCamelCase.
21.1 Usos • En varios lenguajes de programación • Java • .NET • C • C++ • Python • C# • Objective-C • ActionScript • PHP • En las primeras herramientas wiki 40
• Primer wiki, creado por Ward Cunningham • Caja alta y baja en el DRAE.
Capítulo 22
Caml Caml (Originalmente un acrónimo para Categorical let rec fact = function | 0 -> 1 | n -> n * fact(n - 1);; Abstract Machine Language, en español Lenguaje Máquina Abstracto Categórico) es un dialecto de lafamilia de Esta última forma es la definición matemática de factorial losmeta lenguajes, desarrollado en INRIA y anteriormen- como una relación de recurrencia. te en ENS. Note que el compilador infirió el tipo de esta función para Como muchos descendientes delML, Caml es un len- ser int -> int, significa que esta función mapea enteros a guaje de tipado estático, evaluación estricta, y utiliza enteros. Por ejemplo, 12! Es: administración de memoria automática. # fact 12;; - : int = 479001600 La primera implementación de Caml en Lisp fue apodada “CAML pesado”debido a los requisitos de memoria y CPU relativos a su sucesor “Caml Light”, aquello fue implementado en C por Xavier Leroy y Damien Doligez. Además de una reescritura completa, “CAML Special 22.1.3 Derivación numérica (funciones de Light”añadió un potente sistema de módulos al núcleo alto orden) del lenguaje. Actualmente, la implementación principal de Caml es Desde que OCaml es un lenguaje de programación funOCaml, el cual añade muchas características nuevas al cional, es fácil crear y repasar funciones en programas de lenguaje, entre ellas una capa de objeto. OCaml. Esta capacidad tiene un número enorme de aplicaciones. Calcular la derivada numérica de una función es una de ellas. La funciónd en Caml computa la derivada 22.1 Ejemplos numérica de una función dada f en un punto dado x: Lo siguiente, # representa el prompt de OCaml.
22.1.1
Hola Mundo
print_endline “Hello World!";;
let d delta f x = (f (x +. delta) −. f (x −. delta)) /. (2. *. delta);; Esta función requiere un valor infinitesimal delta. Una buena elección para delta es la raíz cúbica del épsilon de la máquina.
El tipo de la función d indica que ésta mapea un tipo de dato flotante a otra función del mismo tipo (float -> float) -> float -> float. Esto nos permite aplicar argumen22.1.2 Función factorial (recursividad y tos parcialmente. Este estilo funcional es conocido como programación puramente funcio- currificación. En este caso, es útil al aplicar parcialmente el primer argumento delta a d, para obtener una función nal) más especializada: Muchas funciones matemáticas, como el factorial, son re- # let d = d (sqrt epsilon_float);; val d : (float -> float) -> presentadas más naturalmente en una forma puramente float -> float = funcional. La siguiente función recursiva, puramente funcional implementa la operación factorial en Caml: Note que el tipo inferido indica que la sustitución d espelet rec fact n = if n=0 then 1 else n * fact(n - 1);; ra una función del tipo flotante float -> float como primer argumento. Podemos computar una aproximación numéLa función puede ser escrita equivalentemente utilizando rica a la derivada de la función x3 − x − 1 en el punto patrones de emparejamiento: x = 3 con: 41
42
CAPÍTULO 22. CAML
# d (fun x -> x *. x *. x −. x −. 1.) 3.;; - : float = 26.
ciation of Computer Machinery.
La respuesta correcta es: f ′ (x) = 3x2 − 1 → f ′ (3) = 27 − 1 = 26
22.4 Enlaces externos
La función d se denomina “función de alto orden”ya que acepta otra función (f) como argumento.
• [Repositorio de Caml en Github]
• [Sitio oficial de Caml] Los conceptos de funciones currificadas y de alto orden son útiles evidentemente en programas matemáticos. De • [Tutoriales de caml (inglés)] hecho, estos conceptos son igualmente aplicables a otras formas de programación y pueden ser empleados en código de factor mucho más agresivamente, resultando epro- 22.4.1 Libros gramas más cortos y con menos errores. • The Functional Approach to Programming with Caml by Guy Cousineau and Michel Mauny.
22.1.4
Transformada Wavelet discreta (concordancia de patrones)
La transformada Wavelet de Haarde de una lista de números enteros de potencia en base dos puede ser implementada muy sucintamente en Caml y es un ejemplo excelente del uso de la concordancia de patrones sobre listas, tomando pares de elementos (h1 y h2) del frente y almacenando sus sumas y diferencias en las listas s y d, respectivamente: # let haar l = let rec aux l s d = match l, s, d with [s], [], d -> s :: d | [], s, d -> aux s [] d | h1 :: h2 :: t, s, d -> aux t (h1 + h2 :: s) (h1 - h2 :: d) | _ -> invalid_arg “haar”in aux l [] [];; val haar : int list -> int list = Por ejemplo: # haar [1; 2; 3; 4; −4; −3; −2; −1];; - : int list = [0; 20; 4; 4; −1; −1; −1; −1] El patrón de emparejamiento permite transformaciones complicadas para ser representadas claramente y sucintamente (brevemente). Además, el compilador de OCaml realiza concordancia de patrones en un código muy eficaz, el tiempo en el que los programas arrojan resultados es más corto y más rápido que el código equivalente escrito con una estructura "switch-case" (Cardelli 1984, p. 210.).
22.2 Véase también • OCaml • ML • F#
22.3 Referencias Cardelli, Luca (1984). Compiling a functional language ACM simposio en LISP y programación funcional, Asso-
Capítulo 23
Cierre de exclusión mutua En ciencias de la computación, los cierres de exclusión Estas son: mutua o candados son un mecanismo de sincronización que limita el acceso a un recurso compartido por varios • Sólo el dueño de un cerrojo puede desbloquearlo procesos o hilos en un ambiente de ejecución concurrente, • La readquisición de un cerrojo no está permitida permitiendo así la exclusión mutua. Cuando un elemento es compartido por más de un hilo, pueden ocurrir condiciones de carrera si el mismo no es protegido adecuadamente. El mecanismo más simple para la protección es el cierre o cerrojo. En general cuando debe protegerse un conjunto de elementos, se le asocia un cerrojo. Cada proceso/hilo para tener acceso a un elemento del conjunto, deberá bloquear, con lo que se convierte en su dueño. Esa es la única forma de ganar acceso. Al terminar de usarlo, el dueño debe desbloquear, para permitir que otro proceso/hilo pueda tomarlo a su vez. Es posible que mientras un proceso/hilo esté accediendo a un recurso (siendo por lo tanto dueño del cerrojo), otro proceso/hilo intente acceder. Esta acción debe esperar hasta que el cerrojo se encuentre libre, para garantizar la exclusión mutua. El proceso/hilo solicitante queda entonces en espera o pasa a estado de bloqueo según el algoritmo implementado. Cuando el dueño del cerrojo lo desbloquea puede tomarlo alguno de los procesos/hilos que esperaban. Este mecanismo se puede ver en un ejemplo de la vida real. Supongamos un baño público, donde sólo puede entrar una persona a la vez. Una vez dentro, se emplea un cierre para evitar que entren otras personas. Si otra persona pretende usar el baño cuando está ocupado, deberá quedar esperando a que la persona que entró anteriormente termine. Si más personas llegaran, formarían una cola (del tipo FIFO) y esperarían su turno. En informática, el programador no debe asumir este tipo de comportamiento en la cola de espera.
Algo muy importante es que todos los procesos/hilos deben utilizar el mismo protocolo para bloquear y desbloquear los cerrojos en el acceso a los recursos, ya que si mientras dos procesos/hilos utilizan el cerrojo de forma correcta, existe otro que simplemente accede a los datos protegidos, no se garantiza la exclusión mutua y pueden darse condiciones de carrera y errores en los resultados.
23.1 Primitivas y uso Las funciones de los cerrojos en general son tres: init(), lock() y unlock(). El cerrojo se inicializa con la función init(). Luego cada proceso/hilo debe llamar a la función lock() antes de acceder a los datos protegidos por el cierre. Al finalizar su sección crítica, el dueño del cerrojo debe desbloquearlo mediante la función unlock().
23.2 Bloqueos en bases de datos Los sistemas gestores de bases de datos suelen utilizar bloqueos para evitar problemas de concurrencia y, en ocasiones, garantizar la serializabilidad de las transacciones. Para hacerlo adecuadamente, los mecanismos de bloqueo suelen implementar protocolos como el bloqueo de dos fases y utilizar registros transaccionales (logs) como apoyo.
El cerrojo, usado de esta manera, forma una sección crítica en cada proceso/hilo, desde que es tomado hasta que se libera. En el ejemplo del baño, dentro de la sección crítica se encuentran las funciones que se realizan generalmente dentro de este tipo de instalaciones sanitarias. Como garantizan la exclusión mutua, muchas veces se los denomina mutex (por mutual exclusion). En general hay un número de restricciones sobre los cerrojos, aunque no son las mismas en todos los sistemas.
43
Capítulo 24
Clase utilidad En programación, una clase utilidad es una clase que define un conjunto de métodos que realizan funciones, normalmente muy reutilizadas. La mayoría de las clases utilidad definen estos métodos comunes con alcance estático. Ejemplos de clases utilidad incluyen java.util.Collections que proveen muchos métodos estáticos (tales como ordenar) en objetos que implementan una Collection (java.util.collection ).
24.1 Enlaces externos • Utility Pattern: Para una clase utilidad, que no requiere instanciación y sólo tiene métodos estáticos, se debe usar un constructor privado.
44
Capítulo 25
Clear.gif El lenguaje HTML para desarrollar páginas web no permite el alineamiento arbitrario de los objetos dentro del documento. Cuando Internet no se encontraba tan desarrollado, y prácticamente el HTML era lo único con lo que se contaba para mostrar contenidos, un truco que los desarrolladores utilizaban para poder alinear los textos a la altura y anchura que se desearan dentro de la página, era crear un archivo transparente de un píxel de tamaño y en formato gráfico GIF, que en aquel entonces era el único que permitía manejar transparencia en las imágenes. El archivo era manipulado dentro del código de la página web para que apareciera con cierta alineación, ya que las imágenes si permitían la alineación, pero no el texto. La transparencia era importante, pues permitía que la imagen no apareciera dentro de la visualización de la página web. El archivo era usualmente llamado clear.gif, aunque cualquier desarrollador que hiciera la imagen podía crearla con el nombre que quisiera. El nombre de dicho archivo dio lugar al de la técnica. La manera sencilla en la que se hace trabajar este truco en el código HTML es la siguiente:
vspace=y
Donde x y y son las coordenadas de espaciado horizontal y vertical que se desean, y el atributo SRC señala la ruta hacia el archivo clear.gif. El texto que se escriba a continuación de ese fragmento de código, se alineará a la altura y anchura indicada en la etiqueta.
45
Capítulo 26
CMake CMake es una herramienta multiplataforma de generación o automatización de código. El nombre es una abreviatura para“cross platform make”(make multiplataforma); más allá del uso de “make”en el nombre, CMake es una suite separada y de más alto nivel que el sistema make común de Unix, siendo similar a las autotools. CMake es una familia de herramientas diseñada para construir, probar y empaquetar software. CMake se utiliza para controlar el proceso de compilación del software usando ficheros de configuración sencillos e independientes de la plataforma. Cmake genera makefiles nativos y espacios de trabajo que pueden usarse en el entorno de desarrollo deseado. Es comparable al GNU build system de Unix en que el proceso es controlado por ficheros de configuración, en el caso de CMake llamados CMakeLists.txt. Al contrario que el GNU build system, que está restringido a plataformas Unix, CMake soporta la generación de ficheros para varios sistemas operativos, lo que facilita el mantenimiento y elimina la necesidad de tener varios conjuntos de ficheros para cada plataforma.
el Visualization Toolkit (VTK), un sistema para gráficos 3D y visualización libres. Para crear CMake, Bill Hoffman en Kitware incorporó algunas ideas de pcmaker, y añadió más cosas propias, con el pensamiento de adoptar algunas de las funcionalidades del GNU build system. La implementación inicial de CMake tuvo lugar a mediados del 2000, con un desarrollo acelerado a comienzos del 2001. Muchas mejoras se debieron a influencias de otros desarrolladores a la hora de incorporar CMake a sus propios sistemas. Por ejemplo, la comunidad de VXL adoptó CMake, contribuyendo con muchas características esenciales. Brad King añadió varias características para dar soporte a CABLE y GCC-XML, un juego de herramientas de envoltura automáticas; y GE Corporate R&D necesitaba soporte para su infraestructura de pruebas (DART). Otras funcionalidades se añadieron para soportar la transición de VTK's a CMake, y soportar ParaView, un sistema de visualización paralela para el Advanced Computing Lab en Los Alamos National Laboratory.
El proceso de construcción se controla creando uno o más ficheros CMakeLists.txt en cada directorio (incluyendo subdirectorios). Cada CMakeLists.txt consiste en uno o 26.2 Documentación y tutoriales más comandos. Cada comando tiene la forma COMANDO (argumentos...) donde COMANDO es el nombre del Aparte de la documentación oficial de CMake, existe un comando, y argumentos es una lista de argumentos sepa- libro titulado Mastering CMake, publicado por Kitware. rados por espacios. CMake provee comandos predefinidos y definidos por el usuario. Existen generadores makefile para Unix, Borland make, Watcom make, MinGW, MSYS y Microsoft NMake. También es posible generar 26.3 Principales funcionalidades ficheros de proyecto para Code::Blocks, Eclipse CDT, Microsoft Visual Studio de la 6 a la 10 incluyendo ver• Ficheros de configuración escritos en un lenguaje de siones de 64 bits y KDevelop. scripting específico para CMake • Análisis automático de dependencias para C, C++, Fortran, y Java
26.1 Historia CMake se creó en respuesta a la necesidad de disponer de un entorno multiplataforma apropiado de construcción para el Insight Segmentation and Registration Toolkit (ITK) creado por la United States National Library of Medicine como parte del Visible Human Project. Fue influenciado por un sistema anterior llamado pcmaker creado por Ken Martin y otros desarrolladores para soportar 46
• Soporte para SWIG, Qt, FLTK, a través del lenguaje de scripting de CMake • Soporte para varias versiones de Microsoft Visual Studio, incluyendo la 6, 7, 7.1, 8.0, 9.0 y 10.0 • Genera ficheros para Eclipse CDT (C/C++ Development Tools)
26.6. VÉASE TAMBIÉN
47
• Detección de cambios en ficheros usando timestamps tradicionales
26.6 Véase también
• Soporte para builds paralelos
• Automake
• Compilador cruzado
• Autoconf
• Vista global de todas las dependencias, usando CMake para generar un diagrama graphviz
• premake
• Soporte para builds multiplataforma • Linux y otros sistemas POSIX (incluyendo AIX, *BSD, HP-UX, IRIX/SGI, y Solaris) • Mac OS X • Windows 95/98/NT/2000/XP, Windows Vista, Windows 7 y MinGW/MSYS • Integrado con DART (software), CDash, CTest y CPack, una colección de herramientas para prueba y liberación de software
• SCons • VTK • Waf
26.7 Enlaces externos • CMake • CMake Wiki • Documentación
26.4 CTest, CPack, CDash
• Listas de correo
Kitware desarrolló estas herramientas en colaboración con muchos otros. Incluyen CMake, CTest, CPack y CDash. CPack es una utilidad de empaquetamiento y despliegue. CTest es un cliente de pruebas libre.
26.5 Aplicaciones CMake • Avidemux • Compiz • Kicad • KVIrc • LMMS • MiKTeX • MuseScore • MySQL • OpenCV • Poppler • PvPGN • Quantum GIS • Scribus • Second Life • SuperTux • OGRE 3D • Ryzom
que
utilizan
Capítulo 27
Codecademy Codecademy es una plataforma interactiva en línea que ofrece clases gratuitas de codificación en lenguajes de programación como Python, PHP, JavaScript, y Ruby, así como lenguajes de marcado incluyendo HTML y CSS* [2]* [3] y también uso de API's. A partir de septiembre del 2011, el sitio ha tenido más de 550,000 usuarios que han completado más de seis millones de ejercicios.* [4]* [5] El sitio ha recibido críticas positivas de varios blogs y sitios web, incluyendo el New York Times* [6] y TechCrunch.* [7]
para aprender como programar, mediante la introducción de un nuevo curso cada semana en el 2012.* [12] Más de 450,000 personas tomaron el curso en el 2012,* [13]* [14] y Codecademy continua ofertando el programa en el 2013.
27.3 Véase también • Academic Earth
Para motivar a los usuarios a participar el sitio cuenta con un sistema de gamificación por el que ofrece insignias o medallas al completar ejercicios, cuenta con foros de discusión y un glosario por curso, y mantiene un registro de la puntuación total del usuario y la muestra a los demás. El sitio también permite que cualquier persona pueda crear y publicar un nuevo curso usando la herramienta de creación de cursos.
• Coursera • Dev Bootcamp • edX • Gilles Babinet • Khan Academy • lynda.com
27.1 Historia
• Marginal Revolution University Codecademy fue fundada en 2011 por Zach Sims y Ryan Bubinski.* [8] Sims dejó la universidad Columbia University para centrarse en el lanzamiento de una empresa, mientras que Bubinski se graduó en Columbia con una licenciatura en ciencias de la computación y biofísica.* [9] La compañía actualmente se encuentra en Nueva York. Obtuvo 2,5 millones de dólares en su primera ronda de financiación en octubre de 2011 y 10 millones en la segunda serie en junio de 2012.* [8]* [10] La última ronda de financiación fue llevada a cabo por Index Ventures.* [11]
• Udacity • Udemy
27.4 Referencias
Finalmente en el año 2014, la empresa Codecademy decide vender publicidad, comenzando con brindar un banner al gobierno de la ciudad de buenos aires.
27.2 Code Year Code Year es un programa gratuito de Codecademy para cualquiera que este interesado en aprender como programar. El programa tiene la intención de ayudar a las personas a seguir a través de un New Year's Resolution 48
[1] «Codecademy.com Site Info». Alexa Internet. Consultado el 18 de Septiembre de 2015. [2] «Codecademy». Codecademy. Consultado el 4 de agosto de 2012. [3] Indvik, Lauren. «Codeacademy Releases Free Ruby Development Courses». Mashable. Mashable. Consultado el 30 de diciembre de 2012. [4] Frier, Sarah. «Codecademy Raises $10M, Sees Job Service as Part of Its Future». Consultado el 19 de junio de 2012. [5] Kafka, Peter. «Codecademy Rounds Up $10 Million for Web Lessons». Consultado el 19 de junio de 2012.
27.5. ENLACES EXTERNOS
[6] Wortham, Jenna. «Codecademy Offers Free Coding Classes for Aspiring Entrepreneurs». The New York Times. Consultado el 26 de julio de 2012. [7] Cincaid, Jason. «Codecademy Surges To 200,000 Users, 2.1 Million Lessons Completed In 72 Hours». TechCrunch. Consultado el 26 de julio de 2012. [8] «30 Under 30: Zach Sims and Ryan Bubinski, Codecademy». Inc.com. 2 de julio de 2012. Consultado el 13 de agosto de 2012. [9] Segall, Laurie (29 de noviembre de 2011). «Codecademy says it can turn anyone into a Web programmer - Nov. 29, 2011». Money.cnn.com. Consultado el 13 de agosto de 2012. [10] Wortham, Jenna (27 de octubre de 2011). «Codecademy Lands $2.5 Million From Investors - NYTimes.com». Bits.blogs.nytimes.com. Consultado el 13 de agosto de 2012. [11] Colao, JJ (19 de junio de 2012). «Codecademy Raises $10 Million To Conquer The World». Forbes.com. [12] Segall, Laurie (6 de enero de 2012). «Code Year draws 200,000 aspiring programmers - Jan. 6, 2012». Money.cnn.com. Consultado el 16 de febrero de 2013. [13] «Learning JavaScript With Code Year " Feld Thoughts Feld Thoughts». Feld.com. Consultado el 16 de febrero de 2013. [14] Codecademy. «Code Year». Code Year. Consultado el 16 de febrero de 2013.
27.5 Enlaces externos • Sitio Web de Codecademy
49
Capítulo 28
Código cerrado En informática un programa es de código cerrado cuando el código fuente no se encuentra disponible para cualquier usuario, es decir no se hace público. Se le llama así en contraposición al código abierto. El software no libre generalmente utiliza un código cerrado. Por su calidad de secreto industrial, su divulgación podría ser constituyente de delito en algunos países.
28.1 Véase también • Software privativo
50
Capítulo 29
Código compilado Un código compilado es un código que previamente fue un código simbólico interpretable por un compilador, y luego ese compilador lo convirtió en un código directamente interpretable por un controlador (Código máquina).
51
Capítulo 30
Código mutante En informática, el término código mutante o código ambiguo se emplea para referirse a un código cuya integridad es modificada por sí mismo durante su ejecución, generalmente este código trata de un malware por el hecho de que si como algoritmo (cuando es ejecutado) se automodifica como información (donde está almacenado) fácilmente puede engañar a un programa del tipo antivirus o similar. Aunque de todas maneras, ciertos programas Antivirus son capaces de detectar este tipo de modificaciones.
52
Capítulo 31
Código objeto En programación, se llama código objeto al código que con parámetros incorrectos o inexistentes puede generar resulta de la compilación del código fuente.* [1] un error que generalmente el compilador no detecta ya Consiste en lenguaje máquina o bytecode y se distribuye que el código objeto no es verificado, únicamente unien varios archivos que corresponden a cada código fuente do. Este tipo de error se puede solucionar reescribiendo compilado. Para obtener un programa ejecutable se han el código de manera correcta y re compilarlo a código objeto. de enlazar todos los archivos de código objeto con un programa llamado enlazador (linker).
31.3 Referencias [1] http://www.alegsa.com.ar/Dic/codigo%20objeto.php
31.4 Enlaces externos • Fases en la realizazión de software
31.1 Código objeto en lenguajes de programación Un claro ejemplo de lenguaje de programación que usa código objeto en sus librerías es Pauscal. Esto le permite aumentar la velocidad de compilación de los programas y reducir su tamaño (ya que cada librería objeto puede ser comprimida), también permite a programadores compartir sus librerías/funciones sin tener la necesidad de liberar sus códigos fuentes originales. Incluso puede permitir a distintos lenguajes de programación compartir funciones sin necesidad de tener que reescribir el código plano a sus respectivas sintaxis.
Wikcionario tiene definiciones y otra información sobre código objeto.Wikcionario
el código objeto es el resultado de la compilación del código fuente. Puede ser en lenguaje máquina o bytecode, y puede distribuirse en varios archivos que corresponden a cada código fuente compilado. Luego un enlazador (linker) se encarga de juntar todos los archivos de código objeto para obtener el programa ejecutable. - See more at: http://www.alegsa.com.ar/Dic/codigo%20objeto. php#sthash.ktzQpZxJ.dpuf Código objeto: Conjunto de instrucciones y datos escritos en un lenguaje que entiende el ordenador directamente: binario o código máquina. Provienen de la traducción de cierto código fuente, es un fragmento del programa final y es específico de la plataforma de ejecución.
31.2 Errores comunes Los código objeto pueden ser muy útiles en muchas situaciones sin embargo consigo traen problemas que pueden generar errores muy difíciles de corregir, por ejemplo cuando un objeto importa funciones de otro código objeto que ha sido modificado, el intento de la librería o el programa que importó la librería de ejecutar el código 53
Capítulo 32
Ofuscación La ofuscación se refiere a encubrir el significado de una 32.1.1 Ejemplos comunicación haciéndola más confusa y complicada de interpretar. Un ejemplo simple de ofuscación es llamar a las variables o funciones con palabras reservadas del lenguaje añadiendo algún símbolo int int_;
32.1 Informática
Con esta línea se define una variable de tipo entero. En computación, la ofuscación se refiere al acto delibe- long int _int(int int_){return int_-int_}; rado de realizar un cambio no destructivo, ya sea en el código fuente de un programa informático o código máquina cuando el programa está en forma compilada o bi- Con esta línea definimos una función con un parámetro entero que devuelve un valor long int, que por otra parte naria, con el fin de que no sea fácil de entender o leer. siempre será 0. En Internet, la ofuscación refiere a crear una publicación _int-_int; o formar parte del grupo los Ofuscados. El código ofuscado es aquél código que, aunque se tiene el código fuente, ha sido enrevesado específicamente para Esto equivale a poner 0. ocultar su funcionalidad (hacerlo ininteligible). (_int-_int)!; La ofuscación binaria se realiza habitualmente para impedir o hacer más difícil los intentos de ingeniería inversa Esto equivale a poner 1. y desensamblado que tienen la intención de obtener una (((!(int_-int_)
View more...
Comments
