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.∧ Programación e ingeniería del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.∨ Referencias históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.∩ Objetivos de la programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.∪ 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
3.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨
3.2 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩
3.3 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩

4 Acoplamiento secuencial 8
4.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪
4.2 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪

5 Adobe Director 9
∧.1 Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
∧.2 Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
∧.3 Director y Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
∧.4 Shockwave / Shockwave 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
∧.∧ Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
∧.∨ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6 Anidamiento (informática) 12
∨.1 En las planillas de cálculo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

i
ii ÍNDICE GENERAL

∨.2 En programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
∨.3 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

7 Antipatrón de diseño 13
∩.1 Algunos antipatrones de desarrollo de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
∩.1.1 Antipatrones de gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
∩.1.2 Antipatrones de gestión de proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
∩.1.3 Antipatrones generales de diseño de software . . . . . . . . . . . . . . . . . . . . . . . . 14
∩.1.4 Antipatrones de programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧
∩.1.∧ Antipatrones metodológicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨
∩.1.∨ Antipatrones de gestión de la con guración . . . . . . . . . . . . . . . . . . . . . . . . . 1∨
∩.2 Algunos antipatrones organizacionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩
∩.3 Relación alfabética de otros antipatrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩
∩.4 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
∩.∧ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8 Archivo de cabecera 21
∪.1 Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
∪.2 Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
∪.3 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
∪.4 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

9 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧
9.1.4 Aserciones estáticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧
9.2 Desactivación de las aserciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧
9.3 Comparación con los manejadores de errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧
9.4 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨

10 Automatización de tareas 27

11 Base de código 28
11.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪

12 Bean 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
1∧.1 Psicología y educación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1∧.2 Informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1∧.3 Derecho mercantil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1∧.4 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

16 Bloqueo mutuo 33
1∨.1 Representación de Bloqueos Mutuos usando grafos . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1∨.2 Condiciones necesarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1∨.3 Evitando bloqueos mutuos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1∨.4 Prevención . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1∨.∧ Livelock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

17 Bodyshopping 35
1∩.1 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧

18 BrookGPU 36

19 Caja blanca (sistemas) 37

19.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩

20 Caja negra (sistemas) 38

20.1 Justi cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∪
20.2 Caja negra y programación modular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∪
20.3 Pruebas de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∪
20.4 Caja negra vs 'Cajanegrizar' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∪
20.∧ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∪

21 CamelCase 40
21.1 Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
21.2 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

22 Caml 41
22.1 Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
22.1.1 Hola Mundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 [Link] 45

26 CMake 46
2∨.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4∨
2∨.2 Documentación y tutoriales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4∨
2∨.3 Principales funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4∨
2∨.4 CTest, CPack, CDash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4∩
2∨.∧ Aplicaciones que utilizan CMake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4∩
2∨.∨ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4∩
2∨.∩ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4∩

27 Codecademy 48
2∩.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4∪
2∩.2 Code Year . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4∪
2∩.3 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4∪
2∩.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4∪
2∩.∧ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

28 Código cerrado 50
2∪.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧0

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧3
31.2 Errores comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧3
31.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧3
31.4 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧3

32 Ofuscación 54
32.1 Informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧4
ÍNDICE GENERAL v

32.1.1 Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧4
32.2 Otros objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧4
32.3 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧∧

33 ColdFusion 56
33.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧∨
33.2 Versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧∨
33.3 Ejemplos de código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧∩
33.4 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧∩

34 Coloreado de sintaxis 58
34.1 Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧∪
34.2 Programas con coloreado de sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧∪
34.3 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧∪

35 Comentario (informática) 59
3∧.1 Información general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧9
3∧.2 Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∧9
3∧.2.1 Planeación / Revisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨0
3∧.2.2 Descripción de código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨0
3∧.2.3 Descripción algorítmica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨0
3∧.2.4 Inclusión de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨0
3∧.2.∧ Depuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨1
3∧.2.∨ Generación de documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨1
3∧.3 Estilos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨1
3∧.3.1 Etiquetas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨1
3∧.4 Curiosidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨1
3∧.∧ Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.1 Ensamblador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.3 C/C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.4 Delphi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.∧ Lua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.∨ Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.∩ Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.∪ Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.9 Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.10 código HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.11 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.12 Visual Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.13 Pauscal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∧.14 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
vi ÍNDICE GENERAL

3∧.∧.1∧ Cobol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∨ Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨2
3∧.∩ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨3

36 Compatibilidad (informática) 64
3∨.1 Problemas de compatibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨4
3∨.2 Emulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨4
3∨.3 OpenSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨4
3∨.4 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨4
3∨.∧ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨∧

37 Competición Internacional Universitaria ACM de Programación 66

3∩.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨∨
3∩.2 Reglas de la competición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨∨
3∩.3 Competiciones locales, regionales y nal mundial . . . . . . . . . . . . . . . . . . . . . . . . . . ∨∩
3∩.4 Lista de competiciones regionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨∩
3∩.∧ Ganadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨∩
3∩.∨ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨∪
3∩.∩ Enlaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨∪
3∩.∩.1 Jueces en Línea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨∪

38 Computación parasitaria 69
3∪.1 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨9
3∪.2 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∨9

39 Conectiva lógica 70
39.1 Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩0
39.1.1 Lenguaje natural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩0
39.1.2 Lenguajes formales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩0
39.2 Lista de conectivos lógicos comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩0
39.2.1 Lista de conectivos lógicos comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩0
39.2.2 Historia de las notaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩1
39.3 Redundancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩1
39.4 Propiedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩2
39.∧ Ciencias de la computación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩2
39.∨ Conectivas por el número de argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩3
39.∨.1 Sin argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩3
39.∨.2 Con un argumento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩3
39.∨.3 Con dos argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩3
39.∩ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩3
39.∪ Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩3
39.9 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩3
ÍNDICE GENERAL vii

40 Con guración regional 74

40.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩4
40.2 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩4
40.3 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩4

41 Conteo de referencias 75
41.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∧

42 Convención de Nombres (Programación) 76

42.1 Bene cios potenciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∨
42.2 Desafíos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∨
42.3 El valor del negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∨
42.4 Elementos comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∩
42.4.1 Longitud de identi cadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∩
42.4.2 Mayúsculas, minúsculas y números . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∩
42.4.3 Identi cadores de varias palabras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∩
42.∧ Metadatos y convenciones híbridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∪
42.∧.1 Notación húngara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∪
42.∧.2 Notación posicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∪
42.∧.3 Esquema de palabra compuesta (del lenguaje) . . . . . . . . . . . . . . . . . . . . . . . . ∩∪
42.∨ Convenciones especí cas del lenguaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∪
42.∨.1 ActionScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∪
42.∨.2 Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩∪
42.∨.3 C y C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩9
42.∨.4 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩9
42.∨.∧ JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩9
42.∨.∨ Lisp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩9
42.∨.∩ .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩9
42.∨.∪ Objective-C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∩9
42.∨.9 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪0
42.∨.10 Python y Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪0
42.∩ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪0
42.∪ Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪0
42.9 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪0

43 Cracking (software) 81
43.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪1

44 Cuaderno de carga 82

45 Curri cación 83
4∧.1 Nomenclatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪3
4∧.2 De nición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪3
viii ÍNDICE GENERAL

4∧.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪3
4∧.4 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪3

46 Código enhebrado 84
4∨.1 Historia que llevó al código enhebrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪4
4∨.2 Desarrollo del código enhebrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪∧
4∨.3 Modelos de enhebrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪∧
4∨.3.1 Enhebrado directo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪∧
4∨.3.2 Enhebrado indirecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪∨
4∨.3.3 Enhebrado de subrutina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪∨
4∨.3.4 Enhebrado de token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪∨
4∨.3.∧ Enhebrado de Hu man . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪∨
4∨.3.∨ Enhebrados menos usados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪∩
4∨.4 Bifurcaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪∩
4∨.∧ Amenidades comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪∩
4∨.∨ Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪∩
4∨.∩ Lectura adicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪∩
4∨.∪ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪∪

47 Código inalcanzable 89
4∩.1 Causas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪9
4∩.2 Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ∪9
4∩.3 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4∩.3.1 Pro ling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4∩.4 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4∩.∧ Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4∩.∨ Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4∩.∩ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

48 Código muerto 91
4∪.1 Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4∪.2 Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4∪.3 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4∪.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4∪.∧ Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4∪.∨ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

49 Código redundante 93
49.1 Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
49.2 Eliminación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
49.3 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
49.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
ÍNDICE GENERAL ix

50 Dato 94
∧0.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
∧0.2 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

51 Depuración de programas 95
∧1.1 Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∧
∧1.2 Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∧
∧1.3 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∧

52 Desarrollador de software 96
∧2.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∨

53 Desarrollo en cascada 97
∧3.1 Fases del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∩
∧3.1.1 Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∩
∧3.1.2 Diseño del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∩
∧3.1.3 Diseño del Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∪
∧3.1.4 Codi cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∪
∧3.1.∧ Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∪
∧3.1.∨ Veri cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∪
∧3.1.∩ Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∪
∧3.2 Variantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∪
∧3.3 Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∪
∧3.4 Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∪
∧3.∧ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9∪
∧3.∨ Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
∧3.∩ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

54 Desarrollo en espiral 100

∧4.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
∧4.2 Ciclos o Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
∧4.2.1 Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
∧4.3 Mecanismos de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
∧4.4 Variaciones del Modelo En Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
∧4.∧ Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
∧4.∨ Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
∧4.∩ Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
∧4.∪ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
∧4.9 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
∧4.10Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

55 Desarrollo iterativo y creciente 103

∧∧.1 Concepto de desarrollo iterativo y creciente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
x ÍNDICE GENERAL

∧∧.2 Ciclo de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

∧∧.2.1 Consideraciones sobre el momento de aplicación . . . . . . . . . . . . . . . . . . . . . . 103
∧∧.2.2 Etapa de inicialización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
∧∧.2.3 Etapa de iteración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
∧∧.3 Caso práctico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
∧∧.4 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
∧∧.∧ Ventajas del desarrollo incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10∧
∧∧.∨ Ventajas del desarrollo iterativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10∧
∧∧.∩ Debilidades de este modelo de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10∧
∧∧.∪ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10∨
∧∧.9 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10∨

56 Detección dinámica de invariantes 107

∧∨.1 Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10∩

57 Diagrama de colaboración 108

∧∩.1 Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10∪
∧∩.2 Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10∪
∧∩.3 Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10∪
∧∩.4 Flujos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
∧∩.∧ Cambios en versiones recientes de UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

58 Diagrama de ujo 110

∧∪.1 Normas de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
∧∪.2 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
∧∪.3 Tipos de diagramas de ujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
∧∪.4 Simbología y signi cado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
∧∪.∧ Cursograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
∧∪.∧.1 Simbología y normas del cursograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
∧∪.∨ Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
∧∪.∩ Ventajas de los diagramas de ujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
∧∪.∪ Software para diseño de diagramas de ujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
∧∪.9 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
∧∪.10Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
∧∪.11Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

59 Diagrama Nassi-Shneiderman 114

∧9.1 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
∧9.2 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
∧9.3 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
∧9.3.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

60 di 115
ÍNDICE GENERAL xi

∨0.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11∧

∨0.2 Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11∧
∨0.3 Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11∨
∨0.4 Variantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11∨
∨0.4.1 Edit script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11∨
∨0.∧ Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11∨
∨0.∨ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11∨
∨0.∩ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11∩

61 Dirección de retorno 118

62 Diseño estructurado 119

∨2.1 Etapas del Diseño estructurado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
∨2.1.1 Descomposición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
∨2.1.2 Jerarquía de módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
∨2.1.3 Independencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
∨2.2 Evaluando el diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
∨2.2.1 Acoplamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
∨2.2.2 Cohesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
∨2.2.3 Fan-In y Fan-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
∨2.3 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

63 Distancia de Damerau-Levenshtein 122

∨3.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
∨3.2 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
∨3.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

64 Distancia de Levenshtein 123

∨4.1 El algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
∨4.2 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
∨4.2.1 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
∨4.2.2 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
∨4.2.3 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
∨4.2.4 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
∨4.2.∧ Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
∨4.2.∨ Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
∨4.2.∩ Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
∨4.2.∪ PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
∨4.2.9 Delphi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
∨4.2.10 [Link] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∧
∨4.2.11 ActionScript 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∧
∨4.2.12 ColdFusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∧
∨4.2.13 JavaScript (NodeJS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∧
xii ÍNDICE GENERAL

∨4.3 Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∧

∨4.4 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∧
∨4.∧ Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∧

65 DLO 126
∨∧.1 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∨

66 Driver Chain Manager 127

∨∨.1 ←Qué hace? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∩
∨∨.1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∩
∨∨.1.2 Capacidades de DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∩
∨∨.1.3 Cuestiones fuera del alcance de DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∩
∨∨.2 Sotrware que utiliza DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∩
∨∨.2.1 Aplicaciones que utilizan DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∩
∨∨.2.2 Empresas desarrolladoras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∪
∨∨.2.3 Sistemas operativos que soportan ʻDCM . . . . . . . . . . . . . . . . . . . . . . . . . . 12∪
∨∨.3 Funcionamiento de la cadena de drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∪
∨∨.3.1 El problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∪
∨∨.3.2 Forma de solucionarlo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∪
∨∨.4 Otras aplicaciones que utilizan DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∪
∨∨.∧ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∪
∨∨.∨ Fuentes y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12∪

67 Dublin Core 129

∨∩.1 Descripción general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
∨∩.2 Clasi cación y elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
∨∩.3 Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
∨∩.4 Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
∨∩.∧ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

68 eAthena 132
∨∪.1 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

69 Efecto Hover 133

∨9.1 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
∨9.2 Enlaces de interés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

70 Emtp 134
∩0.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
∩0.2 ATP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
∩0.3 Método de solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
∩0.4 Distribución de EMTP-ATP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
∩0.∧ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
∩0.∨ Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
ÍNDICE GENERAL xiii

71 Enlace dinámico 135

72 Enlace estático 136

73 Enlazado 137

74 Entrada chapuza 138

∩4.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13∪
∩4.2 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13∪

75 Error de software 139

∩∧.1 Orígenes del término . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
∩∧.2 Defectos de diseño de programas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
∩∧.3 Errores de programación comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
∩∧.4 Defectos de instalación o programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
∩∧.∧ Códigos de errores de lenguajes de programación . . . . . . . . . . . . . . . . . . . . . . . . . . 140
∩∧.∨ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
∩∧.∩ Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
∩∧.∪ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

76 Estilo de programación 142

∩∨.1 Características del estilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
∩∨.1.1 Nombres de variable apropiadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
∩∨.1.2 Estilo de indentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
∩∨.1.3 Valores booleanos en estructuras de decisión . . . . . . . . . . . . . . . . . . . . . . . . . 142
∩∨.1.4 Bucles y estructuras de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
∩∨.1.∧ Espaciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
∩∨.2 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
∩∨.3 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
∩∨.3.1 Convenciones de código en castellano . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
∩∨.3.2 Convenciones de código en inglés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
∩∨.3.3 Convenciones de código de proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

77 Eventos del ratón 144

∩∩.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

78 Exclusión mutua (informática) 145

∩∪.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14∧

79 Expresión regular 146

∩9.1 Construcción de expresiones regulares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14∨
∩9.2 Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14∨
∩9.3 Las expresiones regulares en programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14∩
∩9.4 Descripción de las expresiones regulares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14∪
xiv ÍNDICE GENERAL

∩9.4.1 El punto ".” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14∪

∩9.4.2 La admiración "!" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14∪
∩9.4.3 La barra inversa o antibarra "\" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14∪
∩9.4.4 Los corchetes "[ ]" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
∩9.4.∧ La barra "|" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
∩9.4.∨ El signo de dólar "$" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
∩9.4.∩ El acento circun ejo "^" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
∩9.4.∪ Los paréntesis "()" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧0
∩9.4.9 El signo de interrogación "?" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧0
∩9.4.10 Las llaves "{}" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧0
∩9.4.11 El asterisco "*" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧0
∩9.4.12 El signo de suma "+" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧1
∩9.4.13 Grupos anónimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧1
∩9.∧ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧2

80 Flag 153
∪0.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧3

81 Front-end y back-end 154

∪1.1 Informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧4
∪1.2 Tecnología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧4
∪1.3 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧∧
∪1.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧∧

82 Fuga de memoria 156

∪2.1 RAII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧∨
∪2.2 Fugas de memoria en lenguajes con recolector de basura . . . . . . . . . . . . . . . . . . . . . . . 1∧∨
∪2.3 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧∩

83 Generación de código 158

∪3.1 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧∪

84 Generador de números aleatorios 159

∪4.1 Algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∧9
∪4.2 Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨0
∪4.3 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨0

85 Gledplay 161
∪∧.1 Dispositivos Soportados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨1
∪∧.2 GledDraw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨1
∪∧.3 GledVideo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨2
∪∧.4 GledSave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨2
∪∧.∧ GledApplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨2
∪∧.∨ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨2
ÍNDICE GENERAL xv

86 GPGPU 163
∪∨.1 Modelo de programación GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨3
∪∨.2 Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨3
∪∨.3 Críticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨4
∪∨.4 Otros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨4
∪∨.∧ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨4
∪∨.∨ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨4

87 Hackathon 165
∪∩.1 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨∧
∪∩.2 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨∧

88 Hacker 166
∪∪.1 Otros signi cados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨∨
∪∪.2 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨∩
∪∪.2.1 ARPANET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨∩
∪∪.2.2 UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨∩
∪∪.2.3 GNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨∩
∪∪.2.4 LINUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨∪
∪∪.3 Ética hacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨∪
∪∪.4 Controversia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨∪
∪∪.4.1 Ambigüedad y debate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨∪
∪∪.∧ Activismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨9
∪∪.∨ Terminología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨9
∪∪.∨.1 OverHat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨9
∪∪.∨.2 White hat y black hat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∨9
∪∪.∨.3 Samurái . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩0
∪∪.∨.4 Phreaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩0
∪∪.∨.∧ Lamer o script-kiddie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩0
∪∪.∨.∨ Newbie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩0
∪∪.∩ Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩0
∪∪.∪ Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩0
∪∪.9 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩1
∪∪.10Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩1

89 Heisenbug 172
∪9.1 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩2
∪9.2 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩2

90 Hoja de estilo 173

90.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩3
90.2 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩3
90.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩3
xvi ÍNDICE GENERAL

91 Hola mundo 174

91.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩4
91.2 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩4
91.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩4

92 Homebrew 175
92.1 Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩∧
92.2 Homebrew en diferentes consolas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩∨
92.2.1 Sega Dreamcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩∨
92.2.2 Nintendo Entertainment System (NES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩∨
92.2.3 Super Nintendo Entertainment System (SNES) . . . . . . . . . . . . . . . . . . . . . . . . 1∩∨
92.2.4 Nintendo DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩∩
92.2.∧ Sony PSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩∩
92.2.∨ Microsoft Xbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩∩
92.2.∩ Microsoft Xbox 3∨0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩∩
92.2.∪ Nintendo Wii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩∪
92.2.9 PlayStation 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩∪
92.3 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩∪
92.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩∪

93 ICONIX 179
93.1 Ventajas de Iconix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩9
93.2 Tareas de la metodología Iconix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩9
93.2.1 Fase 1: Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩9
93.2.2 Fase 2: Análisis y diseño preliminar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩9
93.2.3 Fase 3: Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩9
93.2.4 Fase 4: Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩9
93.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩9
93.4 Conceptos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∩9
93.∧ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪0
93.∧.1 Fase 2: Análisis y diseño preliminar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪0
93.∧.2 Fase 3: Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪0
93.∧.3 Fase 4: Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪0
93.∨ Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪0
93.∩ Conceptos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪0
93.∪ Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪0

94 Anexo:Implementaciones de Smalltalk 181

95 Anexo:Implementaciones para algoritmo de rut 182

9∧.1 Objective-C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪2
9∧.2 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪2
9∧.3 Visual Basic MS Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪2
ÍNDICE GENERAL xvii

9∧.4 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪2
9∧.∧ Perl ∨ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪3
9∧.∨ Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪3
9∧.∩ PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪3
9∧.∪ Transact-SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪3
9∧.9 MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪3
9∧.10PSeInt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪3
9∧.11Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪3
9∧.12Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪3
9∧.13Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪3
9∧.14Pl/pgsql de PostgreSql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪3

96 Inanición (informática) 185

97 Indirección 186

98 Infraestructura de lenguaje común 187

9∪.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪∪

99 Ingeniería de software 189

99.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1∪9
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
99.∧ Notaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
99.∧.1 LUM (lenguaje uni cado de modelado) o UML . . . . . . . . . . . . . . . . . . . . . . . 191
99.∧.2 BPMN (notación para el modelado de procesos de negocios) . . . . . . . . . . . . . . . . 191
99.∧.3 Diagrama de ujo de datos (DFD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
99.∨ Herramienta CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
99.∩ Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
99.∩.1 Etapas del proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
99.∩.2 Ventajas* [22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19∧
99.∪ Modelos y Ciclos de Vida del Desarrollo de Software . . . . . . . . . . . . . . . . . . . . . . . . 19∧
99.∪.1 Modelo en cascada o clásico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19∧
99.∪.2 Modelo de prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19∧
99.∪.3 Modelo en espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19∨
99.∪.4 Modelo de desarrollo por etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19∨
99.∪.∧ Modelo Incremental o Iterativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19∨
xviii ÍNDICE GENERAL

99.∪.∨ Modelo RAD (rapid application development) . . . . . . . . . . . . . . . . . . . . . . . . 19∩

99.∪.∩ Modelo de desarrollo concurrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19∩
99.∪.∪ Proceso uni cado del desarrollo de software . . . . . . . . . . . . . . . . . . . . . . . . . 19∩
99.9 Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19∪
99.10Naturaleza de la Ingeniería de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19∪
99.11Participantes y papeles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19∪
99.11.1 Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
99.11.2 Desarrolladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
99.11.3 Gestores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
99.11.4 Usuarios nales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
99.11.∧ 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.1∧Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
99.1∨Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

100Instancia (informática) 202

100.1Etimología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.∧Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

101Instrucción (informática) 204

101.1Campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
101.2Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
101.3Repertorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
101.4Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20∧

102Interfaz binaria de aplicaciones 206

102.1Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20∨
102.2EABI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20∩
102.3Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20∩
102.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20∩
102.∧Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20∩

103Interfaz uida 208

103.1Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20∪
103.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
ÍNDICE GENERAL xix

104Invariante (informática) 210

104.1Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

105Jframe 211
10∧.1Herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
10∧.2Constructores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
10∧.3Métodos propios de la clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
10∧.4Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

106Usuario discusión:Juliasocorro 213

107Kanban (desarrollo) 215

10∩.1El método Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21∧
10∩.2Los principios del método Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21∧
10∩.3Cinco prácticas centrales del método Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21∨
10∩.4Comportamiento emergente con Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21∨
10∩.∧La implementación del método Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21∨
10∩.∨Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21∨
10∩.∩Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21∩

108Kit de desarrollo de software 218

10∪.1Incompatibilidad de licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21∪
10∪.2SDK para añadidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21∪
10∪.3Términos más especí cos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21∪
10∪.4Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21∪
10∪.∧Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
10∪.∨Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
10∪.∩Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

109Kommander 220
109.1El editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
109.2El ejecutor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
109.3Direcciones de Kommander . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

110Last Error (informática) 221

110.1Errores personalizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
110.2En DELPHI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
110.3Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

111Línea de código fuente 222

111.1El uso de medidas de LCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.∧Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

112Macintosh Toolbox 225

113Macro 226
113.1Macros de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22∨
113.2Macros en programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22∨
113.3Macros ocultas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22∨
113.4Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22∨

114Malla de triángulos 3D 227

114.1Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22∩
114.2Obtención de las mallas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22∩
114.3Compresión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22∪

115Mapeo objeto-relacional 229

11∧.1El problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
11∧.2Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
11∧.3Bases de datos distintas a SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
11∧.4Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
11∧.∧Enlaces relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

116Máquina de estados 231

117Máquina desnuda 232

118MCML 233
11∪.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

119Metaprogramación 234
119.1Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

120Microformatos Dublin Core 235

121Modelo de prototipos 236

121.1Etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23∨
121.2Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23∨
121.3Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23∨
121.4Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23∨
121.∧Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23∩

122Modi cador 238

ÍNDICE GENERAL xxi

122.1Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23∪

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.∧Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
123.∨Vé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

12∧.1Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
12∧.2Exclusión mutua en un monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
12∧.3Tipos de monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
12∧.3.1 Tipo Hoare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
12∧.3.2 Tipo Mesa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
12∧.4Veri cación de monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
12∧.4.1 Inicialización de las variables del monitor . . . . . . . . . . . . . . . . . . . . . . . . . . 244
12∧.4.2 Monitores tipo Hoare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
12∧.4.3 Monitores tipo Mesa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
12∧.∧Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
12∧.∨Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

126Anexo:Motores de persistencia 245

12∨.0.1 ColdFusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∧
12∨.0.2 Common Lisp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∧
12∨.0.3 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∧
12∨.0.4 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∧
12∨.0.∧ .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∨
12∨.0.∨ Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∨
12∨.0.∩ PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∨
12∨.0.∪ Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∩
12∨.0.9 Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∩
12∨.0.10Smalltalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∩
12∨.0.11C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∩

127Método de depuración del patito de goma 248

12∩.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∪
12∩.2Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∪
xxii ÍNDICE GENERAL

12∩.3Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24∪

128Net Yaroze 249

12∪.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧0
12∪.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧0
12∪.3Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧0

129Nodo (informática) 251

129.1Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧1
129.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧1

130Notación Reddick 252

130.1Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧2
130.2Notación para objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧2
130.3Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧2

131Notación húngara 253

131.1Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧3
131.2Situación actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧3
131.2.1 Ejemplo notaciones de 1 carácter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧3
131.3Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧3

132Null 254

133NWNScript 255
133.1Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧∧

134Objeto todopoderoso 256

134.1Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧∨
134.2Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧∨
134.3Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧∨

135Oday 257

136O set (informática) 258

13∨.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧∪
13∨.2Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧∪

137OGNL 259
13∩.1Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧9
13∩.2Cadenas (chains) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧9
13∩.3Proyectos que usan OGNL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧9
13∩.4Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∧9

138OpenACS 260
13∪.1Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨0
ÍNDICE GENERAL xxiii

13∪.2Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨0
13∪.3Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨0
13∪.4Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨0

139Operaciones con archivos (informática) 261

139.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨1

140Operador 262
140.1Operadores en un espacio vectorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨2
140.2Operadores bilineales o bivariantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨2
140.3Tipos generales de operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨2
140.3.1 Operadores de condición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨2
140.3.2 Operadores de orden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨3
140.3.3 Operadores lógicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨3
140.3.4 Operaciones aritméticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨3
140.4Otros operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨3
140.∧Temas relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨4
140.∨Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨4

141Operando 265
141.1En informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨∧
141.2Conexiones externas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨∧
141.2.1 Matemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨∧
141.2.2 Informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨∧

142Paquetes en PL/SQL 266

142.1Especi cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨∨
142.2Cuerpo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨∨

143Pascal Casing 268

143.1Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨∪

144Patch (Unix) 269

144.1Contexto de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨9
144.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∨9

145Phrogram 270
14∧.1Detalles técnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩0
14∧.2¡Hola, Mundo! en KPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩0
14∧.3Filosofía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩0
14∧.4Otra información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩0
14∧.∧The Phrogram Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩1
14∧.∨Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩1
xxiv ÍNDICE GENERAL

146Plataforma de desarrollo 272

14∨.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩2

147Plataforma virtual didáctica 273

14∩.1Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩3
14∩.2Herramientas que las componen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩3
14∩.3Para que sirven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩3
14∩.4Autores y contribuyentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩3
14∩.∧Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩3
14∩.∨Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩3
14∩.∩Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩3
14∩.∪Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩4

148Polling 275
14∪.1Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩∧
14∪.2Polling del registro de Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩∧
14∪.3Soluciones para el polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩∧
14∪.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩∧
14∪.∧Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩∨

149Poltergeist (informática) 277

149.1Consecuencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩∩
149.2Solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩∩
149.3Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩∩
149.4Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩∩

150Portabilidad 278
1∧0.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩∪
1∧0.2Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩∪

151Postcondición 279
1∧1.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∩9

152Pragma 280
1∧2.1Programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪0
1∧2.2Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪0
1∧2.3Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪0

153Precondición 281
1∧3.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪1

154Primitiva de sincronización rendezvous 282

1∧4.1Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪2
1∧4.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪2
ÍNDICE GENERAL xxv

155Proceso (informática) 283

1∧∧.1Creación de un proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪4
1∧∧.2Terminación de un proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪4
1∧∧.3Estados de un proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪4
1∧∧.4Tipos de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∧
1∧∧.∧Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∧
1∧∧.∨Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∧
1∧∧.∩Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∧

156Proceso para el desarrollo de software 286

1∧∨.1Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∨
1∧∨.2Actividades del desarrollo de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∨
1∧∨.2.1 Plani cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∨
1∧∨.2.2 Implementación, pruebas y documentación . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∨
1∧∨.2.3 Despliegue y mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∩
1∧∨.3Modelos de Desarrollo de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∩
1∧∨.3.1 Modelo de cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∩
1∧∨.3.2 Modelo de espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∪
1∧∨.3.3 Desarrollo iterativo e incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∪
1∧∨.3.4 Desarrollo ágil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪∪
1∧∨.3.∧ Codi cación y corrección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪9
1∧∨.3.∨ Orientado a la Reutilización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪9
1∧∨.4Modelos de mejora de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪9
1∧∨.∧Métodos formales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2∪9
1∧∨.∨Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
1∧∨.∩Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
1∧∨.∪Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

157Programa informático 291

1∧∩.1Programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
1∧∩.1.1 Paradigmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
1∧∩.1.2 Compilado o interpretando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
1∧∩.1.3 Programas que se auto-modi can . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
1∧∩.2Ejecución y almacenamiento de los programas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
1∧∩.2.1 Programas empotrados en hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
1∧∩.2.2 Programas cargados manualmente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
1∧∩.2.3 Programas generados automáticamente . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
1∧∩.2.4 Ejecución simultánea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
1∧∩.3Categorías funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
1∧∩.4Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
1∧∩.∧Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
1∧∩.∨Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
xxvi ÍNDICE GENERAL

1∧∩.∩Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

158Programa interactivo 296

1∧∪.1Frente a Procesamiento por lotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29∨
1∧∪.1.1 Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29∨
1∧∪.1.2 Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29∨
1∧∪.2Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29∨
1∧∪.2.1 Cajero automático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29∨
1∧∪.2.2 Compresor de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29∨

159Programación lineal paramétrica 297

1∧9.1Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29∩

160Programación visual 298

1∨0.1Programación orientada a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29∪
1∨0.2Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29∪

161Programador 299
1∨1.1Reseña histórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
1∨1.2Funciones del programador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
1∨1.3Especialidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
1∨1.4Notas y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
1∨1.∧Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

162Pseudocódigo 301
1∨2.1Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
1∨2.2Sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
1∨2.3De nición de datos del pseudocódigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
1∨2.4Funciones y operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
1∨2.∧Estructuras de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
1∨2.∧.1 Estructuras secuenciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
1∨2.∧.2 Estructuras selectivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
1∨2.∧.3 Estructuras iterativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
1∨2.∧.4 El anidamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
1∨2.∨Desarrollo de algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
1∨2.∩Funciones y procedimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
1∨2.∪Ventajas del pseudocódigo sobre los diagramas de ujo . . . . . . . . . . . . . . . . . . . . . . . 304
1∨2.9Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
1∨2.10Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
1∨2.11Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
1∨2.12Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

163Puente de aplicación 305

ÍNDICE GENERAL xxvii

164Puntero inteligente 306

1∨4.1Punteros inteligentes en Boost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30∨
1∨4.1.1 Scoped pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30∨
1∨4.1.2 Shared pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30∩
1∨4.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30∩

165Pure data 308

1∨∧.1Tipos de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
1∨∧.2Objetos más importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
1∨∧.3Instalación en GNU posibles problemas y soluciones . . . . . . . . . . . . . . . . . . . . . . . . . 310
1∨∧.4Introducción rápida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
1∨∧.∧Bibliotecas pdp, pidip y opencv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
1∨∧.∨Patch patrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
1∨∧.∩Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
1∨∧.∪Material en español . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
1∨∧.9Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

166QuadTIN 313

167Query string 314

1∨∩.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

168Quest3D 315
1∨∪.1Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∧
1∨∪.1.1 Lógica de las aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∧
1∨∪.1.2 Orientación a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∧
1∨∪.1.3 Editores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∧
1∨∪.1.4 Publicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∧
1∨∪.2Requerimientos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∧
1∨∪.3Licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∨
1∨∪.4Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∨
1∨∪.∧Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∨
1∨∪.∨Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∨

169Quine (programa) 317

1∨9.1Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∩
1∨9.1.1 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∩
1∨9.1.2 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∩
1∨9.1.3 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∩
1∨9.1.4 Common Lisp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∩
1∨9.1.∧ Ocaml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∩
1∨9.1.∨ Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∩
1∨9.1.∩ JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∪
xxviii ÍNDICE GENERAL

1∨9.1.∪ Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∪

1∨9.1.9 BASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∪
1∨9.1.10Pascal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∪
1∨9.1.11Brainfuck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∪
1∨9.1.12HQ9+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∪
1∨9.1.13DOS Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∪
1∨9.1.14PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∪
1∨9.1.1∧PL/I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31∪
1∨9.1.1∨PostScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
1∨9.1.1∩Visual FoxPro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
1∨9.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

170Rebanamiento estático 320

1∩0.1Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
1∩0.2Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
1∩0.3Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
1∩0.4Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

171Recolector de basura 321

1∩1.1Breve reseña histórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
1∩1.2Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
1∩1.3Cómo funciona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
1∩1.4Ventajas y desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
1∩1.∧Cómo se implementa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
1∩1.∨Ejemplos de lenguajes con recolector de basura . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
1∩1.∩Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
1∩1.∪Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

172Recursión 323
1∩2.1Recursión en matemáticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
1∩2.1.1 Conjuntos de nidos de forma recurrente . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
1∩2.1.2 Funciones de nidas de forma recurrente . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
1∩2.1.3 Constantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
1∩2.1.4 Resolución de problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
1∩2.2Recursión en informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
1∩2.3Humor recursivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∧
1∩2.4Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∧
1∩2.∧Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∧
1∩2.∨Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∧

173Refactorización 326
1∩3.1Refactorización de código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∨
1∩3.2Refactorización de otros textos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∨
ÍNDICE GENERAL xxix

1∩3.3Etimología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∩
1∩3.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∩
1∩3.∧Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∩

174Re exión (informática) 328

1∩4.1Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∪
1∩4.2Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∪
1∩4.2.1 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∪
1∩4.2.2 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∪
1∩4.3Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32∪

175Relación de compresión (informática) 329

1∩∧.0.1 Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

176Resolución de problemas de programación 330

1∩∨.1Análisis del problema informático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
1∩∨.2Diseño del algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
1∩∨.2.1 Acciones elementales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
1∩∨.2.2 Secuencia de acciones elementales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
1∩∨.2.3 Composición condicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
1∩∨.2.4 Composición condicional doble (alternativa) . . . . . . . . . . . . . . . . . . . . . . . . . 331
1∩∨.2.∧ Composición condicional múltiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
1∩∨.2.∨ Composición iterativa o bucle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
1∩∨.3Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

177Instancia (programación) 333

1∩∩.1Programación basada en clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
1∩∩.1.1 Clases como objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
1∩∩.2Programación basada en prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
1∩∩.3Notas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
1∩∩.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

178Anexo:Scan code 335

179scanf 336
1∩9.0.1 Modi cantes de longitud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33∨
1∩9.1Sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33∪
1∩9.2Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33∪
1∩9.3Funciones derivadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33∪
1∩9.3.1 fscanf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33∪
1∩9.3.2 sscanf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33∪
1∩9.4Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33∪
1∩9.∧Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
xxx ÍNDICE GENERAL

180SCons 340
1∪0.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
1∪0.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

181Screen scraping 341

1∪1.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

182Sección crítica 342

1∪2.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

183Serialización 343
1∪3.1Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
1∪3.2Soporte en los lenguajes de programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
1∪3.3Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

184Sigil 344

185Signatura (informática) 345

186Signum Framework 346

1∪∨.1Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∨
1∪∨.1.1 Elementos de Signum Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∨
1∪∨.1.2 Entidades primero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∨
1∪∨.1.3 Generación del esquema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∨
1∪∨.1.4 Herencia de entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∨
1∪∨.1.∧ Interfaz de usuario y WCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∩
1∪∨.1.∨ LINQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∩
1∪∨.2Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∩
1∪∨.3Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∩

187Simple Network Library 348

1∪∩.1Origen del nombre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∪
1∪∩.2Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∪
1∪∩.3Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∪
1∪∩.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∪
1∪∩.∧Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∪
1∪∩.∧.1 Documentación de SNL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∪
1∪∩.∨Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34∪

188Smarty 349
1∪∪.1Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
1∪∪.2Críticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
1∪∪.3Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
1∪∪.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧0
ÍNDICE GENERAL xxxi

1∪∪.∧Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧0

189Snippet 351
1∪9.1Rich snippets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧1
1∪9.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧1

190Stack Over ow 352

190.1Funcionamiento de Stack Over ow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧2
190.2Reputación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧2
190.3Moderación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧2
190.4Estadísticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧2

191StarBasic 354
191.1Primer virus para OpenO ce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧4
191.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧4

192Stub 355
192.1Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧∧
192.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧∧

193Subalgoritmo 356
193.1Tipos de subalgoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧∨
193.2→mbito de las variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧∨
193.3Paso de argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧∨
193.4Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧∨

194Tabla de saltos 357

194.1Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧∩
194.2Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧∩
194.3Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧∪

195Tabla de verdad 359

19∧.1De niciones en el cálculo lógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∧9
19∧.2Número de combinaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨0
19∧.2.1 Para cero variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨1
19∧.2.2 Para una variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨1
19∧.2.3 Para dos variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨1
19∧.3Tablas de verdad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨1
19∧.3.1 Verdad Indeterminada o Contingencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨1
19∧.3.2 Contradicción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨2
19∧.3.3 Tautologías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨2
19∧.4Tablas de verdad, proposiciones lógicas y argumentos deductivos . . . . . . . . . . . . . . . . . . 3∨2
19∧.∧Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨2
19∧.∧.1 Cálculo lógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨2
xxxii ÍNDICE GENERAL

19∧.∧.2 Lógica de circuitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨2

19∧.∧.3 Desarrollo del algoritmo fundamental en lógica de circuitos . . . . . . . . . . . . . . . . . 3∨3
19∧.∨Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨4
19∧.∩Notas y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨∧
19∧.∪Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨∧

196Thunk 366
19∨.1Invocación por «gestionada» a «no gestionada» . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨∨
19∨.2Invocación por «no gestionada» a «gestionada» . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨∨
19∨.3Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨∨

197Tipo de dato elemental 367

198Triángulo de Floyd 368

19∪.1Algoritmo computacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨∪
19∪.2Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨∪
19∪.3Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨∪

199Tubería (informática) 369

199.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∨9

200Violación de acceso 371

200.1Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩1

201Waf 372
201.1Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩2
201.2Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩2
201.3Ejemplo Waf archivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩3
201.4Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩3
201.∧Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩3
201.∨Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩3

202Win32 Thread Information Block 374

202.1Contenido del TIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩4
202.2Acceso al TIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩4
202.3Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩4

203Wrapper 375
203.1Computación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩∧
203.2Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩∧
203.3Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩∧

204XAML 376
204.1Tecnología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩∨
204.2Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩∨
ÍNDICE GENERAL xxxiii

204.3Véase también . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩∨

204.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩∩
204.∧Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩∩

205Zenphp 378
20∧.1←Qué es zenphp? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩∪
20∧.2←Qué ventajas ofrece zenphp? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩∪
20∧.3Origen del texto y las imágenes, colaboradores y licencias . . . . . . . . . . . . . . . . . . . . . . 3∩9
20∧.3.1 Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3∩9
20∧.3.2 Imágenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
20∧.3.3 Licencia del contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39∨
Capítulo 1

Programación

La programación informática, acortada como progra- trivial como multiplicar dos números puede necesitar un
mación, es el proceso de diseñar, codi car, depurar y conjunto de instrucciones en lenguaje ensamblador, en
mantener el código fuente de programas computaciona- un lenguaje de alto nivel bastará con solo una. Una vez
les. El código fuente es escrito en un lenguaje de progra-
que se termina de escribir un programa, sea en ensam-
mación. El propósito de la programación es crear progra-blador o en algunos lenguajes de alto nivel, es necesa-
mas que exhiban un comportamiento deseado. El proceso rio compilarlo, es decir, traducirlo completo a lenguaje
de escribir código requiere frecuentemente conocimien- máquina.* [1] Eventualmente será necesaria otra fase de-
nominada comúnmente link o enlace, durante la cual se
tos en varias áreas distintas, además del dominio del len-
anexan al código, generado durante la compilación, los
guaje a utilizar, algoritmos especializados y lógica for-
mal. Programar no involucra necesariamente otras tareas recursos necesarios de alguna biblioteca. En algunos len-
guajes de programación, puede no ser requerido el pro-
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 enceso de compilación y enlace, ya que pueden trabajar en
el desarrollo de pequeñas aplicaciones. modo intérprete. Esta modalidad de trabajo es equivalen-
Del proceso de programación surge lo que comúnmente te pero se realiza instrucción por instrucción, a medida
se conoce como software (conjunto de programas), aun- que es ejecutado el programa.
que 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
Para crear un programa, y que la computadora lo inter- comandos que tienden a asemejarse a una lengua natural
prete y ejecute las instrucciones escritas en él, debe es- acotada (en inglés); y que además tienen la particularidad
cribirse en un lenguaje de programación. En sus inicios de una reducida ambigüedad. Cuanto menos ambiguo es
las computadoras interpretaban solo instrucciones en un un lenguaje de programación, se dice, es más potente. Ba-
lenguaje especí co, del más bajo nivel, conocido como jo esta premisa, y en el extremo, el lenguaje más potente
código máquina, siendo éste excesivamente complicado existente es el binario, con ambigüedad nula (lo cual lleva
para programar. De hecho solo consiste en cadenas de a pensar así del lenguaje ensamblador).
números 1 y 0 (sistema binario). Para facilitar el trabajo En los lenguajes de programación de alto nivel se distin-
de programación, los primeros cientí cos, que trabaja- guen diversos elementos entre los que se incluyen el léxi-
ban en el área, decidieron reemplazar las instrucciones, co propio del lenguaje y las reglas semánticas y sintácti-
secuencias de unos y ceros, por palabras o abreviaturas cas.
provenientes del inglés; las codi caron y crearon así un
lenguaje de mayor nivel, que se conoce como Asembly
o lenguaje ensamblador. Por ejemplo, para sumar se po-
dría usar la letra A de la palabra inglesa add (sumar). 1.3 Programas y algoritmos
En realidad escribir en lenguaje ensamblador es básica-
mente lo mismo que hacerlo en lenguaje máquina, pero Un algoritmo es una secuencia no ambigua, nita y or-
las letras y palabras son bastante más fáciles de recordar denada de instrucciones que han de seguirse para resol-
y entender que secuencias de números binarios. A me- ver un problema. Un programa normalmente implementa
dida que la complejidad de las tareas que realizaban las (traduce a un lenguaje de programación concreto) uno o
computadoras aumentaba, se hizo necesario disponer de más algoritmos. Un algoritmo puede expresarse de dis-
un método sencillo para programar. Entonces, se crea- tintas maneras: en forma grá ca, como un diagrama de
ron los lenguajes de alto nivel. Mientras que una tarea tan ujo, 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. puede almacenarse solo de forma temporal. Un programa
Los programas suelen subdividirse en partes menores, lla- podría tener partes escritas en varios lenguajes, por ejem-
madas módulos, de modo que la complejidad algorítmica plo, Java, C, C++ y ensamblador, que se podrían compilar
de cada una de las partes sea menor que la del programa de forma independiente y luego enlazar juntas para for-
completo, lo cual ayuda al desarrollo del programa. Esta mar un único módulo ejecutable.
es una práctica muy utilizada y se conoce como “re no
progresivo”.
Según Niklaus Wirth, un programa está formado por los 1.5 Programación e ingeniería del
algoritmos y la estructura de datos. software
Se han propuesto diversas técnicas de programación cu-
yo objetivo es mejorar tanto el proceso de creación de Existe una tendencia a identi car 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
• Programación declarativa grandes proyectos.
El proceso de creación de software, desde el punto de vis-
• Programación estructurada
ta de la ingeniería, incluye mínimamente los siguientes
• Programación modular pasos:

• Programación orientada a objetos

1. Reconocer la necesidad de un programa para solu-
cionar un problema o identi car la posibilidad de
automatización de una tarea.
1.4 Compilación
2. Recoger los requisitos del programa. Debe quedar
El programa escrito en un lenguaje de programación de claro qué es lo que debe hacer el programa y para
alto nivel (fácilmente comprensible por el programador) qué se necesita.
es llamado programa fuente y no se puede ejecutar di-
rectamente en una computadora. La opción más común 3. Realizar el análisis de los requisitos del programa.
es compilar el programa obteniendo un módulo objeto, Debe quedar claro qué tareas debe realizar el pro-
aunque también puede ejecutarse en forma más directa a grama. Las pruebas que comprueben la validez del
través de un intérprete informático. programa se pueden especi car en esta fase.
El código fuente del programa se debe someter a un
4. Diseñar la arquitectura del programa. Se debe des-
proceso de traducción para convertirlo a lenguaje máqui-
componer el programa en partes de complejidad
na o bien a un código intermedio, generando así un mó-
abordable.
dulo denominado “objeto”. A este proceso se le llama
compilación.
∧. Implementar el programa. Consiste en realizar un
Habitualmente la creación de un programa ejecutable (un diseño detallado, especi cando completamente to-
tí[Link] 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 codi cación (programación propiamente dicha) de-
dicho) y traduce el código fuente escrito en un lenguaje bería resultar inmediata.
de programación almacenado en un archivo de texto a
código en bajo nivel (normalmente en código objeto, no ∨. Probar el programa. Comprobar que pasan pruebas
directamente a lenguaje máquina). El segundo paso se que se han de nido en el análisis de requisitos
llama enlazado en el cual se enlaza el código de bajo ni-
vel generado de todos los cheros y subprogramas que se ∩. Implantar (instalar) el programa. Consiste en poner
han mandado compilar y se añade el código de las funcio- el programa en funcionamiento junto con los com-
nes que hay en las bibliotecas del compilador para que el ponentes que pueda necesitar (bases de datos, redes
ejecutable pueda comunicarse directamente con el siste- de comunicaciones, etc.).
ma operativo, traduciendo así nalmente 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 pla-
Estos dos pasos se pueden hacer por separado, almace- ni cación y diseño del programa, mientras que antigua-
nando el resultado de la fase de compilación en archivos mente (programación artesanal) la realización de un pro-
objetos (un típico .o para Unix, .obj para MS-Windows, grama consistía casi únicamente en escribir el código, ba-
DOS); para enlazarlos en fases posteriores, o crear direc- jo solo el conocimiento de los requisitos y con una mo-
tamente 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 3

1.6 Referencias históricas • Portabilidad. Un programa es portable cuando tiene

la capacidad de poder ejecutarse en una plataforma,
El trabajo de Ada Lovelace, hija de Anabella Milban- ya sea hardware o software, diferente a aquélla en la
ke Byron y Lord Byron, realizó para la máquina de que se desarrolló. La portabilidad es una caracterís-
Babbage le hizo ganarse el título de primera programa- tica muy deseable para un programa, ya que permi-
dora de computadoras del mundo, aunque Babbage nun- te, por ejemplo, a un programa que se ha elaborado
ca completó la construcción de la máquina. El nombre del para el sistema GNU/Linux ejecutarse también en la
lenguaje de programación Ada fue escogido como home- familia de sistemas operativos Windows. Esto per-
naje a esta programadora. mite que el programa pueda llegar a más usuarios
más fácilmente.

1.7 Objetivos de la programación

1.8 Ciclo de vida del software
La programación debe perseguir la obtención de progra-
mas de calidad. Para ello se establece una serie de factores El término ciclo de vida del software describe el desa-
que determinan la calidad de un programa. Algunos de los rrollo de software, desde la fase inicial hasta la fase nal,
factores de calidad más importantes son los siguientes: incluyendo su estado funcional. El propósito es de nir las
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 ve-
vias a su desarrollo. Para determinar si un progra- ri cación de los procedimientos de desarrollo: se asegura
ma hace lo que debe, es muy importante especi - 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 recti car
su desarrollo y, una vez acabado, compararlo con lo los errores que se detectan tarde dentro de la fase de im-
que realmente hace. plementación (programación propiamente dicha), o peor
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 soft-
ra 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-
do el trabajo del programador, tanto en la fase de • De nición de objetivos: de nir el resultado del pro-
creación como en las fases posteriores de corrección yecto y su papel en la estrategia global.
de errores, ampliaciones, modi caciones, etc. Fases
• Análisis de los requisitos y su viabilidad: recopilar,
que pueden ser realizadas incluso por otro progra-
examinar y formular los requisitos del cliente y exa-
mador, 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ácilmen-
te. Algunos programadores llegan incluso a utilizar • Diseño general: requisitos generales de la arquitec-
Arte ASCII para delimitar secciones de código; una tura de la aplicación.
práctica común es realizar aclaraciones en el código
fuente utilizando líneas de comentarios. Contraria- • Diseño en detalle: de nición precisa de cada sub-
mente, algunos por diversión o para impedirle un conjunto de la aplicación.
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 de nidas durante la etapa de
• E ciencia. Se trata de que el programa, además de diseño.
realizar aquello para lo que fue creado (es decir, que
sea correcto), lo haga gestionando de la mejor for- • Prueba de unidad: prueba individual de cada sub-
ma posible los recursos que utiliza. Normalmente, conjunto de la aplicación para garantizar que se im-
al hablar de e ciencia de un programa, se suele ha- plementaron de acuerdo con las especi caciones.
cer 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 aplica-
memoria 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 e ciencia de un programa, dependiendo de su na-
turaleza (espacio en disco que utiliza, trá co en la • Prueba beta (o validación), para garantizar que el
red que genera, etc.). software cumple con las especi caciones originales.
4 CAPÍTULO 1. PROGRAMACIÓN

• Documentación: se documenta con toda la informa- 1.11 Enlaces externos

ción necesaria, sea funcional nal para los usuarios
del software (manual del usuario), y de desarrollo
• Wikimedia Commons alberga contenido multi-
para futuras adaptaciones, ampliaciones y correc-
media sobre Programación. Commons
ciones.
• Mantenimiento: para todos los procedimientos co-
rrectivos (mantenimiento correctivo) y las actuali- • Wikcionario tiene de niciones y otra informa-
zaciones secundarias del software (mantenimiento ción sobre programació[Link]
continuo).
• Wikiquote alberga frases célebres de o sobre
El orden y la presencia de cada uno de estos procedimien- Programació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.
• Wikilibros alberga un libro o manual sobre
Fundamentos de programación.
1.9 Véase también
•

• Portal:Programación. Contenido relacionado

con Programación.
• Wikiproyecto:Informática/Programación
• error de software
• losofí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, An-
toni Gual (19∪∧). «Software». Biblioteca práctica de la
computación. Barcelona: Ediciones Océano-Éxito, S.A.
Capítulo 2

Portal:Programación

∧
Capítulo 3

&

«Et» redirige aquí. Para otras acepciones, véase El signo en sí es una ligadura ̶combinación de diseño de
E. T. dos letras en un único grafema, usado primero para au-
mentar 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 correspon-
dencia dictada por este último, Tiro, que era un esclavo li-
berto, inventó varias formas de acelerar la escritura, sien-
do por ello considerado el padre de la taquigrafía. En la
Edad Media o en los primeros tiempos de la imprenta el
Evolución de la ligadura &:
uso de ligaduras era muy común, en este caso por la eco-
1-3, cursivas romanas de los siglos ii-iv
4-5, minúsculas medievales de los siglos vi-vii nomía de espacio, cuando la materia prima ̶pergamino
6, minúscula carolingia, s. ix. o papel̶añadía mucho al precio de los libros.
También se le conoce como signo tironiano.
El signo &, cuyo nombre en español es et,* [1] es una al-
ternativa grá ca de la conjunción copulativa latina et, que
signi ca 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 de-
cir, «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 super uo,
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
cetera, en las formas &c. o &cetera. El et latino a la izquierda se encuentra estilizado, pero la forma
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 aca-
dé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 desa-
rrollada, particularmente en la forma uncial, escritura in-
sular y minúscula carolingia. Los calígrafos hicieron un
extensivo uso del et, ya que la condensación de una pala-
bra en una sola letra hacía su trabajo más fácil. Durante
aquel tiempo, se desarrolló una versión mucho más com-
primida del et. Normalmente se le llama ampersand“Ro-
En 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 ejem-
1011), este signo «&» fue considerado a menudo como plos más típicos son &gt; &lt;, y &amp; (>, < y &,
una letra más al nal del alfabeto latino. respectivamente).

∨
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 nal 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 2∧ de septiembre de 2012.

[2] «The History of Court Reporting». National Court Repor-

ters Association.

3.3 Enlaces externos

• Wikimedia Commons alberga contenido multi-

media sobre &Commons.

• Wikcionario tiene de niciones y otra informa-

ción sobre &.Wikcionario

• Wikcionario tiene de niciones y otra informa-

ción sobre [Link]

• Apéndice 4: Lista de símbolos o signos no alfabeti-

zables en la página de la Real Academia Española.
Capítulo 4

Acoplamiento secuencial

En Programación orientada a objetos el antipatrón de di-

seño acoplamiento secuencial se re ere a una clase que
requiere que sus métodos sean llamados en un orden se-
cuencial 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 por-
que 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 nece-
sario 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.

∪
Capítulo 5

Adobe Director

Adobe Director Es una aplicación de Desarrollo de Con el lanzamiento de Director 11 y su evolución a la

Software (o Autoría de Software) Multimedia (que ins- versión 11.∧, de la mano de Adobe, se incorporó sopor-
piró a Adobe Flash® ) destinado para la producción de te para DirectX y se extendieron las capacidades en 3D
programas ejecutables ricos en contenido multimedia. Esbasadas en el engine PhysX de NVIDIA, importación de
considerada una de las herramientas más poderosas de 3D desde Google SketchUp, así como también ltros de
integración y programación de medios digitales, debido a
bitmaps, canales de audio ∧.1, vídeo en alta de nición,
su versatilidad de poder incorporar imágenes, audio, ví-
soporte para H.2∨4, e integración de Adobe Flash CS3
deo digital, películas ash, y un engine 3D, en una solay Shockwave Player 11. Director 12, lanzado en febre-
aplicación, y manipularlas a través de un lenguaje de pro-
ro de 2013, incorporó la posibilidad de publicación para
gramación (Lingo; Javascript). dispositivos iOS, además de otras utilidades como este-
Desarrollado a nes de los años ∪0 por la empresa reoscopía, nuevos efectos, y nuevas potencialidades del
Macromedia, es distribuido desde el año 200∪ por Adobe engine 3D.
Systems Incorporated.
Adobe Director, permite crear y publicar juegos interac-
tivos, prototipos, simulaciones y cursos eLearning para la
5.1 Interfaz
Web, dispositivos iOS, sistemas de escritorio Windows®
y Mac, DVDs y CDs. Con Director también es posible A lo largo de todas sus versiones, la interfaz de Direc-
programar una amplia gama de aplicaciones basadas en tor ha sido el a su concepción inicial, y a su nombre:
redes, lo que ha permitido crear innumerables sistemas y entregarle al desarrollador un escenario (Stage), para el
juegos multiusuario online. armado de su Aplicación. Cada uno de los múltiples me-
dios que pueden ser utilizados en Director son conside-
Director también permite la manipulación de modelos en rados“actores”(casts), cuyas características pueden ser
3D, gracias a Shockwave 3D. Es así como diversos pro- manipuladas a través de guiones (o Scripts) escritos en
gramas de modelamiento, como 3D Studio MAX (de la lenguaje Lingo o Javascript. En síntesis, el desarrollador
empresa Autodesk), permiten exportar sus modelos (in- es el director de su propia película, controlando todos sus
cluyendo las animaciones) en formato Shockwave 3D, el aspectos.
que puede ser importado a Director, y manipulado a tra-
vé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, coe- 5.2 Timeline
cientes de roce, restitución, etc) que permiten lograr si-
mulaciones más realistas, tanto para software de ingenie- • 1985: VideoWorks (Disponible para Apple Macin-
ría avanzada, como para juegos. tosh)
Además del potente lenguaje incorporado (Lingo), una • 1988: Director 1.0
de sus principales ventajas radica en el uso de los llama-
dos xtras. Se trata de “pequeños programas”(plugins) • 1993: Macromind Director se convierte en Macro-
desarrollados en lenguaje C++ por otros usuarios o ter- media Director (v 3.1.3)
ceras empresas, que proporcionan al usuario in nidad de
• 1994: Macromedia Director 4 (Plataformas Win-
utilidades.
dows y Powermac)
Se pueden generar varios tipos de archivos, sin embar-
go lo más normal es crear un archivo ejecutable para • 1996: Macromedia Director ∧ (Aparición de Shock-
Windows (.exe) o Macintosh (.app). De esta forma pue- wave)
de verse la presentación en cualquier ordenador, sin tener
• 1997: Macromedia Director ∨ (Implementación de
instalado Adobe Director.
Behaviors & y soporte mp3)

9
10 CAPÍTULO 5. ADOBE DIRECTOR

• 1997: Macromedia Director ∨.∧ (integración de 5.4 Shockwave / Shockwave 3D

Xtras)
Desde la aparición de Director ∧, Shockwave es el for-
• 1998: Macromedia Director ∩ (Se re-escribió el en- mato exclusivo de publicación para web de Director. El
gine) plugin de shockwave permite ejecutar aplicaciones reali-
zadas en Director (archivos DCR), a través de Internet,
• 2000: Macromedia Director ∪ sin que estas pierdan su calidad ni características, además
de aprovechar al máximo las potencialidades de aquellas
• 2001: Macromedia Director ∪.∧ (Aparición de que poseen engine multiusuario. Con la aparición de Di-
Shockwave3D) rector ∪.∧, Shockwave tuvo un nuevo impulso, al incor-
porar capacidades de manipulación de elementos en 3D
• 2002: Macromedia Director MX (También conoci- (Shockwave 3D). Esto abrió las puertas a los desarrolla-
do como Director 9) dores de Director a un nuevo mundo, a partir del cual fue
posible crear ambientes modelados en 3D (generados en
• 2004: Macromedia Director MX 2004 (También Director, o importados como archivos W3D desde apli-
conocido como Director 10) caciones externas) y utilizar toda la riqueza del código lin-
go / javascript, para manipular dichos modelos en tiempo
• 2008: Adobe Director 11 real.
El motor 3D de Shockwave es todavía el líder indiscuti-
• 2009: Adobe Director 11.∧ ble en su mercado, y hace que este plugin sea muy popular
entre un gran número de desarrolladores de juegos en lí-
• 2010: Adobe Director 11.∧.∪ nea y de jugadores. Los archivos Flash (swf) pueden ser
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 inclu-
yen 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 ltrado
5.3 Director y Flash para composiciones en capas de los grá cos y compati-
bilidad 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 desarro-
desconocedora 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
199∨, orientado al desarrollo de aplicaciones multimedia
• Macromedia Shockwave Player, instalado en un
en Web, y en poco tiempo evolucionó poderosamente de
∧0% de los navegadores. Ficheros con extensión
la mano del lenguaje ActionScript. Director nació varios
".dcr”desarrollados con Adobe Director
años antes (19∪∧), y evolucionó como una poderosa he-
rramienta de integración de medios digitales de alta cali- • Macromedia Flash Player, instalado en un 9∪%
dad para plataformas de escritorio, y que también generó de los navegadores. Utiliza cheros con extensión
una arista para su incorporación a Web (Shockwave). ".swf”desarrollados con Macromedia Flash, Macro-
La evolución de la popularidad de Flash sobre Shockwa- media FreeHand, Generator y otras aplicaciones.
ve tiene varias explicaciones; no solo el plugin de Shock-
wave fue históricamente más pesado y menos amigable
de instalar que Flash, sino también la autoría de Direc- 5.5 Referencias
tor 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- 5.6 Enlaces externos
ñadores Web (sin necesidad de poseer conocimientos de
programación), y de hecho ha incentivado con los años el
• Sitio o cial de Adobe Director
aprendizaje de programación ActionScript a varios “no
programadores”, generando una importante sinergia en • Adobe Director Forum
el mundo del diseño y la programación -antes estricta-
mente lejanos-. Por otro lado, Macromedia logró acuer- • [Link] Foro temático sobre el progra-
dos con empresas como DELL y Apple, para que Flash ma (en inglés).
sea preinstalado en sus sistemas, evitando que los usuarios
deban instalar software adicional. • Foro de usuarios de Adobe Director (en inglés).
5.6. ENLACES EXTERNOS 11

• 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).
Capítulo 6

Anidamiento (informática)

El anidamiento (llamado nesting en inglés) es la linea, ruta as string dim valor_a_devolver as integer
práctica de incorporar llamadas (calls) a funciones o ruta="C:\[Link]”if FileExists(ruta) then open
procedimientos (unas) dentro de otras, mediante la inclu- “C:\[Link]”for input as #1 do while not EOF(1)
sión de diversos niveles de paréntesis. 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 programa-
ció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... n 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 6.3 Véase también
ser evaluadas desde adentro hacia afuera, ya que los re-
sultados de las más internas sirven, temporalmente, de • Bucle (programación)
datos de entrada de las exteriores.
• 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 fun- • Programación estructurada
ciones unas dentro de otras, derivando en fórmulas rela-
tivamente complejas. El programa OpenO [Link] Calc • Pseudocódigo
permite, mediante su asistente de funciones (function wi-
zard), navegar a través de los varios o múltiples niveles
de anidamiento, permitiendo editar (y eventualmente co-
rregir) cada una de ellas por separado. Tal vez de manera
sorprendente, su rival Microsoft Excel no posee esa ca-
racterística, eventualmente deseable cuando se trabaja en
algunas grandes planillas.

6.2 En programación
En los lenguajes de programación estructurada, el anida-
miento 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 indenta-
tion 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
Capítulo 7

Antipatrón de diseño

Un antipatrón de diseño es un patrón de diseño que in- calidad de vida de sus empleados, intenta homoge-
variablemente conduce a una mala solución para un pro- neizar los puestos de trabajo quitando en la medida
blema. de lo posible los permisos a los programadores para
Al documentarse los antipatrones, además de los patro- que no dañen los sistemas operativos, monitoriza a
los equipos de trabajo y actúa cortando la visibili-
nes de diseño, se dan argumentos a los diseñadores de
sistemas para no escoger malos caminos, partiendo de dad de ciertas páginas o las reuniones de programa-
dores, al nal se consigue que se vaya la gente de
documentación disponible en lugar de simplemente la
intuición. la empresa cuando la situación es insostenible, esto
suele ocurrir en ciclos de uno o dos años.
El término se origina inspirado en el libro Design Patterns,
escrito por un grupo de autores conocido como Gang of • Responsable ausente (absentee manager): Situación
Four, y que aglutina un conjunto de buenas soluciones en la que el principal responsable o coordinador se
de programación. Los autores bautizaron dichas solucio- ausenta o permanece en paradero desconocido o no
nes con el nombre de “patrones de diseño”por analo- localizable durante importantes períodos de tiempo.
gía con el mismo término, usado en arquitectura. El libro
Anti-Patterns (de William Brown, Raphael Malveau, Skip • Todo lo que tienes es un martillo (all you have is a
McCormick y Tom Mowbray, junto con la más reciente hammer): Gestión gris y plana, incapaz de tratar a
incorporación de Scott Thomas) describe los antipatrones los subordinados de manera personalizada y acorde
como la contrapartida natural al estudio de los patrones con sus necesidades particulares.
de diseño. El estudio formal de errores que se repiten per-
mite reconocer y reconducir los elementos involucrados • Negociador de jaula de acero (cage match negotia-
hacia una mejor solución. Los antipatrones no se men- tor): Se aplica cuando un coordinador, gestor o res-
cionan en el libro original de Design Patterns, puesto que ponsable aplica una losofía de "éxito a cualquier
éste es anterior. precio”.
Los antipatrones se consideran una parte importante de • Dos caras (doppelganger): Coordinador o compañe-
una buena práctica de programación. Es decir, un buen ro que en un determinado momento puede ser agra-
programador procurará evitar los antipatrones siempre dable y de trato fácil, pero igualmente puede volver-
que sea posible, lo que requiere su reconocimiento e iden- se irracional y despiadado de modo inesperado.
ti cación tan pronto como sea posible, dentro del ciclo de
vida del software. • Rodeos improductivos (fruitless hoops): Gestor o
El concepto de antipatrón se puede aplicar a la ingeniería coordinador que solicita grandes cantidades de da-
en general, e incluso a cualquier tarea realizada por el tos (en ocasiones sin relevancia alguna) antes de to-
hombre. Aunque no se escucha con frecuencia fuera del mar una decisión.
campo ingenieril, la noción está ampliamente extendida.
• Niñito de oro (golden child): Situación en la que
ciertas responsabilidades, oportunidades, reconoci-
mientos o recompensas van a parar a un determina-
7.1 Algunos antipatrones de do miembro del equipo como consecuencia de una
desarrollo de software relación personal o en clara contradicción con su
rendimiento real.

7.1.1 Antipatrones de gestión • Pollo sin cabeza (headless chicken): Se aplica al ges-
tor, coordinador o responsable que vive en una per-
• Productividad a toda costa: La empresa busca la pro- manente situación de pánico y medidas desespera-
ductividad a costa de la calidad del software y de la das.

13
14 CAPÍTULO 7. ANTIPATRÓN DE DISEÑO

• Líder pero no gestor (leader not manager): Un buen • Mala gestión (bad management): Gestionar un pro-
líder no tiene por qué ser necesariamente un buen yecto sin tener su cientes conocimientos sobre la
gestor, coordinador o responsable. materia.

• Gestión clonada (managerial cloning): Situación en • Software in ado (software bloat): Permitir que las
la que los coordinadores o gestores son contratados sucesivas versiones de un sistema exijan cada vez
e instruidos para actuar y trabajar todos del mismo más recursos.
modo, a imagen y semejanza de sus propios jefes.

• 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 ma- base as an IPC): Usar una base de datos para comu-
nipuladora 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 ade-
cuada.
• Sr. Amigo de todos (Mr. Nice Guy): Se aplica al ges-
tor que pretende convertirse en amigo de todos. • Blob: Véase Objeto todopoderoso.

• Héroe del proletariado (proletariat hero): El “em- • BOMQ (Batch Over MQ): Abuso en el empleo de in-
pleado para todo”que siempre es puesto como ejem- tegración basada en mensajes en tiempo real para
plo ante sus compañeros, pero que realmente es la transferencias esporádicas de gran tamaño en segun-
excusa perfecta para demandas crecientes y cons- do plano.
tantes incrementos de expectativas.
• Clase Gorda: Dotar a una clase con demasiados atri-
• Estrellas nacientes (rising upstart): Se aplica a quie- butos y/o métodos, haciéndola responsable de la ma-
nes, teniendo potencial, no son capaces de respe- yoría de la lógica de negocio.
tar la progresión profesional establecida, y preten-
• Botón mágico (magic pushbutton): Tender, desarro-
den sortear los plazos y requisitos de aprendizaje y
llando interfaces, a programar la lógica de negocio
madurez.
en los métodos de interacción, implementando los
• Ejecutivo sin carácter (spineless executive): Gestor, resultados de las acciones del usuario en términos
coordinador o responsable que no tiene el coraje de no su cientemente abstractos.
enfrentarse a las situaciones, asumir las responsabi- • Carrera de obstáculos (race hazard): Incapacidad de
lidades de los errores, o dar la cara por sus subordi- prever las consecuencias de diferentes sucesiones de
nados. eventos.
• Caballero de tres cabezas (three-headed knight): • Entrada chapuza (input kludge): No especi car e im-
Gestor indeciso, poco rme, dubitativo. plementar el manejo de entradas inválidas.
• Arma de nitiva (ultimate weapon): Individuos alta- • Fábrica de combustible (gas factory): Diseñar de
mente competentes en los que la organización o sus manera innecesariamente compleja.
compañeros confían tanto que se convierten en el
canal por el que todo pasa. • Gran bola de lodo (big ball of mud): Construir un
sistema sin estructura de nida.
• Recién llegado (warm body): Trabajador que apenas
cubre las expectativas mínimas y por tanto circula de • Interfaz in ada (interface bloat): Pretender que una
proyecto en proyecto o de equipo en equipo. interfaz sea tan potente que resulta extremadamente
difícil de implementar.
• Arquitecto a obrero (super builder): Creencia por la
• Inversión de abstracción (abstraction inversion): No
que se asigna a un buen diseñador de software al
exponer las funcionalidades implementadas que los
desarrollo de código pensando en que tardara mu-
usuarios necesitan, forzando a que se reimplementen
cho menos en teclearlo.
a más alto nivel.

• Punto de vista ambiguo (ambiguous viewpoint): Pre-

7.1.2 Antipatrones de gestión de proyectos sentar un modelo sin concretar ciertos aspectos, pos-
tergando así decisiones con ictivas.
• Humo y espejos (smoke and mirrors): Mostrar cómo
será una funcionalidad antes de que esté implemen- • Re-dependencia (re-coupling): Introducir dependen-
tada. cias innecesarias entre objetos.
7.1. ALGUNOS ANTIPATRONES DE DESARROLLO DE SOFTWARE 1∧

• Sistema de cañerías de calefacción (stovepipe sys- 7.1.4 Antipatrones de programación

tem): Construir un sistema difícilmente mantenible,
ensamblando componentes poco relacionados. • Nomenclatura heroica (heroic naming): Identi car
los miembros de un programa (interfaces, clases,
propiedades, métodos...) con nombres que provocan
Antipatrones de diseño orientado a objetos que el conjunto aparente estandarización con la in-
geniería del software pero que en realidad oculta una
• Acoplamiento secuencial (sequential coupling): implementación anárquica.
Construir una clase que necesita que sus métodos • Acción a distancia (action at a distance): Provocar
se invoquen en un orden determinado. la interacción no prevista de componentes muy dis-
tantes de un sistema.
• BaseBean: Heredar funcionalidad de una clase utili-
dad en lugar de delegar en ella. • Acumular y disparar (accumulate and re): Estable-
cer una colección de variables globales para ser usa-
• Fallo de clase vacía (empty subclass failure): Crear das por un conjunto de subrutinas.
una clase que no supera el test de la subclase vacía, es
decir, que se comporta de manera diferente cuando • Ancla del barco (boat anchor): Retener partes del
se invoca desde una subclase que no añade modi - sistema que ya no tienen utilidad.
cación alguna. • Bucle activo (busy spin): Utilizar espera activa cuan-
do existen alternativas.
• Llamar a super (callsuper): Obligar a las subclases
a llamar a un método de la superclase que ha sido • Código duro (hard code): Hacer supuestos sobre
sobrescrito. el entorno del sistema en demasiados lugares de la
implementación.
• Modelo de dominio anémico (anemic domain mo-
• Complejidad no indispensable (accidental comple-
del): Usar un modelo del dominio sin ninguna lógica
xity): Dotar de complejidad innecesaria a una solu-
de negocio. Esto no es un enfoque orientado a obje-
ción.
tos porque cada objeto debería tener tanto propie-
dades como comportamiento asociado. • Código espagueti (spaghetti code): Construir sis-
temas cuya estructura es difícilmente comprensi-
• Objeto sumidero (object cesspool): Reutilizar objetos ble, especialmente debido a la escasa utilización de
no adecuados realmente para el n que se persigue. estructuras de programación.

• Objeto todopoderoso (god object): Concentrar de- • Código ravioli (ravioli code): Construir sistemas con
masiada funcionalidad en una única parte del diseño multitud de objetos muy débilmente conectados.
(clase).
• Comprobación de tipos en lugar de interfaz (chec-
king type instead of interface): Comprobar que un
• Poltergeist (informática): Emplear objetos cuyo úni-
objeto es de un tipo concreto cuando lo único que
co propósito es pasar la información a terceros ob-
se necesita es veri car si cumple un contrato deter-
jetos.
minado.
• Problema del círculo-elipse (circle-ellipse problem): • Con anza ciega (blind faith): Descuidar la compro-
Crear variables de tipo pensando en los valores de bación de los resultados que produce una subrutina,
posibles subtipos. o bien de la efectividad de un parche o solución a un
problema.
• Problema del yoyó (yo-yo problem): Construir es-
tructuras (por ejemplo, de herencia) que son difíci- • Doble comprobación de bloqueo (double-checked
les de comprender debido a su excesiva fragmenta- locking): Comprobar, antes de modi car un objeto,
ción. si es necesario hacer esa modi cación, pero sin blo-
quear para comprobarlo, de manera que dicha com-
• Singletonitis: Abuso de la utilización del patrón probación puede fallar.
singleton. • Fallo de caché (caching failure): Olvidar restablecer
una marca de error cuando éste ya ha sido tratado.
• YAFL (yet another fucking layer, y otra maldita ca-
pa más) o 'Código Lasagna': Añadir capas innece- • Lava seca (lava ow): Código muerto e información
sarias a un programa, biblioteca o framework. Esta de diseño olvidada permanecen congelados en un di-
tendencia se extendió bastante después de que se pu- seño cambiante. Esto es análogo a un ujo de lava
blicase el primer libro sobre patrones. en el que se van endureciendo pedazos de roca. La
1∨ CAPÍTULO 7. ANTIPATRÓN DE DISEÑO

solución incluye un proceso de gestión de la con- • Desfactorización (de-factoring): Eliminar funciona-

guración que elimina el código muerto y permite lidad y reemplazarla con documentación.
evolucionar o rehacer el diseño para acrecentar la
calidad. • Factor de improbabilidad (improbability factor):
Asumir que es improbable que un error conocido
• Lógica super-booleana (superboolean logic): Em-
cause verdaderos problemas.
plear comparaciones o abstracciones de la lógica
booleana innecesarias.
• Martillo de oro (golden hammer): Asumir que nues-
• Manejo de excepciones (exception handling): Em- tra solución favorita es universalmente aplicable, ha-
plear el mecanismo de manejo de excepciones del ciendo bueno el refrán a un martillo, todo son clavos.
lenguaje para implementar la lógica general del pro-
grama. • Optimización prematura (premature optimization):
Realizar optimizaciones sin disponer de la informa-
• Manejo de excepciones inútil (useless exception ción su ciente para hacerlo con garantías, sacri -
handling): Introducir condiciones para evitar que se cando decisiones de diseño.
produzcan excepciones en tiempo de ejecución, pero
lanzar manualmente una excepción si dicha condi-
• Programación de copiar y pegar (copy and paste pro-
ción falla.
gramming): Programar copiando y modi cando có-
• Momento del código (code momentum) : Establecer digo existente en lugar de crear soluciones genéri-
demasiadas restricciones sobre una parte del sistema cas.
debido a la asunción de muchas de sus propiedades
desde otros lugares del propio sistema. • Programación por permutación (programming by
permutation): Tratar de aproximarse a una solución
• Números mágicos (magic numbers): Incluir en los modi cando el código una y otra vez para ver si aca-
algoritmos números concretos sin explicación apa- ba por funcionar.
rente.

• Ocultación de errores (error hiding): Capturar un • Reinventar la rueda (reinventing the wheel): Enfren-
error antes de que se muestre al usuario, y reem- tarse a las situaciones buscando soluciones desde ce-
plazarlo por un mensaje sin importancia o ningún ro, sin tener en cuenta otras que puedan existir ya
mensaje en absoluto. para afrontar los mismos problemas.

• Packratting: Consumir memoria en exceso debido • Reinventar la rueda cuadrada (reinventing the square
a no liberar objetos reservados dinámicamente una wheel): Crear una solución pobre cuando ya existe
vez ya han dejado de ser necesarios. una buena.

• Programación por excepción (coding by exception):

Añadir trozos de código para tratar casos especiales
a medida que se identi can. 7.1.6 Antipatrones de gestión de la con -
guración
• Secuencia de bucle por casos (Loop-switch sequen-
ce): Programar un conjunto de pasos secuenciales • Con icto de extensiones (extension con ict): Proble-
usando un bucle en combinación con una estructura mas con diferentes extensiones que tratan de gestio-
de control por casos. nar las mismas partes del sistema (especí co de Mac
• Cadenas mágicas (magic strings): Incluir cadenas de OS).
caracteres determinadas en el código fuente para ha-
cer comparaciones, como tipos de eventos, etc. • In erno de dependencias (dependency hell): Esce-
nario de problemas producidos por las versiones de
otros productos que se necesitan para hacer funcio-
7.1.5 Antipatrones metodológicos nar un tercero.

• Bala de plata (silver bullet): Asumir que nuestra so- • In erno DLL (DLL hell): Problemas con las
lución técnica favorita puede resolver un problema versiones, disponibilidad o proliferación de
mucho mayor. DLLs (especí co de Microsoft Windows)
• Desarrollo conducido por quien prueba (tester dri- • In erno JAR (JAR hell): Problemas con dife-
ven development): Permitir que un proyecto softwa- rentes versiones o ubicaciones de cheros JAR
re avance a base de extraer sus nuevos requisitos de (Java), típicamente causados por la falta de
los informes de errores. comprensión del modelo de carga de clases.
7.3. RELACIÓN ALFABÉTICA DE OTROS ANTIPATRONES 1∩

7.2 Algunos antipatrones organi- • Sistema de cañerías (stovepipe): Tener una organi-
zación estructurada de manera que favorece el ujo
zacionales de información vertical, pero inhibe la comunica-
ción horizontal.
• Alcance incremental (scope creep): Permitir que el
alcance de un proyecto crezca sin el control adecua- • Te lo dije (I told you so): Permitir que la atención se
do. centre en que la desoída advertencia de un experto
se ha demostrado justi cada.
• Dependencia de proveedor (vendor lock-in): Cons-
truir un sistema que dependa en exceso de un com- • Gallina de los huevos de oro (cash cow): Pecar de au-
ponente proporcionado por un tercero. tocomplacencia frente a nuevos productos por dis-
poner de un producto legacy muy lucrativo.
• Diseño en comité (design by committee): Contar con
muchas opiniones sobre un diseño, pero adolecer de
falta de una visión uni cada. 7.3 Relación alfabética de otros an-
• Escalada de compromiso (escalation of commit- tipatrones
ment): No ser capaz de revocar una decisión a la
vista de que no ha sido acertada. • Arrojar al otro lado del muro (thrown over the wall):
Cuando un proyecto involucra a varios grupos de
• Funcionalitis creciente (creeping featuritis): Añadir trabajo y va pasando secuencialmente de uno a otro,
nuevas funcionalidades al sistema en detrimento de con escasa o nula comunicación entre ellos.
su calidad.
• Billete lobo (wolf ticket): Declarar compatibilidad
• Gestión basada en números (management by num- con un estándar cuando ésta no existe, o bien cuando
bers): Prestar demasiada atención a criterios de ges- el estándar solo incluye recomendaciones no obliga-
tión cuantitativos, cuando no son esenciales o difí- torias que, de hecho, no se siguen.
ciles de cumplir.
• Fiesta de los bocazas (Blowhard Jamboree): Cuando
• Gestión de champiñones (mushroom management): se intenta que las decisiones técnicas del proyecto
Tratar a los empleados sin miramientos, sin infor- sean las basadas en opiniones de expertos publicadas
marles de las decisiones que les afectan (mantenién- en prensa.
dolos cubiertos y en la oscuridad, como los champi-
ñones). • Cadena sin longitud (string without length).

• Gestión porque lo digo yo (management by perkele): • Cajas de diálogos en cascada (cascading dialog bo-
Aplicar una gestión autoritaria con tolerancia nula xes).
ante las disensiones. • Callejón sin salida (dead end): Encontrar un proble-
ma que impide continuar trabajando, pero la direc-
• Migración de costes (cost migration): Trasladar los
ción no permite corregir el problema. El equipo que-
gastos de un proyecto a un departamento o socio de
da estancado.
negocio vulnerable.
• Caminar por un campo de minas (walking through
• Obsolescencia continua (continuous obsolescence): a mine eld): Trabajar con un componente pobre-
Destinar desproporcionados esfuerzos a adaptar un mente probado (usualmente inestable), y por tanto
sistema a nuevos entornos. poco con able.
• Organización de cuerda de violín (violin string orga- • Chivo expiatorio (scape goat): Ante circunstancias
nization): Mantener una organización a nada y en de crisis en un proyecto se toma la decisión de di-
buen estado, pero sin ninguna exibilidad. rigir las culpas a una persona o a un conjunto de
personas concretas sin analizar si verdaderamente la
• Parálisis por análisis (analysis paralysis): Dedicar naturaleza del problema se encuentra en las mismas.
esfuerzos desproporcionados a la fase de análisis
de un proyecto, eternizando el proceso de diseño • Codi cación brutal: Presionar a los programadores
iterando sobre la búsqueda de mejores soluciones o a trabajar sobre una arquitectura sin diseñar y sin
variantes. requisitos evidentes.

• Peligro moral (moral hazard): Aislar a quien ha to- • Comité designado (appointed team): Crear un comi-
mado una decisión a raíz de las consecuencias de la té o grupo de trabajo para resolver un problema y no
misma. ocuparse de lograr que el grupo funcione.
1∪ CAPÍTULO 7. ANTIPATRÓN DE DISEÑO

• Compensación equitativa (egalitarian compensa- • El correo electrónico es peligroso (email is dange-

tion): Compensar al personal por el trabajo indivi- rous): Peligro de olvidar que detrás de los emails re-
dual hecho. cibidos hay personas de carne y hueso.

• Contenedor mágico (magic container): La imple- • El gestor controla el proceso (manager controls pro-
mentación de métodos que intentan ser tan exibles cess).
como para adaptar su comportamiento a multitud de • El traje nuevo del emperador (emperor's new clot-
circunstancias, sobrepasando el umbral de una man- hes): Temor a señalar los defectos de un producto o
tenibilidad adecuada del mismo. proceso que un gerente o manager cree que funciona
• Cuerpos tibios (warm bodies). bien.
• El viejo gran duque de York (the grand old Duke of
• Culto al carguero (cargo cult): Consiste en copiar York): Cuando los arquitectos o analistas no inter-
ciertas prácticas que podrían ser consideradas (no vienen (uno o los dos), dejando a los programadores
siempre) buenas prácticas sin saber muy bien los (especialistas en la implementación) prácticamente
bene cios o ventajas que proporcionan, provocando todas las decisiones a nivel e ejecución de las espe-
esfuerzo innecesario en el proyecto para incorporar- ci caciones del usuario.
las o problemas.
• Ellos me entendieron (they understood me): Expli-
• Cultura del miedo (fear culture)): Ambiente en el car a programadores o diseñadores junior lo que se
que cada empleado tiene miedo de mostrar el resul- espera de ellos muy brevemente, y asumir que en-
tado de su trabajo por miedo a ser despedido por tendieron lo que se les pidió.
tener errores.
• Embudo de excepciones (exception funnel): Atrapar
• Cultura del héroe (hero culture): Se produce cuando una excepción e ignorarla, sin reportarlo.
una o pocas personas toman la responsabilidad del
• Entrenar al entrenador (train the trainer): Contratar
éxito de todo el equipo o proyecto, a menudo traba-
una formación sin haber precisado con cierta exac-
jando sobretiempo.
titud la materia sobre la que se desea la misma. Es-
• Decisión aritmética (decision by arithmetic): En lu- to puede provocar que la formación no se enfoque
gar de intentar tomar una decisión con los datos dis- de manera adecuada, tratando aspectos que no son
ponibles y basado en el conocimiento y experiencia necesarios en el proyecto o dejando fuera aspectos
de nuestros colaboradores y el nuestro, se trata de fundamentales. Contratar una formación sin tener
justi car la misma sobre la base de unos factores referencias del formador, ya que lo mismo su nivel
presuntamente objetivos. de conocimiento no es el adecuado a la naturaleza
de la formación a impartir.
• Desarrollo distribuido geográ camente (geographi-
cally distributed development). • Es un problema de operadores (it is an operator pro-
blem).
• Desarrollo marcado por las herramientas (autogene-
• Esconder las armas (cover your assets).
rated stovepipe): Preferir una solución generada au-
tomáticamente sobre la mejor solución. • Falsa economía (false economy): Permitir que los
recortes de presupuesto afecten la e ciencia de los
• Descomposición funcional (functional decomposi- trabajadores (las pérdidas terminan siendo mayores
tion): Traducir un programa de un lenguaje estruc- que lo ahorrado).
turado a uno OO usando una sola clase y muchos
métodos privados. • Falso punto nal subrogado (false surrogate end-
point).
• Diseñar por diseñar (design for the sake of design):
Realizar un diseño excesivamente complejo sin ne- • Fechas en punto otante ( oating point times).
cesidad real. • Haz tu propia base de datos (roll your own databa-
se): Ante la necesidad de persistencia de datos se
• Diseño con arquitectura impuesta (architecture as utiliza una solución que no se basa en un estándar.
requirement): Imponer que el diseño considere, obli-
gatoriamente, el uso de herramientas o métodos no • Ingenieros compatibles e intercambiables (plug
necesariamente idóneos. compatible interchangeable engineers).

• Diseño de fregadero (kitchen sink design). • Introducción de di cultad por analogía (analogy
breakdown): Diseñar por analogía con problemas
• Diseñadores empíricos (architects don't code): Inca- resueltos, posiblemente introduciendo di cultades
pacidad del grupo de diseño para evaluar la comple- no inherentes al problema, o descuidando di culta-
jidad del objeto diseñado. des propias del nuevo caso que se maneja.
7.3. RELACIÓN ALFABÉTICA DE OTROS ANTIPATRONES 19

• Invocar a constructores con nulos (passing nulls to contingencias del proceso de desarrollo, o cuando no
constructors). se es exible ante una plani cación inicial, conser-
vándose a lo largo del proyecto pese a que se pueda
• La disputa familiar (the feud): Cuando existiendo un apreciar que resulta absolutamente irreal.
con icto entre gestores de proyectos no se le busca
una solución de nitiva al mismo. • Nacionalismo (national ism).

• La experiencia mata el diseño (architecture by im- • Navaja suiza (swiss army knife): Intentar crear un
plication): Descuidar el diseño por con ar excesiva- producto que solucione varios problemas poco rela-
mente en la experiencia previa. cionados entre sí.

• Los clientes son tontos (customers are idiots): Pensar • No es mi trabajo (Not my job): No solucionar algún
que uno sabe más que el cliente, y por tanto no es problema evidente argumentando que es problema o
necesaria una investigación con el cliente. fallo de otro.

• Maníaco del control (control freak): El deseo de • No especi car (specify nothing).
control lleva a la microgestión y ésta a su vez a una • No inventado aquí (not invented here): Cuando la or-
pérdida importante de la capacidad de autogestión ganización o uno se niega a utilizar soluciones, me-
del equipo, ya que todos los pasos se miden milimé- todologías, prácticas, herramientas, etc. externas só-
tricamente. lo porque no se nos ocurrió previamente.
• Máquina de Rube Goldberg (Rube Goldberg machi- • Otra reunión más lo resolverá (yet another meeting
ne): Realizar implementaciones muy complejas para will solve it): Ante un problema en la plani cación
tareas sencillas. del proyecto, se convocan reuniones para intentar
dar una solución al problema. En éstas reuniones
• Matar al mensajero (shoot the messenger). participan los miembros del equipo de proyecto que
• Matar dos pájaros de un tiro (kill two birds with one tendrán que dejar su trabajo habitual, produciéndo-
stone). se nuevos retrasos.

• Matrimonio sumarísimo (sumo marriage): Suele • Otro programador más (yet another programmer).
ocurrir en cualquier situación en la que exista una • Presunto heredero (heir apparent): Cuando vemos
dependencia de un elemento o de una serie de facto- que los posibles huecos que podrían quedar para se-
res que di cultan el mantenimiento o evolución del guir progresando en nuestra organización tienen ya
sistema. nombres y apellidos (cuando además sus méritos son
más que discutibles), provocará la salida de la orga-
• Mazorca de maíz (corn cob): Mantener personas en
nización en busca de otras alternativas o se produci-
el proyecto que resultan difíciles, con ictivas o que
rá una pérdida de motivación que impactará direc-
funcionan de manera absolutamente al margen de lo
tamente en la productividad.
que es cualquier trabajo en equipo o de un compor-
tamiento solidario y que rompen con la armonía del • Proceso a prueba de idiotas (idiot proof process).
grupo.
• Programador discordante (net negative producing
• Mecanismos de recompensa discordantes (discor- programmer): Hay proyectos donde el rendimiento
dant reward mechanisms): Un equipo recibe reco- de uno o más miembros del equipo es muy inferior
nocimiento por ser el que más trabajo ejecuta sobre al esperado, hasta el punto de ser su productividad
la base de criterios objetivos que no son válidos para neta en el proyecto negativa (el proyecto mejoraría
medir el nivel de productividad o calidad. con el simple hecho de prescindir de estas personas,
sin necesidad de sustituirlas por otra)
• Mezclador de software (software merger).
• Proyecto del día de la marmota (ground hog day pro-
• Miedo al éxito (fear of success): Permitir que las ject): Discutir los mismos temas en todas las reunio-
únicas razones de que los trabajos no se completen nes, sólo para llegar a la conclusión de que “algo
sean de índole social. debe hacerse”.
• Moneda en punto otante ( oating point currency): • Prueba incompleta (asynchronous unit testing): Des-
Utilizar una representación en punto otante para cuidar en la etapa de pruebas, algunas unidades en
valores que representan dinero, lo que puede provo- todos los casos, o todas las unidades en algunos ca-
car pérdida de precisión. sos.
• Morir plani cando (death by planning): Invertir más • Quiero estimaciones ahora (give me estimates now):
esfuerzo (y tiempo) del necesario para establecer un Dar estimaciones sin tener su cientes datos para ha-
plan que después puede ser destruido por las propias cerlas.
20 CAPÍTULO 7. ANTIPATRÓN DE DISEÑO

• Requisitos esparcidos por la pared (requirements tos- • Violencia intelectual (intellectual violence): De ma-
sed over the wall): Existe un desorden general en los nera interna en un equipo de trabajo o en una
requisitos: se encuentran en distinto grado de termi- reunión con el cliente y/o con usuarios se utilizan
nación, no hay priorización de los mismos o es muy términos, generalmente técnicos, que no son com-
general como para poder hacer una ordenación ade- prendidos o conocidos por la mayoría de los inter-
cuada por ese criterio, etc. Esto normalmente es pro- locutores.
vocado por una colaboración inadecuada por parte
del área usuaria.
• Requisitos ocultos (Hidden requirements): El equipo 7.4 Véase también
de proyecto conocedor de la di cultad de implemen-
tar un determinado requisito lo obvia dentro del ca- • Patrón de diseño
tálogo de requisitos, le asigna una prioridad muy ba-
• Crisis del software
ja o lo engloba dentro de un requisito de mayor nivel
quedando difuminado en el mismo. El área usuaria • Hediondez del código
no especi ca un requisito o no lo especi ca de ma-
nera adecuada, solicitando explicaciones a posterio- • No hay balas de plata
ri por la no implementación de ese requisito o por
su comportamiento incorrecto.
• Si funciona, no lo toques (if it is working don't chan-
7.5 Enlaces externos
ge):.
• [Link] (antipatrones) Portland Pattern Reposi-
• Somos tontos (we are idiots): Pensar que el conoci- tory's Wiki
miento 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 ma-
yor.
• 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 tar-
jeta CRC (Class-Responsibility-Collaboration)
en CRCI (Class-Responsibility-Collaboration-
Implementation).
• 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 con-
secució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 ma-
nera que después es imposible deshacerse de ella.
• Único punto de salida de función (single function exit
point).
• Valor por defecto inde nido (zero means null): Es-
coger un valor arbitrario para representar la inde ni-
ción, sin garantizar que ese valor no puede realmente
ocurrir.
Capítulo 8

Archivo de cabecera

Se denomina header file, al español chero/archivo (de) Sin embargo en esta simple ilustración se requiere que
cabecera, o include file, al español chero de inclu- el programador mantenga la declaración de la función de
sión, en ciencias de computación, especialmente en el add en dos sitios ̶en el archivo que contiene su imple-
ámbito de los lenguajes de programación C y C++, al mentación y en el archivo que usa la funcionalidad. Si
archivo, normalmente en forma de código fuente, que el la de nición de la función llega a alterarse, entonces el
compilador incluye de forma automática al procesar al- programador debe actualizar todos los prototipos repar-
gún otro archivo fuente. Típicamente los programadores tidos a lo largo del programa. Esto es necesario porque
especi can la inclusión de los header les por medio de la implementación de ambos, C y C++ han de diagnosti-
pragmas al comienzo (head o cabecera) de otro archivo car todas las violaciones de lo que en C++ se llama "one
fuente. de nition rule" (ODR), al español “regla de una única
Un header le contiene, normalmente, una declaración de nición”. De hecho, la mayoría de ellos se sirven de
directa de clases, subrutinas, variables, u otros un enlazador para realizar esta labor. El enlazador, sin
identi cadores. Aquellos programadores que desean embargo, suele conocer, de forma muy limitada los tipos
declarar identi cadores estándares en más de un archivo usados en los programas. Por ello, algunas de las viola-
fuente pueden colocar esos identi cadores en un único ciones de ODR no se detectan a la hora de implemen-
header le, que se incluirá cuando el código que contiene tar el lenguaje. Como resultado, es responsabilidad del
sea requerido por otros archivos. programador el mantener la coherencia de todas las de-
claraciones que cruzan las fronteras de una unidad por
La biblioteca estándar de C y la biblioteca estándar de traducir. Buscar todas estas declaraciones de una entidad
C++ tradicionalmente declaran sus funciones estándar en externa y ver car que son compatibles de forma manual
header les. es una tarea ardua. (Nótese que C no de ne el término
“one de nition rule”̶es especí co del lenguaje C++.
Si declaraciones de la misma entidad en muchos archivos
fuentes de C son diferentes, la función no funcionará de
8.1 Motivación forma adecuada y puede llegarse a un comportamiento
impredecible, independientemente de la regla que se esté
En la mayoría de lenguajes de programación modernos, violando.)
los programadores pueden dividir los programas en com- Para entender una violación ODR, considérese el siguien-
ponentes de menor tamaño (como pueden ser clases y te código (correcto):
subrutinas) y distribuir esos componentes entre muchas
/* File print-heading.c */ #include <stdio.h> void
unidades por traducir (típicamente en forma de archivos),
print_heading(void) { printf(“standard heading\n”); }
que el sistema puede compilar de forma autónoma. Si una
/* File main.c */ void print_heading(void); int main(void)
subrutina se tiene que usar al margen de la unidad por
{ print_heading(); return 0; }
traducir donde ha sido de nida, se tiene que introducir el
concepto de declaración directa o prototipos de funcio-
nes. Por ejemplo, una función de nida así en un archivo La unidad por traducir representada por el archivo fuen-
fuente: te main.c referencia a la función print_heading() que está
de nida 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 fun-
int 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) {
exible 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 <stdio.h> void Normalmente, los programadores sólo utilizan los hea-
print_heading(const char *heading) { printf("%s\n”, der les para especi car 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 su-
main.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 inli-
vee ningún valor. Al ejecutar este programa se produce un ne", que suelen incluirse en header les porque la mayoría
comportamiento impredecible: la aplicación puede im- de implementaciones no pueden expendir funciones inli-
primir basura, terminar de forma inesperada o dar pie a ne de forma adecuada sin ver sus de niciones 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 pro-
blema alguno? El motivo es que el compilador se guía por 8.2 Alternativas
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 for- Los header les no son la única solución al problema de
ma de la función. Más tarde, cuando el enlazador combina acceder identi cadores declarados en diferentes archivos.
las unidades de traducción ya compiladas main.c y print- Tienen la desventaja de que los programadores siguen te-
heading.c (en la mayoría de implementaciones represen- niendo que realizar cambios en dos sitios diferentes (en
tadas como archivos main.o o [Link]), probablmente el archivo fuente y en el header le) cuando se realiza un
podría detectar la inconsistencia ̶pero no en C. Las cambio en una de nición. Algunos lenguajes más jóve-
implementaciones en C referencian las funciones por el nes (como Java) prescienden de los header les y usan, en
nombre al nivel de archivo objeto y archivo binario, esto su lugar, una esquema de nombres que permite al compi-
no incluye el valor de retorno o la lista de argumentos. El lador localizar los archivos fuente asociados con imple-
enlazador encuentra una referencia a print_heading() en mentaciones de clases e interfaces (pero, al hacerlo, se
main.o y una función adecuada en print-heading.o. Lle- restringe la libertad a la hora de nombrar archivos). En
gado este punto, toda la información relativa a tipos de estos lenguajes, el problema de ODR se suele resolver
argumentos de funciones se pierde. por medio de dos técnicas: la primera, el compilador po-
←Cómo es entonces posible llevar a cabo declaraciones ne toda la información necesaria sobre los tipos en el có-
múltiples sin problema alguno? La solución se llama hea- digo compilado y esta información es accesisble incluso
der le. El header le de un módulo declara cada función, cuando el programa se ejecuta.; la segunda, Java y otros
objeto y tipo de dato que forma parte del interfaz públi- lenguajes modernos tienen la posiblidad de veri car el
co del módulo ̶por ejemplo, en este caso el header le número y tipo de los argumentos como método de invo-
incluiría sólo la delcaración de add. Todo aquel archivo cación. Todo esto tiene su precio: un exceso en espacio
fuente que se re era a add usa la directiva #include en el y tiempo de ejecución que no es aceptable para algunas
header le: aplicaciones donde el tiempo de respuesta es crítica.

/* File add.h */ #ifndef ADD_H #de ne ADD_H int COBOL y RPG IV tienen una forma de incluir archivos
add(int, int); #endif /* ADD_H */ llamada copybooks. Los programadores“incluyen”éstos
en la fuente del programa de forma similar a como se ha-
ce con los header les, permitiendo también reemplazar
(Nótese que el header le 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
return add(x, add(x, x)); } de la cláusula replacing...by.

Esto reduce la carga del mantenimiento: cuando una de-

nición cambia, solo se tiene que actualizar una única 8.3 Véase también
copia de la declaración (la del chero de cabecera). El
chero de cabecera también se puede incluir en el che- • Application Programming Interface
ro fuente que contiene las correspondientes de niciones,
dándole al compilador la oportunidad de comprobar si la • Interface description language
declaración y la de nición son consistentes.
• #pragma once
8.4. ENLACES EXTERNOS 23

8.4 Enlaces externos

• Esta obra deriva de la traducción de Header -
le de Wikipedia en inglés, publicada por sus edi-
tores bajo la Licencia de documentación libre de
GNU y la Licencia Creative Commons Atribución-
CompartirIgual 3.0 Unported.

• Organizing Code Files (the potential pitfalls and gui-

delines for using header les in C++)
• C++ header le inclusion rules
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 co-
mo indicación de que el programador piensa que dicho En lenguajes como Ei el, las aserciones son parte del pro-
predicado siempre se cumple en ese punto del ujo 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 := ∧; {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
ejecución. Las aserciones pueden ser una forma de documentación:
pueden describir el estado en que el código empieza su
Las aserciones suelen ser útiles para especi car progra-
ejecución (precondición), y el estado que el código espera
mas y para razonar la corrección de los mismos. Por
alcanzar cuando nalice (postcondición); asimismo pue-
ejemplo, una precondición ̶una aserción al comienzo
den servir de especi cación para los invariantes de clase.
de una sección de código ̶determina que se espera que
En Ei el, 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. Es-
Una postcondición ̶colocada al nal ̶describe el esta-
to supone una parte importante del método de diseño por
do que se espera alcanzar al nal 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 19∨9 "An axiomatic ba-
no las soportan explícitamente: la ventaja de usar senten-
sis 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 ejecu-
notación normalmente no es aceptada por los compilado-
ció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 des-
incluir aserciones mediante comentarios. A continuación
fasen (un problema que puede ocurrir con las aserciones
se incluye un ejemplo en C:
comentadas).
x = ∧; /* {x > 0} */ x = x + 1; /* {x > 1} */

Se han incluido las llaves para distinguir este uso de los

9.1.2 Aserciones en tiempo de ejecución
comentarios de su uso habitual.
Una aserción puede ser utilizada para veri car que una
Varios lenguajes de programación modernos incluyen suposición hecha por el programador durante la imple-
una sentencia de aserción, que no es más que una aserción mentación del programa sigue siendo válida durante la
que se comprueba en tiempo de ejecución. Si su evalua- ejecución del programa. Por ejemplo, considérese el si-
ción resulta falsa, se produce un “error de aserción”. guiente código en Java:
La intención de estas sentencias de aserción es facilitar la
int total = contarUsuarios(); if (total % 2 == 0) { // to-
depuración del programa, evitando que dicho fallo quede
tal es par } else { // total es impar assert(total % 2 == 1); }
sin comprobar.
El uso de aserciones ayuda al programador en las tareas
En Java, % es el operador resto (no módulo) ̶si el pri-
de 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 varia-
ble total no es negativa, así que el resto de una división
entre 2 siempre será 0 o 1. La aserción explicita esta su-

24
9.2. DESACTIVACIÓN DE LAS ASERCIONES 2∧

posición ̶si contarUsuarios devuelve un valor negativo, 9.2 Desactivación de las aserciones
es probable que haya un fallo en el programa.
Una gran ventaja de esta técnica es que cuando se produce Las aserciones suelen ser implementadas de modo que
algún error éste es inmediata y directamente detectado, puedan ser activadas o desactivadas, normalmente en el
evitando posibles daños colaterales ocultos. Puesto que conjunto del programa. Sin embargo, los lenguajes que
un error de aserción normalmente informa de la línea de distinguen entre distintos tipos de aserciones – [Link]. pre
código donde se produce, se puede localizar el error sin y postcondiciones – suelen permitir activarlas o desacti-
necesidad de una depuración más exhaustiva. varlas de forma independiente. Si las aserciones son des-
activadas, no se comprueban en tiempo de ejecución. De
Las aserciones también suelen colocarse en puntos que
esta forma el programador puede colocar aserciones en
se supone que no se alcanzan durante la ejecución. Por
lugares donde en otro caso no tendría sentido ponerlas
ejemplo, las aserciones pueden ser colocadas en la cláu-
([Link]., comprobar que no se accede a un array median-
sula default de una estructura switch en lenguajes como
te índices fuera de rango). Puesto que las aserciones son
C, C++ y Java. Los casos que intencionadamente no se
en principio una herramienta de desarrollo, normalmente
manejan pueden provocar errores que aborten el progra-
son desactivadas cuando el programa en cuestión es pu-
ma.
blicado. Por otra parte, como algunas versiones del pro-
En Java, las aserciones han sido parte del lenguaje desde grama pueden incluir aserciones y otras no, es primordial
la versión 1.4. Los errores de aserción resultan en Asser- que su desactivación no modi que el comportamiento del
tionError cuando el prorgama es ejecutado con los pará- programa. En otras palabras, las aserciones deben ser li-
metros correctos, sin los cuales las sentencias de aserción bres de efectos colaterales. Una alternativa en el caso de
son ignoradas. En C y C++, son añadidas por el chero de C o C++ es rede nir la macro assert para evaluar la ex-
cabeceras estándar assert.h de niendo assert (aserción) presión incluso cuando las aserciones están desactivadas.
como una macro que devuelve un error en caso de fallo y
La eliminación de las aserciones del código de produc-
naliza 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 con-
ció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 eli-
minació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 normal-
mente ejecuta su programa con las aserciones activadas.
Cuando una aserción resulta falsa y se produce el corres-
pondiente error, el programador automáticamente recibe 9.3 Comparación con los maneja-
un aviso. Muchas implementaciones además detienen la dores de errores
ejecución del programa ̶esto resulta útil ya que si el pro-
grama sigue ejecutándose tras la violación de una aser-
Es importante establecer las semejanzas y diferencias en-
ció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 in-
aserciones deberían ser utilizadas para documentar situa-
formación proporcionada por el error de aserción (punto
ciones lógicamente imposibles y descubrir posibles erro-
del 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 pro-
algo fundamental está claramente equivocado. Esto di e-
gramador 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 depura-
error son posibles, aunque deberían ser muy poco proba-
ció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
9.1.4 Aserciones estáticas los errores, y un fallo de aserción suele suponer una ter-
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 pa-
metaprogramación de plantillas. ra manejar un error:
2∨ CAPÍTULO 9. ASERCIÓN (INFORMÁTICA)

int *ptr = malloc(sizeof(int) * 10); assert(ptr != NULL);

// usar ptr

Aquí, el programador advierte que malloc puede devol-

ver un puntero a NULL si no resulta posible realizar la
asignación de memoria. Esto es posible: el sistema opera-
tivo 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ógi-
camente 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 utiliza-
ción mixta de aserciones y rutinas estándar de control de
errores para un mismo problema. Esto es útil en situacio-
nes 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 nal pue-
da ejecutar el programa sin recibir mensajes de error in-
necesarios. Esta táctica solamente resulta útil cuando el
error especi cado 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 e ciente.

9.4 Enlaces externos

• Hoare, C. A. R. (2001). «Assertions: a perso-
nal perspective». [Link]. Archiva-
do desde el original el 02 de diciembre de 201∧.
• «Programming With Assertions in Java». ja-
[Link]. Archivado desde el original el 02 de di-
ciembre de 201∧.

• «Using Assertions». [Link]. Artículo técnico.

Capítulo 10

Automatización de tareas

La automatización de tareas es, en informática, el con-

junto de métodos que sirven para realizar tareas repetiti-
vas en un ordenador. Algunos métodos para la automati-
zación de tareas son la programación simple, los macros,
los intérpretes y las bombas lógicas. También hay algunos
programas especí cos que automatizan tareas. Incluso los
virus informáticos utilizados de forma bené ca podrían
considerarse otro método para la automatización de ta-
reas para el usuario.

2∩
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 signi cado de la colec-
ción completa de código fuente usada para construir una
aplicación o componente particular. Típicamente, el co-
debase 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
con guración y de propiedades.
El codebase para un proyecto es típicamente almacena-
do en un repositorio de control de fuentes. Un reposito-
rio del código fuente es un lugar en donde son guardadas
grandes cantidades de código fuente, tanto públicamen-
te como privadamente. Son frecuentemente usados por
proyectos de multi-desarrolladores para manejar, de una
manera organizada, varias versiones y los con ictos que
se presentan con los desarrolladores sometiendo modi -
caciones con ictivas. Subversion y Mercurial son herra-
mientas populares usadas para manejar este ujo de tra-
bajo, y son comunes en proyectos de fuente abierta.
Re riéndose a múltiples codebases como “distintos”se
declara que hay implementaciones independientes sin có-
digo fuente compartido y que históricamente, estas im-
plementaciones no evolucionaron de un proyecto común.
En el caso de estándares, esto puede ser una manera de
demostrar interoperabilidad mostrando dos piezas inde-
pendientes de software que implementan un estándar da-
do.

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)

2∪
Capítulo 12

Bean

Un Bean es un componente software que tiene la particu-

laridad de ser reutilizable y así evitar la tediosa tarea de
programar los distintos componentes uno a uno. Se pue-
de decir que existen con la nalidad 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 ejem-
plo, ya estarán familiarizados con ellos. Un Bean puede
representar desde un botón, un grid de resultados, un pa-
nel contenedor o un simple campo de texto, hasta otras
soluciones mucho más complejas como conexiones a ba-
ses 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 pri-
vados.
- 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 ejecu-

tables 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 soft-
ware y así poder informar de éstos para que los desarro-
lladores los corrijan, o corregirlos ellos mismos. Algu-
nas compañías los contratan para asegurarse de que sus
programas van a funcionar lo mejor posible en el merca-
do. Otro tipo de beta testers son los que trabajan desinte-
resadamente ofreciendo soporte y ayuda a la comunidad
GNU.
Generalmente el“betatester”comparte una cierta a ni-
dad con la herramienta puesta a prueba en cuestión, de ahí
el entusiasmo por probarla, veri car nuevas funcionalida-
des 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 re ere a la bifurcación Soy el padre con id 1 id proceso original 1 Soy el hijo con
de procesos en sistemas operativos, consulta id 2 id proceso original 1
Bifurcación (informática) para otros usos. El orden de la salida será determinada por diversos pa-
rámetros del núcleo del sistema operativo. Como se pue-
Una bifurcación o fork, cuando se aplica en el contex- de observar, el valor contenido en la variable idPropio es
to de un lenguaje de programación o un sistema operati- compartido por proceso padre e hijo; sin embargo, la re-
vo, hace referencia a la creación de una copia de sí mis- ferencia a la variable no es la misma y su posterior modi-
mo por parte de un programa, que entonces actúa como cación en cada código, ya sea del padre o del hijo, no se
un "proceso hijo" del proceso originario, ahora llamado verá re ejada en ambos procesos.
"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 14.2 Véase también
multihilo signi ca que un hilo de ejecución se bifurca.
• 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 bifurca-
ción del proceso. Esta llamada devuelve el identi cador
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 <stdio.h> #include <unistd.h> #include
<sys/types.h> int main(void) { pid_t idHijo; pid_t idPro-
pio; 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 noti ca 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 identi cador 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.1 Psicología y educación 15.4 Enlaces externos

En Psicología, el término binding se re ere a una metodo- • [Link] - Información sobre el pro-
logía innovadora (Proyecto Binding) para enseñar a leer grama 'Binding'
que nace de aplicar la evidencia cientí ca en el ámbito
del aprendizaje, desarrollada por la Universidad de Bar-
celona. Saber cómo trabaja nuestro cerebro para realizar
una tarea tan complicada como la lectura es esencial pa-
ra poder crear las mejores técnicas de aprendizaje lector
([Link]
Aunque todavía queda mucho camino por recorrer en es-
te 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í camente que
es importante a la hora de adquirir la lectura - decodi-
cació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 refe-

rencia 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 adap-
tació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 rmado
y no forzar ninguna norma superior.

32
Capítulo 16

Bloqueo mutuo

En sistemas operativos, el bloqueo mutuo (también co-

nocido como interbloqueo, traba mortal, deadlock, abra-
zo mortal) es el bloqueo permanente de un conjunto de A
procesos o hilos de ejecución en un sistema concurren-
te que compiten por recursos del sistema o bien se co-
munican entre ellos. A diferencia de otros problemas de
concurrencia de procesos, no existe una solución general
para los interbloqueos. R1 R2
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 echa, uno toma el arco, el otro
la echa. Ninguno puede jugar hasta que alguno libere lo B
que tomó.
En el siguiente ejemplo, dos procesos compiten por dos
Ejemplo de representación de Bloqueo Mutuo en grafos de alo-
recursos que necesitan para funcionar, que sólo pueden cación de recursos con dos procesos A y B, y dos recursos R1 y
ser utilizados por un proceso a la vez. El primer proceso R2.
obtiene el permiso de utilizar uno de los recursos (adquie-
re el lock sobre ese recurso). El segundo proceso toma el
lock del otro recurso, y luego intenta utilizar el recurso 16.2 Condiciones necesarias
ya utilizado por el primer proceso, por lo tanto queda en
espera. Cuando el primer proceso a su vez intenta utilizar También conocidas como condiciones de Co man por
el otro recurso, se produce un interbloqueo, donde los dos su primera descripción en 19∩1 en un artículo escrito por
procesos esperan la liberación del recurso que utiliza el E. G. Co man.
otro proceso.
Estas condiciones deben cumplirse simultáneamente y no
son totalmente independientes entre ellas.
Sean los procesos P0 , P1 , ..., Pn y los recursos R0 , R1 , ...,
16.1 Representación de Bloqueos Rm :
Mutuos usando grafos
• Condición de exclusión mutua: existencia de al
menos de un recurso compartido por los procesos,
El Bloqueo mutuo también puede ser representado usan-
al cual sólo puede acceder uno simultáneamente.
do grafos dirigidos, donde el proceso es representado por
un cuadrado y el recurso, por un círculo. Cuando un pro-
ceso solicita un recurso, una echa es dirigida del círculo • Condición de retención y espera: al menos un pro-
al cuadrado. Cuando un recurso es asignado a un proceso, ceso Pi ha adquirido un recurso Ri , y lo retiene mien-
una echa es dirigida del cuadrado al círculo. tras espera al menos un recurso Rj que ya ha sido
asignado a otro proceso.
En la gura del ejemplo, se pueden ver dos procesos dife-
rentes (A y B), cada uno con un recurso diferente asigna-
do (R1 y R2). En este ejemplo clásico de bloqueo mutuo, • Condición de no expropiación: los recursos no
es fácilmente visible la condición de espera circular en pueden ser expropiados por los procesos, es decir,
la que los procesos se encuentran, donde cada uno solicita los recursos sólo podrán ser liberados voluntaria-
un recurso que está asignado a otro proceso. mente por sus propietarios.

33
34 CAPÍTULO 16. BLOQUEO MUTUO

• Condición de espera circular: dado el conjunto • La condición de espera circular es la más fácil de
de procesos P0 ...Pm (subconjunto del total de proce- atacar. Se le permite a un proceso poseer sólo un
sos original),P0 está esperando un recurso adquirido recurso en un determinado momento, o una jerar-
por P1 , que está esperando un recurso adquirido por quía puede ser impuesta de modo tal que los ciclos
P2 ,... ,que está esperando un recurso adquirido por de espera no sean posibles.
Pm , que está esperando un recurso adquirido por P0 .
Esta condición implica la condición de retención y
espera. 16.5 Livelock
Un livelock es similar a un deadlock, excepto que el estado
16.3 Evitando bloqueos mutuos de los dos procesos envueltos en el livelock constantemen-
te cambia con respecto al otro. Livelock es una forma de
Los bloqueos mutuos pueden ser evitados si se sabe cier- inanición y la de nición general sólo dice que un proceso
ta información sobre los procesos antes de la asignación especí co 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 in-
ejemplo cuando dos personas, al encontrarse en un pa-
seguro, 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 adelanta-
hacia 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 detec-
varios algoritmos para evitar bloqueos mutuos: tan y recuperan los interbloqueos, pues si más de uno to-
ma cartas en el asunto, la detección del interbloqueo pue-
• Algoritmo del banquero, introducido por Dijkstra. de ser disparada continuamente; pudiendo ser arreglado
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.
• Algoritmo de solicitud de recursos.

16.4 Prevención
Los bloqueos mutuos pueden prevenirse asegurando que
no suceda alguna de las condiciones necesarias vistas an-
teriormente.

• Eliminando la exclusión mutua: ningún proceso pue-

de tener acceso exclusivo a un recurso. Esto es im-
posible 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 elimi-

nada haciendo que los procesos pidan todos los re-
cursos que van a necesitar antes de empezar. Este
conocimiento por adelantado muchas veces es im-
posible nuevamente. Otra forma es requerir a los
procesos liberar todos sus recursos antes de pedir to-
dos 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 po-
der tener un recurso por un cierto tiempo o el pro-
cesamiento puede quedar inconsistente.
Capítulo 17

Bodyshopping

Bodyshopping es un término ligado al mundo empresa- • Las consultoras informáticas :: [Link]

rial informático o tecnológico que hace referencia a la
venta de capital humano. Conlleva la cesión de personal • Podcast monográ co sobre consultoría
de este tipo a terceras empresas con ánimo de lucro.
Término que proviene del inglés que podríamos de nir
como anglicismo o extranjerismo y que en su traducción
literal hace referencia a la compra de cuerpos. Una for-
ma castiza de denominar estas empresas es charcuteras o
cárnicas.
Esta práctica es muy habitual en el mundo de la consulto-
ría informática y existen multitud de empresas que basan
su negocio en esta "venta" de personal actuando prácti-
camente 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 terce-
ras empresas como profesionales altamente cuali cados y
con una gran experiencia, siendo ésta única y exclusiva-
mente la base de su negocio y de su Retorno de la inver-
sión, ya que a menos experiencia y salario del personal,
mayor bene cio 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 ex-
periencias personales de gente que ha trabajado en
ellas.
• Trabajungla Experiencias personales y salarios so-
bre estas empresas revelados de forma anónima.
• El Informático Impasible: Outsourcing: OnShore y
O Shore
• El Sector de la Consultoría Informática en España «
Peccata Minuta
• Entendiendo el Bodyshopping « Peccata Minuta

3∧
Capítulo 18

BrookGPU

BrookGPU fue desarrollado por la Universidad de Stan-

ford, es un grupo de compiladores y aplicaciones basa-
das en el lenguaje Brook para utilizar con unidades de
procesamiento grá co (GPU). la programación con uni-
dades 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á co (GPU) tipo ATI,
NVIDIA o Grá cos integrados Intel, capaces de soportar
gran paralelismo. BrookGPU compila programas escritos
en Brook, una extensión de ANSI C diseñado para incor-
porar computación de datos paralelos y aritméticos con
un e caz y familiar lenguaje. respecto al modelo gene-
ral de programación, por ujo de datos tipo por Stream,
ofrece 2 grandes ventajas respecto a estos:

• Paralelismo de datos: permite al programador es-

peci car 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 n 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]

3∨
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 funcio-
nes internas de un módulo. Así como las pruebas de caja
negra ejercitan los requisitos funcionales desde el exte-
rior del módulo, las de caja blanca están dirigidas a las
funciones internas. Entre las técnicas usadas se encuen-
tran; la cobertura de caminos (pruebas que hagan que se
recorran todos los posibles caminos de ejecución), prue-
bas sobre las expresiones lógico-aritméticas, pruebas de
camino de datos (de nición-uso de variables), comproba-
ción de bucles (se veri can los bucles para 0,1 e interac-
ciones, 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 me-
nos complejos que los de una función de programación
estructurada). Dentro de las Pruebas de Caja Blanca en-
contramos las llamadas coberturas (sentencia, decisión,
condición y múltiple además de los mencionados cami-
nos 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

3∩
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 pala-
bras, 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

20.3 Pruebas de software
aquel elemento que es estudiado desde el punto de vista de
las entradas que recibe y las salidas o respuestas que pro- En pruebas de software, conociendo una función espe-
duce, sin tener en cuenta su funcionamiento interno. En cí ca para la que fue diseñado el producto, se pueden
otras palabras, de una caja negra nos interesará su forma diseñar pruebas que demuestren que dicha función está
de interactuar con el medio que le rodea (en ocasiones, bien realizada. Dichas pruebas son llevadas a cabo sobre
otros elementos que también podrían ser cajas negras) la interfaz del software, es decir, de la función, actuando
entendiendo qué es lo que hace, pero sin dar importan- sobre ella como una caja negra, proporcionando unas en-
cia a cómo lo hace. Por tanto, de una caja negra deben tradas y estudiando las salidas para ver si concuerdan con
estar muy bien de nidas sus entradas y salidas, es decir, las esperadas.
su interfaz; en cambio, no se precisa de nir ni conocer los
detalles internos de su funcionamiento.
20.4 Caja negra vs 'Cajanegrizar'
20.1 Justi cación Este concepto de caja negra utilizado en física, infor-
mática y disciplinas técnicas o tecnológicas en gene-
Un sistema formado por módulos que cumplan las carac- ral, aunque está relacionado, no debe confundirse con el
terísticas de caja negra será más fácil de entender ya que 'Cajanegrismo'; éste es un concepto más vinculado a la
permitirá dar una visión más clara del conjunto. El siste- sociología que hace referencia al hecho de que las perso-
ma también será más robusto y fácil de mantener, en caso nas solemos olvidarnos del funcionamiento interno de las
de ocurrir un fallo, éste podrá ser aislado y abordado más cosas (generalmente nuevos dispositivos tecnológicos) a
ágilmente. 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 cono-
ce con el nombre de 'cajanegrizar'.
20.2 Caja negra y programación
Se podría decir que la principal diferencia entre ambos
modular conceptos es que mientras el primero, el estudio de un sis-
tema 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 desa-
rrollar, 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-
grama global; el implementador de un módulo concreto • Modularidad

3∪
20.5. VÉASE TAMBIÉN 39

• Interfaz

• Interfaz de usuario
• Diseño estructurado

• Caja blanca (sistemas)

• Abstracto y Abstracción

• Cajanegrizar
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 • OmegaSoft
o palabras compuestas. El nombre se debe a que las ma- • VaxaSoftware
yúsculas a lo largo de una palabra en CamelCase se ase-
mejan a las jorobas de un camello. El nombre CamelCase • La Sexta
se podría traducir como Mayúsculas/Minúsculas Camello. • eDreams
El término case se traduce como“caja tipográ ca”, que
a su vez implica si una letra es mayúscula o minúscula y • En algunos hashtag
tiene su origen en la disposición de los tipos móviles en
casilleros o cajas.
Existen dos tipos de CamelCase:
21.2 Enlaces externos
• Primer wiki, creado por Ward Cunningham
• UpperCamelCase, cuando la primera letra de cada
una de las palabras es mayúscula. Ejemplo: Ejem- • Caja alta y baja en el DRAE.
ploDeUpperCamelCase.
• lowerCamelCase, igual que la anterior con la excep-
ció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
 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 de nició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 in rió el tipo de esta función para
Como muchos descendientes delML, Caml es un len- ser int -> int, signi ca 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 = 4∩9001∨00
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 fun-
OCaml, 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 apli-
caciones. 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:
let d delta f x = (f (x +. delta) −. f (x −. delta)) /. (2. *.
Lo siguiente, # representa el prompt de OCaml. delta);;

22.1.1 Hola Mundo Esta función requiere un valor in nitesimal delta. Una
buena elección para delta es la raíz cúbica del épsilon de
print_endline “Hello World!";; la máquina.
El tipo de la función d indica que ésta mapea un tipo
de dato otante a otra función del mismo tipo ( oat ->
oat) -> oat -> oat. Esto nos permite aplicar argumen-
22.1.2 Función factorial (recursividad y tos parcialmente. Este estilo funcional es conocido como
programación puramente funcio- curri cación. En este caso, es útil al aplicar parcialmente
nal) el primer argumento delta a d, para obtener una función
más especializada:
Muchas funciones matemáticas, como el factorial, son re- # let d = d (sqrt epsilon_ oat);; val d : ( oat -> oat) ->
presentadas más naturalmente en una forma puramente oat -> oat = <fun>
funcional. La siguiente función recursiva, puramente fun-
cional implementa la operación factorial en Caml:
Note que el tipo inferido indica que la sustitución d espe-
let rec fact n = if n=0 then 1 else n * fact(n - 1);; ra una función del tipo otante oat -> oat 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.;; - : oat = 2∨. 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]

Los conceptos de funciones curri cadas y de alto orden • [Sitio o cial de Caml]
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ódi-
go 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 imple-
mentada muy sucintamente en Caml y es un ejemplo ex-
celente del uso de la concordancia de patrones sobre lis-
tas, 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 = <fun>

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 sucinta-
mente (brevemente). Además, el compilador de OCaml
realiza concordancia de patrones en un código muy e -
caz, el tiempo en el que los programas arrojan resultados
es más corto y más rápido que el código equivalente es-
crito con una estructura "switch-case" (Cardelli 19∪4, p.
210.).

22.2 Véase también

• OCaml
• ML
• F#

22.3 Referencias
Cardelli, Luca (19∪4). 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,
permitiendo así la exclusión mutua. • La readquisición de un cerrojo no está permitida
Cuando un elemento es compartido por más de un hilo,
pueden ocurrir condiciones de carrera si el mismo no es Algo muy importante es que todos los procesos/hilos de-
protegido adecuadamente. El mecanismo más simple pa- ben utilizar el mismo protocolo para bloquear y desblo-
ra la protección es el cierre o cerrojo. En general cuando quear los cerrojos en el acceso a los recursos, ya que si
debe protegerse un conjunto de elementos, se le asocia mientras dos procesos/hilos utilizan el cerrojo de forma
un cerrojo. Cada proceso/hilo para tener acceso a un ele- correcta, existe otro que simplemente accede a los datos
mento del conjunto, deberá bloquear, con lo que se con- protegidos, no se garantiza la exclusión mutua y pueden
vierte en su dueño. Esa es la única forma de ganar acceso. darse condiciones de carrera y errores en los resultados.
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é accedien- 23.1 Primitivas y uso
do a un recurso (siendo por lo tanto dueño del cerrojo),
otro proceso/hilo intente acceder. Esta acción debe espe- Las funciones de los cerrojos en general son tres: init(),
rar hasta que el cerrojo se encuentre libre, para garanti- lock() y unlock(). El cerrojo se inicializa con la función
zar la exclusión mutua. El proceso/hilo solicitante queda init(). Luego cada proceso/hilo debe llamar a la función
entonces en espera o pasa a estado de bloqueo según el lock() antes de acceder a los datos protegidos por el cierre.
algoritmo implementado. Cuando el dueño del cerrojo lo Al nalizar su sección crítica, el dueño del cerrojo debe
desbloquea puede tomarlo alguno de los procesos/hilos desbloquearlo mediante la función unlock().
que esperaban.
Este mecanismo se puede ver en un ejemplo de la vida
real. Supongamos un baño público, donde sólo puede en- 23.2 Bloqueos en bases de datos
trar una persona a la vez. Una vez dentro, se emplea un
cierre para evitar que entren otras personas. Si otra per- Los sistemas gestores de bases de datos suelen utilizar
sona pretende usar el baño cuando está ocupado, debe- bloqueos para evitar problemas de concurrencia y, en
rá quedar esperando a que la persona que entró anterior- ocasiones, garantizar la serializabilidad de las transaccio-
mente termine. Si más personas llegaran, formarían una nes. Para hacerlo adecuadamente, los mecanismos de blo-
cola (del tipo FIFO) y esperarían su turno. En informáti- queo suelen implementar protocolos como el bloqueo de
ca, el programador no debe asumir este tipo de compor- dos fases y utilizar registros transaccionales (logs) como
tamiento en la cola de espera. 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 gene-
ralmente 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 ce-
rrojos, 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 de-

ne un conjunto de métodos que realizan funciones, nor-
malmente muy reutilizadas. La mayoría de las clases utili-
dad de nen estos métodos comunes con alcance estático.
Ejemplos de clases utilidad incluyen [Link]
que proveen muchos métodos estáticos (tales como or-
denar) en objetos que implementan una Collection (ja-
[Link] ).

24.1 Enlaces externos

• Utility Pattern: Para una clase utilidad, que no re-
quiere instanciación y sólo tiene métodos estáticos,
se debe usar un constructor privado.

44
Capítulo 25

[Link]

El lenguaje HTML para desarrollar páginas web no per-

mite 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 conta-
ba para mostrar contenidos, un truco que los desarrolla-
dores 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á co GIF, que en aquel entonces era el único que per-
mití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 [Link], aunque
cualquier desarrollador que hiciera la imagen podía crear-
la 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:
<IMG hspace=x vspace=y
SRC="/ruta/al/archivo/[Link]">
Donde x y y son las coordenadas de espaciado horizon-
tal y vertical que se desean, y el atributo SRC señala la
ruta hacia el archivo [Link]. 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.

4∧
Capítulo 26

CMake

CMake es una herramienta multiplataforma de genera- el Visualization Toolkit (VTK), un sistema para grá cos
ción o automatización de código. El nombre es una abre- 3D y visualización libres.
viatura para“cross platform make”(make multiplatafor- Para crear CMake, Bill Ho man en Kitware incorporó
ma); más allá del uso de “make”en el nombre, CMake algunas ideas de pcmaker, y añadió más cosas propias,
es una suite separada y de más alto nivel que el sistema con el pensamiento de adoptar algunas de las funciona-
make común de Unix, siendo similar a las autotools. lidades del GNU build system. La implementación ini-
CMake es una familia de herramientas diseñada para cial de CMake tuvo lugar a mediados del 2000, con un
construir, probar y empaquetar software. CMake se uti- desarrollo acelerado a comienzos del 2001. Muchas me-
liza para controlar el proceso de compilación del softwa- joras se debieron a in uencias de otros desarrolladores a
re usando cheros de con guración sencillos e indepen- la hora de incorporar CMake a sus propios sistemas. Por
dientes de la plataforma. Cmake genera make les nativos ejemplo, la comunidad de VXL adoptó CMake, contribu-
y espacios de trabajo que pueden usarse en el entorno yendo con muchas características esenciales. Brad King
de desarrollo deseado. Es comparable al GNU build sys- añadió varias características para dar soporte a CABLE
tem de Unix en que el proceso es controlado por cheros y GCC-XML, un juego de herramientas de envoltura au-
de con guración, en el caso de CMake llamados CMake- tomáticas; y GE Corporate R&D necesitaba soporte para
[Link]. Al contrario que el GNU build system, que está su infraestructura de pruebas (DART). Otras funcionali-
restringido a plataformas Unix, CMake soporta la gene- dades se añadieron para soportar la transición de VTK's
ración de cheros para varios sistemas operativos, lo que a CMake, y soportar ParaView, un sistema de visualiza-
facilita el mantenimiento y elimina la necesidad de tener ción paralela para el Advanced Computing Lab en Los
varios conjuntos de cheros para cada plataforma. Alamos National Laboratory.
El proceso de construcción se controla creando uno o más
cheros [Link] en cada directorio (incluyendo
subdirectorios). Cada [Link] consiste en uno o 26.2 Documentación y tutoriales
más comandos. Cada comando tiene la forma COMAN-
DO (argumentos...) donde COMANDO es el nombre del Aparte de la documentación o cial 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 prede ni-
dos y de nidos por el usuario. Existen generadores ma-
ke le para Unix, Borland make, Watcom make, MinGW,
MSYS y Microsoft NMake. También es posible generar 26.3 Principales funcionalidades
cheros de proyecto para Code::Blocks, Eclipse CDT,
Microsoft Visual Studio de la ∨ a la 10 incluyendo ver- • Ficheros de con guración escritos en un lenguaje de
siones de ∨4 bits y KDevelop. scripting especí co para CMake

• Análisis automático de dependencias para C, C++,

26.1 Historia Fortran, y Java

• Soporte para SWIG, Qt, FLTK, a través del lenguaje

CMake se creó en respuesta a la necesidad de disponer de scripting de CMake
de un entorno multiplataforma apropiado de construc-
ción para el Insight Segmentation and Registration Tool- • Soporte para varias versiones de Microsoft Visual
kit (ITK) creado por la United States National Library of Studio, incluyendo la ∨, ∩, ∩.1, ∪.0, 9.0 y 10.0
Medicine como parte del Visible Human Project. Fue in-
uenciado por un sistema anterior llamado pcmaker crea- • Genera cheros para Eclipse CDT (C/C++ Deve-
do por Ken Martin y otros desarrolladores para soportar lopment Tools)

4∨
26.6. VÉASE TAMBIÉN 4∩

• Detección de cambios en cheros usando times- 26.6 Véase también

tamps tradicionales
• Soporte para builds paralelos • Automake

• Compilador cruzado • Autoconf

• Vista global de todas las dependencias, usando • premake

CMake para generar un diagrama graphviz
• SCons
• Soporte para builds multiplataforma
• VTK
• Linux y otros sistemas POSIX (incluyendo
AIX, *BSD, HP-UX, IRIX/SGI, y Solaris) • Waf
• Mac OS X
• Windows 9∧/9∪/NT/2000/XP, Windows Vis-
ta, Windows ∩ y MinGW/MSYS 26.7 Enlaces externos
• Integrado con DART (software), CDash, CTest y • CMake
CPack, una colección de herramientas para prueba
y liberación de software • 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 des-
pliegue. CTest es un cliente de pruebas libre.

26.5 Aplicaciones que utilizan

CMake
• Avidemux
• Compiz
• Kicad
• KVIrc
• LMMS
• MiKTeX
• MuseScore
• MySQL
• OpenCV
• Poppler
• PvPGN
• Quantum GIS
• Scribus
• Second Life
• SuperTux
• OGRE 3D
• Ryzom
Capítulo 27

Codecademy

Codecademy es una plataforma interactiva en línea que para aprender como programar, mediante la introducción
ofrece clases gratuitas de codi cación en lenguajes de de un nuevo curso cada semana en el 2012.* [12] Más de
programación como Python, PHP, JavaScript, y Ruby, 4∧0,000 personas tomaron el curso en el 2012,* [13]* [14]
así como lenguajes de marcado incluyendo HTML y y Codecademy continua ofertando el programa en el
CSS* [2]* [3] y también uso de API's. A partir de sep- 2013.
tiembre del 2011, el sitio ha tenido más de ∧∧0,000 usua-
rios que han completado más de seis millones de ejerci-
cios.* [4]* [∧] El sitio ha recibido críticas positivas de va- 27.3 Véase también
rios blogs y sitios web, incluyendo el New York Times* [∨]
y TechCrunch.* [∩]
• Academic Earth
Para motivar a los usuarios a participar el sitio cuenta con
un sistema de gami cación por el que ofrece insignias o • Coursera
medallas al completar ejercicios, cuenta con foros de dis-
cusión y un glosario por curso, y mantiene un registro de • Dev Bootcamp
la puntuación total del usuario y la muestra a los demás. El
• edX
sitio también permite que cualquier persona pueda crear
y publicar un nuevo curso usando la herramienta de crea- • Gilles Babinet
ción de cursos.
• Khan Academy

• [Link]
27.1 Historia
• Marginal Revolution University
Codecademy fue fundada en 2011 por Zach Sims y Ryan
Bubinski.* [∪] Sims dejó la universidad Columbia Uni- • Udacity
versity para centrarse en el lanzamiento de una empresa,
• Udemy
mientras que Bubinski se graduó en Columbia con una li-
cenciatura en ciencias de la computación y biofísica.* [9]
La compañía actualmente se encuentra en Nueva York.
Obtuvo 2,∧ millones de dólares en su primera ronda de - 27.4 Referencias
nanciación en octubre de 2011 y 10 millones en la segun-
da serie en junio de 2012.* [∪]* [10] La última ronda de [1] «[Link] Site Info». Alexa Internet. Consultado
nanciación fue llevada a cabo por Index Ventures.* [11] el 1∪ de Septiembre de 201∧.

Finalmente en el año 2014, la empresa Codecademy deci- [2] «Codecademy». Codecademy. Consultado el 4 de agosto
de vender publicidad, comenzando con brindar un banner de 2012.
al gobierno de la ciudad de buenos aires.
[3] Indvik, Lauren. «Codeacademy Releases Free Ruby De-
velopment Courses». Mashable. Mashable. Consultado el
30 de diciembre de 2012.
27.2 Code Year
[4] Frier, Sarah. «Codecademy Raises $10M, Sees Job Ser-
vice as Part of Its Future». Consultado el 19 de junio de
Code Year es un programa gratuito de Codecademy 2012.
para cualquiera que este interesado en aprender como
programar. El programa tiene la intención de ayudar a las [∧] Kafka, Peter. «Codecademy Rounds Up $10 Million for
personas a seguir a través de un New Year's Resolution Web Lessons». Consultado el 19 de junio de 2012.

4∪
27.5. ENLACES EXTERNOS 49

[∨] Wortham, Jenna. «Codecademy O ers Free Coding Clas-

ses for Aspiring Entrepreneurs». The New York Times.
Consultado el 2∨ de julio de 2012.

[∩] Cincaid, Jason. «Codecademy Surges To 200,000 Users,

2.1 Million Lessons Completed In ∩2 Hours». Tech-
Crunch. Consultado el 2∨ de julio de 2012.

[∪] «30 Under 30: Zach Sims and Ryan Bubinski, Codeca-
demy». [Link]. 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». [Link]. Consultado el 13 de agosto
de 2012.

[10] Wortham, Jenna (2∩ de octubre de 2011). «Codecademy

Lands $2.∧ Million From Investors - [Link]».
[Link]. Consultado el 13 de agosto de
2012.

[11] Colao, JJ (19 de junio de 2012). «Codecademy Raises $10

Million To Conquer The World». [Link].

[12] Segall, Laurie (∨ de enero de 2012). «Code Year draws

200,000 aspiring programmers - Jan. ∨, 2012». Mo-
[Link]. Consultado el 1∨ de febrero de 2013.

[13] «Learning JavaScript With Code Year " Feld Thoughts

Feld Thoughts». [Link]. Consultado el 1∨ de febrero
de 2013.

[14] Codecademy. «Code Year». Code Year. Consultado el 1∨

de febrero de 2013.

27.5 Enlaces externos

• Sitio Web de Codecademy
Capítulo 28

Código cerrado

En informática un programa es de código cerrado cuan-

do el código fuente no se encuentra disponible para cual-
quier 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 ce-
rrado. 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

∧0
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 directa-
mente interpretable por un controlador (Código máqui-
na).

∧1
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 in-
tegridad es modi cada por sí mismo durante su ejecu-
ción, generalmente este código trata de un malware por
el hecho de que si como algoritmo (cuando es ejecuta-
do) se automodi ca como información (donde está alma-
cenado) fácilmente puede engañar a un programa del ti-
po antivirus o similar. Aunque de todas maneras, ciertos
programas Antivirus son capaces de detectar este tipo de
modi caciones.

∧2
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 veri cado, únicamente uni-
en 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 pro-
grama llamado enlazador (linker).

31.3 Referencias
[1] [Link]

31.4 Enlaces externos

• Wikcionario tiene de niciones y otra informa-

Fases en la realizazión de software ción sobre código [Link]

el código objeto es el resultado de la compilación del có-

digo fuente. Puede ser en lenguaje máquina o bytecode, y
31.1 Código objeto en lenguajes de puede distribuirse en varios archivos que corresponden a
programación cada código fuente compilado. Luego un enlazador (lin-
ker) se encarga de juntar todos los archivos de código
Un claro ejemplo de lenguaje de programación que usa objeto para obtener el programa ejecutable. - See mo-
código objeto en sus librerías es Pauscal. Esto le permite re at: [Link]
aumentar la velocidad de compilación de los programas y php#[Link] Código objeto: Conjunto de
reducir su tamaño (ya que cada librería objeto puede ser instrucciones y datos escritos en un lenguaje que entien-
comprimida), también permite a programadores compar- de el ordenador directamente: binario o código máquina.
tir sus librerías/funciones sin tener la necesidad de liberar Provienen de la traducción de cierto código fuente, es un
sus códigos fuentes originales. Incluso puede permitir a fragmento del programa nal y es especí co de la plata-
distintos lenguajes de programación compartir funciones forma de ejecución.
sin necesidad de tener que reescribir el código plano a sus
respectivas sintaxis.

31.2 Errores comunes

Los código objeto pueden ser muy útiles en muchas si-
tuaciones sin embargo consigo traen problemas que pue-
den generar errores muy difíciles de corregir, por ejem-
plo cuando un objeto importa funciones de otro código
objeto que ha sido modi cado, el intento de la librería o
el programa que importó la librería de ejecutar el código

∧3
Capítulo 32

Ofuscación

La ofuscación se re ere a encubrir el signi cado 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ñadien-
do algún símbolo
int int_;
32.1 Informática
Con esta línea se de ne una variable de tipo entero.
En computación, la ofuscación se re ere 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 de nimos una función con un parámetro
naria, con el n de que no sea fácil de entender o leer. entero que devuelve un valor long int, que por otra parte
siempre será 0.
En Internet, la ofuscación re ere a crear una publicación
o formar parte del grupo los Ofuscados. _int-_int;

El código ofuscado es aquél código que, aunque se tiene

el código fuente, ha sido enrevesado especí camente para Esto equivale a poner 0.
ocultar su funcionalidad (hacerlo ininteligible). (_int-_int)!;
La ofuscación binaria se realiza habitualmente para im-
pedir 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_)<<!(int_-int_))<<(!(int_-int_)<<!(int_-
forma de código fuente cercana a la forma original.
int_)))|(!(int_-int_)<<!(int_-int_)));
Como un efecto lateral, la ofuscación, en ocasiones, hace
que los programas resultantes sean más pequeños (aunque
Esto equivale a poner 10.
puede hacer que los programas sean más grandes en otros
casos).
Algunos tienden más a la ofuscación que otros. C, C++
y Perl son los más citados como fácilmente ofuscables.
Las macros de preprocesador son usadas a menudo para
crear código complicado de leer enmascarando la gramá-
tica y sintaxis estándar del lenguaje del cuerpo principal 32.2 Otros objetivos
de código.
Aparte de los lenguajes más conocidos, existen lenguajesLa ofuscación puede servir para otros propósitos. Los
de programación esotéricos. Además, también se puede médicos han sido acusados de usar una jerga para encu-
buscar que el código fuente resulte una obra de ascii art.
brir hechos desagradables de un paciente. El autor y doc-
Existen otros programas ofuscados llamados quine que al tor Michael Crichton ha a rmado que la escritura médica
ejecutarse la salida debe ser el código fuente del progra-
es un “intento altamente capacitado y calculado de con-
ma. fundir al lector”. De forma similar, el lenguaje basado
También hay programas ofuscadores que pueden actuar en texto, como gyaru-moji y algunas formas de leet speak
sobre el código fuente, código objeto o ambos para di - es ofuscado para hacerlo incomprensible a terceras per-
cultar la ingeniería inversa. sonas. lomelo

∧4
32.3. ENLACES EXTERNOS ∧∧

32.3 Enlaces externos

• Competición de código ofuscado en C

• Protección online de librerías javascript

• The International Obfuscated C Code Contest (Con-

curso internacional de código en C ofuscado)

• Cómo proteger código en Java por medio de la ofus-

cación de código

• - Ofuscador de Codigo PHP online

• FOPO - Free Online PHP Obfuscator

• Análisis de ofuscación de código en Javscript

Capítulo 33

ColdFusion

Coldfusion (Adobe ColdFusion) es una plataforma de Es un lenguaje que se ejecuta en el servidor. A diferencia
desarrollo rápido de aplicaciones web que usa el lenguaje de JavaScript y Applets Java, que se ejecuta en el cliente,
de programación CFML. En este aspecto, es un producto ColdFusion se ejecuta en el servidor web. Esto signi -
similar a ASP, JSP o PHP. ca que los guiones escritos en ColdFusion correrán de la
ColdFusion es una herramienta que corre en forma misma manera en cualquier navegador web.
concurrente con la mayoría de los servidores web de
Windows, Mac OS X, Linux y Solaris (también en servi-
dores web personales en Windows 9∪ y puede ser usado 33.1 Historia
para intranets). El servidor de aplicaciones web de Cold-
Fusion trabaja con el servidor HTTP para procesar peti- ColdFusion fue desarrollado inicialmente por J. J. Allai-
ciones de páginas web. Cada vez que se solicita una pági- re, y su primera versión apareció en julio de 199∧. En
na de ColdFusion, el servidor de aplicaciones ColdFusion 2001, estando en el mercado la versión ∧, Allaire fue
ejecuta el guion o programa contenido en la página. adquirido por Macromedia, que en junio de 2002 lanzó
El lenguaje de programación CFML, propio de Coldfu- ColdFusion MX (∨.0), llamado de esta manera para se-
sion, puede crear y modi car variables igual que en otros guir la nomenclatura de sus otros productos. Esta versión
lenguajes de programación que nos son familiares. Posee fue completamente reescrita en Java desde cero, y fue di-
control de ujo de programas, como IF, Case, ciclo, etc. señada, entre otros aspectos, para integrarse de manera
Tiene muchas funciones built-in para realizar tareas más sencilla con Macromedia Flash, el producto estrella de la
complicadas, por ejemplo: para averiguar qué día de la compañía.
semana será el 3 de agosto del 202∩ ColdFusion MX ∩ fue lanzado en febrero de 200∧, meses
DayOfWeekAsString(DayOfWeek('202∩/0∪/03')) antes de la adquisición de Macromedia por Adobe Sys-
tems. En la actualidad está disponible la versión 11.
No es un lenguaje de bases de datos, pero interacciona
de manera simple con bases de datos (Sybase, Oracle,
MySQL, SQL Server, o Access). Usando SQL estándar, 33.2 Versiones
las páginas y aplicaciones web pueden fácilmente recu-
perar, guardar, formatear y presentar información diná- • 1995: Allaire Cold and Fusion, versión 1.0
micamente.
• 1996: Allaire Cold and Fusion, versión 1.∧
Muchas de las funciones poderosas de ColdFusion, co-
mo leer desde y escribir en discos duros del servidor, son • 1996: Allaire Cold and Fusion, versión 2.0
basadas en tags. Así como el tag
• Junio 1997: Allaire Cold and Fusion, versión 3.0
puede tener argumentos como 'width' o 'align', el
tag <CFFILE> tiene argumentos que especi can 'ac- • Enero 1998: Allaire Cold and Fusion, versión 3.1
tion=read/write/copy/delete', path=' etc.
• Noviembre 1998: Allaire ColdFusion, versión 4.0
El tag <CFFORM> construye automáticamente todo el
(a partir de esta versión se le conoce como ColdFu-
código JavaScript para veri car los campos requeridos
sion, ya que antes era “Cold and Fusion”)
antes de hacer el formulario. ColdFusion también tiene
tags para COM, Corba y Applets y Servlets de Java. • Noviembre 1999: Allaire ColdFusion, versión 4.∧
ColdFusion fue diseñado para desarrollar sitios comple-
• Junio 2001: Macromedia ColdFusion, versión ∧.0
jos y de alto trá co. ColdFusion está diseñado para correr
en máquinas multi-procesador, y permite construir sitios • Mayo 2002: Macromedia ColdFusion MX, version
que pueden correr en clusters de servidores. ∨.0, Updater 1, Updater 2, Updater 3

∧∨
33.3. EJEMPLOS DE CÓDIGO ∧∩

• Julio 2003: Macromedia ColdFusion MX, version 33.3 Ejemplos de código

∨.1, hot x, Updater 1
• 2005: Macromedia ColdFusion MX ∩, ∩.0.1, ∩.0.2 Consulta a una base de datos:
<cfquery name="nombredelaconsulta”datasour-
• 30 de julio, 2007: Adobe ColdFusion ∪
ce="conexion_odbc"> SELECT * FROM table WHERE
• 4 de abril, 2009: Adobe ColdFusion ∪.0.1 campo = 'hola' </cfquery>

• 5 de octubre, 2009: Adobe ColdFusion 9 Mostrar la respuesta de la consulta:

<cfoutput query="nombredelaconsulta"> #nombredela-
• 13 de julio, 2010: Adobe ColdFusion 9.0.1 [Link]# <!---Las variables se escriben entre #
• 15 de mayo, 2012: Adobe ColdFusion 10 #. Este texto es un comentario ---> </cfoutput>
Dar valores y mostrar variables:
• 31 de mayo, 2012: Adobe ColdFusion 9.0.2
<cfset sCadena = “Hola mundo!"> Contenido de la va-
• 31 de agosto, 2012: Adobe ColdFusion 10 Update riable: <cfoutput>#sCadena#</cfoutput>
1
Usar servicios web:
• 11 de septiembre, 2012: Adobe ColdFusion 10 Up-
<c nvoke webservice="[Link]
date 2
method="prueba”returnVariable="resultado">
• 16 de octubre, 2012: Adobe ColdFusion 10 Update
3
• 2 de noviembre, 2012: Adobe ColdFusion 10 Up-
33.4 Enlaces externos
date 4
• Web o cial de ColdFusion en Adobe
• 19 de noviembre, 2012: Adobe ColdFusion 10 Up-
date ∧ • Adobe ColdFusion community

• 11 de diciembre, 2012: Adobe ColdFusion 10 Up- • Introducción a Adobe ColdFusion

date ∨
• 15 de enero, 2013: Adobe ColdFusion 10 Update ∩
• 27 de febrero, 2013: Adobe ColdFusion 10 Update
∪
• 10 de abril, 2013: Adobe ColdFusion 10 Update 9
• 14 de mayo, 2013: Adobe ColdFusion 10 Update
10
• 9 de julio, 2013: Adobe ColdFusion 10 Update 11
• 12 de noviembre, 2013: Adobe ColdFusion 10 Up-
date 12
• 10 de enero, 2014: Adobe ColdFusion 10 Update
13
• 14 de octubre, 2014: Adobe ColdFusion 10 Update
14
• 9 de diciembre, 2014: Adobe ColdFusion 10 Up-
date 1∧
• 29 de abril, 2014: Adobe ColdFusion 11
• 22 de septiembre: Adobe ColdFusion 11 Update 1
• 14 de octubre, 2014: Adobe ColdFusion 11 Update
2
• 9 de diciembre, 2014: Adobe ColdFusion 11 Up-
date 3
Capítulo 34

Coloreado de sintaxis

34.1 Ejemplo
Abajo se muestra un trozo de código en C++:
// Bucle for normal for (int i=0; i<maximo; i++) {
*(Una_estructura).un_campo = i+∧; }

A veces, estos editores pueden resaltar las llaves, parén-

tesis y corchetes de forma que al posicionar el cursor so-
bre uno de ellos, se destacan los dos elementos, tanto el
de apertura, como el de cierre ̶incluso con etiquetas
HTML. Esto es de gran ayuda al escribir programas con
gran número de anidamientos hechos con estos elemen-
tos.
Un ejemplo de código HTML con coloreado de sintaxis

El resaltado de sintaxis, a veces llamado coloreado de 34.2 Programas con coloreado de

sintaxis, es una capacidad de algunas aplicaciones para
tratamiento de textos (como los editores de texto), para
sintaxis
diferenciar elementos de texto (especialmente el llamado
código fuente) mediante diversos colores o estilos tipo- • Scintilla
grá cos, dependiendo de las categorías sintácticas de sus • Notepad++
términos, conforme a las reglas de algún lenguaje formal
concreto. • Notepad2

Este resaltado se utiliza a modo de notación secunda- • SciTE

ria, habitualmente para mejorar la legibilidad del código • Geany
fuente de programas o de textos escritos en algún lenguaje
de marcado, permitiendo aumentar la productividad de • Vim
los programadores. Los estilos aplicados por defecto de- • Emacs
penden de cada programa informático, alguno de los cua-
les permiten con gurar los estilos e incluso reconocer di- • gedit
versos lenguajes.
• El visor de código fuente de la mayoría de los
navegadores web.
Presentación independiente del signi cado

La interpretación del texto no varía en absoluto al resaltar 34.3 Véase también

sus elementos. Los cambios en la representación del texto
cumplen una función visual identi cativa y no semántica, • Editor de páginas web
sólo se usan para transmitir información al lector humano.
Por tanto, en el caso del código fuente de un programa, • Editor de texto
los intérpretes y los compiladores lo ignoran. No forman
• WYSIWYG
parte ni del lenguaje formal en sí, ni del texto, por lo que
tampoco se guardan en el chero, sino que se analiza cada • WYSIWYM
vez que se carga.

∧∪
Capítulo 35

Comentario (informática)

/** a un amplio abanico de formas de uso distintas y a la in-

* Simple HelloButton() method. clusión de información inútil dentro del código fuente.
* @version 1.0 Para evitar este inconveniente, muchos programadores y
* @author john doe <doe.j@[Link]>
*/ analistas de software adoptan alguna de las “ losofías”
HelloButton() o metodologías para la correcta utilización de los comen-
{ tarios.
JButton hello = new JButton( "Hello, wor
[Link]( new HelloBtnList

// use the JFrame type until support for t

// new component is finished 35.1 Información general
JFrame frame = new JFrame( "Hello Button"
Container pane = [Link]();
[Link]( hello ); Los comentarios adoptan por norma general un formato
[Link](); o bien de“bloque”(también denominado de“prólogo”
[Link](); // display the fra ) o bien de“ n de línea”(también denominado“inline”
}
).* [∧]
Un comentario de bloque delimita una zona del código
fuente en la cual es permitido expandirse a varias líneas
Un ejemplo de código fuente de Java, con comentarios de prólogo de texto. Esta región se reconoce por un delimitador de
en rojo, comentarios entre líneas en verde. Código del progra-
inicio y un delimitador de nal del comentario. Algunos
ma en azul.
lenguajes de programación admiten que los comentarios
se aniden recursivamente (e.g., MATLAB), pero otros
En la programación de computadoras, un comentario lenguajes no lo admiten (e.g., Java).* [∨]* [∩]* [∪]
es una construcción del lenguaje de programación* [1] Un comentario de n de línea comienza con un delimita-
destinada a incrustar anotaciones legibles al programa- dor y continúa hasta el nal de la línea de texto (es decir,
dor en el código fuente de un Programa informático.* [2] no es necesario un segundo delimitador). En otros casos,
Estas anotaciones son potencialmente signi cativas pa- el comentario de n de línea comienza en una cierta co-
ra los programadores, pero usualmente ignorados por los lumna dentro del código fuente no siendo necesario un
compiladores e intérpretes.* [3]* [4] Los comentarios son delimitador.* [∪]
añadidos usualmente con el propósito de hacer el código
fuente más fácil de entender con vistas a su mantenimien- Los delimitadores son una secuencia conocida de caracte-
to o reutilización. La sintaxis y reglas para los comenta- res y suelen ser distintos para los comentarios de bloque
rios varían y usualmente son de nidas en la especi cación que para los de n de línea. Por ejemplo, el lenguaje C++
del lenguaje de programación. usa, para los comentarios de bloque, los delimitadores /*
y */ mientras que los comentarios de n de línea utiliza
Se ha de tener en cuenta que los comentarios necesitan el delimitador //. Otros lenguajes solamente admiten un
mantenimiento igual que el código y, por tanto, que un tipo de comentario. Por ejemplo, ADA solamente dispo-
comentario preciso y conciso es más fácil de mantener ne de comentarios de n de línea mediante el delimitador
que uno largo, repetitivo y complicado. -−.* [∪]
Los comentarios tienen una amplia gama de posibles
usos: desde la mejora del código fuente con descripcio-
nes básicas hasta la generación de documentación exter- 35.2 Usos
na. También se utilizan para la integración con sistemas
de control de versiones y otros tipos de herramientas de La mejor manera de dar uso a los comentarios es ob-
programación externas. jeto de controversia con posiciones a menudo enfrenta-
La exibilidad proporcionada por los comentarios da pie das.* [9]* [10] Hay una gran variedad de formas de escri-

∧9
∨0 CAPÍTULO 35. COMENTARIO (INFORMÁTICA)

bir comentarios y muchos comentaristas que ofrecen, en 35.2.3 Descripción algorítmica

ocasiones, consejos contradictorios.* [10]
A veces, el código fuente contiene una solución nueva o
digna de mencionarse a un problema especí co. En tales
35.2.1 Planeación / Revisión casos, los comentarios pueden contener una explicación
de la metodología. Estas explicaciones pueden incluir dia-
Los comentarios se pueden utilizar como una forma de gramas y pruebas matemáticas formales. Esto puede ser
pseudocódigo para describir la intención antes de escri- la explicación del código, en lugar de una clari cación
bir el código real. En este caso se debe explicar la lógica de sus intenciones, pero otros encargados del manteni-
detrás del código en lugar del código en sí mismo. miento del código pueden encontrar como fundamental
esta explicación. Esto puede ser especialmente cierto en
/* itera hacia atrás por todos los elementos retornados el caso de problemas de dominios de alta especialización;
por el servidor (estos deben ser procesados cronoló- así como en optimizaciones, construcciones o llamadas a
gicamente)*/ for (i = (numElementsReturned - 1); i funciones de uso no cotidiano.* [13]
>= 0; i--){ /* procesa los datos de cada elemento */
updatePattern(i, returnedElements[i]); } Por ejemplo, un programador puede agregar un comenta-
rio para explicar por qué se eligió un Ordenamiento por
inserción en lugar de quicksort, pues el primero es, en
Si se deja este tipo de comentario luego de escribir el có- teoría, más lento que el segundo. Esto podría escribirse
digo, se simpli ca el proceso de revisión al permitir la de la siguiente manera:
comparación directa del código con los resultados pre-
vistos. Una falacia lógica común es que el código fácil de list = [f (b), f (b), f (c), f (d), f (a), ...]; // Se requiere un
entender hace lo que tiene que hacer. ordenamiento estable, mientras el desempeño realmente
no importa. insertion_sort (list);

35.2.2 Descripción de código

Los comentarios pueden ser utilizados para resumir el có-

digo o para explicar la intención del programador. Se- 35.2.4 Inclusión de recursos
gún esta escuela de pensamiento, re-explicar el código en
lenguaje natural se considera super uo y la necesidad de
volver a explicar el código puede ser un signo de que es Logotipos, diagramas y diagramas de ujo consistentes
demasiado complejo y debe ser reescrito. en construcciones de arte ASCII pueden ser insertados en
el código fuente en forma de comentario.* [14] Además,
puede incrustarse como comentarios avisos de derechos
“No documentes mal código – re-escríbelo.” de autor, fecha de creación, versión del producto, contac-
*
[11] to con el propietario y/o creador, etc..
El fragmento de código que sigue es un simple diagrama
ASCII que representa el ujo de proceso para un script
“Los buenos comentarios no repiten el código,
de administración de sistemas contenido en un Fichero
ni lo explican. Estos aclaran su intención. Los
Windows Script que se ejecuta en Windows Script Host
comentarios deben explicar, a un nivel de abs-
A pesar de que la sección que marca el código aparece co-
tracción más alto que el propio código, lo que
* mo un comentario, el diagrama de hecho aparece en una
se intenta conseguir” [12]
sección XML CDATA sección, que técnicamente se con-
sidera distinta de los comentarios, pero que puede servir
*
Los comentarios también pueden ser utilizados para ex- para propósitos similares. [1∧]
plicar por qué un bloque de código no se ajusta a las con- <!-- begin: wsf_resource_nodes --> <resource
venciones o las buenas prácticas. Esto está especialmente id="ProcessDiagram000"> <![CDATA[ HostApp
relacionado con proyectos de escaso tiempo de desarro- (Main_process) | V [Link] (app_cmd) --> ClientApp
llo, o en la corrección de errores. Por ejemplo: (async_run, batch_process) | | V [Link] (mru_history)
' Se asigna una segunda variable debido a que se pro- ]]> </resource>
ducen errores ' en el servidor cuando se reutilizan los
datos del formulario. No se encontró documentación Aún cuando este diagrama fácilmente podría haber sido
' sobre el comportamiento extraño del servidor, así incluido como un comentario, el ejemplo ilustra un ca-
que simplemente se codi có para resolverlo. vtx = so en que el programador puede optar por no utilizar los
[Link](“local settings”) comentarios, como una forma de incluir recursos en el
código fuente.* [1∧]
35.3. ESTILOS ∨1

35.2.5 Depuración 35.3 Estilos

Una práctica común entre programadores es comentar un Hay muchas alternativas cuando se considera como los
fragmento de código, es decir, agregar delimitadores de comentarios deben aparecer en el código fuente. Para
modo que un bloque de código se convierta en un comen- grandes proyectos, los estilos de los comentarios se agre-
tario, y por tanto no se ejecutará en el programa nal. Es- gan apenas comienzan el proyecto. Normalmente los pro-
to podría hacerse para excluir algunas piezas del código gramadores pre eren estilos que son consistentes, no obs-
del programa o, de manera más común, para encontrar la tructivos, fáciles de modi car, y difíciles de romper.
causa de un error. Comentando sistemáticamente y eje-
cutando partes del programa, la causa del error puede ser Los siguientes fragmentos de código en C son solo un
determinada, permitiendo su corrección. A continuación ejemplo de como los comentarios pueden variar de estilo,
un ejemplo de cómo comentar código con el propósito de mientras todos contienen la misma información básica:
excluirlo: /* Este es el cuerpo del comentario. Variante 1 */
( e”)) opt_enabled = true; /* if ([Link] /***********************************\ * * *
if ([Link] “
(“d”)) opt_debug = true; // */ //* if ([Link] (“v” Este es el cuerpo del comentario. * * Variante 2. * * *
)) opt_verbose = true; // */ \************************************/

El fragmento de código de arriba sugiere que el progra- Factores tales como la preferencia personal, la exibili-
mador optó por desactivar la opción de depuración por dad de las herramientas de programación, y otras consi-
alguna razón. Este estilo especí co de comentario es más deraciones tienden a in uir en las variantes de estilo uti-
adecuado para la depuración. Un carácter de barra simple lizado en el código fuente.
delante del delimitador de apertura es el que permite ha-
bilitar o deshabilitar el comentarios de bloque completo.
35.3.1 Etiquetas
Muchos EIDs permiten agregar o remover rápidamente
este tipo de comentarios con opciones del menú singula-
Algunas etiquetas se utilizan en los comentarios para ayu-
res o atajos del teclado. El programador solamente debe
dar en la indexación de los problemas comunes. Tales
marcar la parte de texto que desea comentar o descomen-
etiquetas son comúnmente resaltado de sintaxis y permi-
tar y elegir la opción apropiada. Esto es particularmente
te búsquedas con herramientas de programación común,
útil con fragmentos grandes de código.
como la utilidad grep de UNIX. Ejemplos de convenios
etiqueta son:

35.2.6 Generación de documentación

• FIXME: para marcar código problemático potencial
que requiere una atención especial y/o revisión.
Las herramientas de programación en ocasiones incorpo-
ran documentación y metadatos en los comentarios.* [1∨]
• NOTE: peligros potenciales para documentar el fun-
Estas pueden incluir las posiciones de inserción para la
cionamiento interno del código y de indicar.
inclusión automática de archivos de cabecera, comandos
para con gurar el modo de resaltado de sintaxis* [1∩] o el
• TODO: para indicar las mejoras plani cadas.
número de revisión del archivo.* [1∪] Estos comentarios
de control funcional son también conocidos comúnmen-
• XXX: para advertir a otros programadores de código
te como anotaciones. Mantener la documentación dentro
problemático o equivoco.
de comentarios en el código fuente es considerado co-
mo una forma de simpli car el proceso de documenta-
ción, así como un aumento en las posibilidades de que la Existe el riesgo de que las etiquetas se acumulan con el
documentación se mantendrá al día con los cambios en tiempo, es conveniente incluir la fecha y el propietario
el código.* [19] Habitualmente este tipos de comentarios de etiqueta en el comentario de etiquetas para facilitar el
requiere utilizar una sintaxis básica para que puedan ser seguimiento.
interpretados por el generador de documentación a dife-
rencia de los comentarios anteriores donde no necesaria-
mente se debe de utilizar una sintaxis prede nida.
35.4 Curiosidades
Ddoc para el [[lenguaje de programacinet D]] y doxygen,
para ser usado con C/C++, Java IDL y PHPDoc para Whitespace es un lenguaje de programación esotérico en
PHP. el cual la sintaxis consiste únicamente en espacios en
C#, F# e implementan una característica similar llamada blanco, tabulador y líneas nuevas, cualquier otro carácter
comentarios XML, que son leídos por IntelliSense para es ignorado, por lo que en este lenguaje cualquier escrito
los ensamblados compilados del [Link].* [20] es un comentario.
∨2 CAPÍTULO 35. COMENTARIO (INFORMÁTICA)

35.5 Ejemplos 35.5.10 código HTML

En las páginas webs .html se introduce el comentario en-
35.5.1 Ensamblador
tre
;comentario <!-- --> <!-- esto es un comentario en código HTML //
-->

35.5.2 Java
35.5.11 SQL
//comentario de línea /*comentario de bloque*/ /** co-
mentario que será usado por javadoc */ //esto es un comentario --este también /* y este en bloque
*/

35.5.3 C/C++
35.5.12 Visual Basic
//comentario en línea /* comentario en bloque*/ #if 0 Co-
mentario de bloque aunque el bloque contenga /* este tipo 'comentario '''comentario XML
de comentarios */ #endif

35.5.13 Pauscal
35.5.4 Delphi
' Soy un sensual comentario.
//comentario en línea
{ comentario en bloque } 35.5.14 PHP
(* comentario en bloque *)
//comentario en línea #este también /* comentario en blo-
En delphi se pueden anidar comentarios de bloque siem- que */
pre que no usen el mismo delimitador, e.g.
(* comentario en bloque { que contiene otros comentarios
en bloque } // o de n de línea y que es perfectamente 35.5.15 Cobol
válido *)
* Comentario

35.5.5 Lua
35.6 Referencias
-- Un comentario de línea --[[ Un comentario de bloque
]]-- [1] Para los propósitos de este artículo, los comentarios de
un lenguaje de programación son tratados indistintamen-
te de comentarios que aparecen en lenguajes de marcas,
35.5.6 Ruby archivos de con guración u otros contextos similares. Más
aún, los lenguajes de marcas con frecuencia se relacio-
#comentario =begin comentario de bloque =end nan de manera cercana con código de lenguajes de pro-
gramación, especialmente en el contexto de generación
de código. Ver por ejemplo Ganguli, Madhushree (2002).
35.5.7 Python Making Use of Jsp (en inglés). Nueva York: Wiley. ISBN
04∩1219∩4∨., Hewitt, Eben (2003). Java for Coldfusion
#comentario Developers (en inglés). Upper Saddle River: Pearson Edu-
cation. ISBN 01304∨1∪0∨.

[2] Source code can be divided into program code (which con-
35.5.8 Perl sists of machine-translatable instructions); and comments
(which include human-readable notes and other kinds of
#comentario annotations in support of the program code).Penny Grubb,
Armstrong Takang (2003). Software Maintenance: Con-
cepts and Practice (en inglés). World Scienti c. pp. ∩,
35.5.9 Javascript 120–121. ISBN 9∪123∪42∨X.

[3] Algunos entornos de programación incluyen los comenta-

En [Link] pueden darse las siguientes formas:
rios como uno de los elementos de la sintaxis del lenguaje
//comentario en línea /* comentario en bloque */ que son retenidos para procesamiento posterior, en lugar
35.7. ENLACES EXTERNOS ∨3

de ser descartados una vez han sido reconocidos por el [19] Ambler, Scott (2004). The Object Primer: Agile Model-
procesador de lenguaje. Driven Development with UML 2.0 (en inglés). Cambridge
University Press. ISBN 139∩∪0∧21∪.
[4] Los comentarios deben ser indicados de tal manera que
sea posible para el procesador de código fuente recono- [20] Murach. C# 2005. p. ∧∨.
cerlos como tal. Esto es usualmente simpli cado al decir
que los comentarios son “ignorados”(luego de ser reco-
nocidos y desechados) por el procesador.
35.7 Enlaces externos
[∧] Dixit, J.B. (2003). Computer Fundamentals and Pro-
gramming in C (en inglés). Laxmi Publications. ISBN • 13 consejos para comentar tu código
∪1∩00∪∪∪2∪.
• Como escribir comentarios (en inglés)
[∨] Desmond, Higham (200∧). MATLAB Guide (en inglés).
SIAM. ISBN 0∪9∪∩1∧∩∪4.

[∩] Vermeulen, Al (2000). The Elements of Java Style (en in-

glés). Cambridge University Press. ISBN 0∧21∩∩∩∨∪2.

[∪] «Using the right comment in Java» (en inglés). Consul-

tado el 24 de julio. Parámetro desconocido |añoacce3so=
ignorado (ayuda)

[9] W. R., Dietrich (2003). Applied Pattern Recognition: Algo-

rithms and Implementation in C++ (en inglés). Springer.
p. ∨∨. ISBN 3∧2∪3∧∧∧∪1. ofrece puntos de vista sobre el
uso adecuado de comentarios en el código fuente

[10] Keyes, Jessica (2003). Software Engineering Handbook

(en inglés). CRC Press. p. 2∧∨. ISBN 0∪49314∩9∪. dis-
cute los comentarios y la ciencia de la documentación

[11] The Elements of Programming Style, Kernighan & Plauger

[12] Code Complete, McConnell

[13] Spinellis, Diomidis (2003). Code reading: The Open

Source Perspective (en inglés). Addison-Wesley. ISBN
0201∩9940∧.

[14] «CodePlotter 1.∨ - Add and edit diagrams in your code

with this 'Visio-like' tool». Consultado el 24 de julio de
200∩.

[1∧] Niederst, Jennifer (200∨). Web Design in a Nutshell:

A Desktop Quick Reference (en inglés). O'Reilly. ISBN
0∧9∨009∪∩[Link] ocasiones la diferencia entre un“comen-
tario”y otros elementos de la sintaxis de un lenguaje de
programación o de marcas implica matices sutiles. Nie-
derst indica una situación tal al decir: “Unfortunately,
XML software thinks of comments as unimportant infor-
mation and may simply remove the comments from a do-
cument before processing it. To avoid this problem, use
an XML CDATA section instead.”

[1∨] Vease e.g., Wynne-Powell, Rod (200∪). Mac Os X for

Photographers: Optimized Image Work ow for the Mac
User (en inglés). Oxford: Focal Press. p. 243. ISBN
0240∧202∩0.

[1∩] Lamb, Linda (199∪). Learning the VI Editor (en inglés).

Sebastopol: O'Reilly & Associates. ISBN 1∧∨∧9242∨∨.
describe el uso de sintaxis modeline en los archivos de
con guración de Vim

[1∪] Ver e.g., Berlin, Daniel (200∨). Practical Subversion, Se-

cond Edition (en inglés). Berkeley: APress. p. 1∨∪. ISBN
1∧90∧9∩∧32.
Capítulo 36

Compatibilidad (informática)

La compatibilidad es la condición que hace que un Un ejemplo:

programa y un sistema, arquitectura o aplicación logren Ejecución de orden del programa:
comprenderse correctamente tanto directamente o in-
directamente (mediante un algoritmo). A este algorit- programa_orden_decir=(“huta”)
mo que hace que un programa logre ser comprendido Ejecución del emulador:
por un sistema, arquitectura o aplicación se lo denomi-
na emulador por el hecho de que es un intérprete entre el emul transformar programa_orden_* en siste-
programa y el sistema, arquitectura o aplicación. ma_realizar_*
Ejecución de orden del programa emulada en memoria:
sistema_realizar_decir=(“Hola”)
36.1 Problemas de compatibilidad
Resultado en el sistema:
Un problema de compatibilidad (incompatibilidad) surge sistema> Hola
a partir de la falta o mala interpretación de un programa
por un algoritmo, esto conlleva a una mala ejecución de
dicho programa o a la imposibilidad de ser ejecutado. 36.3 OpenSource
Un ejemplo práctico:
Hoy en día los programas OpenSource (código abierto),
Compatibilidad:
generalmente en los sistemas basados en unix lograron
programa_orden_decir=(“Hola”) sistema> Hola solucionar bastante el tema de la compatibilidad, por el
El programa le indica una orden al sistema y el sistema la hecho de que el sistema que compilará el programa, podrá
interpreta y la ejecuta sin problemas. antes adaptar el código a su kernel modi cando opciones
de compilación, generalmente ingresando en la consola el
Incompatibilidad Caso A (Mala ejecución): siguiente comando:
programa_orden_decir=(“Hola”) sistema> Chau ./con gure
El programa le indica una orden al sistema y el sistema la Luego compila el código con el siguiente comando:
interpreta pero de forma errónea, devolviendo un resul-
tado no esperado. make

Incompatibilidad Caso B (Imposibilidad de ejecución): Y por último instala los ejecutables compilados con:

programa_orden_da31s4s232sd24∧3ce sistema> Error make-install

El programa le indica una orden al sistema que para él es Logrando así obtener un programa genérico completa-
arbitraria y por ende no logra interpretarla. mente adaptado al sistema operativo que lo ha compilado.

36.2 Emulación 36.4 Véase también

La emulación consiste en utilizar un algoritmo de por me- • Compatibilismo e incompatibilismo

dio, denominado emulador que simula ser el sistema, ar-
• Emulador
quitectura o aplicación para el cual el programa está pre-
parado, el emulador modi ca los comandos del programa • Software
en memoria para que el sistema pueda interpretarlo como
si estuviera especialmente diseñado para él. • Wine

∨4
36.5. ENLACES EXTERNOS ∨∧

• Compatibilidad hacia atrás

36.5 Enlaces externos

• Emulación de windows para unix
• Emuladores

• Más emuladores
Capítulo 37

Competición Internacional Universitaria

ACM de Programación

La Competición Internacional Universitaria ACM de universidad antes del concurso. Los estudiantes que ha-
Programación (en inglés ACM International Colle- yan competido en dos nales mundiales (World Finals) o
giate Programming Contest, abreviado ACM-ICPC o cinco competiciones regionales no pueden participar otra
simplemente ICPC) es una competición anual de pro- vez.
gramación y algorítmica entre universidades de todo el Durante la competición, los equipos tienen ∧ horas pa-
mundo patrocinada por IBM. En la competición prima el ra resolver entre ∪ y 10 problemas (lo normal es ∪ para
trabajo en equipo, el análisis de problemas y el desarrollo las competiciones regionales y 10 para la nal). Se deben
rápido de software. ICPC es un evento organizado por la programar las soluciones con C, C++ o Java. Los progra-
Association for Computing Machinery (ACM). mas enviados por los equipos se compilan y ejecutan con
unos ciertos datos de entrada, si el programa falla al cal-
cular la solución, el equipo es noti cado del error y pue-
37.1 Historia den enviar nuevamente el programa o probar con otros
problemas.
La ACM ICPC es una competición que hubo en la Uni- El ganador es el equipo que resuelve más problemas. Si
versidad A&M de Texas en 19∩0. Pasó a ser una compe- hay equipos empatadas con el mismo número de proble-
tición con varias rondas clasi catorias en 19∩∩ y la nal mas resueltos, el orden de clasi cación se calcula a partir
mundial se organizó en colaboración con la ACM Com- de los que han tardado menos en resolver los problemas.
puter Science Conference. Ejemplo: si un equipo A ha enviado sus soluciones para 2
De 19∩∩ a 19∪9, compitieron principalmente equipos de problemas los ∨0 y 120 minutos desde el inicio del con-
Estados Unidos y Canadá. La sede central está ubicada en curso, y otro equipo B lo ha hecho a los ∪0 y 90 minutos.
la Universidad de Baylor desde 19∪9 y las competiciones El desempate entre ambos equipos se haría mirando los
regionales se ubican en universidades de todo el mundo, tiempos, para el equipo A: ∨0+120 = 1∪0 minutos. Para
bajo el auspicio de la ACM y la colaboración de grandes el equipo B: ∪0+90 = 1∩0 minutos. El equipo B ganaría.
empresas de la industria informática. La ACM ICPC ha El tiempo que se toma para los desempates es el tiempo
ido aumentando en número de participantes y países por que ha pasado desde el inicio del concurso más 20 minu-
lo que ahora es una competición mundial con equipos de tos por cada solución incorrecta enviada. En el ejemplo
∪4 países (en 200∧). anterior, si el equipo A hubiera enviado 2 soluciones in-
Desde 199∩ el principal patrocinador es IBM y la parti- correctas para su primer problema, su tiempo nal sería:
cipación en la competición ha aumentado enormemente. 20+20+∨0+120 = 220.
En 199∩ participaron ∪40 equipos de ∧∨0 universidades. El ICPC se diferencia de otras competiciones de progra-
En 200∧, ∧∨0∨ equipos de 1∩3∩ universidades. El núme- mación (por ejemplo la IOI) en que suele tener un gran
ro de equipos aumenta en un 10 y un 20% cada año. número de problemas (∪ o más para resolver en ∧ ho-
ras) y que es una competición por equipos con un sólo
ordenador. Es necesario un buen entendimiento entre los
37.2 Reglas de la competición miembros de un equipo para conseguir la victoria.

El ICPC es una competición por equipos. Las reglas ac-

tuales estipulan que cada equipo ha de tener como má-
ximo 3 miembros. Los miembros han de ser estudiantes
universitarios, que hayan estudiado menos de ∧ años en la

∨∨
37.5. GANADORES ∨∩

37.3 Competiciones locales, regio- - Manila

nales y nal mundial - Seul
- Teerán
La competición tiene distintas fases clasi catorias. Algu- - Xian
nas universidades tienen competiciones locales para ele-
gir a los componentes de los equipos. Cada universidad - Shanghai
puede mandar un máximo de 2 equipos de 3 personas a - Yokohama
la fase regional, si desean participar con un tercer equipo
- Hanoi
deben solicitarlo a la organización que determinará si les
conceden permiso o no. Las competiciones locales son Regiones de Oceanía:
opcionales y las organiza cada universidad como estime - Pací co sur (SPaci c)
conveniente. Algunas universidades optan por seleccio-
nar a los alumnos con notas más altas o a los que muestran Regiones de América Latina:
más interés. - México y Centroamérica (CAmerica)
Los equipos de cada universidad participan en la fase re- - Caribe
gional, con otros equipos de universidades próximas geo-
grá camente. Hay más de 30 regiones en todo el mundo. - Brasil
Algunas regiones agrupan distintos países (por ejemplo la - Suramérica Norte
SWERC incluye a España, Portugal, Francia y otros paí-
- Suramérica Sur
ses Europeos), otras son un sólo país (la región de Brasil)
y otras son sólo parte un país (Estados Unidos está divi- Regiones de Norteamérica:
dido en varias regiones). Los mejor clasi cados en cada - Paci c Northwest (PacNW)
competición regional participarán en la nal mundial. Ca-
da región envía a la nal un cierto número de equipos, no - North Central (NCNA)
puedo haber más de un equipo de una misma universidad. - East Central (ECNA)
La nal mundial se celebra cada año en un lugar distinto, - Northeastern (NENA)
normalmente hoteles de lujo, y congrega a los equipos
- Rocky Mountain (RM)
ganadores de todas las competiciones regionales.
- Mid-Central (MCUSA)
- Greater New York (GNY)
37.4 Lista de competiciones regio- - Southern California (Scal)

nales - South Central (SCUSA)

- Southeast USA (SEUSA)
Regiones de Europa y Rusia: - Mid-Atlantic (MAUSA)
- Suroeste (SWERC): esta región comprende España,
Portugal, Francia, Italia, Suiza y el oeste de Austria.* [1]
- Noroeste (NWERC)
37.5 Ganadores
- Central (CERC) • 201∧ - Instituto de Óptica y Mecánica Fina de San
- Sureste (SEERC) Petersburgo, Rusia
- Noreste (NEERC) • 2014 - Universidad Estatal de San Petersburgo,
Regiones de →frica: Rusia
- →frica y Arabia (AARPC) • 2013 - Instituto de Óptica y Mecánica Fina de San
- Sudáfrica (SAfrica) Petersburgo, Rusia

Regiones de Asia: • 2012 - Instituto de Óptica y Mecánica Fina de San

Petersburgo, Rusia
- Beijing
- Coimbatore (Coim) • 2011 - Universidad de Zhejiang, China
- Kanpur (Kolkata) • 2010 - Universidad de Shanghai Jiaotong, China
- Dhaka • 2009 - Instituto de Óptica y Mecánica Fina de San
- Kaohsiun Petersburgo, Rusia
∨∪ CAPÍTULO 37. COMPETICIÓN INTERNACIONAL UNIVERSITARIA ACM DE PROGRAMACIÓN

• 200∪ - Instituto de Óptica y Mecánica Fina de San • 19∩9 - Universidad Washington en San Luis,
Petersburgo, Rusia Estados Unidos
• 200∩ - Universidad de Varsovia, Polonia • 19∩∪ - Instituto Tecnológico de Massachusetts,
Estados Unidos
• 200∨ - Universidad Estatal de Saratov, Rusia
• 19∩∩ - Universidad Estatal de Míchigan, Estados
• 200∧ - Universidad de Shanghai Jiaotong, China Unidos
• 2004 - Instituto de Óptica y Mecánica Fina de San
Petersburgo, Rusia
37.6 Véase también
• 2003 - Universidad de Varsovia, Polonia
• 2002 - Universidad de Shanghai Jiaotong, China • Olimpiada Internacional de Informática

• 2001 - Universidad Estatal de San Petersburgo,

Rusia 37.7 Enlaces
• 2000 - Universidad Estatal de San Petersburgo,
Rusia • Sitio o cial

• 1999 - Universidad de Waterloo, Canadá

37.7.1 Jueces en Línea
• 199∪ - Universidad Carlos, República checa
• 199∩ - Harvey Mudd College, Estados Unidos • ACM-ICPC Live Archive Around the World

• 199∨ - Universidad de California, Berkeley, Estados • Universidad de Valladolid Online Judge

Unidos • Caribbean Online Judge
• 199∧ - Universidad Albert-Ludwigs, Friburgo, • Ural State University Online Judge
Alemania
• Tianjin University Online Judge
• 1994 - Universidad de Waterloo, Canadá
• Saratov State University Online Judge
• 1993 - Universidad de Harvard, Estados Unidos
• Sphere Online Judge
• 1992 - Universidad de Melbourne, Australia
• A2 Online Judge
• 1991 - Universidad de Stanford, Estados Unidos
• Codeforces
• 1990 - Universidad de Otago, Nueva Zelanda
• MIPT Online Judge
• 19∪9 - Universidad de California, Los →ngeles,
Estados Unidos • Peking University Online Judge

• 19∪∪ - Instituto Tecnológico de California, Estados • Jilin University Online Judge

Unidos
• Zhejiang University Online Judge
• 19∪∩ - Universidad de Stanford, Estados Unidos
• Harbin Institute of Technology Online Judge
• 19∪∨ - Instituto Tecnológico de California, Estados
Unidos • Tianjin University Online Judge

• 19∪∧ - Universidad de Stanford, Estados Unidos • Fuzhou University Online Judge

• 19∪4 - Universidad Johns Hopkins, Estados Unidos • Online Problems Solving System

• 19∪3 - Universidad de Nebraska, Estados Unidos • University of Dhaka Online Judge & Contest Trai-
ning
• 19∪2 - universidad Baylor, Estados Unidos
• Moscow State University Virtual Contest System
• 19∪1 - Universidad de Missouri-Rolla, Estados Uni-
dos [1] [Link]
• 19∪0 - Universidad Washington en San Luis,
Estados Unidos
Capítulo 38

Computación parasitaria

Computación parasitaria es un paradigma de 38.1 Referencias

programación por el cual una aplicación consigue
realizar cálculos complejos utilizando interacciones 1. Parasitic computing, Barabasi et al., Nature, 412:
autorizadas sobre otras aplicaciones. Surge a partir de un ∪94-∪9∩ (2000).
trabajo publicado en Nature en el año 2000.
En el trabajo original se utilizan dos ordenadores comu-
nicándose a través de internet y protocolo TCP/IP, en una 38.2 Enlaces externos
sesión de comunicación estándar. Uno de los ordenado-
res intenta solucionar un complicado problema, el de la • [Link]
satisfactibilidad de la lógica booleana, o 3-SAT; Lo ha-
ce descomponiendo el problema original en un número • [Link]
considerable de problemas más pequeños. Cada uno de
estos problemas más pequeños se codi ca como una re-
lación entre un checksum (suma de control) y un paquete
de red, de manera que la comprobación de si el checksum
es correcto o no es la solución del problema más peque-
ño. El ordenador envía estos paquetes al ordenador que
pretende realice la computación, el ordenador de destino
comprueba el checksum del paquete recibido, si es co-
rrecto solicita mas paquetes, si es incorrecto, solicita la
retransmisión.
De esta manera, el ordenador que recibe los paquetes y
comprueba checksums, está realizando computaciones en
bene cio del ordenador que las solicita, sin ser consciente
de elllo, y sin hacer nada más que mantener una sesión
TCP/IP normal.
La prueba de concepto en el trabajo original es extre-
madamente ine ciente, ya que la cantidad de recursos
computacionales necesarios para generar y enviar los pa-
quetes fácilmente exceden los recursos computacionales
solicitados al otro extremo; El problema 3-SAT se po-
dría haber solucionado mucho antes si se analizase única-
mente en local. Además, en la práctica, los paquetes pro-
bablemente y ocasionalmente deberán ser retransmitidos
realmente cuando ocurran errores de transmisión y/o red
reales.
De todas maneras, la computación parasitaria a nivel de
checksums simplemente es una prueba de concepto. Los
autores del trabajo original sugieren que a medida que se
mueva la computación a lo largo de la pila de protocolo,
se puede llegar a un punto en el cual la computación soli-
citada al/los ordenadores huésped favorezca al parásito.

∨9
Capítulo 39

Conectiva lógica

En lógica, una conectiva lógica, o simplemente conecti- ya que da el valor de verdad de (C) está completamente
va, (también llamado operador lógico o conectores ló- determinado por el valor de (A) y (B) no tiene sentido pa-
gicos) es un símbolo o palabra que se utiliza para conec- ra el estado (A) y (B) y negar (C). Sin embargo, entonces
tar dos fórmulas bien formadas o sentencias (atómicas o en (D) no es un conector lógico, ya que sería bastante ra-
moleculares), de modo que el valor de verdad de la fórmu- zonable para a rmar (A) y (B) y negar (D): tal vez Pedro
la compuesta depende del valor de verdad de las fórmulas subió a la montaña para ir a buscar un balde de agua, y
componentes. no porque Juan subió la montaña.
Los conectivos lógicos más comunes son los conectivos
binarios (también llamados conectivos diádicos) que
39.1.2 Lenguajes formales
unen dos frases, que pueden ser consideradas los operan-
dos de la función. También es común considerar a la ne-
En los lenguajes formales, las funciones de verdad son
gación como un conectivo monádico.
representadas por símbolos inequívocos. Estos símbolos
Las conectivas lógicas son, junto con los cuanti cadores, se llaman “conectivos lógicos”, “operadores lógicos”
las principales constantes lógicas de muchos sistemas ló- , “operadores proposicionales”, o, en la lógica clásica,
gicos, principalmente la lógica proposicional y la lógica la “de funciones conectivos de verdad.”Véase fórmu-
de predicados. las bien formadas para saber las reglas que permiten las
En programación se utilizan para combinar valores de nuevas fórmulas bien formadas sean construidas al jun-
verdad y obtener nuevos valores que determinen el u- tar otras fórmulas bien formadas utilizando conectivos de
jo de control de un algoritmo o programa. funciones de verdad.
Los conectivos lógicos pueden ser utilizados para conec-
tar más de dos a rmaciones, entonces es común hablar
39.1 Lenguajes de “conector lógico n-ario”.

39.1.1 Lenguaje natural

39.2 Lista de conectivos lógicos co-
La gramática de los lenguajes naturales, dos frases pue- munes
den unirse mediante una conjunción gramatical para for-
mar una oración gramaticalmente compuesta. Algunas de
estas conjunciones gramaticales, pero no todas, son fun- 39.2.1 Lista de conectivos lógicos comunes
ciones de verdad. Por ejemplo, considere las siguientes
frases: Conectivos lógicos comúnmente usados:

A: Juan subió la montaña. • Negación (no): ¬, ~

B: Pedro subió a la montaña. • Conjunción (y): , y, ∙
C: Juan subió a la montaña y Pedro se subió a
la montaña. • Disyunción (o)
D: Juan subió la montaña, por lo tanto Pedro • Implicación material (Si.. entonces): , ⇒,
subió la montaña.
• Bicondicional (si y solo si): , ≡, =
Las palabras y y entonces son conjunciones gramaticales
que unen las oraciones (A) y (B) para formar las oracio- Nombres alternativos para bicondicional son “sii”,
nes compuestas (C) y (D). O y (C) es un conector lógico, “xnor”y “bi-implicación.”

∩0
39.3. REDUNDANCIA ∩1

Por ejemplo, el signi cado de los estados está lloviendo y • Bicondicional: el símbolo fue utilizado ≡ al menos
estoy en el interior se transforma cuando los dos se com- por Russell en 190∪;* [3] se utilizó al menos por
binan con conectivos lógicos: Tarski in 1940;* [9] ⇔ fue utilizado en Vax; otros
símbolos aparecieron puntualmente en la historia
• No está lloviendo como en Gentzen,* [10] ~ en Schfin nkel* [∧] o
en Chazal.* [11]
• Está lloviendo y estoy dentro de casa (P Q)
• Verdadero: el símbolo 1 vino de la interpretación
• Está lloviendo o estoy dentro de casa (P Q) de Boole de la lógica como un álgebra elemental de
booleana como la álbegra dos elementos; otras ano-
• Si está lloviendo, entonces estoy en casa. (P Q) taciones incluyendo fueron encontrados en Peano.
∧

• Si estoy en casa, entonces está lloviendo. (P Q) • Falso: el símbolo 0 también proviene de la inter-
pretación de Boole de la lógica
∨ como un anillo [?];
• Estoy dentro si y solo si está lloviendo (P Q) otras anotaciones inclusive fueron encontradas en
Peano.
• No está lloviendo (¬ P)
Algunos autores utilizan letras para conectivos en algún
Por declaración P = Q = Está lloviendo Estoy dentro de momento de la historia: u. para conjunción (del Alemán
casa. “und”, signi ca“y”) y el. para la disyunción (del Alemán
También es común considerar la fórmula siempre verda- “oder”, signi ca “o”) en los primeros trabajos de Hil-
dera y la fórmula siempre falsa como conectivos bert (1904); N para la negación, K para la conjunción, A
para la disyunción, C para bicondicional en Łukasiewicz
(1929).* [12]
• Verdadero (⊤, 1 o T)

• Falso (⊥, 0 o F)
39.3 Redundancia
39.2.2 Historia de las notaciones El conectivo lógico de la implicación recíproca es en
realidad el mismo que el condicional material con las pre-
• Negación: el símbolo ¬ apareció en Heyting en misas cambiadas, luego el símbolo de implicación es re-
1929.* [1]* [2] (comparar con en símbolo
A cripoca es redundante. En algunos cálculos lógicos (en
de Frege en Begri sschrift); el símbolo ~ apareció particular, en la lógica clásica, ciertas a rmaciones com-
en Russell en 190∪;* [3] una notación alternativa es puestas esencialmente diferentes son lógicamente equiva-
añadir una línea horizontal encima de la fórmula, lentes. Un ejemplo menos trivial es una redundancia de la
como en P ; otra notación alternativa es utilizar una equivalencia clásica entre ¬ P Q P y Q. Por lo tanto,
comilla simple como en P'. un sistema lógico de base clásica no necesita del operador
condicional " " si "¬" (no) y " " (o) operador condicio-
• Conjunción: el símbolo apareció en Heyting en nal que ya se utilizan, o se puede utilizar el " " solo con
1929* [1] (comparar el uso de la notación de Peano un azúcar sintáctico para una composición que tiene una
de notación de intersección en teoría de conjun- negación y una disyunción.
tos)* [4]); & apareció al menos en Schfin nkel en Hay 1∨ funciones booleanas que asocian los valores ver-
1924;* [∧] ∙ vino la interpretación de Boole de la ló- dad de entrada de P y Q con salidas binarias 4 dígitos.
gica como un álgebra elemental. Estos corresponden a las posibles opciones conectivos ló-
gicos binarios para la lógica clásica. Una implementación
• Disyunción: el símbolo apareció en Russell en
diferente de la lógica clásica puede elegir diferentes sub-
190∪ (comparar el uso de Peano de la notación de
conjuntos de funcionalmente completos de conectivos.
unión en teoría de conjuntos); también se utiliza
el símbolo +, a pesar de la ambigüedad surgida de la Un método consiste en elegir un mínimo establecido y -
álgebra elemental ordinaria al ser el + considerado jado por cualquier otra manera lógicas como en el ejem-
un o exclusivo lógicamente interpretado como una plo con el condicional material anteriormente. Los si-
alianza de dos elementos; puntualmente en la histo- guientes son conjuntos mínimos funcionalmente comple-
ria, un + junto con un punto en la esquina inferior tos de conectivos de los operadores en la lógica clásica,
derecha fue usado por Peirce,* [∨] cuyo aridades no excedan 2:

• Implicación: el símbolo se puede ver en Hilbert Un elemento { }, { }.

en 191∩;* [∩] fue utilizado por Russell en 190∪* [3]
(comparar con la notación de la C invertida de Dos elementos { ∨ , ¬}, { ∧ , ¬}, { , ¬}, { , ¬}, { ,
Peano); ⇒ se utilizó en Vax.* [∪] ⊥ }, { , ⊥ }, { , ̸↔ }, { , ̸↔ }, { , ̸→ }, { ,
∩2 CAPÍTULO 39. CONECTIVA LÓGICA

̸← }, { , ̸→ }, { , ̸← }, { ̸→ , ¬}, { ̸← , ¬}, { ̸→ • Dualidad: Para leer las asignaciones de valores de

, ⊤ }, { ̸← , ⊤ }, { ̸→ , ↔ }, { ̸← , ↔ }. verdad para la operación desde arriba hacia abajo
en su tabla de verdad es lo mismo que tomar el com-
Tres elementos { ∨ , ↔ , ⊥ }, { ∨ , ↔ , ̸↔ }, { ∨ , ̸↔ plemento de lectura de la tabla de la misma u otra
, ⊤ }, { ∧ , ↔ , ⊥ }, { ∧ , ↔ , ̸↔ }, { ∧ , ̸↔ , ⊤ }. conectiva desde abajo hacia arriba. Sin recurrir a ta-
blas de verdad esto se puede formular como g̃ (¬a1 ,
Vea más detalles sobre integridad funcional. ..., ¬an ) = ¬g(a1 , ..., an ). E.j., ¬ .
Otro enfoque es utilizar en igualdad de derechos, de un
cierto conjunto conveniente y funcionalmente completo, • Preservación de la verdad: El compuesto todos los
pero no mínimo. Este enfoque requiere más axiomas pro- argumentos son tautologías es una tautología en sí.
posicionales y cada equivalencia entre las formas lógicas E.j., ∨ , ∧ , ⊤ , → , ↔ , . (ver validez)
debe ser o bien un axioma o comprobada como un teore-
ma. • Falsedad de preservación: El compuesto de todos
los argumentos son contradicciones es una contra-
Pero la lógica intuicionista tiene una situación más com-
dicción en sí. Por ejemplo, ∨ , ∧ , ̸↔ , ⊥ , , . (ver
plicada. De sus cinco conectivos { , , , ¬, ⊥} sola-
validez)
mente la negación ¬ tiene que ser reducida a otros co-
nectivos (¬p ≡ (p ⊥)). Ni la conjunción, disyunción
y condicional material tiene una forma equivalente cons- • Involutividad (para conectivos unarios): f(f(a)) =
truida de los otros cuatro conectivos lógicos. a. Por ejemplo negación en la lógica clásica.

En la lógica clásica, tanto la conjunción y la disyunción

39.4 Propiedades son asociativas, conmutativas y idempotentes, en la ma-
yoría de las variedades de lógica multi-valuada y la lógica
Algunos conectivos lógicos tienen propiedades que se intuicionista. Lo mismo es cierto sobre distributiva de la
pueden expresar en teoremas que contienen el conectivo. conjunción y la disyunción sobre más de conjunción, así
Algunas de estas propiedades que una conectiva lógica como para la ley de absorción.
puede tener son: En lógica clásica y algunas variedades de lógica multi-
valuada, la conjunción y la disyunción son duales, y la
• Asociatividad: En una expresión que contiene dos negación es auto-dual, en la lógica intuicionista, esta úl-
o más del mismo conectivo asociativo en una línea, tima también es auto-dual.
el orden de las operaciones, no importa, siempre y
cuando la secuencia de los operandos no cambia.

• Conmutatividad: Los operandos del conectivo 39.5 Ciencias de la computación

pueden ser intercambiados (uno por el otro), mien-
tras que la preservación de equivalencia lógica de la
El planteamiento funcional a la verdad a los operadores
expresión original.
lógicos se implementa como puertas lógicas en circuitos
• Distributividad: Un conectivo denotado por • dis- digitales. Prácticamente todos los circuitos digitales (la
tribuye sobre otra que conecta denotado por el signo principal excepción es DRAM) se construye a partir de
+, • si a • (b + c) = (a • b) + (a • c) para todos los NAND, NOR, NOT y puertas de transmisión; ver más
operandos a, b, c. detalles en función de verdad en informática. Los opera-
dores lógicos más de vectores de bits (correspondientes a
• Idempotencia: Cuando los operandos de una opera- nita álgebra de boole) son operaciones bit a bit.
ción son iguales, el compuesto es lógicamente equi- Pero no todo uso de un conector lógico en programación
valente al operando. informática tiene una semántica de Boole. Por ejemplo,
a veces se implementa evaluación perezosa para P Q
• Absorción: Un par de conectivos ∧ , ∨ satisface la
y P Q, de modo que estos conectores no son conmu-
ley de absorción si a ∧ (a ∨ b) = a para todos los
tativo si algunas de las expresiones P, Q tiene efecto se-
operandos a, b.
cundario. También, un condicional, que en cierto sentido
• Monotonicidad: Si f(a1 ,..., an ) ≤ f(b1 ,..., bn ) para corresponde al conectivo condicional material, es esen-
todo a1 ,..., an , b1 ,..., bn ∈ {0,1} tal que a1 ≤ b1 , a2 cialmente no-booleano porque para si (P) entonces Q; la
≤ b2 ,..., an ≤ bn . Ej., ∨ , ∧ , ⊤ , ⊥ . consiguiente Q no se ejecuta si el antecedente P es falso
(aunque un compuesto como un todo es exitosa ≈“verda-
• A nidad: Cada variable siempre hace una diferen- dera”en tal caso). Esto se acerca más a las ópticas intui-
cia en el valor de verdad de la operación o nunca cionistas y constructivistas sobre el condicional material,
hace una diferencia. Ej., ¬ , ↔ , ̸↔ , ⊤ , ⊥ . más que a las de la lógica clásica.
39.9. ENLACES EXTERNOS ∩3

39.6 Conectivas por el número de [9] Tarski (1940) Introduction to logic and to the methodology
of deductive sciences.
argumentos
[10] Gentzen (1934) Untersuchungen über das logische
Schließen.
Si vemos las distintas conectivas por su número de argu-
mentos podemos distinguir: [11] Chazal (199∨): Éléments de logique formelle.

[12] Véase Roegel

39.6.1 Sin argumentos

Las conectivas lógicas sin argumentos son: 39.9 Enlaces externos

• Hazewinkel, Michiel, ed. (2001), «Propositional
connective» (en inglés), Encyclopaedia of Mathe-
matics, Springer, ISBN 9∩∪-1∧∧∨0∪0104
39.6.2 Con un argumento
• Lloyd Humberstone (2011). The Connectives. MIT
Las conectivas con solo un argumento son: Press. ISBN 9∩∪-0-2∨2-01∨∧4-4.
• Bocheński, Józef Maria (19∧9). A Précis of Mathe-
matical Logic. traducido al inglés de las ediciones
francesa y alemana por Otto Bird. Dordrecht, South
Holland.
39.6.3 Con dos argumentos
• Enderton, Herbert (2001). A Mathematical Intro-
Las conectivas que necesitan dos argumentos son: duction to Logic (2da edición). Boston, MA: Aca-
demic Press. ISBN 9∩∪-0-12-23∪4∧2-3.

• Gamut, L.T.F (1991). «Chapter 2». En University

of Chicago Press. Logic, Language and Meaning 1.
pp. ∧4–∨4. OCLC 213∩23∪0.
39.7 Véase también • Humberstone, Lloyd (2010), «Sentence Connec-
tives in Formal Logic», Stanford Encyclopedia
39.8 Referencias of Philosophy, [Link]
connectives-logic/
[1] Heyting (1929) Die formalen Regeln der intuitionistischen • MacFarlane, John (200∧), «Logical constants»,
Logik. Stanford Encyclopedia of Philosophy, [Link]
[2] Denis Roegel (2002), Petit panorama des notations logi-
[Link]/entries/logical-constants/
ques du 20e siècle (véase chart en página 2).
• Esta obra deriva de la traducción total de Logical
[3] Russell (190∪) Mathematical logic as based on the theory connective de Wikipedia en inglés, concreta-
of types (American Journal of Mathematics 30, p222– mente de esta versión, publicada por sus edito-
2∨2, también en From Frege to Gfidel edited by van Hei-
res bajo la Licencia de documentación libre de
jenoort).
GNU y la Licencia Creative Commons Atribución-
[4] Peano (1∪∪9) Arithmetices principia, nova methodo expo- CompartirIgual 3.0 Unported.
sita.

[∧] Schfin nkel (1924) Über die Bausteine der mathematis-

chen Logik, translated as On the building blocks of mathe-
matical logic in From Frege to Gfidel edited by van Hei-
jenoort.

[∨] Peirce (1∪∨∩) On an improvement in Boole's calculus of

logic.

[∩] Hilbert (191∩/191∪) Prinzipien der Mathematik (Bernays'

course notes).

[∪] Vax (19∪2) Lexique logique, Presses Universitaires de

France.
Capítulo 40

Con guración regional

En informática, la con guración regional* [1] ̶conoci-

da como locale en inglés̶es un conjunto de parámetros
que de ne el idioma, país y cualquier otra preferencia es-
pecial que el usuario desee ver en su interfaz de usuario.
Generalmente, un identi cador de con guración regional
consiste como mínimo de un identi cador de idioma y un
identi cador de región. Este concepto es de fundamental
importancia en el campo de la localización de idiomas.

40.1 Véase también

• Internacionalización y localización

40.2 Referencias
[1] Microsoft Corporation. «Traducción del término en el
Portal de idiomas de Microsoft». Consultado el 1 de no-
viembre de 2014.

40.3 Enlaces externos

• Esta obra deriva de la traducción de Locale de
Wikipedia en inglés, publicada por sus edito-
res bajo la Licencia de documentación libre de
GNU y la Licencia Creative Commons Atribución-
CompartirIgual 3.0 Unported.
• Unicode Common Locale Data Repository

• Language Subtag Registry

∩4
Capítulo 41

Conteo de referencias

Conteo de referencias, en inglés Reference counting, es

una técnica para contabilizar las veces que un determina-
do recurso está siendo referido. Por lo general ese recurso
son bloques de memoria y la técnica permite establecer
cuando no existe ninguna referencia a ese bloque y éste
puede ser liberado. Es una técnica de muy fácil imple-
mentación, pero tiene una importante desventaja: Si las
referencias forman un ciclo los objetos involucrados no
se liberarán nunca. Otra técnica más efectiva es el uso de
un recolector de basura.

41.1 Véase también

• Recolector de basura
• Fuga de memoria

∩∧
Capítulo 42

Convención de Nombres (Programación)

En Programación, una convención de nombres es un • para mejorar la apariencia estética y profesional de

conjunto de reglas para la elección de la secuencia de ca- producto de trabajo (por ejemplo, al no permitir
racteres que se utilizará para un identi cador s que de- nombres excesivamente largos nombres “lindo”,
notan variables, tipos, funciones y otras entidades en el cómico o, o las abreviaturas);
código fuente y la documentación.
• para ayudar a evitar “con ictos de nombres”que
Razones para utilizar una convención de nombres (en lu- podrían ocurrir cuando se combina el producto del
gar de permitir a los programadores elegir cualquier se- trabajo de diferentes organizaciones (véase también:
cuencia de caracteres) incluyen los siguientes: espacios de nombres);

• para reducir el esfuerzo necesario para leer y enten- • para proporcionar datos signi cativos que se utili-
der el código fuente;* [1] zarán en los traspasos de proyectos que requieren la
presentación de código fuente del programa y toda
• para mejorar la apariencia del código fuente (por la documentación pertinente
ejemplo, al no permitir nombres excesivamente lar-
gos o abreviaturas poco claras). • para proporcionar una mejor comprensión en el ca-
so de la reutilización de código después de un largo
intervalo de tiempo.
La elección de las convenciones de nombres puede ser
un problema de enorme polémica, con los partidarios
considerar su tendencia mejor y las demás inferiores.
Coloquialmente, este se dice que es una cuestión de 42.2 Desafíos
dogma.* [2] Muchas empresas también han establecido su
propio conjunto de convenciones para satisfacer mejor La elección de las convenciones de nombres (y la medida
sus intereses. en que se hacen cumplir) es a menudo un tema polémico,
con partidarios considerando su punto de vista para ser el
mejor y los demás como inferiores. Además, incluso con
42.1 Bene cios potenciales las convenciones de nombres conocidos y bien de nidos
en el lugar, algunas organizaciones pueden no adherirse
constantemente a ellos, haciendo que la incoherencia y
Algunos de los bene cios potenciales que se pueden obte-
confusión. Estos retos pueden ser exacerbadas si las reglas
ner mediante la adopción de una convención de nombres
de la convención de nomenclatura no tienen coherencia
incluyen los siguientes:
interna, arbitraria, difíciles de recordar, o percibida de
otra manera como más gravosas de lo bene cioso.
• para proporcionar información adicional (es decir,
los metadatos) sobre el uso que se hace de un iden-
ti cador;
42.3 El valor del negocio
• para ayudar a formalizar las expectativas y promover
la coherencia dentro de un equipo de desarrollo; Aunque en gran parte oculto a la vista de la mayoría de
los usuarios de negocios, identi cadores bien escogidos
• para permitir el uso de refactorización automatizado hacen que sea mucho más fácil para las siguientes genera-
o buscar y reemplazar herramientas con un potencial ciones de analistas y desarrolladores para entender lo que
mínimo para el error; hace el sistema y cómo solucionarlo o ampliar el código
• para mejorar la claridad en los casos de ambigüedad fuente para las nuevas necesidades del negocio.
potencial; Por ejemplo, aunque la siguiente:

∩∨
42.4. ELEMENTOS COMUNES ∩∩

a = b * c; • primeros enlazadores que requerían nombres de va-

riables que se limitan a ∨ caracteres para ahorrar
es sintácticamente correcta, su propósito no es evidente. memoria. Un “avance”más adelante permitió que
Contraste esto con: los nombres de variables ya que se utilizarán para
la comprensión humana, pero donde sólo los prime-
WEEKLY_PAY = hours_worked * pay_rate; ros caracteres fueron signi cativas. En algunas ver-
siones de BASIC como TRS-∪0 Nivel Básico 2, los
lo que implica la intención y el signi cado del código nombres largos se les permitió, pero sólo las dos pri-
fuente, por lo menos para aquellos que están familiari- meras letras fueron signi cativas. Esta característica
zados con el contexto subyacente de la aplicación. permitirá el comportamiento erróneo de que podría
ser difícil de depurar, por ejemplo, cuando fueron
utilizados y destinados a ser distinto nombres como
“VALOR”y “VAI”.
42.4 Elementos comunes
• editor de código fuente temprana s autocompletar
Las reglas exactas de una convención de nombres depen- careciendo
den del contexto en que se emplean. Sin embargo, hay
varios elementos comunes que más in uyen en si no to- • monitores tempranas de baja resolución con longitud
dos los convenios de denominación de uso común hoy en de línea limitada (por ejemplo, sólo ∪0 caracteres)
día.
• gran parte de la informática procedentes de las ma-
temáticas, donde los nombres de variables son, tra-
42.4.1 Longitud de identi cadores dicionalmente, sólo una sola letra

Un elemento fundamental de todas las convenciones de

nomenclatura son las reglas relacionadas con identi ca- 42.4.2 Mayúsculas, minúsculas y números
dora longitud (es decir, el número nito de caracteres
individuales permitidos en un identi cador). Algunas re-Algunas convenciones de nomenclatura si limitan letras
glas dictan un numérico jo atado, mientras que otros es-pueden aparecer en mayúsculas o minúsculas. Otro con-
peci can heurística o directrices menos precisos. venios no restrinjan caso carta, pero conceden una inter-
pretación bien de nido basado en mayúsculas y minúscu-
Reglas de longitud de identi cador son impugnadas de
las. Algunas convenciones de nombres especi can si alfa-
forma rutinaria en la práctica, y sujeto a mucho debate
béticos, numéricos o alfanuméricos caracteres se pueden
académico.
usar, y si es así, en qué secuencia.
Algunas consideraciones:

• identi cadores más cortos pueden ser preferidos co- 42.4.3 Identi cadores de varias palabras
mo más conveniente, ya que son más fáciles de es-
cribir Una recomendación común es “Utilizar identi cadores
signi cativos.”Una sola palabra puede no ser tan signi-
• extremadamente identi cadores cortos (por ejem-
cativa, o especí cas, como varias palabras. En conse-
plo, 'i' o 'j') son muy difíciles de distinguir de forma
cuencia, algunas convenciones de nombres especi can las
única mediante la búsqueda automática y reempla-
reglas para el tratamiento de identi cadores “compues-
zar herramientas
tos”que contienen más de una palabra.
• identi cadores más largos pueden ser preferidos Como en la mayoría de los lenguajes de programación no
porque identi cadores cortos no pueden codi car la están permitidos los espacios en blanco en los identi -
información su ciente o parecer demasiado críptico cadores, se necesita un método de delimitación de cada
• identi cadores más largos pueden ser desfavorecido palabra (para que sea más fácil para los lectores poste-
debido a la confusión visual riores para interpretar personajes que pertenecen a cada
palabra).
Es un tema de investigación abierto si algunos programa-
dores pre eren identi cadores más cortos porque son más Palabras delimitadores separados
fáciles de escribir, o inventan, de los identi cadores más
largos, o porque en muchas situaciones un identi cador Un enfoque consiste en delimitar palabras separadas con
ya simplemente estorba el código visible y proporciona un carácter no alfanumérico. Los dos caracteres más usa-
no perciben bene cio adicional. dos para este n son el guión ("-") y el guión bajo ("_”);
La brevedad en la programación podría ser en parte atri- por ejemplo, el nombre de dos palabras “two words”se
buido a: representaría como “two-words”o “two_words”. El
 ∩∪ CAPÍTULO 42. CONVENCIÓN DE NOMBRES (PROGRAMACIÓN)

guión es usado por casi todos los programadores que es- ve en los ∪,3 (máximo ∪ caracteres con periodo separador
criben COBOL, Forth, y Lisp; también es común que los seguido de 3 caracteres tipo de archivo) estilo MS-DOS.
nombres de selector en Cascading Style Sheets. La ma-
yoría de los otros idiomas (por ejemplo, las lenguas en las
familias C y Pascal) se reservan el guión para su uso co-
mo el operador in jo resta, por lo que no está disponible 42.5.3 Esquema de palabra compuesta (del
para su uso en los identi cadores y por lo tanto se utilizan lenguaje)
en lugar de subrayado. Véase el caso de serpientes.
Uno de los sistemas de convenciones publicadas prime-
Carta de los casos separados palabras ros fue de IBM “del lenguaje”documentada en un IMS
(Information Management System) 19∪0 Manual * [cita
requerida].
Otro enfoque consiste en indicar los límites de pala-
bra utilizando capitalización medial (también llamado Se detalla el esquema de palabra PRIME-MODIFIER-
"CamelCase" y muchos otros nombres), haciendo así CLASS, que consistía en nombres como “MEM-ACT-
“two words”ya sea como“twoWords”o“TwoWords” NO”para indicar “número de cuenta del cliente.”
. Esta convención se utiliza comúnmente en Java, C# y PRIME palabras estaban destinadas a indicar las princi-
Visual Basic. Tratamiento de las siglas en identi cadores pales “entidades”de interés para un sistema.
(por ejemplo, el“XML”y“HTTP”en XMLHttpRequest
) varía. Algunos dictan que sean en minúsculas (por Palabras MODIFIER fueron utilizados para el re na-
ejemplo XmlHttpRequest ) para facilitar la mecanogra- miento adicional, la cuali cación y la legibilidad.
fía y la lectura, mientras que otros los dejan upperca- Palabras CLASS ideal sería una lista muy corta de los
sed (por ejemplo XMLHTTPRequest ) para la exacti- tipos de datos relevantes para una aplicación particular.
tud. Una opción menos popular es ampliar siempre las Clase de palabras comunes pueden ser: NO (número),
siglas (por ejemplo ExtensibleMarkupLanguageHyper- ID (identi cador), TXT (texto), AMT (cantidad), CANT
TextTransferProtocolRequest ). (cantidad), FL (bandera), CD (código), W (trabajo) y así
sucesivamente. En la práctica, la clase de palabras dispo-
nibles sería una lista de menos de dos docenas de térmi-
42.5 Metadatos y convenciones hí- nos.
bridas Palabras CLASS, normalmente situados a la derecha (su-
jo), sirven el mismo propósito como pre jos de notación
húngara.
Algunas convenciones de nombres representan normas o
requisitos que van más allá de los requisitos de un pro- El propósito de la clase de palabras, además de la consis-
yecto especí co o dominio del problema, y en lugar de tencia, era especi car al programador el tipo de datos de
re ejar una mayor conjunto general de principios de - un campo de datos particular. Antes de la aceptación de
nidos por la arquitectura de software, lenguaje de pro- BOOLEAN (dos valores únicos) Campos, FL (bandera)
gramación subyacente u otro tipo de metodología entre indicarían un campo con sólo dos valores posibles.
proyectos.

42.5.1 Notación húngara 42.6 Convenciones especí cas del

Tal vez la más conocida es la notación húngara, que co- lenguaje
di ca ya sea el propósito (“Aplicaciones de Hungría”)
o el tipo (“Sistemas de Hungría”) de una variable en su 42.6.1 ActionScript
nombre.* [3] Por ejemplo, el pre jo“sz”para el szName
variable indica que la variable es una cadena de cero (es
Las convenciones y las mejores prácticas de codi ca-
decir null-) terminado.
ción de Adobe sugieren estándares de nomenclatura para
ActionScript que en su mayoría son consistentes con los
42.5.2 Notación posicional de ECMAScript. * [cita requerida] El estilo de identi ca-
dores es similar a la de Java.
Un estilo utilizado para muy cortas (∪ caracteres y menos)
podría ser: LCCIIL01, donde LC sería la aplicación (car-
tas de crédito), C para COBOL, IIL para el subconjunto 42.6.2 Ada
proceso en particular, y el 01 un número de secuencia.
Este tipo de convenciones se encuentra todavía en uso En Ada, el único estilo recomendado de identi cadores
activo en mainframes que dependen de JCL y también se es Mixed_Case_With_Underscores.* [4]
42.6. CONVENCIONES ESPECÍFICAS DEL LENGUAJE ∩9

42.6.3 C y C++ lugar de parseDBMXMLFromIPAddress ). También se

puede establecer el límite en dos o más letras (por ejem-
En C y C++, las palabras clave e identi cadores de la bi- plo parseDbmXmlFromIpAddress ).
blioteca estándar son en su mayoría en minúsculas. En
la biblioteca estándar de C, los nombres abreviados son
los más comunes (por ejemplo isalnum para una prueba 42.6.5 JavaScript
de la función si un carácter es alfanumérico), mientras
que la biblioteca estándar C++ menudo utiliza un guión Las bibliotecas incorporadas de JavaScript utilizan las
como separador de palabra (por ejemplo out_of_range ). mismas convenciones de nomenclatura como Java. Las
Identi cadores representan macros son, por convención, clases utilizan camel case superior (RegExp, TypeError,
escrito usando sólo letras mayúsculas y guiones bajos (es- XMLHttpRequest, DOMObject) y métodos utilizar lo-
to está relacionado con la convención en muchos lengua- wer camel case (getElementById, getElementsByTagNa-
jes de programación de la utilización de todo mayúscu- meNS, createCDATASection). Con el n de ser consis-
las identi cadores de constantes). Nombres que contie- tentes desarrolladores más de JavaScript siguen estas con-
*
nen doble guión o que comienzan con un guión bajo y venciones. [cita requerida] Ver también: convenciones
una letra mayúscula se reservan para la implementación de Douglas Crockford
(compilador, biblioteca estándar) y no deben ser usados
(por ejemplo reserved__ o _Reserved ).* [∧]* [∨] Esto es
super cialmente similar a a lar, pero la semántica di e- 42.6.6 Lisp
re: los subrayados son parte del valor del identi cador, en
lugar de ser carácter delimitador (como se a la): el valor La práctica común en la mayoría de los dialectos de Lisp
de __foo es __foo (que está reservado), no foo (pero en es utilizar guiones para separar las palabras en los iden-
un espacio de nombres diferente). ti cadores, como en with-open- le y make-hash-table.
Nombres de variables globales convencionalmente co-
mienzan y terminan con asteriscos: *map-walls*. Nom-
bres Constantes están marcadas por signos de suma:
42.6.4 Java +map-size+.* [10]
En Java, las convenciones de nombres para los identi-
cadores se han establecido y propuesto por varias co- 42.6.7 .NET
munidades de Java como Sun Microsystems,* [∩] Nets-
cape,* [∪] AmbySoft,* [9] etc Una muestra de las conven- Microsoft NET recomienda UpperCamelCase para la
ciones de nomenclatura establecidas por Sun Microsys- mayoría de los identi cadores. (LowerCamelCase se re-
tems se enumeran a continuación, donde un nombre en comienda para los parámetros y variables) y es una con-
"CamelCase" es un compuesto de un número de palabras vención común para los [Link].* [11] Microsoft
unidas sin espacios, con letra inicial de cada palabra enrecomienda también que no se utilicen pistas de tipo pre-
mayúsculas - por ejemplo “CamelCase”. jo (también conocido como notación húngara).* [12] En
Compiladores Java no hacen cumplir estas reglas, pe- lugar de utilizar la notación húngara se recomienda ter-
ro no seguir las mismas pueden dar lugar a confusión minar el identi cador con el nombre de la clase base; Lo-
*
y código erróneo. Por ejemplo, [Link]() y Wid- ginButton en lugar de BtnLogin. [13]
[Link]() implica signi cativamente diferentes com-
portamientos: [Link]() implica una invocación al
método expand() en una instancia con nombre widget, 42.6.8 Objective-C
mientras que [Link]() implica una invocación al
método estático expand() en la clase Widget. Objective-C tiene un estilo común de codi cación que
tiene sus raíces en Apple ejemplo de código.
Un estilo de programación Java ampliamente utili-
zado dicta que UpperCamelCase ser utilizado para Entidades de primer nivel, incluyendo clases, protocolos,
clases y lowerCamelCase utilizarse para instancias y categorías, así como construcciones de C que se utilizan
métodos.* [∩] Reconociendo este uso, algunos IDE como en los programas de Objective-C como variables y fun-
Eclipse, implementar atajos basados en CamelCase. Por ciones globales, están en UpperCamelCase con una breve
ejemplo, en el contenido de Eclipse función de asisten- mayúsculas-espacio de nombres que denota pre jo, como
cia, escribiendo únicamente las letras mayúsculas de una NSString, UIAppDelegate, NSApp o CGRectMake. Las
palabra CamelCase sugerirá ningún nombre de la clase constantes pueden ser opcionalmente precedidos por una
a juego o método (por ejemplo, al escribir “NPE”y letra minúscula “k”como kCFBooleanTrue.
activando ayuda de contenido podría sugerir NullPointe- variables de instancia de un uso objeto lowerCamelCase
rException ). precedidos por un guión, como _delegate y _tableView.
Siglas de tres o más letras se camelCase en lugar de Nombres de los métodos utilizan múltiples partes lower-
mayúsculas (por ejemplo, parseDbmXmlFromIPAddress CamelCase separados por dos puntos que delimitan argu-
 ∪0 CAPÍTULO 42. CONVENCIÓN DE NOMBRES (PROGRAMACIÓN)

mentos, como: aplicación: didFinishLaunchingWithOp- [11] Microsoft NET Framework Estilos de Capitalización
tions:, stringWithFormat: y IsRunning.
[12] Guía de NET Framework Developer - Convenciones de
nomenclatura general
42.6.9 Perl [13] [Framework Instrucciones de diseño, Krzysztof Cwalina,
Brad Abrams Página ∨2]
Perl toma algunas señales de su patrimonio C para con-
venciones. A nivel local ambito de variables y nombres [14] «Perl style guide».
de subrutinas son minúsculas con guiones bajos in jos. [1∧] «perlmodlib - constructing new Perl modules and nding
Subrutinas y variables con la intención de ser tratado co- existing ones».
mo privado están pre jadas con un guión bajo. Las va-
riables del paquete son título entubado. Constantes de- [1∨] [Guía de Estilo [Link]
claradas son mayúsculas. Los nombres de paquetes son pep-000∪/ de código Python PEP∪]
camel case-exceptuando prágmata por ejemplo, strict y
mro -que son minúsculas. * [14] * [1∧]
42.9 Enlaces externos
42.6.10 Python y Ruby • Americana Name Society - Promueve la onomásti-
ca, el estudio de los nombres y las prácticas de asig-
Python y Ruby tanto recomiendan UpperCa-
nación de nombres, tanto en Estados Unidos como
melCase para nombres de clases, CAPITALI-
en el extranjero.
ZED_WITH_UNDERSCORES para las constantes
y lowercase_separated_by_underscores para otros • Codi cació[Link] tiene una de 100 pági-
nombres. En Python, si un nombre está destinado a ser nas pdf que usa la lingüística y la psicología para
“privado”, que está precedido de un guión bajo.* [1∨] intentar un análisis de costo / bene cio de las cues-
tiones de nomenclatura de identi cadores

42.7 Véase también • Convenciones de nomenclatura de Ontología La

aplicación de etiquetado o las convenciones de no-
menclatura uni cadas en la ingeniería de la ontolo-
42.8 Referencias gía ayudarán a armonizar la apariencia y aumentar
la robustez de las unidades de representación onto-
[1] Derek M. Jones“nombres operando la in uencia del ope- lógica, como nombres de clases y relaciones dentro
rador decisiones de precedencia”Un experimento que in- del conjunto ortogonal de ontologías OBO Foundry.
vestiga el efecto de los nombres de variables de selección
de prioridad de operador

[2] Raymond, Eric S. (1 de octubre de 2004), «religious

issues», The Jargon File (version 4.4.∪ edición), http://
[Link]/jargon/html/R/[Link], con-
sultado el ∩ de noviembre de 2011

[3] [Link]

[4] [Link]
9∧style/html/sec_3/[Link]

[∧] «ISO/IEC 9∪99:1999 Programming languages -- C». ISO.

[∨] «ISO/IEC 14∪∪2:2011 Information technology -- Pro-

gramming languages -- C++». ISO.

[∩]“Convenciones de código para el lenguaje de programa-

ción Java”, Sección 9:“Convenciones de nomenclatura”

[∪]“SOFTWARE DE NETSCAPE Normas de codi cación

GUÍA PARA JAVA”, Collab Software Codi cación Guía
de Normas para Java

[9] “AmbySoft Inc. Estándares de Codi cación para v1∩.01d

Java”

[10] [Link]
Capítulo 43

Cracking (software)

El cracking es la modi cación del software con la inten-

ción de eliminar los métodos de protección de los cuales
este disponga: protección de copias, versiones de prue-
ba, números de serie, claves de hardware, veri cación de
fechas, veri cación de CD o publicidad y adware.
La distribución y uso de copias modi cadas es ilegal en
casi todos los países desarrollados. Muchos juicios se han
llevado a cabo debido al cracking de software; sin embar-
go, la mayoría de estos han tenido que ver con la distribu-
ción de copias duplicadas en vez de con el proceso de que-
brantar la protección, debido a la di cultdad de construir
pruebas válidas de culpabilidad individual en el segun-
do caso. En Estados Unidos, la aprobación de la Digital
Millennium Copyright Act (DMCA) declaró a la modi-
cación de software, así como a la distribución de infor-
mación que habilita el cracking de software, ilegal. Sin
embargo, la ley ha sido apenas probada en el poder judi-
cial de EE. UU. en casos de ingeniería inversa para úni-
co uso personal. La Unión Europea aprobó la Directiva
de la Unión Europea sobre derecho de autor en mayo de
2001, haciendo la infracción de los derechos de autor de
software ilegal en los estados miembros, una vez que la
legislación nacional fuera promulgada en favor de la di-
rectiva.

43.1 Véase también

• Crack informático
• Cracker

• Password cracking
• Razor 1911

∪1
Capítulo 44

Cuaderno de carga

El cuaderno de carga es, dentro de la terminología

informática, el modo de comunicación más frecuente en-
tre el analista y el programador de un proyecto. En él el
analista detalla las especi caciones que el programador
debe seguir para desarrollar un programa informático.

∪2
Capítulo 45

Curri cación

En la ciencia de la computación, curri car es la técni- 45.4 Enlaces externos

ca inventada por Moses Schfin nkel y Gottlob Frege que
consiste en transformar una función que utiliza múltiples
• Wikcionario tiene de niciones y otra informa-
argumentos (o más especí camente una n-tupla como ar-
ción sobre curri [Link]
gumento) en una función que utiliza un único argumento.
• Currying in Python

• Implicit currying in Scheme

45.1 Nomenclatura
• Currying in Ruby

El nombre “curri car”, acuñado por Christopher Stra- • Currying in Smalltalk

chey en 19∨∩, es una referencia al lógico Haskell Curry.
Un nombre alternativo, Schön nkelisation, ha sido pro- • Currying in Algol∨∪G
puesto.* [1] • Currying != Generalized Partial Application! - post
at [Link]

• Currying in Scala
45.2 De nición
• Currying in Perl
Dada una función f del tipo f : (X × Y ) → Z , cu-
rri cándola sería una función del tipo curry(f ) : X →
(Y → Z) . En otras palabras, curry(f ) toma un argu-
mento del tipo X y retorna una función del tipo Y → Z
. Descurri car es la transformación inversa.
Intuitivamente, la curri cación expone que“Si jas algu-
nos argumentos, tendrás una función de los argumentos
restantes”. Por ejemplo, si la función div signi ca la ver-
sión curri cada de la operación x / y, entonces div con
el parámetro x jado en 1 es otra función: igual que la
función inv que devuelve la inversa multiplicativa de sus
argumentos, de nida por inv(y) = 1 / y.
La motivación práctica para curri car es que en oca-
siones, muy seguidas, las funciones obtenidas al utili-
zar algunos, pero no todos, los argumentos en una fun-
ción curri cada pueden resultar útiles; por ejemplo, mu-
chos lenguajes tienen una función o un operador similar
a plus_one. Curri car hace fácil de nir dichas funciones.

45.3 Referencias

[1] I. Heim and A. Kratzer (199∪). Semantics in Generative

Grammar. Blackwell.

∪3
Capítulo 46

Código enhebrado

En ciencias de la computación, el término código en- plataforma de hardware especí ca. Un acercamiento di-
hebrado se re ere a una técnica de implementación ferente usa un conjunto de instrucciones de una máquina
del compilador donde el código generado tiene una for- virtual - que no tiene un destino particular de hardware.
ma que esencialmente consiste enteramente en llama- Un intérprete lo ejecuta en cada nuevo hardware de des-
das a subrutinas. El código puede ser procesado por un tino.
intérprete, o simplemente puede ser una secuencia de ins-
Los computadores tempranos tenían relativamente poca
trucciones de llamadas a código de máquina. memoria. Por ejemplo, la mayoría de los Data General
Una de las principales ventajas del código enhebrado es Nova, IBM 1130, y muchas computadores Apple II te-
que es muy compacto, comparado al código generado nían solamente 4 k palabras de memoria RAM instalada.
por técnicas alternativas de generación del código y de Consecuentemente se pasaba mucho tiempo intentando
convención de llamadas. Esta ventaja usualmente viene a encontrar formas de reducir el tamaño de los programas
expensas de una velocidad de ejecución ligeramente más de tal manera que pudieran caber en la memoria dispo-
lenta (usualmente apenas una sola instrucción de máqui- nible. Al mismo tiempo, los computadores eran relati-
na). Sin embargo, a veces hay un efecto sinergético - a vamente lentos, así que la interpretación simple era per-
veces un código más compacto es más pequeño y sig- ceptiblemente mucho más lenta que ejecutar el código de
ni cativamente más rápido que el código no enhebra- máquina.
do.* [1] Un programa su cientemente pequeño para ca- En vez de escribir cada paso de una operación en cada
ber enteramente en la memoria de acceso aleatorio pue- parte del programa donde era necesaria, los programa-
de correr más rápido que un programa menos compacto dores ahorraban memoria escribiendo cada paso de tales
en el espacio de intercambio que requiere un constante operaciones una sola vez y poniéndolo en una subrutina
acceso mecánico de la unidad de disco, aunque sufra de (ver "no te repitas").
la sobrecarga en la interpretación del código enhebrado.
Similarmente, un programa lo su cientemente pequeño Este proceso - la refactorización de código - es usado hoy,
para caber enteramente en el caché del procesador de laaunque por diversas razones. En estos programas, la apli-
computadora puede correr más rápido que un programa cación del nivel superior puede consistir de nada más que
menos compacto que sufra fallas de caché constantes. llamadas a subrutinas. A su vez, muchas de estas subru-
tinas, también no consisten nada más que llamadas a su-
El código enhebrado es bien conocido como la técnica brutinas de nivel inferior.
de implementación comúnmente usada en el lenguaje de
programación Forth. También fue usado en las versiones Los mainframes y algunos microprocesadores tempranos
tempranas del lenguaje de programación B, así como en tales como el RCA 1∪02 requerían varias instrucciones
muchas implementaciones de BASIC, y algunas imple- para llamar a una subrutina. En la aplicación de nivel su-
mentaciones de COBOL y de otros lenguajes para pe- perior y en muchas subrutinas, esa secuencia es constan-
queños microcomputadores. temente repetida, sólo cambiando la dirección de la su-
brutina desde una llamada a la siguiente. Usando la me-
moria para almacenar las mismas instrucciones repetida-
mente era un desperdicio.
46.1 Historia que llevó al código
La respuesta simple fue una tabla de saltos (es decir una
enhebrado tabla consistiendo solo en las direcciones contiguas de las
subrutinas - usualmente extraídas usando un índice, un
La manera común de hacer programas de computadora es registro de propósitos generales o un puntero). Las direc-
usando un compilador para“traducir”un programa escri- ciones pueden ser directas o indirectas, contiguas o no
to en una cierto lenguaje simbólico al código de máquina. contiguas (encadenadas por punteros), relativas o absolu-
El código es típicamente rápido pero no es portable pues- tas, resueltas en de tiempo de compilación o construidas
to que el código binario ejecutable es diseñado para una dinámicamente - pero el programa se convierte en una

∪4
 46.3. MODELOS DE ENHEBRADO ∪∧

lista de puntos de entrada al código real a ser ejecutado. *tp++

Esta técnica “se ha reinventado”con los nombres de Esto se llama código enhebrado directo (DTC). Aunque
“código enhebrado”, “tabla de despacho”o “tabla de la técnica sea más vieja, el primer uso extensamente cir-
método virtual”- todas estas técnicas llenan propósitos culado del término“código enhebrado”es probablemente
similares. el artículo “código enhebrado”de Bell de 19∩3.* [2]
En 19∩0, Charles H. Moore inventó una notación más
compacta para su máquina virtual Forth: el código en-
46.2 Desarrollo del código enhe- hebrado indirecto (ITC). Originalmente, Moore inven-
brado tó esto porque era fácil y rápido en los minicomputado-
res de NOVA, que tenían un bit de indirección en cada
Para ahorrar espacio, los programadores exprimieron las dirección. Moore dijo (en comentarios publicados en la
listas códigos de llamadas a subrutinas y las convirtieron edición de la revista Byte sobre Forth) que él encontró
en simples listas con solo las direcciones de las subrutinas, esto tan conveniente que lo propagó en todos los diseños
y usaron un pequeño loop para llamar a cada subrutina Forth posteriores.
una por una. Por ejemplo: Algunos compiladores Forth compilan los programas
start: thread: pushA: *sp++ = A tp = &thread &pushA Forth en código enhebrado directo, mientras que otros
jump top top: &pushB pushB: *sp++ = B jump *tp++ hacen código enhebrado indirecto. Los programas actúan
&add jump top ... add: *sp++ = *--sp + *--sp jump top igual de cualquier manera.
En este caso, la decodi cación de los bytecodes se realiza
una sola vez, durante la compilación o la carga de progra-
ma, así que no es repetida cada vez que una instrucción
es ejecutada. Esto puede ahorrar mucho tiempo y espa-
cio cuando la sobrecarga por la decodi cación (decode) 46.3 Modelos de enhebrado
y el enviar (dispath) es grande comparado al costo de la
ejecución.
Prácticamente todo el código enhebrado ejecutable usa
Observe, sin embargo, que las direcciones en thread para uno u otro de estos métodos para invocar subrutinas (cada
&pushA, &pushB, etc., tienen dos o más bytes, compara- método es llamado un “modelo de enhebrado”).
dos a típicamente un byte, para el intérprete de decodi -
car (decode) y enviar (dispath) descrito arriba. En general
las instrucciones para un intérprete de decodi car y en-
viar pueden ser de cualquier tamaño. Como ejemplo, un
intérprete de decodi car y enviar para simular un Intel 46.3.1 Enhebrado directo
Pentium decodi ca las instrucciones con un rango de 1
a 1∨ bytes. Sin embargo, los sistemas de bytecode eligen
típicamente códigos de 1 byte para las operaciones más Las direcciones en el enhebrado son las direcciones del
comunes. Así, el enhebrado a menudo tiene un costo de lenguaje de máquina. Esta forma es simple, pero puede
espacio más alto que los bytecodes. En la mayoría de los tener sobrecargas porque el enhebrado consiste solo de
usos, la reducción en costo de decodi car compensa el direcciones de máquina, así que todos los otros paráme-
aumento en costo de espacio. tros deben ser cargados indirectamente desde la memo-
ria. Algunos sistemas Forth producen código enhebrado
Observe también que mientras que los bytecodes son no- directo. En muchas máquinas el enhebrado directo es más
minalmente independientes de la máquina, el formato y rápido que el enhebrado de subrutina (ver la referencia
el valor de los punteros en el enhebrado generalmente abajo).
dependen de la máquina destino que está ejecutando al
intérprete. Así, un intérprete puede cargar un programa Como ejemplo, una máquina de pila puede ejecutar la se-
cuencia“push A, push B, add”. Eso puede ser traducido
bytecode portable, decodi car los bytecodes para generar
código enhebrado independiente de la plataforma, luego al enhebrado y rutinas siguientes, donde el tp es iniciali-
zado apuntando hacia la dirección de &thread.
ejecutar el código enhebrado sin referencia adicional a los
bytecodes. thread: pushA: *sp++ = A pushB: *sp++ = B add: *sp++
El loop es simple, así que está duplicado en cada hand- = *--sp + *--sp &pushA jump *tp++ jump *tp++ jump
ler, removiendo jump top de la lista de instrucciones de *tp++ &pushB &add ...
máquina necesarias para ejecutar cada instrucción del in- Alternativamente, los operandos pueden estar incluidos
térprete. Como ejemplo: en el enhebrado. Esto puede remover alguna indirección
start: thread: pushA: *sp++ = A tp = thread &pushA necesaria arriba, pero hace el enhebrado más grande:
jump *tp++ jump *tp++ &pushB pushB: *sp++ = B thread: push: *sp++ = *tp++ add: *sp++ = *--sp + *--sp
&add jump *tp++ ... add: *sp++ = *--sp + *--sp jump &push jump *tp++ jump *tp++ &A &push &B &add
 ∪∨ CAPÍTULO 46. CÓDIGO ENHEBRADO

46.3.2 Enhebrado indirecto thread: pushA: pushB: add: call pushA *sp++ = A *sp++
= B *sp++ = *--sp + *--sp call pushB ret ret ret call add
El enhebrado indirecto usa punteros que apuntan hacia
localizaciones que a su vez apuntan al código de máqui-
na. El puntero indirecto puede ser seguido por los ope- 46.3.4 Enhebrado de token
randos que son almacenados en el“bloque”indirecto en
vez de estar almacenados repetidamente en el enhebra- El código enhebrado de token usa listas de índices de ∪
do. Así, el código indirecto es a menudo más compacto ó 12 bits a una tabla de punteros. El código enhebrado
que el código enhebrado directo, pero la indirección típi- de token es notablemente compacto, sin mucho esfuer-
camente también lo hace más lenta, aunque usualmente zo especial por un programador. Tiene usualmente entre
todavía más rápida que los intérpretes de bytecode. Don- la mitad y tres cuartas partes el tamaño de otros códi-
de los operandos del handler incluyen tanto valores como gos enhebrados, los cuales a su vez tienen entre la cuarta
tipos, los ahorros de espacio sobre el código enhebrado y la octava parte del tamaño del código compilado. Los
directo pueden ser signi cativos. Los sistemas Forth más punteros de la tabla pueden ser tanto indirectos como di-
antiguos producían típicamente código enhebrado indi- rectos. Algunos compiladores Forth producen código en-
recto. hebrado de token. Algunos programadores consideran al
“p-code”generado por algunos compiladores de Pascal,
Como ejemplo, si la meta es ejecutar el“psuh A, push B,
al igual que los bytecodes usados por .NET, Java, BASIC,
add”, lo siguiente puede ser usado. Aquí, el tp es inicia-
y algunos compiladores C, como enhebrado de token.
lizado apuntando a la dirección &thread, cada fragmento
del código (push, add) es encontrado por doble indirec- Históricamente, un acercamiento común es el bytecode,
ción por medio del tp; y los operandos para cada frag- que utiliza opcodes de ∪ bits y, a menudo, una máquina
mento de código son encontrados en el primer nivel de virtual basada en pila. Un interpretador típico es conocido
indirección siguiendo la dirección del fragmento. como "decode and dispatch interpreter" y sigue la forma:
thread: i_pushA: push: add: &i_pushA &push *sp++ = bytecode: top: pushA: pushB: add: 0 /*pushA*/ i = deco-
*(*tp + 1) *sp++ = *--sp + *--sp &i_pushB &A jump de(vpc++) *sp++ = A *sp++ = B *sp++ = *--sp + *--sp
*(*tp++) jump *(*tp++) &i_add i_pushB: &push &B 1 /*pushB*/ addr = table[i] jump top jump top jump top
i_add: &add 2 /*add*/ jump *addr
Si la máquina virtual usa solamente instrucciones del ta-
maño de un byte, el decode() es simplemente un ferch
46.3.3 Enhebrado de subrutina desde el bytecode, pero a menudo hay instrucciones co-
munes de 1 byte más instrucciones menos comunes de
El “código enhebrado de subrutina”(también llamado múltiples bytes (ver CISC), en este caso, decode() es más
“código enhebrado de llamada”) consiste en una serie complejo. La decodi cación de opcodes de un solo by-
de instrucciones “call”en lenguaje de máquina (o solo te puede ser muy simple y e cientemente manejado por
las direcciones de las funciones “call”, en oposición el una tabla de saltos usando el opcode directamente como
enhebrado directo el cual usa“jump”). Los compilado- un índice.
res tempranos para el ALGOL, FORTRAN, COBOL y
Para, en las instrucciones donde las operaciones indivi-
algunos sistemas Forth produjeron a menudo código en-
duales son simples, por ejemplo “push”y “add”, la
hebrado de subrutina. El código en muchos de estos sis-
sobrecarga implicada en decidir lo que se debe ejecutar
temas operaba una pila de operandos LIFO (last-in- rs-
es más grande que el costo real de la ejecución, tales intér-
out), que tenía una bien desarrollada teoría del compi-
pretes son a menudo mucho más lentos que el código de
lador. La mayoría de los procesadores modernos tienen
máquina. Sin embargo para instrucciones (“compuestas”
soporte especial del hardware para las subrutinas con las
) más complejas, el porcentaje de sobrecarga es propor-
instrucciones “call”y “return”, así que la sobrecar-
cionalmente menos signi cativo.
ga de una instrucción de máquina adicional por envío es
disminuida; pero según mediciones de Antón Ertl, “en
contraste con los mitos populares, el enhebrado de subru- 46.3.5 Enhebrado de Hu man
tina es usualmente más lento que el enhebrado directo”.
[3] Pruebas más recientes de Ertl demuestran que el en- El código enhebrado de Hu man consiste en listas de
hebrado directo es el modelo de enhebrado más rápido códigos Hu man. Un código de Hu man es una cade-
en los procesadores Xeon, Opteron, y Athlon, mientras na de bits de longitud variable usada para identi car un
que el enhebrado indirecto es el modelo de enhebrado elemento único. Un intérprete de enhebrado de Hu man
más rápido en procesadores Pentium M, y el enhebrado localiza las subrutinas usando una tabla de índice o un ár-
de subrutina es el modelo de enhebrado más rápido en el bol de punteros que pueden ser navagados por el código
Pentium 4, el Pentium III, y procesadores PPC. Hu man. El código enhebrado de Hu man es una de las
Como un ejemplo de enhebrado de llamada, el“push A, más compactas representaciones conocidas para un pro-
push B, add": grama de computadora. Básicamente el índice y los códi-
46.6. REFERENCIAS ∪∩

gos están organizados midiendo la frecuencia en que cada • SP o s (puntero de pila de parámetros, usado para
subrutina ocurre en el código. A las llamadas frecuen- pasar parámetros entre las palabras)
tes se le dan los códigos más cortos. Las operaciones con
frecuencias aproximadamente iguales se le dan códigos
A menudo, las máquinas virtuales enhebradas tales como
con longitudes de bits casi iguales. La mayoría de los sis-
las implementaciones de Forth tienen una máquina virtual
temas enhebrados de Hu man han sido implementados
simple en su corazón, consistiendo en tres primitivas. Ésas
como sistemas Forth de enhebrado directo, y son usados
son:
para grandes cantidades de paquetes de código corriendo
lentamente dentro de pequeños y baratos [[microcontro-
lador}}es. La mayoría de las aplicaciones publicadas han • nest, también llamado docol
estado en juguetes, calculadoras o relojes.
• unnest, o semi_s (; s)

46.3.6 Enhebrados menos usados • next

• Enhebrado de cadena, donde las operaciones son

identi cadas por cadenas, usualmente buscados en En una máquina virtual de enhebrado indirecto, la que
una tabla hash. Esto fue usado por Charles H. Moo- está dada aquí, las operaciones es:
re en las implementaciones más tempranas de Forth next: (ip)+ -> w ; jmp (w)+ nest: ip -> -(rp) ; w -> ip ;
y en el lenguaje de computadora experimental in- next unnest: (rp)+ -> ip ; next
terpretado por hardware de la Universidad Illinois.
También se utiliza en Bashforth. Éste es quizás el intérprete más simple y más rápido o
máquina virtual.

46.4 Bifurcaciones
46.6 Referencias
Los ejemplos de arriba no muestran bifurcaciones. Para
todos los intérpretes, una bifurcación cambia el puntero [1] Speed of various interpreter dispatch techniques V2
del enhebrado (arriba indicado como tp). Como ejemplo,
una bifurcación condicional cuando el valor tope de la pi- [2] James R. Bell, “Threaded Code”, CACM, 19∩3, 1∨, ∨,
la es cero puede ser codi cada como sigue. Observe que pp 3∩0–3∩2
el &thread[123] es la localización a saltar (jump), no la
dirección de un handler, y así que debe ser saltada (tp++)
independientemente de si la bifurcación es tomada.
46.7 Lectura adicional
thread: brz: ... tmp = *tp++ &brz if (*sp++ == 0) &th-
read[123] tp = tmp ... jump *tp++
• Anton Ertl's explanatory page What is Threaded
Code? describes di erent threading techniques and
provides further references.
46.5 Amenidades comunes
• The Development of the C Language by Dennis M.
En una máquina, la separación de las pilas de datos y de Ritchie describes B (a precursor of C) as implemen-
retorno elimina mucho del código para el manejo de la ted using “threaded code”.
pila, reduciendo substancialmente el tamaño del código
enhebrado. El principio de la doble pila fue originado tres • Thinking Forth Project includes the seminal (but out
veces independientemente: para los grandes sistemas de of print) book Thinking Forth by Leo Brodie publis-
Burroughs, el Forth y el PostScript, y es usado en algunas hed in 19∪4.
máquinas virtuales de Java.
Tres registros están a menudo presentes en una máquina • Starting FORTH online version of the book Starting
virtual enhebrada. Otro existe para pasar datos entre las FORTH by Leo Brodie published in 19∪1.
subrutinas (“palabras”). Éstos son:
• Brad Rodriguez's Moving FORTH: Part 1: Design
Decisions in the Forth Kernel covers threading tech-
• IP o i (puntero de instrucción); llamado tp en los niques in depth.
ejemplos de arriba

• w (puntero de trabajo) • Historia de los CPU de propósito general

• rp o r (puntero de pila de retorno) • GCC extensions. Labels as Values

∪∪ CAPÍTULO 46. CÓDIGO ENHEBRADO

46.8 Véase también

• Compilación en tiempo de ejecución
• Tabla de saltos

• Forth
Capítulo 47

Código inalcanzable

En programación, el código inalcanzable es una parte • Código complejo obsoleto que se retuvo intencio-
del código fuente que nunca podrá ser ejecutado porque nalmente, pero se dejó inalcanzable para que pueda
no existe ningún camino dentro de las estructuras de con- ser utilizado más adelante en el desarrollo si es ne-
trol en el resto del programa para llegar a este código.* [1] cesario.
Suele referirse a este tipo de código como código muerto,
aunque entre ellos hay una diferencia (el código muerto • Construcciones de depuración y vestigios de código
se ejecuta pero no produce cambios en la salida del pro- durante el desarrollo que aún no se han retirado del
grama).* [2] programa.

El código inalcanzable generalmente se considera inde-

seable por las siguiente razones: En los últimos cinco casos, el código que es inalcanza-
ble, a menudo existe como parte de un legado, es decir,
1. Ocupa memoria innecesaria. código que una vez fue útil, pero ya no se utiliza o no
se requiere. Sin embargo, el código inalcanzable también
2. Genera almacenamiento innecesario en la caché de puede ser parte de un componente complejo (biblioteca,
instrucciones de la CPU - lo que también disminuye módulo o rutina), donde el código sigue siendo útil en
la localidad de datos. conjunción con diferentes datos de entrada (nunca gene-
3. Desde la perspectiva de mantenimiento de soft- rada por la aplicación actual) o en condiciones que no se
ware, se pierde tiempo y esfuerzo en mantener y cumplen en el entorno de ejecución actual, haciendo el
documentar una pieza de código que nunca se eje- código correspondiente inalcanzable, pero puede ocurrir
cuta. en otros entornos de ejecución, para que el componente
no ha sido desarrollado.
Un ejemplo de tal código condicionalmente inalcanzable
47.1 Causas puede ser la implementación de una función printf() en
la biblioteca de tiempo de ejecución de un compilador, el
La existencia de código inalcanzable puede ser debido a cual contiene el código complejo para procesar todos los
varios factores, tales como: argumentos de cadenas posibles, de los que en realidad
es sólo un pequeño subconjunto utilizados en el progra-
• Errores de programación en situaciones complejas ma. Sin tener que recompilar la biblioteca de ejecución,
de saltos condicionales. los compiladores normalmente no serán capaces de eli-
minar las secciones de código no utilizadas en tiempo de
• Consecuencia de las transformaciones internas rea- compilación.
lizadas por un compilador optimizador.
• Pruebas de software incompletas que no se pudo de-
tectar código inalcanzable.
47.2 Ejemplo
• Código obsoleto que un programador se haya olvi-
dado de borrar. Considerando el siguiente código en C:
• Código no utilizado que un programador haya deci- int foo (int X, int Y) { return X + Y; int Z = X*Y; }
dido no suprimir, ya que estaba entremezclado con
el código funcional.
La de nición de Z = X*Y nunca es alcanzada debido a
• Código condicionalmente útil que nunca será alcan- que la función retorna el ujo del programa a la parte que
zado, dado que los datos de entrada nunca causará la llamo antes, de esta manera dicha de nición puede ser
que el código va a ser ejecutado. descartada.

∪9
90 CAPÍTULO 47. CÓDIGO INALCANZABLE

47.3 Análisis ACM Transactions on Programming Languages & Sys-

tems (TOPLAS). Bibcode:3∩∪-41∧. |autor= y |apellido=
redundantes (ayuda)
La detección de código inalcanzable es una forma de
análisis estático y consiste en realizar un análisis de con- [2] «Eliminación de Código Inalcanzable y Código Muerto».
trol de ujo para encontrar el código que nunca se eje-
cutará independientemente de los valores de las varia- [3] «Java Language Speci cation».
bles y otras condiciones en tiempo de ejecución. En al-
gunos lenguajes (como Java* [3]) algunas formas de códi-
go inalcanzable no están permitidas y no es posible com- 47.6 Bibliografía
pilar el programa con este tipo de código. Se conoce a
la optimización que remueve código inalcanzable como • Muchnick S. S. 199∩ Advanced Compiler Design
eliminación de código muerto (que es la misma para el and Implementation. Morgan Kaufmann.
código muerto y código redundante).
• Appel, A. W. 199∪ Modern Compiler Implementa-
A veces el código puede volverse inalcanzable por algu- tion in Java. Cambridge University Press.
na optimización introducida por el compilador como por
ejemplo: eliminación de subexpresiones comunes.
En la práctica la so sticación del análisis realizado tiene 47.7 Enlaces externos
un impacto signi cativo en la cantidad de código inal-
canzable que se detecta. Por ejemplo, el plegamiento de • Código inalcanzable java
constantes y un simple análisis de control de ujo mues-
tra que la declaración a = 2 en el siguiente código no se
puede alcanzar:
int N = 2 + 1; if (N == 4) { a = 2; }

Sin embargo se necesita mas so sticación para determi-

nar si esta declaración a = 2 es o no inalcanzable debido
que con un método tradicional habría que calcular la raíz
cuadrada en tiempo de compilación:
double d = sqrt(2); if (d > ∧) { a = 2; }

47.3.1 Pro ling

A veces se pueden utilizar pro lers para detectar código
inalcanzable, un pro ler no prueba nada acerca de si el
código realmente es o no inalcanzable pero es una bue-
na heurística para buscar código potencialmente inalcan-
zable. Una vez detectado las partes potenciales se puede
llevar a cabo en las mismas un análisis más profundo.

47.4 Véase también

• Código muerto

• Código redundante

• Cobertura de código

47.5 Referencias
[1] Debray, S. K.; Evans, W., Muth, R., and De Sutter, B.
(2000-03). «Compiler techniques for code compaction.»
(PDF). Volume 22, issue 2 (en inglés). New York, USA:
Capítulo 48

Código muerto

En programación, se conoce como código muerto a una mente cuando algún módulo entero quede muerto.* [3]
parte del código fuente que se ejecuta pero sus resultados Algunos IDE (como Visual Studio 2010* [4] y
nunca se usan.* [1]* [2] La ejecución de este tipo de código Eclipse* [∧]) poseen la habilidad de detectar código
consume tiempo de computo en algo que jamás se utiliza. muerto durante tiempo de compilación.
Es frecuente confundirlo con el código inalcanzable aun-
que conservan una diferencia (este jamás se ejecuta, y si
bien los dos son indeseables el código muerto es más gra- 48.3 Véase también
ve que el inalcanzable).
Además de consumir tiempo de computo el código muer- • Código inalcanzable
to puede arrojar excepciones o afectar un estado global
del programa. por lo tanto si bien los resultados jamás • Código redundante
se utilizan remover este código puede cambiar la salida
del programa y evitar bugs innecesarios. Esta es una ra-
zón por la cual el código muerto es menos deseado que el 48.4 Referencias
código inalcanzable.
[1] Debray, S. K., Evans, W., Muth, R., and De Sutter, B.
2000. Compiler techniques for code compaction. ACM
48.1 Ejemplo Trans. Program. Lang. Syst. 22, 2 (Mar. 2000), 3∩∪-41∧.

[2] Appel, A. W. 199∪ Modern Compiler Implementation in

int foo (int X, int Y) { int Z = X/Y; return X*Y; } Java. Cambridge University Press.

[3] Douglas W. Jones Dead Code Maintenance, Risks ∪.19

En el código anterior la división entre X e Y se calcu- (Feb. 1, 19∪9)
la pero jamás se utiliza, además, en el caso que Y sea 0
el programa arrojaría una excepción con posibilidad de [4] Habib Heydarian, Microsoft Corp.
abortar la ejecución, por lo tanto la salida del programa [∧] Eclipse Developer Guide
se ve afectada por esta línea.

48.5 Bibliografía
48.2 Análisis
• Muchnick S. S. 199∩ Advanced Compiler Design
Se puede utilizar una optimización de compilador lla- and Implementation. Morgan Kaufmann.
mada eliminación de código muerto para eliminar este
código. Este análisis se puede llevar a cabo mediante el • Appel, A. W. 199∪ Modern Compiler Implementa-
análisis de variable viva, que es una forma de análisis está- tion in Java. Cambridge University Press.
tico de software y análisis de ujo de datos. Esta también
es una diferencia con respecto al código inalcanzable que
se descubre mediante un análisis de control del ujo. 48.6 Enlaces externos
La eliminación de código en general es la misma técnica
que se usa para eliminar el código inalcanzable y el código • Optimización de código
redundante.
• Dead Code Detector (DCD) Java/JEE
En los proyectos de programación grandes, a veces es
difícil de reconocer y eliminar código muerto, especial- • Comparación de DCD para Java

91
92 CAPÍTULO 48. CÓDIGO MUERTO

• UCDetector Plugin Eclipse para encontrar código

muerto Java
Capítulo 49

Código redundante

En programación, se conoce como código redundante 49.2 Eliminación

a cualquier parte del código fuente que tenga algún tipo
de redundancia tales como recalcular un valor que ha sido Existen técnicas de optimización de software comúnmen-
calculado previamente y todavía esta disponible.* [1] te llevadas a cabo por un compilador optimizador para
Una instrucción NOP podría ser considerado como códi- eliminar el código redundante del código fuente. La más
go redundante que ha sido explícitamente insertado para común es la eliminación de código muerto.
rellenar el ujo de instrucciones o introducir un retardo
de tiempo, por ejemplo para crear un bucle de temporiza-
ción para“perder el tiempo”. Los identi cadores que se 49.3 Véase también
declaran, pero nunca se les hace referencia, se denominan
declaraciones redundantes. • Código muerto

• Código inalcanzable

49.4 Referencias
49.1 Ejemplos
[1] Debray, S. K., Evans, W., Muth, R., and De Sutter, B.
2000. Compiler techniques for code compaction. ACM
int foo(int X) { int Y = X*2; return X*2; } Trans. Program. Lang. Syst. 22, 2 (Mar. 2000), 3∩∪–41∧.

En este ejemplo la instrucción int Y = X*2; puede ser re-

movida para evitar calcular el valor dos veces, o también
se puede retornar el valor de la variable Y (aunque parti-
cularmente este método consume mas memoria).
Considerando:
#de ne min(A,B) ((A)<(B)?(A):(B)) int magni-
tud_mas_corta(int u1, int v1, int u2, int v2) { /* retorna
la magnitud mas corta entre (u1,v1) y (u2,v2) */ return
sqrt(min(u1*u1 + v1*v1, u2*u2 + v2*v2)); }

Como consecuencia de usar el preprocesador de C el

compilador escribirá la forma expandida:
int magnitud_mas_corta(int u1, int v1, int u2, int v2) {
int temp; if (u1*u1 + v1*v1 < u2*u2 + v2*v2) temp =
u1*u1 + v1*v1; /* Redundante */ else temp = u2*u2 +
v2*v2; /* Redundante */ return sqrt(temp); }

Provocando un código totalmente redundante e ine cien-

te, sin embargo debido a que los macros de máximo y
mínimo son muy utilizados los compiladores modernos
detectan estas situaciones y corrigen el código generado.

93
Capítulo 50

Dato

Un dato es una representación simbólica (numérica, alfa- • Dato experimental

bética, algorítmica, espacial, etc.) de un atributo o varia-
ble cuantitativa o cualitativa. Los datos describen hechos
empíricos, sucesos y entidades. Es un valor o referente 50.2 Enlaces externos
que recibe el computador por diferentes medios, los datos
representan la información que el programador manipula
en la construcción de una solución o en el desarrollo de • Wikcionario tiene de niciones y otra informa-
un algoritmo. ción sobre [Link]
Los datos aisladamente pueden no contener información • Datos Grá cos: Web que permite generar grá cos a
humanamente relevante. Sólo cuando un conjunto de da- partir de datos del Instituto Nacional de Estadística.
tos se examina conjuntamente a la luz de un enfoque,
hipótesis o teoría se puede apreciar la información con- • Gra [Link]: Tienda on-line de grá cas
tenida en dichos datos. Los datos pueden consistir en nú- para uso digital e impreso. Servicio de producción
meros, estadísticas o proposiciones descriptivas. Los da- de grá cas a la medida para empresas y particulares.
tos convenientemente agrupados, estructurados e inter- • Stat4You: En stat4you tienes todas las estadísticas
pretados se consideran que son la base de la información del INE y del ISTAC para que crees tus grá cos fá-
humanamente relevante que se pueden utilizar en la to- cilmente.
ma de decisiones, la reducción de la incertidumbre o la
realización de cálculos. Es de empleo muy común en el • Centro de datos - Lanzarote: La mayor colección de
ámbito informático y, en general, prácticamente en cual- datos y estadísticas de la Isla de Lanzarote en Inter-
quier investigación cientí ca. net.
En programación, un dato es la expresión general que des-
cribe las características de las entidades sobre las cuales
opera un algoritmo.
En estructura de datos, es la parte mínima de la informa-
ción.

Datos Procesamiento Información

Un dato por sí mismo no constituye información, es el procesa-

miento de los datos lo que nos proporciona información.

50.1 Véase también

• Información
• Conocimiento
• Sabiduría
• Metadato
• Estadística

94
Capítulo 51

Depuración de programas

51.1 Origen
Existe una controversia acerca del origen del término de-
puración o “debugging”en inglés. Los términos “bug”
y “debugging”son atribuidos popularmente a la almi-
rante Grace Murray Hopper por los años 1940. Mientras
trabajaba con un Mark II en la Universidad de Harvard,
ella encontró una polilla atrapada en un relé impidiendo
las operaciones de dicha computadora, por lo cual ella co-
mentó que cuando se sacó aquella polilla le habían hecho
“debugging”al sistema. Sin embargo el término “bug”
cómo signi cado de error técnico data cerca de 1∪∩∪, y
el término “debugging”o depuración ha sido usado en
aeronáutica antes de entrar al mundo de las computado-
ras.
Una fotografía del supuestamente primer “bug”(bicho) real, el
cual fue depurado (“debugged”) en 1947.

51.2 Aplicación
Como el software y los sistemas electrónicos se vuelven
generalmente más complejos, se han desarrollado varias
técnicas comunes de depuración para detectar anomalías,
corregir funcionalidades y optimizar código fuente. Exis-
Depuración de programas es el proceso de identi car y
ten algunos a cionados que consideran la depuración co-
corregir errores de programación. En inglés se le conoce
mo una forma de arte.
como debugging, es que se asemeja a la eliminación de
bichos (bugs), manera en que se conoce informalmente a
los errores de programación. Se dice que el término bug
proviene de la época de los ordenadores de válvula ter- 51.3 Véase también
moiónica, en los cuales los problemas se generaban por
los insectos que eran atraídos por las luces y estropeaban • Depurador
el equipo. Si bien existen técnicas para la revisión siste-
mática del código fuente y se cuenta con medios compu- • Error de software
tacionales para la detección de errores (depuradores) y fa- • Emulador BOCHS
cilidades integradas en los sistemas lower CASE y en los
ambientes de desarrollo integrado, sigue siendo en buena
medida una actividad manual, que desafía la paciencia,
la imaginación y la intuición del programador. Muchas
veces se requiere incluir en el código fuente instruccio-
nes auxiliares que permitan el seguimiento de la ejecu-
ción del programa, presentando los valores de variables
y direcciones de memoria y ralentizando la salida de da-
tos (modo de depuración). Dentro de un proceso formal
de aseguramiento de la calidad, puede ser asimilado al
concepto de prueba unitaria.

9∧
Capítulo 52

Desarrollador de software

El desarrollador de software es una persona • Ingeniería del software

programadora que se dedica a uno o más aspectos
del proceso de desarrollo de software. Se trata de un • Interfaz de programación de aplicaciones
ámbito más amplio de la programación. • Programación
El desarrollador puede contribuir a la visión general del
• Software
proyecto más a nivel de aplicación que a nivel de compo-
nentes o en las tareas de programación individuales.
Conforme pasa el tiempo, las diferencias entre el diseño
de sistemas informáticos, el desarrollo de software y la
programación se van haciendo más claras. En el nicho de
mercado puede encontrarse una separación entre progra-
madores y desarrolladores, siendo estos últimos los que
diseñan la estructura o jerarquía de clases. Incluso esos
desarrolladores se convierten en arquitectos de sistemas
informáticos, aquellos que diseñan la arquitectura a va-
rios niveles o las interacciones entre componentes de un
proyecto de software grande.
El concepto de desarrollo de software incluye:

• trabajo en equipo: los proyectos son en general una

colaboración entre varios desarrolladores, que tra-
tan cada uno una parte del programa, y también de
otros colaboradores como los comerciales, que de -
nen con el cliente la nalidad del producto, diseña-
dores grá cos que de nen el aspecto y la ergonomía,
entre otros temas.

• concepción o diseño: a partir de un pliego de condi-

ciones (user requirement speci cations), de nir las
especi caciones técnicas (estructura de los datos,
comunicación entre los módulos, etcétera).

• pruebas: que sirven para detectar las disconformida-

des y los errores

• mantenimiento: la corrección de los errores después

de la salida del programa informático, y la mejora
para hacer evolucionar el producto.

52.1 Véase también

• Ambiente de desarrollo integrado

• Desarrollador de videojuegos

9∨
Capítulo 53

Desarrollo en cascada

En Ingeniería de software el desarrollo en cascada, tam-

bién llamado modelo en cascada (denominado así por la Requisitos
posición de las fases en el desarrollo de esta, que pare-
cen caer en cascada “por gravedad” hacia las siguien- Diseño
tes fases), es el enfoque metodológico que ordena rigu-
rosamente las etapas del proceso para el desarrollo de
software, de tal forma que el inicio de cada etapa debe Implementación
esperar al término de la etapa anterior.* [1] Al nal de ca-
da etapa, el modelo está diseñado para llevar a cabo una
revisión nal, que se encarga de determinar si el proyecto Verificación
está listo para avanzar a la siguiente fase. Este modelo fue
el primero en originarse y es la base de todos los demás Maintenimiento
modelos de ciclo de vida.
Un ejemplo de una metodología de desarrollo en cascada
es: El “modelo cascada”sin modi car. El progreso uye de arriba
hacía abajo, como una cascada.

1. Análisis de requisitos.
qué objetivos debe cubrir. De esta fase surge
2. Diseño del Sistema.
una memoria llamada SRD (documento de es-
3. Segregación del programa. peci cación de requisitos), que contiene la es-
peci cación completa de lo que debe hacer el
4. Diversi cación. sistema sin entrar en detalles internos.
∧. Veri cación integral.
Es importante señalar que en esta etapa se debe
∨. Ordeñado del programa. consensuar todo lo que se requiere del sistema
y será aquello lo que seguirá en las siguientes
De esta forma, cualquier error de diseño detectado en etapas, no pudiéndose requerir nuevos resulta-
la etapa de prueba conduce necesariamente al rediseño dos a mitad del proceso de elaboración del soft-
y nueva programación del código afectado, aumentando ware de una manera.
los costos del desarrollo. La palabra cascada sugiere, me-
diante la metáfora de la fuerza de la gravedad, el esfuer-
zo necesario para introducir un cambio en las fases más 53.1.2 Diseño del Sistema
avanzadas de un proyecto.
Descompone y organiza el sistema en elemen-
Si bien ha sido ampliamente criticado desde el ámbito tos que puedan elaborarse por separado, apro-
académico y la industria* [cita requerida], sigue siendo el vechando las ventajas del desarrollo en equipo.
paradigma más seguido al día de hoy* [cita requerida]. Como resultado surge el SDD (Documento de
Diseño del Software), que contiene la descrip-
ción de la estructura relacional global del sis-
53.1 Fases del modelo tema y la especi cación de lo que debe hacer
cada una de sus partes, así como la manera en
53.1.1 Análisis de requisitos que se combinan unas con otras.

En esta fase se analizan las necesidades de los Es conveniente distinguir entre diseño de al-
usuarios nales del software para determinar to nivel o arquitectónico y diseño detallado. El

9∩
9∪ CAPÍTULO 53. DESARROLLO EN CASCADA

primero de ellos tiene como objetivo de nir la 53.2 Variantes

estructura de la solución (una vez que la fase de
análisis ha descrito el problema) identi cando Existen variantes de este modelo; especialmen-
grandes módulos (conjuntos de funciones que te destacamos la que hace uso de prototipos y
van a estar asociadas) y sus relaciones. Con ello en la que se establece un ciclo antes de llegar
se de ne la arquitectura de la solución elegi- a la fase de mantenimiento, veri cando que el
da. El segundo de ne los algoritmos empleados sistema nal este libre de fallos.
y la organización del código para comenzar la
Otros ejemplos de variantes del modelo en cas-
implementación.
cada son el modelo en cascada con fases so-
lapadas, cascada con subproyectos, y cascada
53.1.3 Diseño del Programa con reducción de riesgos.* [2]

Es la fase en donde se realizan los algoritmos

necesarios para el cumplimiento de los requeri- 53.3 Ventajas
mientos del usuario así como también los análi-
sis necesarios para saber qué herramientas usar Realiza un buen funcionamiento en equipos
en la etapa de Codi cación débiles y productos maduros, por lo que se re-
quiere de menos capital y herramientas para
hacerlo funcionar de manera óptima.
53.1.4 Codi cación
Es un modelo fácil de implementar y entender.
Es la fase en donde se implementa el código Está orientado a documentos.
fuente, haciendo uso de prototipos así como de
Es un modelo conocido y utilizado con fre-
pruebas y ensayos para corregir errores.
cuencia.
Dependiendo del lenguaje de programación y
Promueve una metodología de trabajo efecti-
su versión se crean las bibliotecas y componen-
va: De nir antes que diseñar, diseñar antes que
tes reutilizables dentro del mismo proyecto pa-
codi car.* [3]
ra hacer que la programación sea un proceso
mucho más rápido.
53.4 Desventajas
53.1.5 Pruebas
En la vida real, un proyecto rara vez sigue una
Los elementos, ya programados, se ensamblan secuencia lineal, esto crea una mala implemen-
para componer el sistema y se comprueba que tación del modelo, lo cual hace que lo lleve al
funciona correctamente y que cumple con los fracaso.
requisitos, antes de ser entregado al usuario -
El proceso de creación del software tarda mu-
nal.
cho tiempo ya que debe pasar por el proceso de
prueba y hasta que el software no esté completo
53.1.6 Veri cación no se opera. Esto es la base para que funcione
bien.
Es la fase en donde el usuario nal ejecuta el Cualquier error de diseño detectado en la etapa
sistema, para ello el o los programadores ya de prueba conduce necesariamente al rediseño
realizaron exhaustivas pruebas para comprobar y nueva programación del código afectado, au-
que el sistema no falle. mentando los costos del desarrollo.
En la creación de desarrollo de cascada se im- Una etapa determinada del proyecto no se pue-
plementa los códigos de investigación y prue- de llevar a cabo a menos de que se haya culmi-
bas del mismo. nado la etapa anterior.

53.1.7 Mantenimiento 53.5 Véase también

Una de las etapas más críticas, ya que se destina
un ∩∧ % de los recursos, es el mantenimiento • Ingeniería de software
del Software ya que al utilizarlo como usuario • Desarrollo en espiral
nal puede ser que no cumpla con todas nues-
tras expectativas. • Modelos de desarrollo de software: Cascada vs V
53.7. ENLACES EXTERNOS 99

53.6 Referencias
[1] S. Pressman, Roger. Ingeniería del Software: Un enfoque
práctico, 3.ª Edición, Pag. 2∨-30.

[2] , Patricia Arieta Melgarejo, Modelos del ciclo de vida de

software.

[3] , Ruby Casallas, Andrés Yie, Ingeniería de Software: Ci-

clos de Vida y Metodologías.

53.7 Enlaces externos

• Ciclo de vida del software
Capítulo 54

Desarrollo en espiral

El desarrollo en espiral es un modelo de ciclo de vida Enhancement”.* [1] En 19∪∪, Boehm publicó un artículo
del software de nido por primera vez por Barry Boehm similar* [2] destinado a una audiencia más amplía. Bási-
en 19∪∨,* [1] utilizado generalmente en la Ingeniería de camente consiste en una serie de ciclos que se repiten en
software. Las actividades de este modelo se conforman en forma de espiral, comenzando desde el centro. Se suele
una espiral, en la que cada bucle o iteración representa un interpretar como que dentro de cada ciclo de la espiral se
conjunto de actividades. Las actividades no están jadas sigue un Modelo Cascada, pero no necesariamente debe
a ninguna prioridad, sino que las siguientes se eligen en ser así. El Espiral puede verse como un modelo evoluti-
función del análisis de riesgo, comenzando por el bucle vo que conjuga la naturaleza iterativa del modelo MCP
interior. con los aspectos controlados y sistemáticos del Modelo
Cascada, con el agregado de gestión de riesgo.

54.1 Introducción 54.2 Ciclos o Iteraciones

La Ingeniería de software, se vale y establece a partir de En cada vuelta o iteración hay que tener en cuenta:
una serie de modelos que establecen y muestran las dis-
tintas etapas y estados por los que pasa un producto soft-
ware, desde su concepción inicial, pasando por su desa- • Los Objetivos: qué necesidad debe cubrir el pro-
rrollo, puesta en marcha y posterior mantenimiento, hasta ducto.
la retirada del producto. A estos modelos se les denomina
• Alternativas: las diferentes formas de conseguir los
«modelos de ciclo de vida del software». El primer mode-
objetivos de forma exitosa, desde diferentes puntos
lo concebido fue el de Royce, más comúnmente conocido
de vista como pueden ser:
como desarrollo en cascada o desarrollo lineal secuencial.
Este modelo establece que las diversas actividades que se
van realizando al desarrollar un producto software suce- 1. Características: experiencia del personal, requisi-
den de forma lineal. tos a cumplir, etc.
Boehm, autor de diversos artículos de ingeniería del soft- 2. Formas de gestión del sistema.
ware; modelos de estimación de esfuerzo y tiempo que
se consume en hacer productos software; y Modelos de 3. Riesgo asumido con cada alternativa.
Ciclo de Vida; ideó y promulgó un modelo desde un en-
foque distinto al tradicional en Cascada: El Modelo Evo- • Desarrollar y Veri car: Programar y probar el
lutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tie- software.
ne en cuenta fuertemente el riesgo que aparece a la hora
de desarrollar software. Para ello, se comienza mirando
las posibles alternativas de desarrollo, se opta por la de Si el resultado no es el adecuado o se necesita implemen-
riesgo más asumible y se hace un ciclo de la espiral. Si el tar mejoras o funcionalidades:
cliente quiere seguir haciendo mejoras en el software, se
vuelve a evaluar las distintas nuevas alternativas y riesgos • Se plani caran los siguientes pasos y se comienza un
y se realiza otra vuelta de la espiral, así hasta que llegue nuevo ciclo de la espiral. La espiral tiene una forma
un momento en el que el producto software desarrollado de caracola y se dice que mantiene dos dimensiones,
sea aceptado y no necesite seguir mejorándose con otro la radial y la angular:
nuevo ciclo.
Este modelo fue propuesto por Boehm en 19∪∨ en su ar- 1. Angular: Indica el avance del proyecto del software
tículo “A Spiral Model of Software Development and dentro de un ciclo.

100
54.3. MECANISMOS DE CONTROL 101

2. Radial: Indica el aumento del coste del proyecto, • Dependiendo del resultado de la evaluación de los
ya que con cada nueva iteración se pasa más tiempo riesgos, se elige un modelo para el desarrollo, el que
desarrollando. puede ser cualquiera de los otros existentes, como
formal, evolutivo, cascada, etc. Así si por ejemplo
Este sistema es muy utilizado en proyectos grandes y si los riesgos en la interfaz de usuario son dominan-
complejos como puede ser, por ejemplo, la creación de tes, un modelo de desarrollo apropiado podría ser
un Sistema Operativo. la construcción de prototipos evolutivos. Si lo ries-
gos de protección son la principal consideración, un
Al ser un modelo de Ciclo de Vida orientado a la gestión desarrollo basado en transformaciones formales po-
de riesgo se dice que uno de los aspectos fundamentales dría ser el más apropiado.
de su éxito radica en que el equipo que lo aplique tenga
la necesaria experiencia y habilidad para detectar y cata-
logar correctamente los riesgos. Análisis del riesgo

• Se lleva a cabo el estudio de las causas de las posi-

54.2.1 Tareas bles amenazas y probables eventos no deseados y los
daños y consecuencias que éstas puedan producir.
Para cada ciclo habrá cuatro actividades: Se evalúan alternativas. Se debe tener un prototipo
antes de comenzar a desarrollar y probar.
1. Determinar Objetivos.
En resumen, es para tener en cuenta los riesgos de cada
2. Análisis del riesgo. uno de los ambitos
3. Desarrollar y probar.

4. 'Planificación.' 54.3 Mecanismos de control

• La dimensión radial mide el coste.
Determinar objetivos Análisis del riesgo
• La dimensión angular mide el grado de avance del
proyecto.

54.4 Variaciones del Modelo En

Espiral
Planificación Desarrollar y probar

Modelo en Espiral Típico de seis regiones

Modelo en espiral(Boehm, 1986).
El modelo en espiral puede adaptarse y aplicarse a lo largo
de la vida del software de computadora, a diferencia del
modelo de proceso clásico que termina cuando se entrega
Determinar o jar objetivos
el software.
• Fijar también los productos de nidos a obtener: re- Las ∨ regiones que componen este modelo son las siguien-
quisitos, especi cación, manual de usuario. tes:
• Fijar las restricciones.
• Comunicación con el cliente - Tareas necesarias pa-
• Identi cación de riesgos del proyecto y estrategias ra plantear la comunicación entre el desarrollador y
alternativas para evitarlos. el cliente.

• Hay una cosa que solo se hace una vez: plani cación • Plani cación - Tareas inherentes a la de nición de
inicial. recursos, el tiempo y otras informaciones relaciona-
das con el proyecto. Son todos los requerimientos.

Desarrollar, veri car y validar(probar) • Análisis de riesgos – Tareas para evaluar riesgos téc-
nicos y otras informaciones relacionadas con el pro-
• Tareas de la actividad propia y de prueba. yecto.

• Análisis de alternativas e identi cación resolución • Ingeniería - Tareas para construir una o más repre-
de riesgos. sentaciones de la aplicación.
102 CAPÍTULO 54. DESARROLLO EN ESPIRAL

• Construcción y adaptación - Tareas requeridas para 54.7 Inconvenientes

construir, probar, instalar y proporcionar soporte a
los usuarios. Plani car un proyecto con esta metodología es a menudo
imposible, debido a la incertidumbre en el número de ite-
• Evaluación del cliente - Tareas requeridas para ob- raciones que serán necesarias. En este contexto la evalua-
tener la reacción del cliente según la evaluación de ción de riesgos es de la mayor importancia y, para gran-
las representaciones del software creadas durante la des proyectos, dicha evaluación requiere la intervención
etapa de ingeniería e implementación durante la eta- de profesionales de gran experiencia.
pa de instalación.* [3]
El IEEE clasi ca al desarrollo en espiral como modelo no
operativo en sus clasi caciones de MCV.* [∧]
Modelo en espiral WIN WIN

El modelo Win-Win es una adaptación del modelo espiral 54.8 Véase también
que se enfatiza en la participación del cliente en el pro-
ceso de desarrollo de un producto de software. En un ca- • Ingeniería de Software
so ideal, el desarrollador simplemente pregunta al cliente
lo que se requiere y el cliente proporciona su ciente in- • Desarrollo de Software
formación y detalles para proceder. Sin embargo esto no • Modelo en Cascada o Secuencial
suele ocurrir en la mayoría de los casos y es necesario
que se establezcan negociaciones signi cativas entre am- • Modelo Iterativo Incremental
bas partes para equilibrar la funcionalidad y rendimiento
con los costos y tiempo de salida al mercado del produc- • Modelo por Prototipos
to. El modelo Win-Win deriva su nombre del objetivo de • Modelo de Desarrollo Rápido
estas negociaciones, es decir, “ganar-ganar”. El cliente
recibe el producto que satisface la mayoría de sus nece-
sidades, y el desarrollador trabaja para alcanzar presu-
puestos y fechas de entrega. Para lograr este objetivo, se
54.9 Referencias
realizan varias actividades de negociación al principio de
cada paso alrededor de la espiral.* [4] [1] Boehm B, A Spiral Model of Software Development
and Enhancement, ACM SIGSOFT Software Enginee-
ring Notes, ACM, 11(4):14-24, Agosto 19∪∨.

[2] Boehm B, “A Spiral Model of Software Development

54.5 Ventajas and Enhancement", IEEE Computer, IEEE, 21(∧):∨1-∩2,
May 19∪∪
El análisis del riesgo se hace de forma explícita y clara.
[3] [Link]
Une los mejores elementos de los restantes modelos. [Link]

[4] [Link]
• Reduce riesgos del proyecto
[∧] Developing a Software Project Life Cycle Process (IEEE
• Incorpora objetivos de calidad 10∩4), 30 de marzo de 200∨.

• Integra el desarrollo con el mantenimiento, etc.

54.10 Enlaces externos
Además es posible tener en cuenta mejoras y nuevos re-
querimientos sin romper con la metodología, ya que este • A Spiral Model of Software Development and En-
ciclo de vida no es rígido ni estático. hancement. artículo original de Barry Boehm en el
que proponía el modelo de desarrollo en espiral (en
inglés)

54.6 Desventajas

• Genera mucho tiempo en el desarrollo del sistema

• Modelo costoso

• Requiere experiencia en la identi cación de riesgos

Capítulo 55

Desarrollo iterativo y creciente

Desarrollo iterativo y creciente (o incremental) es un ed Process y el Dynamic Systems Development Met-

proceso de desarrollo de software creado en respuesta a hod. El desarrollo incremental e iterativo es también una
las debilidades del modelo tradicional de cascada. parte esencial de un tipo de programación conocido co-
Básicamente este modelo de desarrollo, que no es más mo Extreme Programming y los demás frameworks de
desarrollo rápido de software.
que un conjunto de tareas agrupadas en pequeñas etapas
*
repetitivas (iteraciones), [1] es uno de los más utilizados
en los últimos tiempos ya que, como se relaciona con no-
vedosas estrategias de desarrollo de software y una pro- 55.2 Ciclo de vida
gramación extrema, es empleado en metodologías diver-
sas. La idea principal detrás de mejoramiento iterativo es
El modelo consta de diversas etapas de desarrollo en cada desarrollar un sistema de programas de manera incre-
incremento, las cuales inician con el análisis y nalizan mental, permitiéndole al desarrollador sacar ventaja de lo
con la instauración y aprobación del sistema.* [2] que se ha aprendido a lo largo del desarrollo anterior, in-
crementando, versiones entregables del sistema. El apren-
dizaje viene de dos vertientes: el desarrollo del sistema,
y su uso (mientras sea posible). Los pasos claves en el
55.1 Concepto de desarrollo itera- proceso son comenzar con una implementación simple de
los requerimientos del sistema, e iterativamente mejorar
tivo y creciente la secuencia evolutiva de versiones hasta que el sistema
completo esté implementado. En cada iteración, se reali-
Se plani ca un proyecto en distintos bloques temporales zan cambios en el diseño y se agregan nuevas funcionali-
que se le denominan iteración. En una iteración se repite dades y capacidades al sistema.
un determinado proceso de trabajo que brinda un resul- Básicamente este modelo se basa en dos premisas:
tado más completo para un producto nal, de forma que
quien lo utilice reciba bene cios de este proyecto de ma-
• Los usuarios nunca saben bien que es lo que necesi-
nera creciente.
tan para satisfacer sus necesidades.
Para llegar a lograr esto, cada requerimiento debe tener
un completo desarrollo en una única iteración que debe de • En el desarrollo, los procesos tienden a cambiar.* [4]
incluir pruebas y una documentación para que el equipo
pueda cumplir con todos los objetivos que sean necesa- El proceso en sí mismo consiste de:
rios y esté listo para ser dado al cliente. Así se evita tener
arriesgadas actividades en el proyecto nalizado. • Etapa de inicialización
Lo que se busca es que en cada iteración los componentes • Etapa de iteración
logren evolucionar el producto dependiendo de los com-
pletados de las iteraciones antecesoras, agregando más • Lista de control de proyecto
opciones de requisitos y logrando así un mejoramiento
mucho más completo.
55.2.1 Consideraciones sobre el momento
Una manera muy primordial para dirigir al proceso itera-
de aplicación
tivo incremental es la de priorizar los objetivos y reque-
rimientos en función del valor que ofrece el cliente.* [3] Para integrar la usabilidad en un proceso de desarrollo,
Para apoyar el desarrollo de proyectos por medio de este no es su ciente con asignar técnicas de usabilidad a ac-
modelo se han creado frameworks (entornos de trabajo), tividades de desarrollo, puesto que no todas las técnicas
de los cuales los dos más famosos son el Rational Uni- de usabilidad son aplicables en cualquier momento de un

103
104 CAPÍTULO 55. DESARROLLO ITERATIVO Y CRECIENTE

desarrollo iterativo. Por ejemplo, las técnicas para desa- • Las modi caciones deben ser más fáciles de hacer
rrollar el concepto del producto están concebidas para su conforme avanzan las iteraciones. Si no es así, hay un
aplicación en los primeros esfuerzos del desarrollo, cuan- problema primordial usualmente encontrado en un
do las necesidades se identi can y el esquema general del diseño débil o en la proliferación excesiva de parches
sistema se establece. Aunque es aconsejable aplicarlas al sistema.
también más tarde, para re nar el concepto, su princi-
pal esfuerzo de aplicación esta en las tareas iniciales de • Los parches normalmente deben permanecer solo
desarrollo.* [∧] por una o dos iteraciones. Se hacen necesarios para
evitar el rediseño durante una fase de implementa-
ción.
55.2.2 Etapa de inicialización
• La implementación existente debe ser analizada fre-
Se crea una versión del sistema. La meta de esta etapa cuentemente para determinar qué tal se ajusta a las
es crear un producto con el que el usuario pueda inter- metas del proyecto.
actuar, y por ende retroalimentar el proceso. Debe ofre-
cer una muestra de los aspectos claves del problema y • Las facilidades para analizar el programa deben ser
proveer una solución lo su cientemente simple para ser utilizadas cada vez para ayudar en el análisis de im-
comprendida e implementada fácilmente. Para guiar el plementaciones parciales.
proceso de iteración se crea una lista de control de pro-
• La opinión del usuario debe ser solicitada y anali-
yecto, que contiene un historial de todas las tareas que
zada para indicar de ciencias en la implementación
necesitan ser realizadas. Incluye cosas como nuevas fun-
referida por él.
cionalidades para ser implementadas, y areas de rediseño
de la solución ya existente. Esta lista de control se revisa
periódica y constantemente como resultado de la fase de
análisis. 55.3 Caso práctico
La mejora iterativa fue exitosamente aplicada al desarro-
55.2.3 Etapa de iteración llo de una familia extensa de compiladores para una fa-
milia de lenguajes de programación en una gama de ar-
Esta etapa involucra el rediseño e implementación de una quitecturas de hardware. Un conjunto de 1∩ versiones del
tarea de la lista de control de proyecto, y el análisis de la sistema se desarrollaron en un lugar, generando 1∩ mil lí-
versión más reciente del sistema. La meta del diseño e neas de código fuente de lenguaje de alto nivel (∨∧00 de
implementación de cualquier iteración es ser simple, di- código ejecutable). El sistema posteriormente fue desa-
recta y modular, para poder soportar el rediseño de la rrollado en dos sitios diferentes, llegando a dos versiones
etapa o como una tarea añadida a la lista de control de diferentes del lenguaje base: una versión esencialmente
proyecto. El código puede, en ciertos casos, representar se enfocaba en aplicaciones matemáticas, añadiendo nú-
la mayor fuente de documentación del sistema. El aná- meros reales y varias funciones matemáticas, y la otra se
lisis de una iteración se basa en la retroalimentación del centró en añadir capacidades para escribir del compila-
usuario y en el análisis de las funcionalidades disponibles dor. Cada iteración fue analizada del punto de vista de
del programa. Involucra el análisis de la estructura, mo- los usuarios (las capacidades del lenguaje fueron deter-
dularidad, usabilidad, con abilidad, e ciencia y e cacia minadas en parte por las necesidades del usuario) y el
(alcanzar las metas). La lista de control del proyecto se punto de vista del desarrollador (el diseño del compila-
modi ca bajo la luz de los resultados del análisis. dor evolucionó para ser más fácilmente modi cable, por
Las guías primarias que guían la implementación y el aná- ejemplo, para añadir nuevos tipos de datos). Mediciones
lisis incluyen: tales como acoplamiento y modularización fueron segui-
das sobre múltiples versiones.
• Cualquier di cultad en el diseño, codi cación y
prueba de una modi cación debería apuntar a la ne-
cesidad de rediseñar o recodi car. 55.4 Características
• Las modi caciones deben ajustarse fácilmente a los
Usando análisis y mediciones como guías para el proce-
módulos fáciles de encontrar y a los aislados. Si no
so de mejora es una diferencia mayor entre las mejoras
es así, entonces se requiere algún grado de rediseño.
iterativas y el desarrollo rápido de aplicaciones, princi-
• Las modi caciones a las tablas deben ser especial- palmente por dos razones:
mente fáciles de realizar. Si dicha modi cación no
ocurre rápidamente, se debe aplicar algo de redise- • Provee de soporte para determinar la efectividad de
ño. los procesos y de la calidad del producto.
55.7. DEBILIDADES DE ESTE MODELO DE DESARROLLO 10∧

• Permite estudiar y después mejorar y ajustar el pro- • Permite separar la complejidad del proyecto, gracias
ceso para el ambiente en particular. a su desarrollo por parte de cada iteración o bloque.

Estas mediciones y actividades de análisis pueden ser • El producto es consistente y puntual en el desarrollo.
añadidas a los métodos de desarrollo rápido existentes. • Los productos desarrollados con este modelo tienen
De hecho, el contexto de iteraciones múltiples conlleva una menor probabilidad de fallar.
ventajas en el uso de mediciones. Las medidas a veces
• Se obtiene un aprendizaje en cada iteración que es
son difíciles de comprender en lo absoluto, aunque en los
aplicado en el desarrollo del producto y aumenta las
cambios relativos en las medidas a través de la evolución
experiencias para próximos proyectos.* [∩]
del sistema puede ser muy informativo porque proveen
una base de comparación. Por ejemplo, un vector de me-
didas m1, m2,..., mn puede ser de nido para caracterizar
varios aspectos del producto en cierto punto, como pue- 55.7 Debilidades de este modelo de
den ser el esfuerzo total realizado, los cambios, los defec- desarrollo
tos, los atributos lógico, físico y dinámico, consideracio-
nes del entorno, etcétera. Así el observador puede decir • La entrega temprana de los proyectos produce la
como las características del producto como el tamaño, la creación de sistemas demasiados simples que a ve-
complejidad, el acoplamiento y la cohesión incrementan ces se ven un poco monótonos a los ojos del personal
o disminuyen en el tiempo. También puede monitorear- que lo recibe.* [∨]
se el cambio relativo de varios aspectos de un producto o
pueden proveer los límites de las medidas para apuntar a
• La mayoría de los incrementos se harán en base de
problemas potenciales y anomalías.
las necesidades de los usuarios. Los incrementos en
si ya son estipulados desde antes de la entrega del
proyecto, sin embargo hay que ver cómo se maneja
55.5 Ventajas del desarrollo incre- el producto para ver si necesita otros cambios ade-
mental más de los estipulados antes de la entrega del pro-
yecto. Este problema no se ve frecuentemente ya
• En este modelo los usuarios no tienen que esperar que la mayoría de las veces los incrementos estipu-
hasta que el sistema completo se entregue para hacer lados suplen satisfactoriamente al usuario.* [∨]
uso de él. El primer incremento cumple los reque-
rimientos más importantes de tal forma que pueden • Los incrementos no deben constar de muchas líneas
utilizar el software al instante. de código ya que la idea de los incrementos es agre-
gar accesorios al programa principal (o funcional),
• Los usuarios pueden utilizar los incrementos inicia- para que este tenga una y mil formas de desenvol-
les como prototipos y obtener experiencia sobre los verse en su tarea; llenar los incrementos de muchas
requerimientos de los incrementos posteriores del líneas de código provocaría que se perdiera la obje-
sistema. tividad o base de lo que se trata el desarrollo incre-
• Existe muy pocas probabilidades de riesgo en el sis- mental.* [∨]
tema. Aunque se pueden encontrar problemas en al-
gunos incrementos, lo normal es que el sistema se • Requiere de un cliente involucrado durante todo el
entregue sin inconvenientes al usuario. curso del proyecto. Hay clientes que simplemente no
estarán dispuestos a invertir el tiempo necesario.
• Ya que los sistemas de más alta prioridad se entre-
gan primero, y los incrementos posteriores se inte-
• El trato con el cliente debe basarse en principios
gran entre ellos, es muy poco probable que los sis-
éticos y colaboración mutua, más que trabajar ca-
temas más importantes sean a los que se les hagan
da parte independientemente, defendiendo sólo su
más pruebas. Esto quiere decir que es menos proba-
propio bene cio.* [∪]
ble que los usuarios encuentren fallas de funciona-
miento del software en las partes más importantes
del sistema.* [∨] • La entrega de un programa que es parcial pero fun-
cional puede hacer vulnerable al programa debido
a la falta de robustez en su sistema, provocando que
agentes ajenos puedan interferir con el correcto fun-
55.6 Ventajas del desarrollo itera- cionamiento del programa en sí.* [∨]
tivo
• Infunde responsabilidad en el equipo de desarrollo
• En el desarrollo de este modelo se da la retroalimen- al trabajar directamente con el cliente, requiriendo
tación muy temprano a los usuarios. de profesionales sobre el promedio.
10∨ CAPÍTULO 55. DESARROLLO ITERATIVO Y CRECIENTE

• Sufre fuertes penalizaciones en proyectos en los cua-

les los requerimientos están previamente de nidos,
o para proyectos“todo/nada”en los cuales se requie-
re que se completen en un 100% el producto para ser
implementado (por ejemplo, licitaciones) otro pun-
to muy importante es asegurarnos de que el trabajo
se pueda cumplir tomando en cuenta los costos que
podamos usar en nuestros propios recursos.

55.8 Véase también

• Scrum
• Iteración

• Desarrollo en cascada
• Ingeniería de software

• Desarrollo de software

55.9 Referencias
[1] |Proceso de Desarrollo Iterativo| [Link]
[Link]/?p=13

[2] |Desarrollo de software. Ciclo de vida iterativo in-

cremental| [Link]
desarrollo-de-software-ciclo-de-vida-iterativo-incremental/

[3] |Desarrollo iterativo e incremental| [Link]

[Link]/desarrollo-iterativo-incremental

[4] |Modelo Iterativo| [Link]

com/Modelo+Iterativo

[∧] Constantine, L. L., Lockwood, L. A. D.: Software for Use:

A Practical Guide to the Models and Methods of Usage -
Centred Design. Addison - Wesley ( 1999)

[∨] Ian Sommerville (200∧). «Entrega Incremental». Ingenie-

ría del Software, Séptima edición edición... España: Pear-
son.

[∩] |Proceso de Desarrollo Iterativo| [Link]

[Link]/?p=13

[∪] |Desarrollo iterativo e incremental| [Link]

[Link]/desarrollo-iterativo-incremental
Capítulo 56

Detección dinámica de invariantes

La “generación dinámica de invariantes”es una téc-

nica dinámica para el análisis informático, normalmente
orientado a la prueba y monitorización de software

56.1 Implementaciones
La implementación más famosa es Daikon

10∩
Capítulo 57

Diagrama de colaboración

Un diagrama de colaboración en las versiones de UML implícitas. Un diagrama de comunicación muestra rela-
1.x es esencialmente un diagrama que muestra interaccio- ciones entre roles geométricamente y relaciona los men-
nes organizadas alrededor de los roles. A diferencia de los sajes con las relaciones, pero las secuencias temporales
diagramas de secuencia, los diagramas de colaboración, están menos claras.
también llamados diagramas de comunicación, muestran
explícitamente las relaciones de los roles. Por otra par-
te, un diagrama de comunicación no muestra el tiempo
como una dimensión aparte, por lo que resulta necesario
etiquetar con números de secuencia tanto la secuencia de 57.2 Tipos
mensajes como los hilos concurrentes.

Es útil marcar los objetos en cuatro grupos: los que exis-

• Muestra cómo las instancias especí cas de las clases
ten con la interacción entera; los creados durante la in-
trabajan juntas para conseguir un objetivo común.
teracción (restricción {new}); los destruidos durante la
• Implementa las asociaciones del diagrama de clases interacción (restricción {destroyed}); y los que se crean
mediante el paso de mensajes de un objeto a otro. y se destruyen durante la interacción (restricción {tran-
Dicha implementación es llamada “enlace”. sient}).
Aunque las comunicaciones muestran directamente la
Un diagrama de comunicación es también un diagrama implementación de una operación, pueden también mos-
de clases que contiene roles de clasi cador y roles de aso- trar la realización de una clase entera. En este uso, mues-
ciación en lugar de sólo clasi cadores y asociaciones. Los tran el contexto necesario para implementar todas las
roles de clasi cador y los de asociación describen la con- operaciones de una clase. Esto permite que el modelador
guración de los objetos y de los enlaces que pueden ocu- vea los roles múltiples que los objetos pueden desempe-
rrir cuando se ejecuta una instancia de la comunicación. ñar en varias operaciones.
Cuando se instancia una comunicación, los objetos están No hay ejemplos de los diagramas, diferentes casos o sis-
ligados a los roles de clasi cador y los enlaces a los roles temas, ya que con UML se modelan áreas de un negocio
de asociación. El rol de asociación puede ser desempe- así como los sistemas que estos requieren
ñado por varios tipos de enlaces temporales, tales como
argumentos de procedimiento o variables locales del pro-
cedimiento. Los símbolos de enlace pueden llevar este-
reotipos para indicar enlaces temporales.
57.3 Mensajes
57.1 Usos
Los mensajes se muestran como echas etiquetadas uni-
das a los enlaces. Cada mensaje tiene un número de se-
Un uso de un diagrama de colaboración es mostrar la im- cuencia, una lista opcional de mensajes precedentes, una
plementación de una operación. La comunicación mues- condición opcional de guarda, un nombre, una lista de
tra los parámetros y las variables locales de la operación, argumentos y un nombre de valor de retorno opcional.
así como asociaciones más permanentes. Cuando se im- El nombre de serie incluye el nombre (opcional) de un
plementa el comportamiento, la secuencia de los mensa- hilo. Todos los mensajes del mismo hilo se ordenan se-
jes corresponde a la estructura de llamadas anidadas y el cuencialmente. Los mensajes de diversos hilos son con-
paso de señales del programa. currentes a menos que haya una dependencia secuencial
Un diagrama de secuencia muestra secuencias en el tiem- explícita. En conclusión en un diagrama muy sencillo de
po como dimensión geométrica, pero las relaciones son hacer.

10∪
 57.5. CAMBIOS EN VERSIONES RECIENTES DE UML 109

57.4 Flujos
Generalmente, un diagrama de comunicación contiene un
símbolo para un objeto durante una operación completa.
Sin embargo, a veces, un objeto contiene diferentes esta-
dos que se deban hacer explícitos. Por ejemplo, un objeto
pudo cambiar de localización o sus asociaciones pudieron
diferenciarse.
Los diferentes símbolos de objeto que representan un ob-
jeto se pueden conectar usando ujos“become”o“con-
versión”. Un ujo“become”es una transición, a partir
de un estado de un objeto a otro. Se dibuja como una e-
cha de línea discontinua con el estereotipo “become”o
“conversión”y puede ser etiquetado con un número de
serie para mostrar cuando ocurre. Un ujo de conversión
también se utiliza para mostrar la migración de un objeto
a partir de una localización a otra distinta para otro lugar
también se deben marcar con el número en secuencias.

57.5 Cambios en versiones recien-

tes de UML
En versiones recientes de UML este diagrama ha sido re-
emplazado por el diagrama de comunicación.
Capítulo 58

Diagrama de ujo

La lámpara no
funciona

¿Está No
enchufada Enchufar
la lámpara? la lámpara

Sí

¿Está Sí
quemada la Cambiar la
ampolleta? ampolleta

No

Comprar
nueva lámpara

Diagrama de ujo sencillo con los pasos a seguir si una lámpara

no funciona.

El diagrama de ujo o diagrama de actividades es la

representación grá ca del algoritmo o proceso. Se utiliza
en disciplinas como programación, economía, procesos
industriales y psicología cognitiva.
En Lenguaje Uni cado de Modelado (UML), un diagra-
ma de actividades representa los ujos de trabajo paso a
paso de negocio y operacionales de los componentes en
un sistema. Un diagrama de actividades muestra el ujo
de control general.
En SysML el diagrama ha sido extendido para indicar u-
jos entre pasos que mueven elementos físicos (p. ej., ga- Diagrama de actividades para un loop a(bucle
solina) o energía (p. ej., presión). Los cambios adicionales
permiten al diagrama soportar mejor ujos de compor-
tamiento y datos continuos.
Estos diagramas utilizan símbolos con signi cados de ni- tan el ujo de ejecución mediante echas que conectan
dos que representan los pasos del algoritmo, y represen- los puntos de inicio y de n del proceso.

110
58.3. TIPOS DE DIAGRAMAS DE FLUJO 111

58.1 Normas de trabajo es una forma especial de diagrama de estado usado para
modelar una secuencia de acciones y condiciones toma-
Un diagrama de ujo presenta generalmente un único das dentro de un proceso.
punto de inicio y un único punto de cierre, aunque puede La especi cación del Lenguaje de Noti cación Uni cado
tener más, siempre que cumpla con la lógica requerida. (UNL) de ne un diagrama de actividad como:
Las siguientes son acciones previas a la realización del “…una variación de los estados de una máquina, los cuales
diagrama de ujo: representan el rendimiento de las acciones o subactivida-
des y las transiciones se provocan por la realización de las
*
• Identi car las ideas principales al ser incluidas en el acciones o subactividades.” [1]
diagrama de ujo. Deben estar presentes el autor o El propósito del diagrama de actividad es modelar un pro-
responsable del proceso, los autores o responsables ceso de ujo de trabajo (work ow) y/o modelar operacio-
del proceso anterior y posterior y de otros proce- nes.
sos interrelacionados, así como las terceras partes
interesadas. Una Operación es un servicio proporcionado por un ob-
jeto, que está disponible a través de una interfaz.
• De nir qué se espera obtener del diagrama de ujo.
Una Interfaz es un grupo de operaciones relacionadas con
• Identi car quién lo empleará y cómo. la semántica.

• Establecer el nivel de detalle requerido.

• Determinar los límites del proceso a describir. 58.3 Tipos de diagramas de ujo

Los pasos a seguir para construir el diagrama de ujo son: • Formato vertical: En él, el ujo y la secuencia de las
operaciones, va de arriba hacia abajo. Es una lista
ordenada de las operaciones de un proceso con toda
• Establecer el alcance del proceso a describir. De es-
la información que se considere necesaria, según su
ta manera quedará jado el comienzo y el nal del
propósito.
diagrama. Frecuentemente el comienzo es la salida
del proceso previo y el nal la entrada al proceso • Formato horizontal: En él, el ujo o la secuencia de
siguiente. las operaciones, va de izquierda a derecha.
• Identi car y listar las principales activida-
• Formato panorámico: El proceso entero está repre-
des/subprocesos que están incluidos en el proceso a
sentado en una sola carta y puede apreciarse de una
describir y su orden cronológico.
sola mirada mucho más rápido que leyendo el tex-
• Si el nivel de detalle de nido incluye actividades to, lo que facilita su comprensión, aun para personas
menores, listarlas también. no familiarizadas. Registra no solo en línea vertical,
sino también horizontal, distintas acciones simultá-
• Identi car y listar los puntos de decisión. neas y la participación de más de un puesto o depar-
tamento que el formato vertical no registra.
• Construir el diagrama respetando la secuencia cro-
nológica y asignando los correspondientes símbolos. • Formato Arquitectónico: Describe el itinerario de
• Asignar un título al diagrama y veri car que esté ruta de una forma o persona sobre el plano arquitec-
completo y describa con exactitud el proceso ele- tónico del área de trabajo. El primero de los ujo-
gido. gramas es eminentemente descriptivo, mientras que
los utilizados son fundamentalmente representati-
vos.
58.2 Descripción
En UML 1.x, un diagrama de actividades es una variación
58.4 Simbología y signi cado
del diagrama de estado UNL donde los “estados”re-
presentan operaciones, y las transiciones representan las • Óvalo o Elipse: Inicio y Final (Abre y cierra el dia-
actividades que ocurren cuando la operación se completa. grama).
El diagrama de mensajes de UML 2.0, mientras que es • Rectángulo: Actividad (Representa la ejecución de
similar en aspecto al diagrama de actividades UML 1.x, una o más actividades o procedimientos).
ahora tiene semánticas basadas en redes de Petri. En
UML 2.0, el diagrama general de interacción está basado • Rombo: Decisión (Formula una pregunta o cues-
en el diagrama de actividades. El diagrama de actividad tión).
112 CAPÍTULO 58. DIAGRAMA DE FLUJO

• Círculo: Conector (Representa el enlace de activi- 58.6 Historia

dades con otra dentro de un procedimiento).
• Triángulo boca abajo: Archivo de nitivo (Guarda
un documento en forma permanente).
• Triángulo boca arriba: Archivo temporal (Propor-
ciona un tiempo para el almacenamiento del docu-
mento). La paternidad del diagrama de ujo es en principio algo
difusa. El método estructurado para documentar grá ca-
mente un proceso como un ujo de pasos sucesivo y alter-
nativos, el“proceso de diagrama de ujo”, fue expuesto
58.5 Cursograma por Frank Gilbreth, en la Sociedad Americana de Inge-
nieros Mecánicos (ASME), en 1921, bajo el enunciado
Se trata de la más común y práctica entre todas las clases de “Proceso de Grá cas-Primeros pasos para encontrar
de diagramas de ujo. Describe el ujo de información el mejor modo”. Estas herramientas de Gilbreth rápida-
en un ente u organización, sus procesos, sistemas admi- mente encontraron sitio en los programas de ingeniería
nistrativos y de control. Permite la impresión visual de los industrial.
procedimientos y una clara y lógica interpretación.
Al principio de los 30, un ingeniero industrial, Allan H.
Mogensen comenzó la formación de personas de nego-
58.5.1 Simbología y normas del cursogra- cios en Lake Placid, Nueva York, incluyendo el uso del
ma diagrama de ujo. Art Spinanger, asistente a las clases de
Mogesen, utilizó las herramientas en su trabajo en Proc-
• Círculo: Procedimiento estandarizado. ter & Gamble, donde desarrolló su“Programa Metódico
de Cambios por Etapas”. Otro asistente al grupo de gra-
• Cuadrado: Proceso de control. duados en 1944, Ben S. Graham, director de ingeniería
• Línea continua: Flujo de información vía formula- de Formcraft Standard Register Corporation, adaptó la
rio o documentación en soporte de papel escrito. grá ca de ujo de procesos al tratamiento de la informa-
ción en su empresa. Y desarrolló la grá ca del proceso
• Línea interrumpida: Flujo de información vía for- de múltiples ujos en múltiples pantallas, documentos, y
mulario digital. sus relaciones. En 194∩, ASME adoptó un conjunto de
símbolos derivados de la obra original de Gilbreth como
• Rectángulo: Formulario o documentación. Se gra-
Norma ASME para los grá cos de procesos (preparada
fíca con el doble de ancho que su altura.
Mishad, Ramsan y Raiaan).
• Rectángulo Pequeño: Valor o medio de pago (che- Sin embargo, según explica Douglas Hartree fueron ori-
que, pagaré, etc.). Se grafíca con el cuádruple de an- ginalmente Herman Goldstine y John von Neumann quie-
cho que su altura, siendo su ancho igual al de los for- nes desarrollaron el diagrama de ujo (inicialmente lla-
mularios. mado“diagrama”) para plani car los programas de or-
• Triángulo (base inferior): Archivo de nitivo. denador. Las tablas de programación original de ujo de
Goldstine y von Neumann, aparecen en un informe no pu-
• Triángulo Invertido (base superior): Archivo blicado, “Plani cación y codi cación de los problemas
Transitorio. de un instrumento de computación electrónica, la Parte
• Semióvalo: Demora. II, Volumen 1 "(194∩), reproducido en las obras comple-
tas de von Neumann.
• Rombo: División entre opciones.
Inicialmente los diagramas de ujo resultaron un medio
• Trapezoide: Carga de datos al sistema. popular para describir algoritmos de computadora, y aún
se utilizan con este n. Herramientas como los diagra-
• Elipsoide: Acceso por pantalla. mas de actividad UML, pueden ser considerados como
• Hexágono: Proceso no representado. evoluciones del diagrama de ujo.

• Pentágono: Conector. En la década de 19∩0 la popularidad de los diagramas de

ujo como método propio de la informática disminuyó,
• Cruz de Diagonales: Destrucción de Formularios. con el nuevo hardware y los nuevos lenguajes de progra-
mación de tercera generación. Y por otra parte se con-
Según la normativa, el ujo presupuesto es de izquierda virtieron en instrumentos comunes en el mundo empre-
a derecha y de arriba hacia abajo, siendo optativo el uso sarial. Son una expresión concisa, legible y práctica de
de echas. Cuando el sentido es invertido (de derecha a algoritmos. Actualmente se aplican en muchos campos
izquierda o de abajo hacia arriba), es obligatorio el uso de del conocimiento, especialmente como simpli cación y
la echa. expresión lógica de procesos, etc.
58.9. VÉASE TAMBIÉN 113

58.7 Ventajas de los diagramas de 58.9 Véase también

ujo
58.10 Referencias
• Favorecen la comprensión del proceso al mostrarlo
como un dibujo. El cerebro humano reconoce muy [1] Bellows, Jeannie, Castek (2000). Activity Diagrams and
fácilmente los dibujos. Un buen diagrama de ujo Operation Architecture. Technologies Group Inc.
reemplaza varias páginas de texto.

• Permiten identi car los problemas y las oportunida- 58.11 Enlaces externos
des de mejora del proceso. Se identi can los pasos,
los ujos de los reprocesos, los con ictos de autori-
dad, las responsabilidades, los cuellos de botella, y • Wikimedia Commons alberga contenido multi-
los puntos de decisión. media sobre Diagrama de ujoCommons.

• Muestran las interfaces cliente-proveedor y las

• Wikimedia Commons alberga contenido multi-
transacciones que en ellas se realizan, facilitando a
media sobre diagrama de actividadesCommons.
los empleados el análisis de las mismas.
• Documentos de la Especi cación UML 2.0
• Son una excelente herramienta para capacitar a los
nuevos empleados y también a los que desarrollan la • Introducción a los Diagramas de Actividades UML
tarea, cuando se realizan mejoras en el proceso. 2

• Al igual que el pseudocódigo, el diagrama de ujo • Microsoft O ce Visio Tutorial

con nes de análisis de algoritmos de programación • PSeInt herramienta para asistir a un estudiante en
puede ser ejecutado en un ordenador, con un IDE sus primeros pasos en programación.
como Free DFD.

58.8 Software para diseño de dia-

gramas de ujo
Actualmente existe una gran cantidad de software para la
elaboración de diagramas de ujo. A continuación se lis-
tan los programas más comunes para elaborar diagramas
de ujo.

• Microsoft O ce ofrece 3 herramientas útiles para

la elaboración de diagramas. Uno de ellos es Micro-
soft O ce Word, que nos permite crear diagramas
de ujo básicos a través de la opción“Formas”que
tiene un apartado especial para diagramas de ujo.
De igual manera Microsoft O ce Power Point ofre-
ce las mismas opciones para crear los diseños de dia-
gramas de ujo. Otra herramienta un poco más so-
sticada es Microsoft O ce Visio, que además de
la simbología básica de los diagramas de ujo cuen-
ta con una variedad de herramientas para elaborar
otros tipos de diagramas como es el caso diagramas
UML entre otros tipos de diagramas de ujo.

• Otro programa e ciente y muy fácil de usar es el pro-

grama “Dia”que brinda una solución rápida para
la creación de diagramas de ujo además de otro ti-
po de diagramas usados en el ambiente informático.
Es considerado la versión no comercial de Microsoft
Visio.
Capítulo 59

Diagrama Nassi-Shneiderman

En programación de computadores un diagrama Nassi- do lo que se puede representar con un diagrama Nassi-
Shneiderman (o NSD por sus siglas en inglés), también Shneiderman se puede representar con un diagrama de
conocido como diagrama de Chapin* [1]* [2] es una repre- ujo. Las únicas excepciones se dan en las instrucciones
sentación grá ca que muestra el diseño de un programa GOTO, break y continue.
estructurado.

59.2 Referencias
[1] Molina Marco, A.; Letelier Torres, P.; Sánchez Palma, P.;
Sánchez Díaz, J. (199∩). «Métodos para especi cación
de módulos». Metodología y tecnología de la programa-
ción. Valencia: Universidad Politécnica de Valencia. p. ∧0.
ISBN ∪4∩∩21∧19∩. Consultado el 2∨ de agosto de 2013.

[2] Eslava Muñoz, V.J. (2012). «Diseño de algoritmos».

Ejemplo de un diagrama Nassi-Shneiderman. Aprendiendo a programar paso a paso con C. Bubok Pu-
blishing. p. 42. ISBN 9∩∪∪4∨∪∨10∨10. Consultado el 2∨
de agosto de 2013.
Fue desarrollado en 19∩2 por Isaac Nassi y Ben Shneider-
man. Este diagrama también es conocido como estructo-
grama, ya que sirve para representar la estructura de los • Nassi, I.; Shneiderman, B.: Técnicas de diagramas
programas. Combina la descripción textual del pseudocó- de ujo para programación estructurada, SIGPLAN
digo con la representación grá ca del diagrama de ujo. Notices XII, Agosto 19∩3.

59.1 Descripción 59.3 Enlaces externos

Basado en un diseño top-down (de lo complejo a lo sim- • Wikimedia Commons alberga contenido mul-
ple), el problema que se debe resolver se divide en sub- timedia sobre Diagrama Nassi-Shneiderman.
problemas cada vez más pequeños - y simples - hasta que Commons
solo queden instrucciones simples y construcciones para
el control de ujo. El diagrama Nassi-Shneiderman re- • A short history of structured owcharts (Nassi-
eja la descomposición del problema en una forma sim- Shneiderman Diagrams), por Ben Shneiderman
ple usando cajas anidadas para representar cada uno de
los subproblemas. Para mantener una consistencia con los
59.3.1 Software
fundamentos de la programación estructurada, los diagra-
mas Nassi-Shneiderman no tienen representación para las • Structorizer – Editor de diagramas Nassi-
instrucciones GOTO. Shneiderman para Linux, Mac OS X & Microsoft
Los diagramas Nassi-Shneiderman se utilizan muy rara- Windows, distribuido bajo GNU General Public
mente en las tareas de programación formal. Su nivel de License
abstracción es muy cercano al código de la programación
estructurada y ciertas modi caciones requieren que se re- • Nessi – Editor e intérprete de diagramas Nassi-
dibuje todo el diagrama. Shneiderman, multiplataforma (Java), distribuido
bajo GNU General Public License
Los diagramas Nassi-Shneiderman son (la mayoría de
las veces) isomór cos con los diagramas de ujo. To-

114
Capítulo 60

di

En informática, di es una utilidad para la comparación veía di con la habilidad natural para crear órdenes de
de archivos que genera las diferencias entre dos archi- edición útiles. Estas órdenes de edición, cuando se gra-
vos o los cambios realizados en un archivo determinado baban en un archivo, podían, junto con el archivo origi-
comparándolo con una versión anterior del mismo archi- nal, ser reconstituidas completamente por ed en el archi-
vo. Di expone los cambios realizados por línea en los vo modi cado. Esto reducía enormemente el necesario
archivos de texto. Las implementaciones modernas tam- almacenamiento secundario para mantener las distintas
bién soportan archivos binarios.* [1] El resultado se cono- versiones de un archivo. McIlroy consideró escribir un
ce como di o patch ya que el mismo puede ser aplicado post-procesador para di donde una variedad de forma-
con el programa Unix patch. El resultado de la compa- tos de resultados pudiesen ser diseñados e implementa-
ración de un archivo similar también se llama “di ”. dos, pero encontró que era más frugal y sencillo hacer
De la misma manera que se usa la palabra "grep" para que di fuese el responsable de generar la sintaxis y la in-
describir la acción de buscar, la palabra di se usa en la formación de entrada de orden contrario aceptada por el
jerga como un verbo que se re ere al cálculo de cualquier comando ed. En 19∪∧, Larry Wall compuso una utilidad
diferencia. Un ejemplo de di . separada, patch, que generalizó y extendió la habilidad
para modi car archivos con resultado di . Los modos de
Emacs permiten también convertir el formato de patches
e incluso editar patches interactivamente.
60.1 Historia
En los primeros años de di , los usos habituales eran la
La utilidad di fue desarrollada a comienzos de los años comparación de cambios en la fuente del código del soft-
setenta en el sistema operativo Unix que estaba creándo- ware y el marcado de documentos técnicos, la veri ca-
se en AT&T Bell Labs en Murray Hill, Nueva Jersey. La ción de la salida de errores de programa, la comparación
versión nal, que apareció por primera vez con la ∧ª edi- de listados de sistemas de archivos y el análisis del códi-
ción de Unix en 19∩4, fue toda ella escrita por Douglas go del montaje del ordenador. La salida apuntada por ed
McIlroy. Este trabajo fue publicado en un artículo de fue modi cada para proporcionar compresión a una se-
19∩∨ co-escrito con James W. Hunt que desarrolló un cuencia de modi caciones hecha a un archivo. La Source
prototipo inicial de di .* [2] Code Control System (SCCS) y su habilidad para archi-
var revisiones apareció a nales de los años setenta como
El trabajo de McIlroy fue precedido e in uido por el pro- consecuencia de almacenar órdenes de edición de di .
grama comparison de Steve Johnson en GECOS y por
el programa proof de Mike Lesk también originado en El Project Xanadu es un predecesor conceptual de di .
Unix y, como di , producía cambios línea a línea e in- Era un proyecto de hipertexto concebido por primera vez
cluso utilizaba paréntesis angulares (">" y "<") para pre- en 19∨0 que debía incluir una versión de un sistema de se-
sentar las inserciones y borrados de línea en el resultado guimiento necesario para su característica de“transpoin-
del programa. Las heurísticas utilizadas en estas prime- ting windows”. La característica subsumía las diferencias
ras aplicaciones fueron, sin embargo, juzgadas como no de archivos en el término expansivo "transclusión", en el
ables. La utilidad potencial de la herramienta di pro- que un documento incluía en él partes de otros documen-
vocó que McIlroy acometiese la investigación y diseño tos o revisiones.
de una herramienta más robusta que podía usarse en una
gran variedad de tareas pero que al tiempo se condujese
bien en los procesos y con las limitaciones de tamaño del
hardware de PDP-11. Su análisis del problema lo llevó
60.2 Algoritmo
a cabo con la colaboración de distintas personas de Bell
Labs como Alfred Aho, Elliot Pinson, Je rey Ullman y La operación de di se basa en resolver el problema
Harold S. Stone. Problema de Subsecuencia Común mas Larga (LCS).
En el contexto de Unix, el uso del editor de línea ed pro- En el problema LCS, se tienen dos secuencias de ítems:

11∧
11∨ CAPÍTULO 60. DIFF

abcdfghjqzabcdefgijkrxyz 60.4 Variantes

y se desea encontrar la secuencia más larga de ítems que
La mayoría de las implementaciones de di se han man-
se presenta las dos secuencias originales en el mismo or-
tenido aparentemente sin cambios desde 19∩∧. Las mo-
den. Esto es, se quiere encontrar una nueva secuencia que
pueda obtenerse de la primera secuencia eliminando al- di caciones consisten en mejoras en el algoritmo base,
gunos ítems, y de la segunda secuencia eliminando otrosla adición de características útiles al comando y el dise-
ño de un nuevos formatos de salida. El algoritmo básico
ítems. Se quiere también que esta secuencia sea tan larga
como sea posible. En este caso es: se describe en el artículo An O(ND) Di erence Algorithm
and its Variations de Eugene W. Myers* [4] y en A File
abcdfgjz
Comparison Program de Webb Miller and Myers.* [∧] El
De la subsecuencia común más larga solo hay un pequeño algoritmo fue descubierto independientemente y descri-
paso para conseguir un resultado del tipo de di : to en Algorithms for Approximate String Matching, de E.
ehiqkrxy+-+-++++ Ukkonen.* [∨] Las primeras ediciones del programa di
fueron diseñadas para la comparación de líneas de archi-
vos de texto dejando que el carácter newline delimitase
las líneas. En los años ochenta, la ayuda para los archivos
binarios dio lugar a un cambio en el diseño y la imple-
mentación de la aplicación.

60.3 Uso 60.4.1 Edit script

Un edit script puede generarse por medio de versiones
Es invocado desde la línea de comando con los nombres modernas de di con la opción -e. option. El edit script
de dos archivos: di original new. El resultado del co- resultante para el ejemplo anterior es el siguiente:
mando representa los cambios requeridos para hacer que 24a Este párrafo contiene importantes nuevas adiciones
el archivo original se convierta en el nuevo archivo. a este documento. . 1∩c detenidamente este documento.
Si original y nuevo son directorios, entonces di se ejecu- Por . ∪,14c comprimir nada. . 0a Esta es una importante
tará sobre cada archivo que exista en ambos directorios. noticia! Debería por lo tanto ser situada al comienzo de
Una opción, -r, hará que cualesquiera subdirectorios em- este documento! .
parejados comparen archivos entre directorios.
Todos los ejemplos en el artículo usan los archivos origi-
nal y nuevo: 60.5 Referencias
El comando di original nuevo produce el siguiente re- [1] MacKenzie et al. “Binary Files and Forcing Text Com-
sultado di normal: parison”in Comparing and Merging Files with GNU Di
0a1,∨ > Esta es una importante > noticia. ¡Debería > por and Patch. Descargado el 2∪ de abril de 200∩.
lo tanto situarse al > comienzo de este > documento! > [2] James W. Hunt and M. Douglas McIlroy (June 19∩∨).
∪,14c14 < comprimir el tamaño de los < cambios. < < «An Algorithm for Di erential File Comparison». Com-
Este párrafo contiene < texto que está anticuado. < Será puting Science Technical Report, Bell Laboratories 41.
borrado en < breve. --- > comprimir nada. 1∩c1∩ < de-
[3] David MacKenzie, Paul Eggert, and Richard Stallman
ternidamente este documento. Por --- > detenidamente
(199∩). Comparing and Merging Files with GNU Di and
este documento. Por 24a2∧,2∪ > > Este párrafo contiene
Patch. ISBN 0-9∧41∨1∩-∧-0.
> importantes nuevas adiciones > a este documento.
[4] E. Myers (19∪∨). «An O(ND) Di erence Algorithm and
En este formato de salida tradicional, a sustituye a aña-
Its Variations». Algorithmica 1 (2): 2∧1–2∨∨.
dido, d a borrado (deleted) y c a cambiado. Los números
de línea del archivo original aparecen antes de a/d/c y los [∧] Webb Miller and Eugene W. Myers (19∪∧). «A File Com-
del archivo modi cado después. Los paréntesis angulares parison Program». Software ̶Practice and Experience 15
aparecen al comienzo de las líneas que son añadidas, bo- (11): 102∧–1040. doi:10.1002/spe.43∪01∧1102.
rradas o cambiadas. Las líneas añadidas se incluyen en el [∨] E. Ukkonen (19∪∧). «Algorithms for Approximate
archivo original para aparecer en el archivo nuevo. Las String Matching». Information and Control 64: 100–11∪.
líneas borradas se eliminan del archivo original para ser doi:10.101∨/S0019-99∧∪(∪∧)∪004∨-2.
borradas en el archivo nuevo.
Por defecto, las líneas comunes a los dos archivos no se
muestran. Las líneas que se han movido se muestran co- 60.6 Véase también
mo añadidas en su nuevo lugar y como borradas en su
antiguo lugar.* [3] • Distancia de Levenshtein
60.7. ENLACES EXTERNOS 11∩

60.7 Enlaces externos

• Sitio o cial (en inglés)
Capítulo 61

Dirección de retorno

Dirección de retorno es un término de programación

informática con el que se re ere a un dato almacenado
dentro de la pila, dato que le indica al programa en qué
línea situarse luego de nalizar una función.

11∪
Capítulo 62

Diseño estructurado

En programación y diseño de algoritmos, el diseño es- Ciencias de la Computación Niklaus Wirth, que consis-
tructurado persigue elaborar algoritmos que cumplan la te precisamente en volver a aplicar el estudio descendente
propiedad de modularidad, para ello, dado un problema Top-Down a cada subproblema una y otra vez hasta obte-
que se pretende resolver mediante la elaboración de un ner subproblemas su cientemente pequeños, que puedan
programa de ordenador, se busca dividir dicho programa ser resueltos por módulos que cumplan, en la medida de
en módulos siguiendo los principios de diseño de Des- lo posible, las características deseables en un módulo en
composición por re namientos sucesivos, creación de el ámbito de la programación. En palabras del propio Ni-
una Jerarquía modular y elaboración de módulos Inde- klaus Wirth:
pendientes.
• En cada paso (del re namiento), una o varias ins-
trucciones del programa dado, se descomponen en
62.1 Etapas del Diseño estructura- instrucciones más detalladas. Esta descomposición
sucesiva o re namiento de especi caciones termina
do cuanto todas las instrucciones están expresadas en
términos de la computadora usada o del lenguaje de
62.1.1 Descomposición programación...

Para ello se requiere un adecuado análisis de dicho pro- • Conforme se re nan las tareas, también los datos
blema, siendo necesario de nir primeramente el proble- pueden ser re nados, descompuestos o estructura-
ma, para lo cual deberá de contener una detallada pero dos, siendo lo natural re nar las especi caciones del
concisa descripción del mismo, un problema bien de ni- programa y de los datos en paralelo.
do es aquel que lleva implícitas tanto una situación inicial
como nal claras • Cada paso de re namiento implica algunas decisio-
nes de diseño. Es importante que el programador sea
←Por qué descomponer un problema en partes? Experi- consciente de los criterios subyacentes (en las de-
mentalmente está comprobado que: cisiones de diseño adoptadas) y de la existencia de
soluciones alternativas...
• Un problema complejo cuesta más de resolver que
otro más sencillo (de Perogrullo). Problema del re namiento sucesivo

• La complejidad de un problema global es mayor que ←Cuándo parar el re namiento?. Un re namiento excesi-
el valor de las complejidades de cada una de sus par- vo podría dar lugar a un número tan grande de módulos
tes por separado. que haría poco práctica la descomposición. Se tendrán en
cuenta estos criterios para dejar de descomponer:
Según esto, merece la pena el esfuerzo de dividir un pro- • Cuando no haya tareas bien de nidas.
blema grande en subproblemas más pequeños. Si el obje-
tivo es elaborar un programa para resolver dicho proble- • Cuando la interfaz de un módulo sea tan complicada
ma grande, cada subproblema (menos complejo) podrá como el propio módulo
ser resuelto por un módulo (subalgoritmo) relativamen-
te fácil de implementar (más que el programa global No
dividido). Ahora la cuestión es ¿cómo realizar la descom- 62.1.2 Jerarquía de módulos
posición?; realizando un estudio descendente Top-Down
que nos lleve desde la concepción del problema (progra- Ésta es una consecuencia directa de la descomposición
ma o algoritmo) global hasta identi car sus partes (módu- del problema mediante re namientos sucesivos, el re-
los). Esta técnica se repite aplicando una estrategia llama- sultado será un conjunto de módulos estrati cados en ca-
da de re namiento sucesivo propuesta por el experto en pas a modo de pirámide donde en la cima habrá un único

119
120 CAPÍTULO 62. DISEÑO ESTRUCTURADO

módulo que representará al programa global y en los ni- • Acoplamiento Común.- Dos módulos acceden a un
veles inferiores aparecerán los módulos resultantes de las mismo recurso común, típicamente memoria com-
sucesivas divisiones. partida, una variable global o un chero. Una varian-
Al nal, debe obtenerse una estructura piramidal donde te de este tipo de acoplamiento es el acoplamiento
los módulos de los niveles superiores se encargan de las externo:
tareas de coordinación, lógica de la aplicación y mani- • Acoplamiento externo.- Los módulos están
pulación de los módulos inferiores; estos otros deberán ligados a componentes externos. Por ejemplo,
realizar tareas de cálculo, tratamiento y entrada/salida de dispositivos de E/S, protocolos de comunica-
información. ciones... etc.

• Acoplamiento de contenido.- Ocurre cuando un

62.1.3 Independencia módulo necesita acceder a una parte de otro módulo.

Ver 'Independencia en Características de un módulo.

62.2.2 Cohesión

62.2 Evaluando el diseño Se de ne como la medida de fuerza o relación fun-

cional existente entre las sentencias o grupos de sen-
tencias de un mismo módulo. Un módulo cohesionado
Para evaluar o determinar cómo es de bueno un diseño ejecutará una única tarea sencilla interactuando muy poco
estructurado se utilizan los conceptos de acoplamiento o nada con el resto de módulos del programa. Se persigue
y cohesión; éstos están muy relacionados entre sí, tanto que los módulos tengan una alta cohesión.
que difícilmente se puede variar uno sin que eso afecte
al otro. También cabe decir que estos conceptos no son En el diseño estructurado podemos encontrarnos con los
medidas que se puedan cuanti car numéricamente, son siguientes ∩ tipos de cohesión (de la mejor o más deseable
más bien magnitudes cualitativas. También se tienen en a la menos recomendable):
consideración los conceptos de fan-in y fan-out.
• Cohesión funcional: Los elementos del módulo es-
tán relacionados en el desarrollo de una única fun-
62.2.1 Acoplamiento ción.

Se de ne como el grado de interdependencia que hay • Cohesión secuencial: Un módulo realiza distintas
entre los distintos módulos de un programa; lo desea- tareas en secuencia, de forma que las entradas de
ble es que esta interdependencia sea lo menor posible, es cada tarea son las salidas de la tarea anterior. No es
decir, un bajo acoplamiento. Los niveles de acoplamien- una mala cohesión si las tareas implicadas no son
to, ordenados de menor (más deseable) a mayor (menos muy complejas y requieren pocas líneas de código.
deseable) son:
• Cohesión comunicacional: El módulo realiza ac-
tividades paralelas usando los mismos datos de en-
• Acoplamiento normal.- Un módulo llama a otro de trada y salida. Como en el caso anterior, tampoco
un nivel inferior y tan solo intercambian datos (pa- se trata de un mal tipo de cohesión si las tareas son
rámetros de entrada/salida). Dentro de este tipo de relativamente sencillas.
acoplamiento podemos encontrarnos 3 subtipos, de-
pendiendo de los datos que intercambien los módu- • Cohesión procedimental: El módulo tiene una se-
los: rie de funciones relacionadas por un procedimiento
efectuado por el código (a modo de biblioteca). Es
• Acoplamiento de datos: Los módulos se comu- similar a la secuencial, pero puede incluir el paso de
nican mediante parámetros. controles. Será deseable que las funciones estén rela-
• Acoplamiento de marca o por estampado: Los cionadas o realicen tareas dentro del mismo ámbito
módulos se pasan datos con estructura de re- (p.e. la biblioteca string.h de C contienen funciones
gistro. No es muy deseable si el módulo recep- para operar con cadenas de caracteres).
tor sólo requiere parte de los datos que se le
pasan. • Cohesión temporal: Los elementos del módulo es-
tán implicados en actividades relacionadas con el
• Acoplamiento de control: Los datos que se in- tiempo.
tercambian entre los módulos son controles.
Debido a que en este subtipo un módulo con- • Cohesión lógica: Las actividades que realiza el mó-
trola la ejecución del otro, no es un buen aco- dulo tienen la misma categoría. Esto es, es como si
plamiento, ya que impide que sean totalmente se tuvieran partes independientes dentro del mismo
independientes. módulo.
62.3. VÉASE TAMBIÉN 121

• Cohesión casual o coincidente: Los elementos del

módulo contribuyen a las actividades relacionándose
mutuamente de una manera poco signi cativa. Este
tipo de cohesión viola el principio de independencia
y de caja negra de los módulos.

62.2.3 Fan-In y Fan-Out

Además de los dos conceptos anteriores, se deben tener en
cuenta el grado de absorción (fan-in) y la diseminación
del control (fan-out) de los módulos para garantizar la
calidad del diseño.

• Fan-In: También llamado grado de absorción. Es

el número de superordinados inmediatos que tiene
el módulo en cuestión. Es conveniente maximizar el
fan-in durante el proceso de diseño, ya que cada ins-
tancia de fan-in múltiple indica que se ha evitado la
duplicación de código.

• Fan-Out: También llamado diseminación del con-

trol. Es el número de subordinados inmediatos que
tiene el módulo en cuestión. Conviene no tener un
fan-out ni muy alto ni muy bajo, ya que eso es un
posible indicador de un diseño pobre. Si no es posi-
ble evitarlo, es preferible un fan-out bajo antes que
uno alto.

62.3 Véase también

• Diseño orientado a objetos
• Programación estructurada

• Programación modular
• Dinámica de sistemas

• Sistema complejo
• Sistema dinámico

• Encapsulamiento (programación orientada a obje-

tos)

• Abstracción (programación orientada a objetos)

Capítulo 63

Distancia de Damerau-Levenshtein

En la teoría de la información y en la ciencia de compu-

tadores, se llama distancia de Damerau-Levenshtein o
distancia de edición al número mínimo de operaciones
requeridas para transformar una cadena de caracteres en
otra. Se entiende por operación, bien una inserción, eli-
minación, sustitución o transposición de dos caracteres.
Lo que la distingue de la distancia de Levenshtein es que
esta última cuenta como una sola operación de edición a
cualquiera de las tres primeras, pero cuenta la transposi-
ción como dos operaciones de edición.

63.1 Véase también

• Ispell

63.2 Enlaces externos

• Implementación en C++ de la distancia de
Damerau-Levenshtein como UDF para MySQL

63.3 Referencias

122
 Capítulo 64

Distancia de Levenshtein

La distancia de Levenshtein, distancia de edición o lenStr2+1 columns declare int d[0..lenStr1, 0..lenStr2]
distancia entre palabras es el número mínimo de ope- // i and j are used to iterate over str1 and str2 declare int
raciones requeridas para transformar una cadena de ca- i, j, cost for i from 0 to lenStr1 d[i, 0] := i for j from 0
racteres en otra, se usa ampliamente en teoría de la in- to lenStr2 d[0, j] := j for i from 1 to lenStr1 for j from
formación y ciencias de la computación. Se entiende por 1 to lenStr2 if str1[i] = str2[j] then cost := 0 else cost :=
operación, bien una inserción, eliminación o la sustitu- 1 d[i, j] := minimum( d[i-1, j] + 1, // deletion d[i, j-1]
ción de un carácter. Esta distancia recibe ese nombre en + 1, // insertion d[i-1, j-1] + cost // substitution ) return
honor al cientí co ruso Vladimir Levenshtein, quien se d[lenStr1, lenStr2]
ocupó de esta distancia en 19∨∧. Es útil en programas que El invariante mantenido a través del algorítmo es que pue-
determinan cuán similares son dos cadenas de caracteres, da transformar el segmento inicial str1[1..i] en str2[1..j]
como es el caso de los correctores de ortografía. empleando un mínimo de d[i,j] operaciones. Al nal, el
Por ejemplo, la distancia de Levenshtein entre “casa”y elemento ubicado en la parte INFERIOR derecha de la
“calle”es de 3 porque se necesitan al menos tres ediciones matriz contiene la respuesta.
elementales para cambiar uno en el otro.

1. casa cala (sustitución de 's' por 'l')

64.2 Implementación
2. cala calla (inserción de 'l' entre 'l' y 'a')
3. calla calle (sustitución de 'a' por 'e') A continuación se puede ver la implementación de la fun-
ción para varios lenguajes de programación. Otros len-
Se le considera una generalización de la distancia de guajes de más alto nível, como php o la funciones de
Hamming, que se usa para cadenas de la misma longitud usuario de MySQL, las incorporan ya, sin necesidad de
y que solo considera como operación la sustitución. Hay implementarla para ser usada.
otras generalizaciones de la distancia de Levenshtein, co-
mo la distancia de Damerau-Levenshtein, que consideran
el intercambio de dos caracteres como una operación. 64.2.1 C
Como buena“distancia”, cumple (aunque es complicado
demostrarlo formalmente), que: int Levenshtein(char *s1,char *s2) { int
t1,t2,i,j,*m,costo,res,ancho; // Calcula tamanios
Dist(A,B) == Dist(B,A) strings t1=strlen(s1); t2=strlen(s2); // Veri ca
Dist(A,B) + Dist(B,C) >= Dist(A,C) que exista algo que comparar if (t1==0) re-
turn(t2); if (t2==0) return(t1); ancho=t1+1; // Re-
serva matriz con malloc m[i,j] = m[j*ancho+i]
64.1 El algoritmo !! m=(int*)malloc(sizeof(int)*(t1+1)*(t2+1)); if
(m==NULL) return(−1); // ERROR!! // Rellena pri-
mera la y primera columna for (i=0;i<=t1;i++) m[i]=i;
Se trata de un algoritmo de tipo bottom-up, común en for (j=0;j<=t2;j++) m[j*ancho]=j; // Recorremos resto
programación dinámica. Se apoya en el uso de una ma- de la matriz llenando pesos for (i=1;i<=t1;i++) for
triz (n + 1) × (m + 1), donde n y m son las longitudes de (j=1;j<=t2;j++) { if (s1[i-1]==s2[j-1]) costo=0; else
las cadenas. Aquí se indica el algoritmo en pseudocódigo costo=1; m[j*ancho+i]=Minimo(Minimo(m[j*ancho+i-
para una función LevenshteinDistance que toma dos ca- 1]+1, // Eliminacion m[(j-1)*ancho+i]+1), // Insercion
denas, str1 de longitud lenStr1, y str2 de longitud lenStr2, m[(j-1)*ancho+i-1]+costo); } // Sustitucion // Devol-
y calcula la distancia Levenshtein entre ellos: vemos esquina nal de la matriz res=m[t2*ancho+t1];
int LevenshteinDistance(char str1[1..lenStr1], char free(m); return(res); }
str2[1..lenStr2]) // d is a table with lenStr1+1 rows and

123
124 CAPÍTULO 64. DISTANCIA DE LEVENSHTEIN

64.2.2 C++

#include <string> #include <vector> #include <algo-

rithm> using namespace std; int levenshtein(const string 64.2.5 Perl
&s1, const string &s2) { int N1 = [Link](); int N2 =
[Link](); int i, j; vector<int> T(N2+1); for ( i = 0; i <= sub fastdistance { my $word1 = shift; my $word2 = shift;
N2; i++ ) T[i] = i; for ( i = 0; i < N1; i++ ) { T[0] = i+1; return 0 if $word1 eq $word2; my @d; my $len1 = length
int corner = i; for ( j = 0; j < N2; j++ ) { int upper = $word1; my $len2 = length $word2; $d[0][0] = 0; for
T[j+1]; if ( s1[i] == s2[j] ) T[j+1] = corner; else T[j+1] (1.. $len1) { $d[$_][0] = $_; return $_ if $_!=$len1
= min(T[j], min(upper, corner)) + 1; corner = upper; } } && substr($word1,$_) eq substr($word2,$_); } for (1..
return T[N2]; } $len2) { $d[0][$_] = $_; return $_ if $_!=$len2 &&
substr($word1,$_) eq substr($word2,$_); } for my $i
(1.. $len1) { my $w1 = substr($word1,$i-1,1); for (1..
$len2) { $d[$i][$_] = _min($d[$i-1][$_]+1, $d[$i][$_-
64.2.3 C# 1]+1, $d[$i-1][$_-1]+($w1 eq substr($word2,$_-1,1) ? 0
: 1)); } } return $d[$len1][$len2]; } sub _min { return
public int LevenshteinDistance(string s, string t, out $_[0] < $_[1] ? $_[0] < $_[2] ? $_[0] : $_[2] : $_[1] <
double porcentaje) { porcentaje = 0; // d es una tabla $_[2] ? $_[1] : $_[2]; }
con m+1 renglones y n+1 columnas int costo = 0; int m
= [Link]; int n = [Link]; int[,] d = new int[m + 1, n
+ 1]; // Veri ca que exista algo que comparar if (n == 64.2.6 Python
0) return m; if (m == 0) return n; // Llena la primera
columna y la primera la. for (int i = 0; i <= m; d[i, 0] = def distance(str1, str2): d=dict() for i in ran-
i++) ; for (int j = 0; j <= n; d[0, j] = j++) ; /// recorre la ge(len(str1)+1): d[i]=dict() d[i][0]=i for i in ran-
matriz llenando cada unos de los pesos. /// i columnas, ge(len(str2)+1): d[0][i] = i for i in range(1, len(str1)+1):
j renglones for (int i = 1; i <= m; i++) { // recorre for j in range(1, len(str2)+1): d[i][j] = min(d[i][j-1]+1,
para j for (int j = 1; j <= n; j++) { /// si son iguales en d[i-1][j]+1, d[i-1][j-1]+(not str1[i-1] == str2[j-1]))
posiciones equidistantes el peso es 0 /// de lo contrario el return d[len(str1)][len(str2)]
peso suma a uno. costo = (s[i - 1] == t[j - 1]) ? 0 : 1; d[i,
j] = [Link]([Link](d[i - 1, j] + 1,
//Eliminacion d[i, j - 1] + 1), //Inserccion d[i - 1, j - 1] 64.2.7 Ruby
+ costo); //Sustitucion } } /// Calculamos el porcentaje
de cambios en la palabra. if ([Link] > [Link]) class String def levenshtein(other) other = other.to_s dis-
porcentaje = ((double)d[m, n] / (double)[Link]); tance = [Link]([Link] + 1, 0) (0..[Link]).each do
else porcentaje = ((double)d[m, n] / (double)[Link]); |i| distance[i] = [Link]([Link] + 1) distance[i][0]
return d[m, n]; } = i end (0..[Link]).each do |j| distance[0][j] = j end
(1..[Link]).each do |i| (1..[Link]).each do |j| distan-
ce[i][j] = [distance[i - 1][j] + 1, distance[i][j - 1] + 1,
distance[i - 1][j - 1] + ((self[i - 1] == other[j - 1]) ? 0
64.2.4 Java : 1)].min end end distance[[Link]][[Link]] end end
puts “casa”.levenshtein “calle”#=> 3
Implementado como una clase estática.
public class LevenshteinDistance { private static int 64.2.8 PHP
minimum(int a, int b, int c) { if(a<=b && a<=c) { return
a; } if(b<=a && b<=c) { return b; } return c; } pu- <?php $lev = levenshtein($input, $word); ?>
blic static int computeLevenshteinDistance(String
str1, String str2) { return computeLevenshtein-
Distance([Link](), [Link]());
} private static int computeLevenshteinDistan- 64.2.9 Delphi
ce(char [] str1, char [] str2) { int [][]distance
= new int[[Link]+1][[Link]+1]; for(int function LevenshteinDistance(Str1, Str2: String): In-
i=0;i<=[Link];i++) { distance[i][0]=i; } for(int teger; var d : array of array of Integer; Len1, Len2
j=0;j<=[Link];j++) { distance[0][j]=j; } for(int : Integer; i,j,cost:Integer; begin Len1:=Length(Str1);
i=1;i<=[Link];i++) { for(int j=1;j<=[Link];j++) Len2:=Length(Str2); SetLength(d,Len1+1); for i :=
{ distance[i][j]= minimum(distance[i-1][j]+1, distan- Low(d) to High(d) do SetLength(d[i],Len2+1); for i := 0
ce[i][j-1]+1, distance[i-1][j-1]+ ((str1[i-1]==str2[j- to Len1 do d[i,0]:=i; for j := 0 to Len2 do d[0,j]:=j; for i:=
1])?0:1)); } } return distance[[Link]][[Link]]; } 1 to Len1 do for j:= 1 to Len2 do begin if Str1[i]=Str2[j]
} then cost:=0 else cost:=1; d[i,j]:= Min(d[i-1, j] + 1, //
 64.3. APLICACIONES 12∧

deletion, Min(d[i, j-1] + 1, // insertion d[i-1, j-1] + cost) == s2[j - 1]) c = 0; else c = 1; var r = d[j * a + i - 1] +
// substitution ); end; Result:=d[Len1,Len2]; end; 1; var s = d[(j - 1) * a + i] + 1; var t = d[(j - 1) * a + i
- 1] + c; d[j * a + i] = [Link]([Link](r, s), t); } }
return(d[l2 * a + l1]); }

64.2.10 [Link]
Public Function Levenshtein(ByVal s1 As String, ByVal 64.3 Aplicaciones
s2 As String) As Integer Dim coste As Integer = 0
Dim n1 As Integer = [Link] Dim n2 As Integer =
• El proyecto ASJP usa la distancia de Levenshtein
[Link] Dim m As Integer(,) = New Integer(n1, n2)
total en una lista de palabras en diferentes lenguas
{} For i As Integer = 0 To n1 m(i, 0) = i Next For i As
del mundo, para medir la “similaridad”o “cer-
Integer = 1 To n2 m(0, i) = i Next For i1 As Integer = 1
canía”de las mismas, esa distancia calculada puede
To n1 For i2 As Integer = 1 To n2 coste = If((s1(i1 - 1) =
emplearse para proponer una clasi cación logené-
s2(i2 - 1)), 0, 1) m(i1, i2) = [Link]([Link](m(i1
tica tentativa de las lenguas del mundo.* [1]
- 1, i2) + 1, m(i1, i2 - 1) + 1), m(i1 - 1, i2 - 1) + coste)
Next Next Return m(n1, n2) End Function • La distancia de Damerau-Levenshtein es una ge-
neralización de la distancia de Levenshtein usada
por los correctores ortográ cos y en la detección de
fraudes en listas de datos.
64.2.11 ActionScript 3.0
public class StringUtils { public static function
levenshtein(s1:String, s2:String):int { if ([Link]
64.4 Véase también
== 0 || [Link] == 0) return 0; var m:uint = [Link]
+ 1; var n:uint = [Link] + 1; var i:uint, j:uint, • Distancia de Damerau-Levenshtein
cost:uint; var d:Vector.<Vector.<int>> = new Vec- • Algoritmo Needleman-Wunsch
tor.<Vector.<int>>(); for (i = 0; i < m; i++) { d[i] =
new Vector.<int>(); for (j = 0; j < n; j++) d[i][j] = 0; • Algoritmo Smith-Waterman
} for (i = 0; i < m; d[i][0] = i++) ; for (j = 0; j < n;
d[0][j] = j++) ; for (i = 1; i < m; i++) { for (j = 1; j < • Algoritmo Bitap
n; j++) { cost = ([Link](i - 1) == [Link](j - 1)) ? • Autómata de Levenshtein
0 : 1; d[i][j] = [Link]([Link](d[i - 1][j] + 1, d[i][j
- 1] + 1), d[i - 1][j - 1] + cost); } } return d[m-1][n-1]; } } • Espacio métrico

• Agrep
• Ratcli /Obershelp
64.2.12 ColdFusion
• Dynamic time warping
<cfscript> function levDistance(s,t) { var d = Array-
New(2); var i = 1; var j = 1; var s_i = “A"; var t_j = • Distancia de Jaro-Winkler
“A"; var cost = 0; var n = len(s)+1; var m = len(t)+1;
d[n][m]=0; if (n is 1) { return m; } if (m is 1) { return n;
} for (i = 1; i lte n; i=i+1) { d[i][1] = i-1; } for (j = 1; j lte 64.5 Referencias
m; j=j+1) { d[1][j] = j-1; } for (i = 2; i lte n; i=i+1) { s_i
= Mid(s,i-1,1); for (j = 2; j lte m; j=j+1) { t_j = Mid(t,j- [1] ASJP - World Language Tree
1,1); if (s_i is t_j) { cost = 0; } else { cost = 1; } d[i][j] =
min(d[i-1][j]+1, d[i][j-1]+1); d[i][j] = min(d[i][j], d[i-
1][j-1] + cost); } } return d[n][m]; } </cfscript>

64.2.13 JavaScript (NodeJS)

function levenshtein(s1, s2) { var l1 = [Link]; var l2
= [Link]; var d = []; var c = 0; var a = 0; if(l1 == 0)
return l2; if(l2 == 0) return l1; var d = new Bu er((l1
+ 1) * (l2 + 1)); a = l1 + 1; for(var i = 0; i <= l1; d[i] =
i++); for(var j = 0; j <= l2; d[j * a] = j++); for(var i = 1;
i <= l1; i++) { for(var j = 1; j <= l2; j++) { if(s1[i - 1]
Capítulo 65

DLO

La expresión DLO (Document Like Object) está amplia-

mente reconocida en la literatura sobre metadatos para
aludir a los documentos de Internet (texto, imagen, au-
dio, video, etc.) y se utiliza para referirse a una unidad
documental o al documento digital mínimo, que for-
ma parte de una colección digital, al cual se le aplican
metadatos para su descripción y recuperación.
El acrónimo DLO surge en el desarrollo de metadatos
del Dublin Core, concretamente en el primer taller que
se llevó a cabo en Ohio (Estados Unidos), donde empe-
zó a utilizarse para diferenciar nociones individuales que
constituyen un objeto discreto, digno de una descripción
individual a través de metadatos.
En el tercer taller que se realizó se amplió su signi cado
para referirse a cualquier recurso de información es-
pecí co que se caracterizase por ser estable (es decir,
que tenía un contenido idéntico para cada usuario).

65.1 Enlaces externos

Glosario web y proyecto de investigación de efectividad
de metadatos
Página o cial de Dublin Core

12∨
Capítulo 66

Driver Chain Manager

Driver Chain Manager (DCM) es una tecnología de 66.1.2 Capacidades de DCM

Microsoft que facilita instalar y trabajar con múltiples
tecnologías de asistencia que utilizan la interfaz del dri- 1. Cuando múltiples drivers están instalados y solo se
ver de la pantalla (Display Driver Interface o DDI) en un está ejecutando uno, los demás no interferirán en és-
mismo equipo. ta independientemente de su posición.
DCM permite a un programa tener conocimiento de la 2. Un usuario puede instalar o desinstalar un driver en
existencia de las otras aplicaciones de asistencia. Permi- cualquier momento sin afectar a los demás.
te evitar que se produzcan problemas entre ellas., como
fallos, mal funcionamiento, que se corrompan o incluso 3. Existen aplicaciones de control remoto que también
que no funcionen. se basan en este encadenamiento.

La tecnología DCM viene instalada en Windows. La 4. Todos los drivers de la cadena usarán el mismo có-
biblioteca se actualiza cuando se actualizan las ayudas. digo de escape para controlar la comunicación entre
Un programador puede utilizar DCM en sus aplicaciones los usuarios y los controladores.
programando desde Microsoft Visual Studio empleando
∧. En caso de que se cambie el adaptador de la pantalla
la biblioteca MSDN.
se detectará si el ajuste de la cadena puede llevarse
a cabo.
∨. Los drivers instalados no interferirán con los nuevos.
66.1 ¿Qué hace?
66.1.3 Cuestiones fuera del alcance de
DCM es un conjunto de rutinas de la biblioteca MSDN DCM
usada por la tecnología de asistencia de Windows. Permi-
te la instalación, desinstalación y mantenimiento de inter- 1. DCM no garantiza que 2 drivers se puedan ejecu-
ceptadores del driver grá co. tar al mismo tiempo. Esto queda en manos de los
Las aplicaciones de asistencia utilizan éstas rutinas para desarrolladores de éstos.
saber en que posición de la cadena de drivers deben co- 2. Para los vendedores que soportan DCM, Los dri-
locar el suyo, de manera que no inter eran con las demás vers instalados pueden permanecer después de los
aplicaciones y éstas con ella que usan DCM. Sin embargo DCM no tendrá co-
nocimiento de ellos.
3. Puede haber otros driver que no usen DCM, pero
66.1.1 Objetivos DCM no tendrá conocimiento de ellos.
4. DCM no soporta usuarios con múltiples monitores.
1. Proporcionar su ciente información sobre los obje-
tos en la pantalla.
66.2 Sotrware que utiliza DCM
2. Asegurarse de que otras aplicaciones de asistencia
instaladas en el sistema no inter eran con las que ya
66.2.1 Aplicaciones que utilizan DCM
se están ejecutando.
Las siguientes aplicaciones ya utilizan esta tecnología.
3. Asegurarse de que varias aplicaciones de asistencia
pueden ejecutarse simultáneamente. • Dolphin Computer Access:

12∩
12∪ CAPÍTULO 66. DRIVER CHAIN MANAGER

• Hal ∧.20 y superior, haya eliminado la información que el segundo necesita,

• Lunar ∧.20 y superior, imposibilitando su funcionamiento.
• Lunar Plus ∧.20 y superior, Actualmente no existe ninguna regla que diga en que or-
den se ejecutan los controladores, eso sin tener en cuenta
• Supernova ∧.20 y superior.
que puede haber más de un lector o magni cador instala-
• Freedom Scienti c: dos en la misma máquina. En caso de haber 2 magni ca-
dores surgiría el problema de cual magní ca la pantalla o
• JAWS 4.∧1 y superior, si se amplía 2 veces consecutivas (ampliación de la am-
• Magic ∪.1 y superior. pliación).
Además las dos aplicaciones no tienen conocimiento una
• GW Micro:
de la otra, por lo que no pueden solucionar el problema.
• Window-Eyes 4.21 y superior. El problema se agrava si son software de diferentes com-
pañías.
• Ai Squared:
Otro problema se crea al desinstalar uno de los drivers,
• ZoomText ∩,11 con el programa de utilidad pudiéndose producir que se rompa la cadena y por ello
del driver. que se pierda el controlador nal.
• ZoomText ∪.0 o superior (DCM built-in).
66.3.2 Forma de solucionarlo
66.2.2 Empresas desarrolladoras
DCM aporta a los desarrolladores de estas aplicaciones
DCM es el resultado de un esfuerzo común de Microsoft una aplicación llamada“DCMUtil”que les permite ma-
y de las empresas asociadas Ai Squared, Dolphin Com- nejar el orden de los drivers y ajustarlos para un correcto
puter Access, GW Micro, y Freedom Scienti c. funcionamiento.

66.2.3 Sistemas operativos que soportan 66.4 Otras aplicaciones que utili-
‘DCM zan DCM
DCM 1.0 es compatible con Windows NT versión 4,
Windows 2000 y Windows XP. Existen otras aplicaciones, de distintas tipologías, que
pueden utilizar DCM. De ellas se destaca el software de
acceso remoto, el cual necesita capturar la imagen de la
pantalla y enviarla por la red.
66.3 Funcionamiento de la cadena
de drivers
66.5 Véase también
El sistema operativo Windows permite instalar una cade-
na de drivers para la generación de la imagen de la panta- • Ti otecnología.
lla. El primer driver obtendrá la información de las apli-
caciones y se la pasará al siguiente driver y así sucesiva- • Windows.
mente con el resto de los drivers, esta cadena acabará en
• MSDN.
el driver de la tarjeta grá ca. Al colocar otros drivers lo
que se pretende es capturar y/o modi car la información.
Por ejemplo, un lector de pantalla no modi cará la infor- 66.6 Fuentes y referencias
mación que reciba, pero capturará los datos necesarios
que requiera para poder leer por el altavoz. Por el contra-
1. biblioteca MSDN: DCM (en inglés).
rio un magni cador de pantalla recortará un rectángulo
de la entrada y se lo pasará al siguiente driver.

66.3.1 El problema
El problema es que el orden de la cadena no es aleato-
rio. Algunas aplicaciones deben ejecutar sus rutinas an-
tes que otras. Por ejemplo, si ejecutamos el magni cador
antes que un lector de pantalla, es posible que el primero
 Capítulo 67

Dublin Core

Dublin Core es un modelo de metadatos elaborado y aus- • Elementos relacionados principalmente con el con-
piciado por la DCMI (Dublin Core Metadata Initiative), tenido del recurso.
una organización dedicada a fomentar la adopción exten-
sa de los estándares interoperables de los metadatos y a • Elementos relacionados principalmente con el re-
promover el desarrollo de los vocabularios especializados curso cuando es visto como una propiedad intelec-
de metadatos para describir recursos para permitir siste- tual.
mas más inteligentes el descubrimiento del recurso. • Elementos relacionados principalmente con la ins-
Las implementaciones de Dublin Core usan generalmente tanciación del recurso.
XML y se basan en el Resource Description Framework.
Dublin Core se de ne por ISO en su norma ISO 1∧∪3∨ Dentro de cada clasi cación encontramos los siguientes
del año 2003, y la norma NISO Z39.∪∧-200∩. elementos:
El nombre viene por Dublin, Ohio, Estados Unidos, ciu- Contenido:
dad que en 199∧ albergó la primera reunión a nivel mun-
dial de muchos de los especialistas en metadatos y Web
• Título: el nombre dado a un recurso, habitualmente
de la época.
por el autor.

Etiqueta: [Link]
67.1 Descripción general
• Claves: los temas del recurso. Típicamente, Subject
Dublin Core es un sistema de 15 de niciones semánti-
expresará las claves o frases que describen el título o
cas descriptivas que pretenden transmitir un signi cado
el contenido del recurso. Se fomentará el uso de vo-
semántico a las mismas.
cabularios controlados y de sistemas de clasi cación
Estas de niciones: formales.

• Son opcionales Etiqueta: [Link]

• Se pueden repetir
• Descripción: una descripción textual del recurso.
• Pueden aparecer en cualquier orden Puede ser un resumen en el caso de un documen-
to o una descripción del contenido en el caso de un
documento visual.
Este sistema de de niciones fue diseñado especí camen-
te para proporcionar un vocabulario de características
“base”, capaces de proporcionar la información descrip- Etiqueta: [Link]
tiva básica sobre cualquier recurso, sin que importe el for-
mato de origen, el área de especialización o el origen cul- • Fuente: secuencia de caracteres usados para identi-
tural. car unívocamente un trabajo a partir del cual pro-
viene el recurso actual.

67.2 Clasi cación y elementos Etiqueta: [Link]

En general, podemos clasi car estos elementos en tres • Tipo del Recurso: la categoría del recurso. Por
grupos que indican la clase o el ámbito de la información ejemplo, página personal, romance, poema, diccio-
que se guarda en ellos: nario, etc.

129
130 CAPÍTULO 67. DUBLIN CORE

Etiqueta: [Link] • Fecha: una fecha en la cual el recurso se puso a dis-

posición del usuario en su forma actual. Esta fecha
• Relación: es un identi cador de un segundo recur- no se tiene que confundir con la que pertenece al
so y su relación con el recurso actual. Este elemento elemento Coverage, que estaría asociada con el re-
permite enlazar los recursos relacionados y las des- curso en la medida que el contenido intelectual está
cripciones de los recursos. de alguna manera relacionado con aquella fecha.

Etiqueta: [Link] Etiqueta: [Link]

• Cobertura: es la característica de cobertura espa- • Formato: es el formato de datos de un recurso, usa-

cial y/o temporal del contenido intelectual del re- do para identi car el software y, posiblemente, el
curso. hardware que se necesitaría para mostrar el recurso.

La cobertura espacial se re ere a una región fí- Etiqueta: [Link]

sica, utilizando por ejemplo coordenadas.
La cobertura temporal se re ere al contenido • Identi cador del Recurso: secuencia de caracteres
del recurso, no a cuándo fue creado (que ya lo utilizados para identi car unívocamente un recurso.
encontramos en el elemento Date). Ejemplos para recursos en línea pueden ser URLs
y URNs. Para otros recursos pueden ser usados
Etiqueta: [Link] otros formatos de identi cadores, como por ejem-
plo ISBN (“International Standard Book Number”
Propiedad Intelectual: ).

• Autor o Creador: la persona u organización res- Etiqueta: [Link] er

ponsable de la creación del contenido intelectual del
recurso. Por ejemplo, los autores en el caso de do- • Lengua: lengua/s del contenido intelectual del re-
cumentos escritos; artistas, fotógrafos e ilustradores curso.
en el caso de recursos visuales.
Etiqueta: [Link]
Etiqueta: [Link]

• Editor: la entidad responsable de hacer que el re-

curso se encuentre disponible en la red en su forma-
67.3 Usos
to actual.
Cualquier persona puede utilizar los metadatos de Dublin
Etiqueta: [Link] Core para describir los recursos de un sistema de infor-
mación. Las páginas Web son uno de los tipos más comu-
nes de recursos que utilizan las descripciones de Dublin
• Otros Colaboradores: una persona u organización Core.
que haya tenido una contribución intelectual signi -
cativa, pero que esta sea secundaria en comparación Los metadatos de Dublin Core están siendo utilizados co-
con las de las personas u organizaciones especi - mo la base para los sistemas descriptivos para varios gru-
cadas en el elemento Creator. (por ejemplo: editor, pos de interés como por ejemplo:
ilustrador y traductor).
• Organizaciones educativas
Etiqueta: [Link]
• Bibliotecas
• Derechos: son una referencia (por ejemplo, una • Instituciones del gobierno.
URL) para una nota sobre derechos de autor, para
un servicio de gestión de derechos o para un servicio • Sector cientí co de la investigación.
que dará información sobre términos y condiciones
de acceso a un recurso. • Autores de páginas Web.

• Negocios que requieren lugares más investigables.

Etiqueta: [Link]
• Corporaciones con sistemas de gerencia extensos en
Instanciación: conocimiento
67.5. ENLACES EXTERNOS 131

67.4 Ventajas
• La simplicidad

• La exibilidad
• La independencia sintáctica

• La interoperabilidad semántica

• Alto nivel de normalización formal

• Crecimiento y evolución del estándar a través de una
institución formal consorciada: la DCMI.
• Consenso internacional

• Modularidad de Metadatos en la Web

• Arquitectura de Metadatos para la Web

67.5 Enlaces externos

•
• Página web o cial (en inglés)

• SEDIC
• y documentos XML/RDF para Recuperación
Capítulo 68

eAthena

eAthena es emulador de código abierto de Ragnarok On-

line. Está escrito en C, aunque se está trabajando en una
versión en C++ llamada eApp(eA++). eAthena soporta
Linux 32bit y ∨4bit y Win32/∨4, aunque se recomienda
el uso de Linux para su mejor desempeño y seguridad.
eAthena está bajo licencia GPL. eAthena posee 2 versio-
nes, TXT y SQL. Como sus nombres lo dicen SQL tra-
baja con bases de datos MySQL mientras que txt trabaja
con archivos de texto. Se recomienda utilizar SQL pa-
ra un mejor desempeño. Está actualizado según el cliente
coreano de Ragnarok Online (kRO) ya que es el que tiene
las últimas novedades de Ragnarok Online.
Muchos de los servidores Ragnarok Online son creados
sobre la base de eAthena ya que estos son muy modi -
cables y no son el juego en si, es solo una emulación a
diferencia de los servidores basados en el mismo códi-
go de Ragnarok Online que son ilegales ya que violan los
Derechos de autor que impone Gravity Corp..
Algunos de los servidores más populares funcionan bajo
eAthena, debido a ser normalmente gratuitos
Cabe resaltar que todo el material que se encuentra en la
parte del cliente, es el que se distribuye sin costo alguno
en los o ciales y que Gravity Corp, solamente exime a
Gravity de toda responsabilidad por ello, incluido su ser-
vidor gratuito de prueba.

68.1 Enlaces externos

• Foro o cial de eAthena

• Foro o cial de Soporte en Español de eAthena

• Repositorio SVN o cial de eAthena

132
Capítulo 69

Efecto Hover

El efecto Hover consiste en la alteración del aspecto de

un elemento de la interfaz grá ca* [1] cuando se sitúa
el puntero sobre el mismo, pero no se ha seleccionado
aún.* [2]

69.1 Referencias
[1] Ejemplo de efecto Hover sobre un enlace.

[2] Blog de Andrés Nieto

69.2 Enlaces de interés

• Efecto Hover según W3C. (en inglés)

• Programación de efecto Hover en JavaScript.

• Más ejemplos de programación.

• Efecto Hover en Microsoft.

• Efecto Hover en Developing Webs dot Net (en in-
glés)
• Tutorial de Efecto Hover en Texto

133
Capítulo 70

Emtp

EMTP es un programa de computadora destinado al aná- sistema simulado.

lisis de circuitos eléctricos, especialmente en régimen
transitorio. El programa permite modelar matemática-
mente sistemas eléctricos, mecánicos y de control, mo- 70.4 Distribución de EMTP-ATP
nofásicos y polifásicos. Su nombre proviene del acrónimo
inglés ElectroMagnetic Transients Program.
El ATP se distribuye por medio de los grupos de usuarios
existentes en varias regiones del mundo. Cualquier per-
sona puede solicitar los materiales del programa siempre
70.1 Historia que esté de acuerdo con la licencia y que sea aprobado
por el grupo de usuarios.
El programa EMTP fue desarrollado como contrapar- Algunos grupos de usuarios son:
te del Transient Network Analyzer (TNA, Analizador de
transitorios en redes) en los años nales de la década de • Canadian/American EMTP User Group
19∨0 por Hermann W. Dommel. Años más tarde él cede-
ría los derechos de autor sobre el programa a la Bonneville • European EMTP-ATP Users Group Assoc.
Power Administration (BPA) de los Estados Unidos. (EEUG)
• Japanese ATP User Group (JAUG)

70.2 ATP • Latin American EMTP User Group (CAUE)

• Argentinian EMTP User Group (CAUE)
El programa ATP, Alternative Transients Program surge
• Australian EMTP User Group (AEUG)
del año 19∪4 cuando los Drs. W. Scott Meyer y Tsu-huei
Liu no aprobaron la comercialización del EMTP por parte • Korean EMTP User Group
de DCG (EMTP Development Coordination Group de la
• Republic of China EMTP User Group
BPA) y EPRI (Electric Power Research Institute). Los Drs.
Meyer y Liu empezaron el desarrollo del ATP como una • Indian EMTP User Group
alternativa no comercializada del EMTP, pero basado en
una copia de éste colocada en el dominio público. • South African ATP User Group

Aunque el programa puede ser adquirido sin costo, ATP

no es del dominio público, se requiere una licencia antes 70.5 Enlaces externos
que los materiales puedan ser recibidos por el interesa-
do. Los requerimientos para usar el ATP son honestidad
en su manejo y el compromiso de no participación en la Página principal de EMTP-ATP con historia e informa-
comercialización de EMTP o de otros programas de si- ción de contacto de los grupos de usuarios
mulación de transitorios.* [1] Grupo de usuarios de EMPT-ATP de Europa
En términos generales, el programa es el mismo y suele
mencionarse como EMTP, ATP o bien EMTP-ATP. • SIMULACIÓN DE SISTEMAS ELÉCTRICOS
CON ATP-EMTP APLICACIONES

70.3 Método de solución 70.6 Referencias

El programa EMTP-ATP utiliza el método de integración [1] Historia y licencia del programa ATP
trapezoidal para resolver las ecuaciones diferenciales del

134
Capítulo 71

Enlace dinámico

Un enlace dinámico es aquel en el cual una biblioteca de

código es enlazada cuando un determinado programa se
ejecuta (en oposición a un enlace estático, que se produ-
ce en tiempo de compilación). La ventaja de este tipo de
enlace es que el programa es más liviano, y que evita la
duplicación de código (por ejemplo, cuando dos progra-
mas requieren usar la misma biblioteca, se necesita sólo
una copia de ésta).
Las bibliotecas de enlace dinámico, o bibliotecas com-
partidas, suelen encontrarse en directorios especí cos del
sistema operativo, de forma que, cada vez que un progra-
ma necesite usar alguna, el sistema operativo conozca el
lugar en el que se encuentra, para así poder enlazarla. Esto
ocasiona algunos problemas de dependencias, principal-
mente entre diferentes versiones de una misma biblioteca.
Muchos programas tienen procedimientos a los que no
llaman, salvo en circunstancias excepcionales. Haciendo
uso de bibliotecas de enlace dinámico, después del en-
samblaje, podemos enlazar cada procedimiento en el mo-
mento en que es llamado.

13∧
Capítulo 72

Enlace estático

Una biblioteca estática es aquella que se enlaza en tiempo

de compilación (en oposición a una de enlace dinámico,
que se enlaza en tiempo de ejecución). La ventaja de este
tipo de enlace es que hace que un programa no dependa
de ninguna biblioteca (puesto que las enlazó al compilar),
haciendo más fácil su distribución.
El enlazado permite al programador y al propio sistema
operativo dividir un programa en varios archivos llama-
dos módulos, que pueden ensamblarse por separado y en-
lazarse en una ocasión posterior, el enlace puede ser de
naturaleza estática o dinámica. El enlace estático da como
resultado, un archivo ejecutable con todos los símbolos y
módulos respectivos incluidos en dicho archivo.

13∨
Capítulo 73

Enlazado

Enlazado, es un proceso que une el código de los módu-

los y bibliotecas que forman un programa para generar el
ejecutable nal.
Este proceso es realizado muchas veces directamente por
el compilador y coloca las referencias externas (como a
las DLL) de manera que funcionen directamente, como
puede ser la situación de las funciones de manera numé-
rica. En algunos compiladores viene un ejecutable espe-
cí co [Link] para esta función.

13∩
Capítulo 74

Entrada chapuza

En computación el antipatrón de diseño Chapuza de en-

trada ocurre cuando la entrada de datos de un programa
especí co no se maneja adecuadamente. Por ejemplo, si
un programa acepta la entrada de cualquier texto por par-
te del usuario nal y se utiliza un algoritmo que manipule
mediante muchas combinaciones todas las cadenas posi-
bles tanto si son válidas como si no lo son.
Por lo general es difícil para un programador detectar, en
una prueba de unidad, todas las posibles combinaciones
erróneas de una entrada de datos. Sin embargo es muy
fácil para el usuario nal reconocer que la cadena de en-
trada es incorrecta y así bloquear el programa. De hecho,
el Desbordamiento de búfer es un ejemplo de agujero de
seguridad provocado por los problemas que causa un mal
manejo de los datos de entrada.
Para evitar la Chapuza de entrada se pueden utilizar al-
goritmos de validación que determinen que datos deben
ser válidos y evitar el tratamiento de los datos no váli-
dos. Por ejemplo, realizar el análisis léxico y/o sintáctico
utilizando software especí co tales como la Herramienta
de programación lex, Yacc y GNU_Bison que permiten
obtener un control robusto de texto compuesto por expre-
siones regulares y gramáticas libres de contexto del len-
guaje. Se recomienda el empleo de estas tecnologías para
asegurar el manejo adecuado de entradas inesperadas.

74.1 Véase también

• Antipatrón de diseño
• Patrón de diseño
• Herramienta de programación lex
• GNU Bison
• Yacc

74.2 Enlaces externos

• Input Kludge AntiPattern Problem by Sourcema-
king Teaching IT Professionals

13∪
Capítulo 75

Error de software

realidad, el término “bug”ya formaba parte del idio-

ma, al menos desde que Thomas Alva Edison lo utilizó en
1∪∪9 re riéndose a interferencias y mal funcionamiento.
Es posible que Hopper lo haya asociado por primera vez a
la informática, en este caso, relacionado a un insecto real.
Por otra parte, aunque durante los años ∧0 del siglo XX,
Hopper también empleó el término“debug”al hablar de
la depuración de errores en los códigos de programación,
el primer uso registrado del término se encuentra en la
Journal of the Royal Aeronautical Society de 194∧.* [∩]

75.2 Defectos de diseño de progra-

mas
Foto del origen de la leyenda acerca del primer“bug”informático
conocido.
• Diseños con colores inapropiados para las personas
que padecen daltonismo
Un error de software, comúnmente conocido como bug
(«bicho»), es un error o fallo en un programa de compu- • Diseños que usan textos con tipografías de difícil
tador o sistema de software que desencadena un resulta- lectura por su tamaño o diseño
do indeseado. Los programas que ayudan a la detección y
eliminación de errores de programación de software son • Diseños que fuerzan el uso del ratón o mouse sin
denominados depuradores (debuggers). dejar alternativas de teclado para personas con dis-
Entre las numerosas incidencias notables causadas por es- funciones motrices
te tipo de error se incluyen la destrucción, en 19∨2, de
• Diseños con implicaciones culturales, por ejemplo
la sonda espacial Mariner 1,* [1] en 199∨, del Ariane ∧
usando partes del cuerpo que en una determinada
∧01.* [2] y, en 201∧, el Airbus A400M* [3]
cultura sean objeto de vergüenza o burla o símbolos
con características de identidad cultural o religiosa

75.1 Orígenes del término • Estimar que el equipo donde se instalará tiene de-
terminadas características (como la resolución de la
pantalla, la velocidad del procesador, la cantidad de
En 19∨∩, los creadores de Mark III informaron del pri- memoria o conectividad a internet) propias de un
mer caso de error en un ordenador causado por un bug. equipo de gama alta, en vez de diseñar el software
El Mark II, ordenador sucesor de ASCC Mark II, cons- para su ejecución en equipos normales
truido en 1944, sufrió un fallo en un relé electromagnéti-
co. Cuando se investigó ese relé, se encontró una polilla
(bug) que provocó que el relé quedase abierto. Grace Mu-
rray Hopper, licenciada en física y destacada matemática 75.3 Errores de programación co-
que trabajó como programadora en el Mark II, pegó el munes
insecto con cinta adhesiva en la bitácora.* [4]
Este incidente es erróneamente referido como el origen • División por cero
de la utilización del término inglés bug («bicho») para
indicar un problema en un aparato o sistema.* [∧]* [∨] En • Ciclo in nito

139
140 CAPÍTULO 75. ERROR DE SOFTWARE

• Problemas aritméticos como desbordamientos Abre el archivo “miarchivo”para escritura comienza a

(over ow) o subdesbordamientos (under ow). escribir datos en mi archivo cierra el archivo

• Exceder el tamaño del array Si “miarchivo”no existe (o el programa o el usuario

no tienen privilegios su cientes para abrirlo), el sistema
• Utilizar una variable no inicializada operativo regresará un error que el programa no atrapará
y tendremos un mensaje como “El archivo “miarchi-
• Acceder a memoria no permitida (Violación de ac- vo”no puede ser abierto para escritura”y botones pa-
ceso) ra reintentar, cancelar y abortar (en el sistema operativo
• Pérdida de memoria (memory leak) Windows), que no tendrán otra acción que repetirse in-
de nidamente sin posibilidad de salir de ese ciclo como
• Desbordamiento o subdesbordamiento de la pila (es- no sea dando por terminado violentamente el programa.
tructura de datos) Un código que permitiese atrapar el error en tiempo de
ejecución sería:
• Desbordamiento de búfer (bu er over ow)
Abre el archivo“miarchivo”para escritura Si el sistema
• Bloqueo mutuo (deadlock) operativo lo permite comienza a escribir datos en“miar-
chivo”si no lo permitió informa al usuario de lo que suce-
• Indizado inadecuado de tablas en bases de datos. de regresa al usuario a un punto donde no haya con icto
• Desbordamiento de la pila de recursión, cuando se (el menú principal, por ejemplo) Continúa operando nor-
dejan demasiadas llamadas en espera. malmente
Los diferentes lenguajes de programación permiten dife-
rentes construcciones lógicas a los programadores para
75.4 Defectos de instalación o pro- atrapar y resolver errores en tiempo de ejecución, como
pueden ser las sentencias assert, try y on error en diferen-
gramación tes lenguajes de programación.

• Eliminación o sustitución de bibliotecas comunes a

más de un programa o del sistema (DLC Hell).
75.6 Véase también
• Reiniciar arbitrariamente la sesión de un usuario pa-
ra que la instalación tenga efecto. • Last Error
• Suponer que el usuario tiene una conexión perma- • Agujero de seguridad
nente a internet.
• Bugzilla
• Utilizar como fuente enlaces simbólicos a cheros
que pueden cambiar de ubicación. • Hot x

• Depurador

75.5 Códigos de errores de lengua- • Depuración de programas

jes de programación • Ingeniería de software

La mayor parte de los lenguajes de programación presen-

tan al menos dos tipos de errores que permiten a los pro- 75.7 Referencias
gramadores manejar las fallas de los programas de una
manera e ciente y que no resulte agresiva con el usua- [1] (en inglés) «History's Worst Software Bugs.», p. 1. Wired.
rio nal. Dichos errores son de compilación y errores en Consultado el 20 de marzo de 2014.
tiempo de ejecución.
[2] (en inglés) «History's Worst Software Bugs.», p. 2. Wired.
Los errores de compilación normalmente inhiben que el
Consultado el 20 de marzo de 2014.
código fuente derive en un programa ejecutable, mien-
tras que los errores en tiempo de ejecución son situacio- [3] (en inglés) «Airbus Cites Assembly Problem in A400M
nes especí cas en las que un evento externo al programa Crash». Consultado el 22 de junio de 201∧
impide su ejecución. Regularmente un programador e -
[4] (en inglés) «Rear Admiral Grace Murray Hopper, USNR,
ciente debe intentar imaginar como debe responder ante
(190∨-1992)»: imagen: Photo #: NH 9∨∧∨∨-KN. Naval
esos eventos de manera que sea el programa y no el usua-
History and Heritage Command. Consultado el 20 de mar-
rio o el sistema operativo los que resuelvan el problema. zo de 2014.
Así por ejemplo un bloque de error no manejado podría
hacer lo siguiente: [∧] bug
75.8. ENLACES EXTERNOS 141

[∨] La polilla que voló dentro de un ordenador y el origen de

«bug informático» | Microsiervos (Leyendas Urbanas)

[∩] (en inglés) «bug». World Wide Words. Consultado el 20

de marzo de 2014.

75.8 Enlaces externos

• Buscador de Vulnerabilidades por productos de
INTECO-CERT
 Capítulo 76

Estilo de programación

Estilo de programación (también llamado estándares de o bien:

código o convención de código) es un término que des- if(horas < 24 && minutos < ∨0 && segundos < ∨0) {
cribe convenciones para escribir código fuente en ciertos return true; } else { return false; }
lenguajes de programación.
El estilo de programación es frecuentemente dependien- con algo como:
te del lenguaje de programación que se haya elegido para
escribir. Por ejemplo el estilo del lenguaje de programa- if(horas<24&&minutos<∨0&&segundos<∨0){return
ción C variará con respecto al del lenguaje BASIC. true;} else{return false;}

Los primeros dos ejemplos son mucho más fáciles de leer

76.1 Características del estilo porque están bien indentados, y los bloques lógicos de
código se agrupan y se representan juntos de forma más
76.1.1 Nombres de variable apropiadas clara.

Una piedra clave para un buen estilo es la elección

apropiada de nombres de variable. Variables pobremen- 76.1.3 Valores booleanos en estructuras de
te nombradas di cultan la lectura del código fuente y su decisión
comprensión.
Como ejemplo, considérese el siguiente extracto de Algunos programadores piensan que las estructuras de
pseudocódigo: decisión como las anteriores, donde el resultado de la de-
cisión es meramente una computación de un valor boo-
get a b c if a < 24 and b < ∨0 and c < ∨0 return true leano, son demasiado prolijos e incluso propensos al
else return false error. Pre eren hacer la decisión en la computación por
Debido a la elección de nombres de variable, es difícil sí mismo, como esto:
darse cuenta de la función del código. Compárese ahora return horas < 12 && minutos < ∨0 && segundos < ∨0;
con la siguiente versión:
La diferencia es, con frecuencia, puramente estilística y
get horas minutos segundos if horas < 24 and minutos < sintáctica, ya que los compiladores modernos producirán
∨0 and segundos < ∨0 return true else return false código objeto idéntico en las dos formas.
La intención el código es ahora más sencilla de discernir,
“dado una hora en 24 horas, se devolverá true si es válida
y false si no”. 76.1.4 Bucles y estructuras de control

El uso de estructuras de control lógicas para bucles tam-

76.1.2 Estilo de indentación
bién es parte de un buen estilo de programación. Ayuda a
Estilo de indentación, en lenguajes de programación que alguien que esté leyendo el código a entender la secuencia
usan llaves para indentar o delimitar bloques lógicos de de ejecución (en programación imperativa). Por ejemplo,
código, como por ejemplo C, es también un punto clave el siguiente pseudocódigo:
el buen estilo. Usando un estilo lógico y consistente hace cuenta = 0 while cuenta < ∧ print cuenta * 2 cuenta =
el código de uno más legible. Compárese: cuenta + 1 endwhile
if(horas < 24 && minutos < ∨0 && segundos < ∨0){ El extracto anterior cumple con las dos recomendaciones
return true; }else{ return false; } de estilo anteriores, pero el siguiente uso de la construc-
ción for hace el código mucho más fácil de leer:

142
 76.3. ENLACES EXTERNOS 143

for cuenta = 0, cuenta < ∧, cuenta=cuenta+1 print cuenta (traducción al español)

*2
• Guía de estilo para código Python (traducción al es-
En muchos lenguajes, el patrón frecuentemente usado pañol)
“por cada elemento en un rango”puede ser acortado a:
• Estándar de código: C# (Philips Medical Systems)
for cuenta = 0 to ∧ print cuenta * 2
• Estilo de programación para Mono
76.1.5 Espaciado • Guía de calidad y estilo Ada 9∧: Directrices para
programadores profesionales
Los lenguajes de formato libre ignoran frecuentemente
los espacios en blanco. El buen uso del espaciado en la • Guía de estilo programación Java
disposición del código de uno es, por tanto, considerado • Estándares de código Java de Ambysoft
un buen estilo de programación.
Compárese el siguiente extracto de código C: • Estándares de código de PHP::Pear

int cuenta; for(cuenta=0;cuenta<10;cuenta++){printf("%d” • Estándares de código Symbian OS C++

,cuenta*cuenta+cuenta);}
con: 76.3.3 Convenciones de código de proyec-
int cuenta; for (cuenta = 0; cuenta < 10; cuenta++) { tos
printf("%d”, cuenta * cuenta + cuenta); }
• Estándares de codi cación de GNU
En los lenguajes de programación de la familia C se reco-
mienda también evitar el uso de caracteres tabulador en • Guía de estilo para codi cación en Mozilla
medio de una línea, ya que diferentes editores de textos
muestran su anchura de forma diferente. • Guía de estilo para el núcleo Linux
El lenguaje de programación Python usa indentación para • Guía de estilo para el código de NetBSD
indicar estructuras de control, por tanto se requiere obli-
gatoriamente una buena indentación. Haciendo esto, la
necesidad de marcar con llaves ({ y }) es eliminada, y la
legibilidad es mejorada sin interferir con los estilos de co-
di cación comunes. Con todo, esto lleva frecuentemente
a problemas donde el código es copiado y pegado den-
tro de un programa Python, requiriendo un tedioso re-
formateado. Adicionalmente, el código Python se vuelve
inusable cuando es publicado en un foro o página web que
elimine el espacio en blanco.

76.2 Véase también

• Estilo de indentación
• Bug

76.3 Enlaces externos

76.3.1 Convenciones de código en caste-

llano
• Manual de Estilo de programación, en formato PDF
y licencia CreativeCommons

76.3.2 Convenciones de código en inglés

• Convenciones de código para el lenguaje Java
Capítulo 77

Eventos del ratón

Un evento del ratón es una acción realizada por el usua-

rio de una interfaz de usuario utilizando el ratón de
computadora (mouse). La interpretación de estas accio-
nes mediante software desarrollado para ello, permite
ejecutar una función asociada a dicha acción.
Algunos ejemplos de eventos de ratón son:

• mouse over: se produce cuando el cursor o puntero

del ratón se encuentra por encima de una determi-
nada zona.
• mouse out: se produce cuando el cursor abandona
una determinada zona.
• mouse clicked: se produce cuando se pulsa un botón
del ratón.
• mouse double-clicked: se produce cuando se pulsa
dos veces en un intervalo pequeño de tiempo un mis-
mo botón del ratón.

La programación de los eventos del mouse se lleva a cabo

mediante llamadas a rutinas especí cas que se ejecutan
cuando se produce una acción. Además, la acción que se
llevará a cabo será diferente dependiendo de en qué par-
te de la pantalla se sitúe este, por ejemplo, si se pulsa el
botón izquierdo y el puntero está en una parte externa a
una aplicación, no ocurrirá nada, pero si por el contrario,
en puntero se encuentra sobre un área que contiene un
botón, al pulsar sobre el ratón se deberá ejecutar la rutina
asociada a ese botón.

77.1 Véase también

• Clic (informática)

• Doble clic

144
Capítulo 78

Exclusión mutua (informática)

Los algoritmos de exclusión mutua (comúnmente abre- semáforo y ambos se quedan a la espera de que el otro
viada como mutex por mutual exclusion) se usan en proceso libere el semáforo. Otros efectos comunes inclu-
programación concurrente para evitar el ingreso a sus sec- yen la Inanición, en el cual un proceso esencial no se eje-
ciones críticas por más de un proceso a la vez. La sección cuta durante el tiempo deseado, y la inversión de priori-
crítica es el fragmento de código donde puede modi car- dades, en el que una tarea de prioridad elevada espera por
se un recurso compartido. otra tarea de menor prioridad, así como la latencia alta en
La mayor parte de estos recursos son las señales, conta- la que la respuesta a las interrupciones no es inmediata.
dores, colas y otros datos que se emplean en la comuni- La mayor parte de la investigación actual en este campo,
cación entre el código que se ejecuta cuando se da servi- pretende eliminar los efectos anteriormente descritos. Si
cio a una interrupción y el código que se ejecuta el resto bien no hay un esquema perfecto conocido, hay un in-
del tiempo. Se trata de un problema de vital importan- teresante esquema no clásico de envío de mensajes entre
cia porque, si no se toman las precauciones debidas, una fragmentos de código que, aunque permite inversiones de
interrupción puede ocurrir entre dos instrucciones cua- prioridad y produce una mayor latencia, impide los inter-
lesquiera del código normal y esto puede provocar graves bloqueos.
fallos. Algunos ejemplos de algoritmos clásicos de exclusión
La técnica que se emplea por lo común para conseguir la mutua son:
exclusión mutua es inhabilitar las interrupciones durante
el conjunto de instrucciones más pequeño que impedi- • El algoritmo de Dekker.
rá la corrupción de la estructura compartida (la sección
crítica). Esto impide que el código de la interrupción se • El algoritmo de Peterson.
ejecute en mitad de la sección crítica.
En un sistema multiprocesador de memoria compartida,
se usa la operación indivisible test-and-set sobre una ban- 78.1 Véase también
dera, para esperar hasta que el otro procesador la despeje.
La operación test-and-set realiza ambas operaciones sin • Cierre de exclusión mutua o locks
liberar el bus de memoria a otro procesador. Así, cuando
el código deja la sección crítica, se despeja la bandera. • Semáforo (inventado por Edsger Dijkstra)
Esto se conoce como spin lock o espera activa. • Monitor (concurrencia)(inventado por C. A. R.
Algunos sistemas tienen instrucciones multioperación in- Hoare) (sin interbloqueos)
divisibles similares a las anteriormente descritas para ma-
nipular las listas enlazadas que se utilizan para las colas
de eventos y otras estructuras de datos que los sistemas
operativos usan comúnmente.
La mayoría de los métodos de exclusión mutua clásicos
intentan reducir la latencia y espera activa mediante las
colas y cambios de contexto. Algunos investigadores a r-
man que las pruebas indican que estos algoritmos espe-
ciales pierden más tiempo del que ahorran.
A pesar de todo lo dicho, muchas técnicas de exclu-
sión mutua tienen efectos colaterales. Por ejemplo, los
semáforos permiten interbloqueos (deadlocks) en los que
un proceso obtiene un semáforo, otro proceso obtiene el

14∧
 Capítulo 79

Expresión regular

Una expresión regular, a menudo llamada también re- Agrupación Los paréntesis pueden usarse para de nir
gex, es una secuencia de caracteres que forma un patrón el ámbito y precedencia de los demás operadores.
de búsqueda, principalmente utilizada para la búsqueda Por ejemplo, "(p|m)adre”es lo mismo que “pa-
de patrones de cadenas de caracteres u operaciones de dre|madre”, y "(des)?amor”se corresponde con
sustituciones. Por ejemplo, el grupo formado por las ca- amor y con desamor.
denas Handel, Hflndel y Haendel se describe con el patrón
“H(a|ä|ae)ndel”. La mayoría de las formalizaciones pro-
porcionan los siguientes constructores: una expresión re-
gular es una forma de representar a los lenguajes regula-
res ( nitos o in nitos) y se construye utilizando caracteres Los constructores pueden combinarse libremente dentro
del alfabeto sobre el cual se de ne el lenguaje. de la misma expresión, por lo que“H(ae?|ä)ndel”equivale
a “H(a|ae|ä)ndel”.
En informática, las expresiones regulares proveen una
manera muy exible de buscar o reconocer cadenas de La sintaxis precisa de las expresiones regulares cambia
texto. según las herramientas y aplicaciones consideradas, y se
describe con más detalle a continuación.

79.1 Construcción de expresiones

regulares
Especí camente, las expresiones regulares se construyen
utilizando los operadores unión, concatenación y clausura 79.2 Aplicaciones
de Kleene. Toda expresión regular tiene algún autómata
nito asociado.
Su utilidad más obvia es la de describir un conjunto de
Alternación Una barra vertical separa las alternativas. cadenas para una determinada función, resultando de uti-
Por ejemplo,“marrón|castaño”se corresponde con lidad en editores de texto y otras aplicaciones informáti-
marrón o castaño. cas para buscar y manipular textos.

Cuanti cación Un cuanti cador tras un carácter espe- Numerosos editores de texto y otras herramientas utilizan
ci ca la frecuencia con la que éste puede ocurrir. expresiones regulares para buscar y reemplazar patrones
Los cuanti cadores más comunes son ?, + y *: en un texto. Por ejemplo, las herramientas proporciona-
das por las distribuciones de Unix (incluyendo el editor
? El signo de interrogación indica que el carácter sed y el ltro grep) popularizaron el concepto de expre-
que le precede puede aparecer como mucho sión regular entre usuarios no programadores, aunque ya
una vez. Por ejemplo, “ob?scuro”se corres- era familiar entre los programadores.
ponde con oscuro y obscuro.
Inicialmente, este reconocimiento de cadenas se progra-
+ El signo más indica que el carácter que le prece- maba para cada aplicación sin mecanismo alguno inhe-
de debe aparecer al menos una vez. Por ejem- rente al lenguaje de programación pero, con el tiempo, se
plo,“ho+la”describe el conjunto in nito hola, ha ido incorporado el uso de expresiones regulares para
hoola, hooola, hoooola, etcétera. facilitar programar la detección de ciertas cadenas. Por
* El asterisco indica que el carácter que le prece- ejemplo, Perl tiene un potente motor de expresiones re-
de puede aparecer cero, una, o más veces. Por gulares directamente incluido en su sintaxis. Otros len-
ejemplo,“0*42”se corresponde con 42, 042, guajes lo han incorporado como funciones especí cas sin
0042, 00042, etcétera. incorporarlo a su sintaxis.

14∨
79.3. LAS EXPRESIONES REGULARES EN PROGRAMACIÓN 14∩

79.3 Las expresiones regulares en • C++: Desde su versión C++11 es posible utilizar ex-
presiones regulares mediante la biblioteca estándar,
programación usando la cabecera <regex>.
Nota: Para el entendimiento completo de esta • Java: existen varias bibliotecas hechas para java que
sección es necesario poseer conocimientos ge- permiten el uso de RegEx, y Sun planea dar soporte
nerales acerca de lenguajes de programación o a estas desde el SDK
programación en general.
• JavaScript: a partir de la versión 1.2 (ie4+, ns4+)
En el área de la programación las expresiones regulares JavaScript tiene soporte integrado para expresiones
son un método por medio del cual se pueden realizar bús- regulares.
quedas dentro de cadenas de caracteres. Sin importar la
amplitud de la búsqueda requerida de un patrón de ni- • Perl: es el lenguaje que hizo crecer a las expresio-
do de caracteres, las expresiones regulares proporcionan nes regulares en el ámbito de la programación hasta
una solución práctica al problema. Adicionalmente, un llegar a lo que son hoy en día.
uso derivado de la búsqueda de patrones es la validación
• PCRE: biblioteca de ExReg para C, C++ y otros
de un formato especí co en una cadena de caracteres da-
lenguajes que puedan utilizar bibliotecas dll (Visual
da, como por ejemplo fechas o identi cadores.
Basic ∨ por ejemplo).
Para poder utilizar las expresiones regulares al programar
es necesario tener acceso a un motor de búsqueda con la • PHP: tiene dos tipos diferentes de expresiones re-
capacidad de utilizarlas. Es posible clasi car los motores gulares disponibles para el programador, aunque la
disponibles en dos tipos según su uso: motores para el variante POSIX (ereg) va a ser desechada en PHP
programador y motores para el usuario nal. ∨.
Motores para el usuario nal: son programas que per- • Python: lenguaje de scripting con soporte de expre-
miten realizar búsquedas sobre el contenido de un archivo siones regulares mediante su librería <regex>.
o sobre un texto extraído y colocado en el programa. Es-
tán diseñados para permitir al usuario realizar búsquedas • .Net Framework: provee un conjunto de clases me-
avanzadas usando este mecanismo, sin embargo es nece- diante las cuales es posible utilizar expresiones re-
sario aprender a redactar expresiones regulares adecuadas gulares para hacer búsquedas, reemplazar cadenas y
para poder utilizarlos e cientemente. Algunos programas validar patrones.
disponibles de este tipo son:
Nota: de las herramientas mencionadas con anterioridad
• grep: programa de los sistemas operativos se utilizan el EditPad Pro y el .Net Framework para dar
Unix/Linux. ejemplos, aunque es posible utilizar las expresiones re-
• sed: programa de los sistemas operativos gulares con cualquier combinación de las herramientas
Unix/Linux que permite la modi cación de la mencionadas. Aunque en general las Expresiones Regu-
salida. lares utilizan un lenguaje común en todas las herramien-
tas, las explicaciones prácticas acerca de la utilización de
• PowerGrep: versión de grep para los sistemas ope- las herramientas y los ejemplos de código deben ser inter-
rativos Windows. pretados de forma diferente. También es necesario hacer
• RegexBuddy: ayuda a crear las expresiones regulares notar que existen algunos detalles de sintaxis de las expre-
en forma interactiva y luego le permite al usuario siones regulares que son propios del .Net Framework que
usarlas y guardarlas. se utilizan en forma diferente en las demás herramien-
tas de programación. Cuando estos casos se den se hará
• EditPad Pro: permite realizar búsquedas con expre- notar en forma explícita para que el lector pueda buscar
siones regulares sobre archivos y las muestra por información respecto a estos detalles en fuentes adicio-
medio de código de colores para facilitar su lectu- nales. En el futuro se incluirán adicionalmente ejemplos
ra y comprensión. de otras herramientas y lenguajes de programación.
Expresiones regulares como motor de búsqueda
Motores para el programador: permiten automatizar el
Las expresiones regulares permiten encontrar porciones
proceso de búsqueda de modo que sea posible utilizarlo
especí cas de texto dentro de una cadena más grande de
muchas veces para un propósito especí co. Estas son al-
gunas de las herramientas de programación disponiblescaracteres. Así, si es necesario encontrar el texto“lote”en
que ofrecen motores de búsqueda con soporte a expre- la expresión“el ocelote saltó al lote contiguo”cualquier
siones regulares: motor de búsqueda sería capaz de efectuar esta labor. Sin
embargo, la mayoría de los motores de búsqueda encon-
• AWK: Forma una parte esencial del lenguaje y por trarían también el fragmento“lote”de la palabra“ocelo-
extensión de la herramienta awk de Unix/Linux te”, lo cual podría no ser el resultado esperado. Algunos
 14∪ CAPÍTULO 79. EXPRESIÓN REGULAR

motores de búsqueda permiten adicionalmente especi - 79.4.2 La admiración "!"

car que se desea encontrar solamente palabras comple-
tas, solucionando este problema. Las expresiones regu- Se utiliza para realizar una “búsqueda anticipada nega-
lares permiten especi car todas estas opciones adiciona- tiva”. La construcción de la expresión regular es con el
les y muchas otras sin necesidad de con gurar opciones par de paréntesis, el paréntesis de apertura seguida de un
adicionales, sino utilizando el mismo texto de búsqueda signo de interrogación y un signo de exclamación. Dentro
como un lenguaje que permite enviarle al motor de bús- de la búsqueda tenemos la expresión regular. Por ejem-
queda exactamente lo que deseamos encontrar en todos plo, para excluir exactamente una palabra, habrá que uti-
los casos, sin necesidad de activar opciones adicionales al lizar "^(palabra.+|(?!palabra).*)$"
realizar la búsqueda.
Expresiones regulares como lenguaje 79.4.3 La barra inversa o antibarra "\"
Para especi car opciones dentro del texto a buscar se uti-
liza un lenguaje o convención mediante el cual se le trans- Se utiliza para escapar el siguiente carácter de la expre-
mite al motor de búsqueda el resultado que se desea obte- sión de búsqueda de forma que este adquiera un signi ca-
ner. Este lenguaje le da un signi cado especial a una serie do especial o deje de tenerlo. O sea, la barra inversa no se
de caracteres. Por lo tanto cuando el motor de búsqueda utiliza nunca por sí sola, sino en combinación con otros
de expresiones regulares encuentre estos caracteres no los caracteres. Al utilizarlo por ejemplo en combinación con
buscará en el texto en forma literal, sino que buscará lo el punto "\.”este deja de tener su signi cado normal y se
que los caracteres signi can. A estos caracteres se les lla- comporta como un carácter literal.
ma algunas veces“meta-caracteres”. A continuación se De la misma forma, cuando se coloca la barra inversa se-
listan los principales meta-caracteres y su función y cómo guida de cualquiera de los caracteres especiales que dis-
los interpreta el motor de expresiones regulares. cutiremos a continuación, estos dejan de tener su signi -
cado especial y se convierten en caracteres de búsqueda
literal.
Como ya se mencionó con anterioridad, la barra inversa
79.4 Descripción de las expresiones también puede darle signi cado especial a caracteres que
regulares no lo tienen. A continuación hay una lista de algunas de
estas combinaciones:

79.4.1 El punto ".” • \t ̶Representa un tabulador.

• \r ̶Representa el“retorno de carro”o“regreso al
El punto se interpreta por el motor de búsqueda como inicio”o sea el lugar en que la línea vuelve a iniciar.
“cualquier carácter”, es decir, busca cualquier carácter
SIN incluir los saltos de línea. Los motores de Expre- • \n ̶Representa la“nueva línea”el carácter por me-
siones regulares tienen una opción de con guración que dio del cual una línea da inicio. Es necesario recor-
permite modi car este comportamiento. En .Net Frame- dar que en Windows es necesaria una combinación
work se utiliza la opción [Link] para de \r\n para comenzar una nueva línea, mientras que
especi car la opción de que busque todos los caracteres en Unix solamente se usa \n y en Mac_OS clásico se
incluidos el salto de línea (\n). usa solamente \r.

El punto se utiliza de la siguiente forma: Si se le dice al • \a ̶Representa una “campana”o “beep”que se

motor de RegEx que busque“g.t”en la cadena“el gato produce al imprimir este carácter.
de piedra en la gótica puerta de getisboro goot”el mo- • \e ̶Representa la tecla “Esc”o “Escape”
tor de búsqueda encontrará “gat”, “gót”y por último
“get”. Nótese que el motor de búsqueda no encuentra • \f ̶Representa un salto de página
“goot"; esto es porque el punto representa un solo carácter • \v ̶Representa un tabulador vertical
y únicamente uno. Si es necesario que el motor encuen-
tre también la expresión “goot”, será necesario utilizar • \x ̶Se utiliza para representar caracteres ASCII o
repeticiones, las cuales se explican más adelante. ANSI si conoce su código. De esta forma, si se busca
el símbolo de derechos de autor y la fuente en la que
Aunque el punto es muy útil para encontrar caracteres que
se busca utiliza el conjunto de caracteres Latin-1 es
no conocemos, es necesario recordar que corresponde a
posible encontrarlo utilizando "\xA9”.
cualquier carácter y que muchas veces esto no es lo que
se requiere. Es muy diferente buscar cualquier carácter • \u ̶Se utiliza para representar caracteres Unicode
que buscar cualquier carácter alfanumérico o cualquier si se conoce su código. "\u00A2”representa el sím-
dígito o cualquier no-dígito o cualquier no-alfanumérico. bolo de centavos. No todos los motores de Expre-
Se debe tomar esto en cuenta antes de utilizar el punto y siones Regulares soportan Unicode. El .Net Frame-
obtener resultados no deseados. work lo hace, pero el EditPad Pro no, por ejemplo.
79.4. DESCRIPCIÓN DE LAS EXPRESIONES REGULARES 149

• \d ̶Representa un dígito del 0 al 9. con la barra inversa dentro de los corchetes es la propia
barra inversa. La expresión regular "[\dA-Fa-f]" nos per-
• \w ̶Representa cualquier carácter alfanumérico. mite encontrar dígitos hexadecimales. Los corchetes nos
• \s ̶Representa un espacio en blanco. permiten también encontrar palabras aún si están escri-
tas de forma errónea, por ejemplo, la expresión regular
• \D ̶Representa cualquier carácter que no sea un “expresi[oó]n”permite encontrar en un texto la palabra
dígito del 0 al 9. “expresión”aunque se haya escrito con o sin tilde. Es
necesario aclarar que sin importar cuantos caracteres se
• \W ̶Representa cualquier carácter no alfanuméri-
introduzcan dentro del grupo por medio de los corchetes,
co.
el grupo sólo le dice al motor de búsqueda que encuentre
• \S ̶Representa cualquier carácter que no sea un es- un solo carácter a la vez, es decir, que“expresi[oó]n”no
pacio en blanco. encontrará “expresion”o “expresión”.

• \A ̶Representa el inicio de la cadena. No un ca-

rácter sino una posición. 79.4.5 La barra "|"
• \Z ̶Representa el nal de la cadena. No un carácter
Sirve para indicar una de varias opciones. Por ejemplo,
sino una posición.
la expresión regular “a|e”encontrará cualquier “a”
• \b ̶Marca la posición de una palabra limitada por o “e”dentro del texto. La expresión regular “es-
espacios en blanco, puntuación o el inicio/ nal de te|oeste|norte|sur”permitirá encontrar cualquiera de los
una cadena. nombres de los puntos cardinales. La barra se utiliza co-
múnmente en conjunto con otros caracteres especiales.
• \B ̶Marca la posición entre dos caracteres alfanu-
méricos o dos no-alfanuméricos.
79.4.6 El signo de dólar "$"
Notas:
Representa el nal de la cadena de caracteres o el nal de
• Utilidades como [Link] de Windows o gu- la línea, si se utiliza el modo multi-línea. No representa
charmap de GNOME permiten encontrar los códi- un carácter en especial sino una posición. Si se utiliza la
gos ASCII/ANSI/UNICODE para utilizarlos en Ex- expresión regular "\.$" el motor encontrará todos los lu-
presiones Regulares. gares donde un punto nalice la línea, lo que es útil para
avanzar entre párrafos.
• Algunos lenguajes, como Java, asignan su propio
signi cado a la barra invertida, por lo que deberá
repetirse para que sea considerada una expresión re- 79.4.7 El acento circun ejo "^"
gular (ej. String expresion="\\d.\\d”para indicar el
patrón \d.\d). Este carácter tiene una doble funcionalidad, que di ere
cuando se utiliza individualmente y cuando se utiliza en
conjunto con otros caracteres especiales. En primer lugar
79.4.4 Los corchetes "[ ]"
su funcionalidad como carácter individual: el carácter "^"
La función de los corchetes en el lenguaje de las expre- representa el inicio de la cadena (de la misma forma que
siones regulares es representar “clases de caracteres”, el signo de dólar "$" representa el nal de la cadena). Por
o sea, agrupar caracteres en grupos o clases. Son útiles tanto, si se utiliza la expresión regular "^[a-z]" el motor
cuando es necesario buscar uno de un grupo de caracte- encontrará todos los párrafos que den inicio con una le-
res. Dentro de los corchetes es posible utilizar el guion "- tra minúscula. Cuando se utiliza en conjunto con los cor-
" para especi car rangos de caracteres. Adicionalmente, chetes de la siguiente forma "[^\w ]" permite encontrar
los metacaracteres pierden su signi cado y se convierten cualquier carácter que NO se encuentre dentro del grupo
en literales cuando se encuentran dentro de los corche- indicado. La expresión indicada permite encontrar, por
tes. Por ejemplo, como vimos en la entrega anterior "\d” ejemplo, cualquier carácter que no sea alfanumérico o un
nos es útil para buscar cualquier carácter que represente espacio, es decir, busca todos los símbolos de puntuación
un dígito. Sin embargo esta denominación no incluye el y demás caracteres especiales.
punto ".”que divide la parte decimal de un número. Para La utilización en conjunto de los caracteres especiales "^"
buscar cualquier carácter que representa un dígito o un y "$" permite realizar validaciones en forma sencilla. Por
punto podemos utilizar la expresión regular "[\d.]". Co- ejemplo "^\d$" permite asegurar que la cadena a veri car
mo se hizo notar anteriormente, dentro de los corchetes, representa un único dígito "^\d\d/\d\d/\d\d\d\d$" permi-
el punto representa un carácter literal y no un metaca- te validar una fecha en formato corto, aunque no permite
rácter, por lo que no es necesario antecederlo con la ba- veri car si es una fecha válida, ya que 99/99/9999 tam-
rra inversa. El único carácter que es necesario anteceder bién sería válido en este formato; la validación completa
1∧0 CAPÍTULO 79. EXPRESIÓN REGULAR

de una fecha también es posible mediante expresiones re- de nen grupos “anónimos”, sin embargo el signo de
gulares, como se ejempli ca más adelante. pregunta en conjunto con los paréntesis triangulares "<>"
permite “nombrar”estos grupos de la siguiente forma:
"^(?<Día>\d\d)\/(?<Mes>\d\d)\/(?<Año>\d\d\d\d)$";
79.4.8 Los paréntesis "()" Con lo cual se le especi ca al motor de búsqueda que
los primeros dos dígitos encontrados llevarán la etiqueta
De forma similar que los corchetes, los paréntesis sirven “Día”, los segundos la etiqueta “Mes”y los últimos
para agrupar caracteres, sin embargo existen varias dife- cuatro dígitos llevarán la etiqueta “Año”.
rencias fundamentales entre los grupos establecidos por
medio de corchetes y los grupos establecidos por parén- NOTA: a pesar de la complejidad y exibilidad dada por
tesis: los caracteres especiales estudiados hasta ahora, en su
mayoría nos permiten encontrar solamente un carácter
a la vez, o un grupo de caracteres a la vez. Los meta-
• Los caracteres especiales conservan su signi cado
caracteres enumerados en adelante permiten establecer
dentro de los paréntesis.
repeticiones.
• Los grupos establecidos con paréntesis establecen
una “etiqueta”o “punto de referencia”para el
motor de búsqueda que puede ser utilizada poste- 79.4.10 Las llaves "{}"
riormente como se denota más adelante.
Comúnmente las llaves son caracteres literales cuando se
• Utilizados en conjunto con la barra "|" permite ha- utilizan por separado en una expresión regular. Para que
cer búsquedas opcionales. Por ejemplo la expresión adquieran su función de metacaracteres es necesario que
regular “al (este|oeste|norte|sur) de”permite bus- encierren uno o varios números separados por coma y que
car textos que den indicaciones por medio de puntos estén colocados a la derecha de otra expresión regular
cardinales, mientras que la expresión regular “es- de la siguiente forma: "\d{2}" Esta expresión le dice al
te|oeste|norte|sur”encontraría“este”en la palabra motor de búsqueda que encuentre dos dígitos contiguos.
“esteban”, no pudiendo cumplir con este propósito. Utilizando esta fórmula podríamos convertir el ejemplo
"^\d\d/\d\d/\d\d\d\d$" que servía para validar un formato
• Utilizados en conjunto con otros caracteres especia-
de fecha en "^\d{2}/\d{2}/\d{4}$" para una mayor cla-
les que se detallan posteriormente, ofrece funciona-
ridad en la lectura de la expresión.
lidad adicional.
"\d{2,4}" Esta forma añade un segundo número separado
por una coma, el cuál indica al motor de búsqueda que
79.4.9 El signo de interrogación "?" como máximo debe aparecer 4 veces la expresión regular
\d. Los posibles valores son:
El signo de interrogación tiene varias funciones dentro
del lenguaje de las expresiones regulares. La primera de
• "^\d\d$" (mínimo 2 repeticiones)
ellas es especi car que una parte de la búsqueda es op-
cional. Por ejemplo, la expresión regular “ob?scuridad” • "^\d\d\d$"(tiene 3 repeticiones, por lo tanto entra en
permite encontrar tanto “oscuridad”como “obscuri- el rango 2-4)
dad”. En conjunto con los paréntesis redondos permite
especi car que un conjunto mayor de caracteres es • "^\d\d\d\d$" (máximo 4 repeticiones)
opcional; por ejemplo“Nov(\.|iembre|ember)?" permite
encontrar tanto “Nov”como “Nov.”, “Noviembre” Nota: aunque esta forma de encontrar elementos repeti-
y “November”. Como se mencionó anteriormente, los dos es muy útil, algunas veces no se conoce con claridad
paréntesis nos permiten establecer un “punto de refe- cuantas veces se repite lo que se busca o su grado de re-
rencia”para el motor de búsqueda. Sin embargo, algunas petición es variable. En estos casos los siguientes meta-
veces, no se desea utilizarlos con este propósito, como caracteres son útiles.
en el ejemplo anterior “Nov(\.|iembre|ember)?". En
este caso el establecimiento de este punto de referencia
(que se detalla más adelante) representa una inversión 79.4.11 El asterisco "*"
inútil de recursos por parte del motor de búsqueda.
Para evitarlo se puede utilizar el signo de pregunta El asterisco sirve para encontrar algo que se encuentra re-
de la siguiente forma: “Nov(?:\.|iembre|ember)?". petido 0 o más veces. Por ejemplo, utilizando la expresión
Aunque el resultado obtenido será el mismo, el motor "[a-zA-Z]\d*" será posible encontrar tanto “H”como
de búsqueda no realizará una inversión inútil de recursos “H1”,“H01”,“H100”y“H1000”, es decir, una letra
en este grupo, sino que lo ignorará. Cuando no sea seguida de un número inde nido de dígitos. Es necesario
necesario reutilizar el grupo, es aconsejable utilizar tener cuidado con el comportamiento del asterisco, ya que
este formato. De forma similar, es posible utilizar el éste, por defecto, trata de encontrar la mayor cantidad po-
signo de pregunta con otro signi cado: Los paréntesis sible de caracteres que correspondan con el patrón que se
79.4. DESCRIPCIÓN DE LAS EXPRESIONES REGULARES 1∧1

busca. De esta forma si se utiliza "\(.*\)" para encontrar

cualquier cadena que se encuentre entre paréntesis y se lo Luego asumiendo que el texto que se desea examinar con
aplica sobre el texto“Ver (Fig. 1) y (Fig. 2)" se esperaría la expresión regular se encuentra en la variable “sText”
que el motor de búsqueda encuentre los textos "(Fig. 1)" y podemos recorrer todas las instancias encontradas de la
"(Fig. 2)", sin embargo, debido a esta característica, en su siguiente forma:
lugar encontrará el texto "(Fig. 1) y (Fig. 2)". Esto sucede
porque el asterisco le dice al motor de búsqueda que llene foreach(Match CurrentMatch in _TagPar-
todos los espacios posibles entre los dos paréntesis. Para [Link](sText)){ // ----- Código extra aquí -----
obtener el resultado deseado se debe utilizar el asterisco }
en conjunto con el signo de interrogación de la siguien-
te forma: "\(.*?\)" Esto es equivalente a decirle al motor Luego se puede utilizar la propiedad Groups de la clase
de búsqueda que “Encuentre un paréntesis de apertura Match para traer el resultado de la búsqueda:
y luego encuentre cualquier secuencia de caracteres hasta
que encuentre un paréntesis de cierre”. foreach(Match CurrentMatch in _TagPar-
[Link](sText)){ String sTagName = CurrentMatch.
Groups[1].Value; }
79.4.12 El signo de suma "+"
Grupos nominales
Se utiliza para encontrar una cadena que se encuentre re-
Los grupos nominales son aquellos a los que se les asigna
petida una o más veces. A diferencia del asterisco, la ex-
un nombre, dentro de la expresión regular para poder uti-
presión "[a-zA-Z]\d+" encontrará“H1”pero no encon-
lizarlos posteriormente. Esto se hace de forma diferente
trará “H”. También es posible utilizar este metacarác-
en los distintos motores de búsqueda, a continuación se
ter en conjunto con el signo de interrogación para limitar
explica como hacerlo en el motor del .Net Framework.
hasta donde se efectúa la repetición.
Utilizando el ejemplo anterior es posible convertir "<([a-
zA-Z]\w*?)>" en "<(?<TagName>[a-zA-Z]\w*?)>" Pa-
79.4.13 Grupos anónimos ra encontrar etiquetas HTML. Nótese el signo de pregun-
ta y el texto“TagName”encerrado entre paréntesis trian-
Los grupos anónimos se establecen cada vez que se en- gulares, seguido de éste. Para utilizar este ejemplo en el
cierra una expresión regular en paréntesis, por lo que la .Net Framework es posible utilizar el siguiente código:
expresión "<([a-zA-Z]\w*?)>" de ne un grupo anónimo.
Regex _TagParser = new Regex("<(?<TagName>[a-
El motor de búsqueda almacenará una referencia al grupo
zA-Z]\w*?)>"); foreach(Match CurrentMatch in
anónimo que corresponda a la expresión encerrada entre
_TagParser.Matches(sText)){ String sTagName = Cu-
los paréntesis.
rrentMatch. Groups["TagName"]. Value; }
La forma más inmediata de utilizar los grupos que se
de nen, es dentro de la misma expresión regular, lo
Es posible de nir tantos grupos como sea nece-
cual se realiza utilizando la barra inversa "\" seguida
sario, de esta forma se puede de nir algo como:
del número del grupo al que se desea hacer referen-
"<(?<TagName>[a-zA-Z]\w*?) ?(?<Attributes>.*?)>"
cia de la siguiente forma: "<([a-zA-Z]\w*?)>.*?</\1>"
para encontrar no solo el nombre del tag HTML sino
Esta expresión regular encontrará tanto la cadena
también sus atributos de la siguiente forma:
"<font>Esta</font>" como la cadena "<b>prueba</b>"
en el texto "<font>Esta</font> es una <b>prueba</b>" a Regex _TagParser = new Regex("<(?<TagName>[a-
pesar de que la expresión no contiene los literales“font” zA-Z]\w*?) ?(?<Attributes>.*?)>"); foreach(Match
y “B”. CurrentMatch in _TagParser.Matches(sText)){ String
sTagName = CurrentMatch. Groups["TagName"].
Otra forma de utilizar los grupos es en el lenguaje de pro-
Value; String sAttributes = CurrentMatch.
gramación que se esté utilizando. Cada lenguaje tiene una
Groups["Attributes"]. Value; }
forma distinta de acceder a los grupos. Los ejemplos enu-
merados a continuación utilizan las clases del .Net Fra-
mework, usando la sintáxis de C# (la cual puede fácil- Pero es posible ir mucho más allá de la siguiente forma:
mente adaptarse a VB .Net o cualquier otro lenguaje del "<?(?<TagName>[a-zA-Z][\w\r\n]*?) ?(?:(?<Attribu-
Framework o incluso Java o JavaScript). te>[\w-\r\n]*?)='?"?(?<Value>[\w-:;,\./= \r\n]*?)'?"?
Para utilizar el motor de búsqueda del .Net Framework ?)>"
es necesario en primer lugar hacer referencia al espacio
de nombres [Link]. Luego es Esta expresión permite encontrar el nombre de la etique-
necesario declarar una instancia de la clase Regex de la ta, el nombre del atributo y su valor.
siguiente forma:
Sin embargo, una etiqueta HTML puede tener más de un
Regex _TagParser = new Regex("<([a-zA-Z]\w*?)>");
1∧2 CAPÍTULO 79. EXPRESIÓN REGULAR

atributo. Este puede resolverse utilizando repeticiones de

la siguiente forma:
"<?(?<TagName>[a-zA-Z][\w\r\n]*?) ?(?:(?<Attribu-
te>[\w-\r\n]*?)='?"?(?<Value>[\w-:;,\./= \r\n]*?)'?"?
?)*?>"

Y en el código puede utilizarse de la siguiente forma:

Regex _TagParser = new Regex("<?(?<TagName>[a-
zA-Z][\w\r\n]*?)? (?:(?<Attribute>[\w-\r\n]*?)='?"?
(?<Value>[\w-:;,\./= \r\n]*?)'?"? ?)*?>"); foreach(Match
CurrentMatch in _TagParser.Matches(sText)){ String
sTagName = CurrentMatch. Groups["TagName"]. Va-
lue; foreach(Capture CurrentCapture in CurrentMatch.
Groups["Attribute"]. Captures){ AttributesCollection.
Add(CurrentCapture. Value) } foreach(Capture Current-
Capture in CurrentMatch. Groups["value"]. Captures){
ValuesCollection. Add(CurrentCapture. Value) } }

Es posible profundizar utilizando una expresión regular

como esta:
"<?(?<TagName>[a-zA-Z][\w\r\n]*?) ?(?:(?<Attribu-
te>[\w-\r\n]*?)='?"?(?<Value>[\w-:;,\./= \r\n]*?)'?"?
?)*?>(?<Content>.*?)</\1>"

La cual permitiría encontrar el nombre de la etiqueta, sus

atributos, valores y el contenido de esta, todo con una sola
expresión regular.

79.5 Enlaces externos

• Editor regex en línea (en inglés)

• Tutorial Expresiones Regulares en Python (en in-

glés)

• Expresiones Regulares en Perl

• Manual sobre Expresiones Regulares

• Portal de Información Expresiones Regulares en

General (en inglés)
Capítulo 80

Flag

En programación, la bandera o ag se re ere a uno o

más bits que se utilizan para almacenar un valor binario
o código que tiene asignado un signi cado. Las banderas
normalmente forman parte de una determinada estructu-
ra de datos, como un registro de una base de datos, y el
signi cado del valor que gura en una bandera típicamen-
te se de nirá en relación a la estructura de datos de la que
forma parte. En muchos casos el valor binario de la ban-
dera se entenderá como la representación de uno de los
posibles estados. En otras ocasiones, los valores binarios
pueden representar uno o más atributos de un campo de
bits, a menudo relacionados con habilidades o permisos,
como “se puede escribir”o “puede ser borrado”. De
todos modos, hay muchos otros posibles signi cados que
pueden asignarse a los valores de la bandera. Un uso co-
mún de las banderas es marcar o designar estructuras de
datos para un posterior tratamiento.
Dentro de los microprocesadores y otros dispositivos
lógicos, las banderas se utilizan mayoritariamente para
controlar o indicar el estado intermedio o nal o el re-
sultado de diferentes operaciones. Por ejemplo, los mi-
croprocesadores suelen tener un registro de estado que se
compone de varias de estas banderas que se usarán para
indicar varias condiciones establecidas como resultado de
una operación, como podría ser hacer notar que ha habi-
do un desbordamiento en una operación aritmética. Una
vez establecidas, las banderas pueden utilizarse en ope-
raciones posteriores como el control de ujo en una ope-
ración de salto condicional. Por ejemplo, la instrucción
en lenguaje ensamblador de Intel x∪∨ je (salta si igual)
comprobará el ag Z (cero) del registro de estado y si es-
tá establecido (por una operación anterior) ejecutará un
salto a la dirección indicada.
A los diferentes parámetros de control de una shell de
línea de comandos también se les suele llamar banderas.
Estas shells utilizan un analizador sintáctico para traducir
los parámetros pasados en banderas al uso de las vistas en
este artículo.

80.1 Véase también

• Registro de estado

1∧3
Capítulo 81

Front-end y back-end

Front-end y back-end son términos que se re eren a la presentación simbólico-fonética y el back-end convierte
separación de intereses entre una capa de presentación y la representación fonética y simbólica en el sonido.
una capa de acceso a datos, respectivamente. Pueden tra- Muchos programas tienen su concepto de diseño dividi-
ducirse al español el primero como interfaz, nal fron- do en front-ends y back-ends, pero en la mayoría de los
tal o frontal y el segundo como motor, dorsal nal* [1]o
casos, el back-end está oculto del usuario nal y solo pue-
zaga,* [2] aunque es común dejar estos términos en in- den utilizarlo el cliente intermedio o el administrador que
glés.
se encargará de gestionar el sistema de información. Sin
embargo, muchos programas están escritos para servir de
simple front-end para otros que ya existen, como es el ca-
81.1 Informática so de las interfaces grá cas construidas sobre una interfaz
de línea de órdenes. Este tipo de front-end es común en
En diseño de software el front-end es la parte del software entornos de escritorio Unix (como los GUI), donde los
que interactúa con el o los usuarios y el back-end es la programas son desarrollados siguiendo la losofía de di-
parte que procesa la entrada desde el front-end. La se- seño de muchos programas pequeños capaces de ejecutar-
paración del sistema en front-ends y back-ends es un tipo se independientemente o combinados.
de abstracción que ayuda a mantener las diferentes partes
del sistema separadas. La idea general es que el front-end
sea el responsable de recolectar los datos de entrada del
usuario, que pueden ser de muchas y variadas formas, y
81.2 Tecnología
los transforma ajustándolos a las especi caciones que de-
manda el back-end para poder procesarlos, devolviendo En radiotelescopios y antenas parabólicas, el front-end
generalmente una respuesta que el front-end recibe y ex- consiste en un paquete que contiene a la antena de bo-
pone al usuario de una forma entendible para este. La co- cina y a la guía de ondas, como un requisito para que las
nexión del front-end y el back-end es un tipo de interfaz. antenas detecten la señal de radio. El back end se re ere
al ampli cador y al ltro que re na y modi ca la señal
En diseño web (o desarrollo web) hace referencia a la vi- antes de presentarla al usuario.
sualización del usuario navegante por un lado (front-end),
y del administrador del sitio con sus respectivos sistemas En la automatización de diseño electrónico, el ciclo del
por el otro (back-end). diseño, que es el front-end, equivale al diseño lógico y
eléctrico (ej. captura esquemática, síntesis lógica). A ve-
Muchos métodos conocidos para interactuar con ordena-
ces el boceto de una estructura (del inglés oorplanning),
dores pueden ser conceptualizados en términos de front- es considerado como un front-end. Un place and route
end y back-end. Por ejemplo, un administrador de archi- (del idioma inglés, un lugar y ruta) o un diseño persona-
vos grá co como Windows Explorer, Dolphin, Nautilus lizado de la capa de veri cación física (design rule chec-
y Finder puede ser considerado como un front-end para king), o una disposición (layout) versus esquemática, son
el sistema de archivos de la computadora. Otro ejemplo considerados como back-end.
consiste en considerar al Shell como front-end que sirve
como interfaz para interactuar con el núcleo del sistema En diseño de circuitos integrados de radiofrecuencia el
operativo que cumple el rol back-end. front-end hace referencia a los bloques de la cadena de
recepción que se encargan de ltrar, ampli car y trasla-
En un compilador el front-end traslada el lenguaje del có- dar la señal de RF a banda base. Generalmente los blo-
digo fuente a una representación intermedia que a su vez ques comprendidos son balun, ampli cador de bajo ruido
funciona con el back-end para producir en la salida el có- (LNA), ltros y mezcladores de señal. Por otro lado, ac-
digo. tualmente las tecnologías de radio de nida por software
En sintetizadores del habla, el front-end se re ere a la par- (SDR) y radio cognitiva (CR), entre otras, implementan
te del sistema que convierte la entrada del texto en una re- front-ends que no necesariamente integran todos los blo-

1∧4
81.4. REFERENCIAS 1∧∧

ques anteriormente citados.

81.3 Véase también

• Arquitectura de software
• Cliente-servidor

• Programación por capas

81.4 Referencias
[1] [Link]
21∧444

[2] [Link]
Capítulo 82

Fuga de memoria

Una fuga de memoria (más conocido por el término tos terminan su vida. A diferencia de la recolección de
inglés memory leak) es un error de software que ocurre basura, RAII tiene las ventajas de: saber cuándo los ob-
cuando un bloque de memoria reservada no es liberada en jetos existen y saber cuándo no. Se puede comparar los
un programa de computación. Comúnmente ocurre por- siguientes ejemplos en C y C++:
que se pierden todas las referencias a esa área de memoria
/* Versión en C */ #include <stdlib.h> void f(int
antes de haberse liberado.
n) { int* array = calloc(n, sizeof(int)); reali-
Dependiendo de la cantidad de memoria perdida y el zar_otras_operaciones(); free(array); }
tiempo que el programa siga en ejecución, este proble- // Versión en C++. #include <vector> void f(int n) {
ma puede llevar al agotamiento de la memoria disponible std::vector<int> array (n); realizar_otras_operaciones();
en la computadora. }
Este problema se da principalmente en aquellos lenguajes
de programación en los que el manejo de memoria es La versión en C requiere que el desarrollador haga la li-
manual (C o C++ principalmente), y por lo tanto es el beración de memoria, a diferencia de la versión en C++.
programador el que debe saber en qué momento exac- Esto evita la sobrecarga de los esquemas de la recolección
to puede liberar la memoria. Otros lenguajes utilizan un de basura, e incluso puede ser aplicado a otros recursos
recolector de basura o conteo de referencias que automá- como:
ticamente efectúa esta liberación. Sin embargo todavía es
posible la existencia de fugas en estos lenguajes si el pro- •“Handles”a archivos, que la recolección de basura
grama acumula referencias a objetos, impidiendo así que “mark-and-sweep”no maneja tan efectivamente
el recolector llegue a considerarlos en desuso. • Ventanas que han de ser cerradas
Existen varias formas de luchar contra este problema.
• Iconos en el área de noti cación que han de ser ocul-
Una forma es el uso de un recolector de basura incluso
tados
en el caso en el que éste no sea parte estándar del lengua-
je. El más conocido recolector de basura usado de esta • Código de sincronización como monitores, seccio-
manera es el Boehm-Demers-Weiser conservative garba- nes críticas, etc. que deben ser liberados para per-
ge collector. Otras técnicas utilizadas son la adopción de mitir que otros hilos de ejecución(“threads”) los
esquemas de conteo de referencias o el uso de pools de obtengan
memoria (técnica menos popular, utilizada en el servidor
•“Handles”al registro de Windows que están abiertos
Apache y en el sistema de versiones Subversion).
También hay herramientas para“auscultar”un programa • Conexiones de red
y detectar las fugas. Una de las herramientas más cono- • Objetos GDI de Windows
cidas es Valgrind.
• Acciones a realizar cuando se termina una función
(o bloque de código) en cualquier punto posible (la
acción la realiza el destructor de un objeto creado
82.1 RAII cuando empieza la función)

"Adquirir Recursos es Inicializar", a menudo referido

por sus siglas en inglés RAII (de “Resource Acquisi- 82.2 Fugas de memoria en lengua-
tion Is Initialization”), es un popular patrón de diseño
en varios lenguajes de programación orientados a objetos jes con recolector de basura
como C++, y Ada. RAII soluciona las fugas de memo-
ria relacionando objetos con los recursos adquiridos, y Las fugas de memoria en lenguajes como JavaScript tam-
automáticamente liberando los recursos cuando los obje- bién son comunes, por ejemplo pueden ocurrir cuando

1∧∨
82.3. VÉASE TAMBIÉN 1∧∩

hay referencias circulares entre los objetos. Por ejemplo

un objeto ventana tiene una referencia a cada uno de sus
controles (botones, imágenes, etc), a su vez cada control
tiene una referencia a la ventana que lo contiene. Los
recolectores de memoria que usan conteo de referencias
pueden no darse cuenta que una ventana ya no es usada
porque sigue habiendo referencia a ella (de sus controles).
Estas fugas de memoria son muy comunes cuando se pro-
grama en forma despreocupada. Hay técnicas para evitar-
las (por ejemplo eliminar alguna de las referencias para
cortar el círculo).
En JavaScript ocurren también referencias circulares
cuando se escriben funciones dentro de otras, porque
cuando una función es escrita dentro de otra se mantie-
ne una referencia a la que la incluye (para poder usar sus
variables). El concepto de clausura explica estos compor-
tamientos.

82.3 Véase también

• Memoria dinámica

• Conteo de referencias

• Recolector de basura
Capítulo 83

Generación de código

En programación, la generación de código es una de

las fases mediante el cual un compilador convierte un
programa sintácticamente correcto en una serie de ins-
trucciones a ser interpretadas por una máquina. La en-
trada en esta fase viene representada, típicamente, por
un →rbol Sintáctico, un →rbol de Sintaxis Abstracta, o
una Representación Intermedia; la máquina destino pue-
de ser un microprocesador o una máquina abstracta tal
como una máquina virtual o un lenguaje intermedio, le-
gible por un humano. Compiladores más so sticados rea-
lizan múltiples traducciones en cadena (pipelining) con el
n de poder construir código para múltiples plataformas y
evitar tener que construir todas las capas del compilador.
En términos más generales, la generación de código: es
usada para construir programas de una manera automáti-
ca evitando que los programadores tengan que escribir el
código a mano. La generación de código puede realizar-
se en tiempo de ejecución, Tiempo de carga, o Tiempo
de compilación. Los compiladores JIT son un ejemplo de
generadores de código.

83.1 Enlaces externos

• FRAWA Framework for Web Applications deve-
lopment
• Frawa

1∧∪
Capítulo 84

Generador de números aleatorios

internamente) un valor x0 , que llamaremos semilla, y, a

partir de él, se van generando x1 , x2 , x3 , ...
Siempre que se parta de la misma semilla, se obtendrá la
misma secuencia de valores.
Por la condición anterior, es evidente que todos los valo-
res generados por este procedimiento son números ente-
ros entre 0 y m−1 . El número máximo de cifras distintas
que pueden obtenerse con el procedimiento descrito es m
, así que llegará un momento en que el primer número ge-
nerado se repetirá produciéndose un ciclo.
El ciclo dónde inevitablemente caerá el generador intere-
sa que sea de la mayor longitud posible (como máximo m
Un generador de números aleatorios es un dispositivo ), para evitar que se repitan pronto los valores aleatorios.
informático o físico diseñado para producir secuencias de Por ejemplo, para los valores a = 3 , c = 5 , x0 = 2 y
números sin un orden aparente. m = 32 se obtiene la siguiente secuencia de valores:
2−11-∨-23-10-3-14-1∧-1∪-2∩-22-∩-2∨-19-30-31-
2−11-∨
84.1 Algoritmos La secuencia generada tiene como longitud 1∨ números
(el número generado en la decimoséptima posición es el
Los algoritmos para la generación de valores uni- 2 inicial, por lo que toda la secuencia se repite a partir de
formemente distribuidos están presentes en todas las ahí), muy inferior a la longitud máxima que podría tener
calculadoras y lenguajes de programación, y suelen estar ( m =32). Determinadas elecciones de parámetros del ge-
basados en congruencias numéricas del tipo: nerador ( x0 , a , c y m ) conducen a ciclos de amplitud
x ≡ (ax + c) (mod m) máxima.
n+1 n

El éxito de este tipo de generadores de valores de una • Si c≠0:

variable aleatoria depende de la elección de los cuatro
parámetros que intervienen inicialmente en la expresión • m.c.d.(c, m) = 1
anterior: • a ≡ 1 (mod p) para cada primo p de m
• a ≡ 1 (mod 4) si 4 es divisor de m
• El valor inicial o semilla: x0
• Si c=0:
• La constante multiplicativa: a
• m es primo
• La constante aditiva: c • am−1/p ≡ 1 (mod m) La condición es que
NO SEA congruente para cada factor primo p
• El número m respecto al cual se calculan los restos de m-1.

Estos cuatro valores deben ser números enteros no nega- Por ejemplo, tomando como valores m = 25 = 32 ,
tivos y que cumplan la siguiente condición: x0 , a, c < m a = 5 , x0 = 1 y c = 3 se obtiene la siguiente secuencia
. de números, que tiene longitud máxima:
La mayor parte de los generadores de números aleatorios 1−∪-11-2∨-∧-2∪-1∧-14-9-1∨-19-2-13-4-23-22-1∩-24-
son, en realidad, pseudoaleatorios; se calcula (o introduce 2∩-10-21-12-31-30-2∧-0-3-1∪-29-20-∩-∨-1

1∧9
1∨0 CAPÍTULO 84. GENERADOR DE NÚMEROS ALEATORIOS

El standard POSIX C de ne para la función de generación

de números seudoaleatorios los valores de c = 12345 ,
m = 32768 y a = 1103515245 .
Recientemente se ha descubierto que es posible ge-
nerar verdaderos números aleatorios mediante softwa-
re.* [1]* [2]* [3]

84.2 Bibliografía
• Alberto, Marva; Schwer, Ingrid; Cámara, Vivia-
na; Fumero, Yanina (200∧). Matemática Discre-
ta. Universidad Nac. del Litoral. p. 29∧. ISBN
9∩∪9∪∩∧0∪431∧.

• Blanco Castañeda, Liliana (2004). Probabilidad.

textos. Univ. Nacional de Colombia. p. 29∧. ISBN
9∩∪9∧∪∩01449∧.

84.3 Enlaces externos

• Generador de números aleatorios on-line

• Generador simple de números aleatorios on-line

[1] True random numbers generator C++

[2] CPU Time Jitter Based Non-Physical True Random

Number Generator

[3] Software Random Number Generation Based on Race

Conditions
Capítulo 85

Gledplay

GledPlay es un SDK para desarrollar juegos para cepto de Sprite. Las características principales de Gled-
dispositivos móviles. Los juegos construidos con Gled- Draw son:
Play corren sobre PC de escritorio con Microsoft Win-
dows, PocketPC and Smartphones. • copiado rápido de super cies, con transparencia
GledPlay contiene 4 módulos de desarrollo: alpha blending o color clave.

• Cambio de tamaño, rotación, e inversión de super -

• GledDraw: Un framework de grá cos 2D orientado cies.
a Super cies, basado en DirectDraw.
• Carga de archivos JPG, GIF, PNG y BMP.
• GledVideo: Un reproductor de video integrado con
GledDraw. • Escritura de archivos PNG y BMP.
• GledSave: Un módulo de abstracción del Sistema de • Super cies de 3 o 4 canales para simpli car las ope-
archivos, que permita la lectura y escritura de archi- raciones con transparencia.
vos en paquetes.
• Escritura de texto, con fuentes normales o con alpha
• GledApplication: Un módulo especí co para mane- blended.
jar los detalles de programación no relacionados con
la lógica del juego. • Manejo de animaciones

• Clipping opcional
85.1 Dispositivos Soportados • Utilización de Shaders del sistema o personalizados,
para personalizar los efectos del copiado de super -
'GledPlay está construido para: cies.

• Microsoft Windows para computadores personales • Traducción de Surface desde o hacia un HDC, para
de escritorio. permitir el uso de la librería estandard de windows
GDI sobre las super cies.
• Pocket PC
• Puntos, líneas, y rectángulos, con manejo de trans-
• Smartphones parencia.

GledPlay fomenta el desarrollo sobre PC de escritorio, • Clase panel, para utilizar coordenadas relativas en
sin utilizar emuladores o dispositivos móviles reales. Una los métodos de dibujo, y facilitar la modularización.
vez nalizado el desarrollo con GledPlay para compu- • Fullscreen en PC. (Los modos soportados son:
tadores de escritorio, la aplicación se compila para las 320X240, ∨40X4∪0, ∪00X∨00, 1024X∩∨∪)
plataformas deseadas utilizando el mismo código. De es-
ta manera se reduce el tiempo de desarrollo. • Zoom X2 opcional en desktop PC para facilitar la
detección de errores.

• Soporte para Dispositivos de Altas Resoluciones

85.2 GledDraw (VGA en PPC, QVGA en SP, y dispositivos de pan-
tallas cuadradas).
GledDraw es un framework de grá cos 2D orientado a
Super cies, basado en DirectDraw. Se maneja con enti- • Soporte para Pocket Pcs y Smartphones con panta-
dades llamadas super cies, que serían similares al con- llas cuadradas.

1∨1
1∨2 CAPÍTULO 85. GLEDPLAY

85.3 GledVideo
Las principales funcionalidades de GledVideo son:

• reproducción de videos OGG Theora

• Manejo de subtitulos, utilizando an archivo de sub-
titulos SubRip

85.4 GledSave
GledSave provee un API común para acceder a diferen-
tes sistemas de archivo, basado en Jakarta's Common Vir-
tual File System. Es una interfaz simple que permite acce-
der a diferentes sistemas de la misma manera. Funciona
para:

• Computadores de escritorio con MS Windows.

• Pocket PC
• Smartphones

• Archivos ZIP

85.5 GledApplication
GledApplication maneja los detalles especí cos de la
programación que no están relacionadas con la lógica del
juego como la inicialización de threads, el manejo de
eventos, el ciclo del juego, los estados del juego, etc.

• Manejo de la aplicación como inicio y n.

• Con guración de la máquina de estados para usar
diferentes ciclos.
• Manipulación de los fps.

85.6 Enlaces externos

• GledPlay site(en inglés)
• GledPlay source code

• Wiki de GledPlay con tutoriales y artículos(en in-

glés)

• Foro de GledPlay Forum en PocketMatrix

Capítulo 86

GPGPU

GPGPU o General-Purpose Computing on Grap- que generalmente no se puede leer y escribir en la misma
hics Processing Units es un concepto reciente dentro de textura, si esta operación es imprescindible para el desa-
informática que trata de estudiar y aprovechar las capa- rrollo del algoritmo, éste se debe dividir en varias pasa-
cidades de cómputo de una GPU. das.
Una GPU es un procesador diseñado para los cómputos Pese a que cualquier algoritmo que sea implementable en
implicados en la generación de grá cos 3D interactivos. una CPU lo es también en una GPU, esas implementacio-
Algunas de sus características (bajo precio en relación nes no serán igual de e cientes en las dos arquitecturas.
a su potencia de cálculo, gran paralelismo, optimización En concreto, los algoritmos con un alto grado de para-
para cálculos en coma otante), se consideran atracti- lelismo, sin necesidad de estructuras de datos complejas
vas para su uso en aplicaciones fuera de los grá cos por y con una alta intensidad aritmética son los que mayores
computadora, especialmente en el ámbito cientí co y de bene cios obtienen de su implementación en la GPU.
simulación. Así, se han desarrollado técnicas para la im-
plementación de simulaciones de uidos, bases de datos,
algoritmos de clustering, etc.

86.1 Modelo de programación

GPU 86.2 Herramientas

Debido a las diferencias fundamentales entre las arqui- Tradicionalmente, el desarrollo de software GPGPU se
tecturas de la GPU y la CPU, no cualquier problema se
había hecho bien en lenguaje ensamblador, o bien en al-
puede bene ciar de una implementación en la GPU. En guno de los lenguajes especí cos para aplicaciones grá-
concreto, el acceso a memoria plantea las mayores di - cas usando la GPU, como GLSL, Cg o HLSL. Pero
cultades. Las CPU están diseñadas para el acceso aleato- recientemente han surgido herramientas para facilitar el
rio a memoria. Esto favorece la creación de estructuras desarrollo de aplicaciones GPGPU, al abstraer muchos de
de datos complejas, con punteros a posiciones arbitra- los detalles relacionados con los grá cos, y presentar una
rias en memoria. En cambio, en una GPU, el acceso a interfaz de más alto nivel. Una de ellas es BrookGPU,
memoria está mucho más restringido. Por ejemplo, en un desarrollada en la Universidad de Stanford, consistente
procesador de vértices (la parte de una GPU diseñada pa- en una extensión a ANSI C que proporciona nuevos tipos
ra transformar vértice en aplicaciones 3D), se favorece el de datos y operaciones (“stream”, “kernel”, “re-
modelo scatter, en el que el programa lee en una posición duction”, etc.) automáticamente convertidos a una im-
predeterminada de la memoria, pero escribe en una o va- plementación que aprovecha la GPU sin intervención ex-
rias posiciones arbitrarias. En cambio, un procesador de plícita por parte del programador. Otra herramienta con
píxeles, o fragmentos, favorece el modelo gather, pudien- objetivos similares es Sh, una extensión de C++ para
do el programa leer de varias posiciones arbitrarias, pero metaprogramación con una implementación automática
escribir en sólo una posición predeterminada. en la GPU. La opción más extendida en la actualidad es
La tarea del diseñador de algoritmos GPGPU consiste CUDA, de NVidia, una extensión de C que permite la co-
principalmente en adaptar los accesos a memoria y las di cación de algoritmos en GPU de NVidia. Por último,
estructuras de datos a las características de la GPU. Ge- podemos incluir en esta discusión a OpenCL, una com-
neralmente, la forma de almacenar datos es en un bu er binación de interfaz y lenguaje de programación para el
2D, en lugar de lo que normalmente sería una textura. El desarrollo de aplicaciones paralelas que puedan ser eje-
acceso a esas estructuras de datos es el equivalente a una cutadas, de forma transparente, en diversas unidades de
lectura o escritura de una posición en la textura. Puesto procesamiento (CPU multinúcleo, GPU, etc.).

1∨3
1∨4 CAPÍTULO 86. GPGPU

86.3 Críticas 86.6 Enlaces externos

Pese a que las ventajas del uso de la GPU para ciertas • Portal que aglomera noticias, publicaciones y enla-
aplicaciones es evidente, no faltan las críticas, general- ces sobre el avance de, GPGPU (en inglés).
mente referidas a la inconveniencia de usar un procesador
• Página del proyecto BrookGPU (en inglés).
para nes completamente diferentes a lo que se pensaba
al diseñarlos. Un argumento común es la falta de con- • Página de soporte GPU para Folding@home (en in-
tinuidad de las arquitecturas usadas. Debido a la rápida glés).
evolución del hardware grá co, implementaciones de al-
goritmos que funcionaban óptimamente en un modelo de • Página del proyecto Sh (en inglés).
GPU, dejan de hacerlo, o lo hacen subóptimamente en
• Explicación sobre sus posibilidades (en español).
un modelo posterior. Otra crítica es la falta de precisión
de los registros de coma otante presentes en las GPU. • Artículo que explica algunos bene cios (en inglés).
Generalmente, se utilizan 2 o 4 bytes para representar un
número real en una GPU, que en comparación con los 4,
∪ o más usados en las CPU modernas, no es su ciente
para muchas aplicaciones cientí cas.

86.4 Otros
Microsoft ha terminado de desarrollar la nueva versión 11
de su API Direct3D. A pesar de que la anterior versión,
Direct3D 10, es relativamente nueva, debido a la canti-
dad de novedades que están apareciendo últimamente en
el mundo de las tarjetas grá cas, entre ellas el teselado,
Microsoft desarrolló esta nueva versión, en la que cabe
destacar la nueva tecnología de computación de “sha-
ders”para permitir que la GPU no sea solamente usada
para grá cos 3D y así puedan los desarrolladores tomar
ventaja de las tarjetas grá cas como procesadores en pa-
ralelo.
El proyecto de computación distribuida Folding@home,
creado por la Universidad de Stanford, ha dado soporte
para utilizar la potencia computacional de la GPU, ade-
más de la CPU. Pruebas recientes hablan de que son posi-
bles ganancias de rendimiento de hasta 40 veces una CPU
Intel Pentium 4, aunque claro, todo esto depende de la
GPU utilizada.

86.5 Véase también

• CUDA

• Close to Metal

• Graphics Processing Unit

• Larrabee (GPU)

• OpenCL

• Intel MIC

• Direct Rendering Manager

Capítulo 87

Hackathon

Un hackathon o hackatón, es un término usado en las [2] Caldeiro, Graciela; Merpert, Ariel y Odetti, Valeria.
comunidades hacker para referirse a un encuentro de Nuestro primer Hackaton (2013). PENT, Flacso Argenti-
programadores cuyo objetivo es el desarrollo colaborati- na, Disponible en: [Link]
vo de software, aunque en ocasiones puede haber también nuestro-primer-hackaton
un componente de hardware. Estos eventos pueden durar
entre dos días y una semana. El objetivo es doble: por un
lado hacer aportes al proyecto de software libre que se 87.2 Enlaces externos
desee y, por otro, aprender sin prisas.* [1]
El término integra los conceptos de maratón y hacker, • CyberCamp Hackathon organizado por el INCIBE
aludiendo a un experiencia colectiva que persigue la me-
• Hackathon en la Universidad de Granada
ta común de desarrollar aplicaciones de forma colabora-
tiva en un lapso corto. Se cree que el término fue creado • HackathonExpress en la Ciudad de Corrientes
en 1999 de forma independiente por los desarrolladores
de OpenBSD y el equipo de marketing de Sun Microsys- • El Club de Emprendedores de la CEU-UAO orga-
tems. niza el maratón “BCN Thinking Challenge”
Algunos hackatons tienen propósitos educativos o socia-
les, aunque en muchos casos el objetivo es crear un soft-
ware utilizable. Los Hackatons tienden a tener un enfoque
especí co, que puede incluir el lenguaje de programación
utilizado, el sistema operativo, una aplicación, una API,
el destinatario o el grupo demográ co de los programa-
dores. En otros casos, no hay ninguna restricción sobre el
tipo de software que está siendo creado en el evento.
El hackatón, desde el punto de vista organizativo, supone
una dinámica horizontal e intensiva en donde los parti-
cipantes complementan experiencias y habilidades indi-
viduales con el propósito de desarrollar soluciones con-
cretas. De allí que para los especialistas en educación, el
hackatón posea ciertas características propias de un dis-
positivo pedagógico en tanto promueve el trabajo cola-
borativo entre pares orientado a la resolución de proble-
mas, hace foco sobre el proceso de trabajo como instan-
cia de aprendizaje y favorece la motivación intrínseca de
los participantes. En 201∧, en el campeonato de hackat-
hon internacional en Barcelona, Pablo Pardo Alcócer, el
representante de Bolivia, ganó el primer puesto.* [2]

87.1 Referencias

[1] «Harán una hackatón para promover alternativas a los

problemas porteños». diario “La nación”. Consultado
el 13 de mayo de 2013.

1∨∧
Capítulo 88

Hacker

El término hacker tiene diferentes signi cados. Según el depuran y arreglan errores en los sistemas (“White
diccionario de los hackers,* [1] es todo individuo que se hats”) y a los de moral ambigua como son los“Grey
dedica a programar de forma entusiasta, o sea un exper- hats”.
to entusiasta de cualquier tipo, que considera que poner
la información al alcance de todos constituye un extraor-
• Una comunidad de entusiastas programadores y
dinario bien.* [2] De acuerdo a Eric Raymond el motivo
diseñadores de sistemas originada en los sesen-
principal que tienen estas personas para crear software en
ta alrededor del Instituto Tecnológico de Mas-
su tiempo libre, y después distribuirlos de manera gratui-
sachusetts (MIT), el Tech Model Railroad Club
ta, es el de ser reconocidos por sus iguales.* [3]El término
(TMRC) y el Laboratorio de Inteligencia Arti -
hacker nace en la segunda mitad del siglo XX y su origen
cial del MIT.* [∧]Esta comunidad se caracteriza
está ligado con los clubes y laboratorios del MIT.
por el lanzamiento del movimiento de software li-
bre.«How To Become A Hacker».El [[Request for

88.1 Otros signi cados

comments|RFC]] 1392* [∨] amplia este signi cado como
“persona que se disfruta de un conocimiento profundo del
En informática, un hacker,* [4] es una persona que perte- funcionamiento interno de un sistema, en particular de
nece a una de estas comunidades o subculturas distintas, computadoras y redes informáticas” Leer historia del
pero no completamente independientes: término

• La comunidad de a cionados a la informática do-

méstica, centrada en el hardware posterior a los se-
tenta y en el software (juegos de computadora, crac-
keo de software, la demoscene) de entre los ochen-
ta/noventa.

• Se utiliza la palabra Hacker, para describir a una

persona que practica la programación informática,
con una especie de pasión artística, o que forma par-
te de la cultura de los hackers, es decir al grupo de
programadores que históricamente están en los orí-
genes de Internet, en Linux y en la World Wide Web.

• Desde que se usó por primera vez la palabra Hacker

ésta ha sido mal utilizada, mal interpretada y enca-
sillada en un contexto errado, antes que nada, acla-
remos que el término Hacker no tiene nada que ver
con actividades delictivas, si bien muchos Hackers
El emblema hacker, un proyecto para crear un símbolo recono- cometen errores, la de nición no tiene nada que ver
cible para la percepción de la cultura hacker. con ello.

• En seguridad informática este término concierne • De nición 1: Término para designar a alguien con
principalmente a entradas remotas no autorizadas talento, conocimiento, inteligencia e ingenio, es-
por medio de redes de comunicación como Internet pecialmente relacionadas con las operaciones de
( Black hats”). Pero también incluye a aquellos que
“ computadora, redes, seguridad, etc.

1∨∨
 88.2. HISTORIA 1∨∩

• De nición 2: Persona que disfruta aprendiendo de- Los hackers de MIT crearon su propio sistema operativo,
talles de los sistemas de programación y cómo ex- el ITS que usaba el lenguaje LISP.* [10]
tender sus capacidades, tan intensamente como, al
contrario, muchos usuarios pre eren aprender sólo
el mínimo necesario. 88.2.2 UNIX

No obstante, más allá de las de niciones del término

“Hacker”vinculadas al mundo informático o tecnológi-
co, cabe destacar el uso de esta palabra por extensión (y
de hecho así fue en sus inicios el origen de la misma) a
toda persona que implementa soluciones para cualquier
sistema, sea informático o no, de manera que éste pue-
da emplearse de formas no pensadas por quienes crearon
dichos sistemas. Así mismo, el término Hacker está indi-
solublemente unido a toda persona que manipula o que
posee conocimientos prácticos que modi can los usos de
Placa que dice“vive libre o muere UNIX* *marca registrada de
las cosas de modo que éstas puedan emplearse para nes
laboratorios Bell
no previstos en su origen. De ahí el uso de los términos
de“hackeado”como sinónimo de“alterado en su nes”
Al mismo tiempo que ARPANET nacía, también era
para cumplir otras funciones.
creado el sistema
operativo UNIX en los laboratorios bell. UNIX, junto con
el lenguaje C eran muy portables y compatibles con las
88.2 Historia máquinas, de hecho UNIX tenía incluso su propia co-
nexión con otras máquinas que tuvieran UNIX y el cual
En 19∨1 el MIT, el Massachusetts Institute of Techno- recibió el nombre de Usenet. Para 19∪0 los primeros si-
logy, adquirió la microcomputadora PDP-1, lo que atra- tios en Usenet empezaban a transmitir noticias, formando
jo la curiosidad de un grupo de estudiantes que forma- una gran red de distribución que crecería más que ARPA-
ban parte del Tech Model Railroad Club, TMRC, ya que NET.* [11]
podrían interactuar directamente con ella mediante códi- Ambos grupos de hackers estaban divididos y era poco
gos de programación. Debido a que la microcomputadora común que alguien que usara UNIX también usara AR-
tardaba mucho en encender, se quedaba prendida toda la PANET. En 19∪3 se canceló la distribución de la PDP-
noche haciendo que los miembros del TMRC tuvieran ac- 10, la cual fuera una de las microcomputadoras favoritas
ceso a ella y pudieran empezar a experimentar, uno de los de los hackers y en la cual se construyó el ITS. Después de
logros más famosos de estos experimentos fue la creación la cancelación de esta microcomputadora por parte de la
del videojuego Spacewar. Tiempo después algunos miem- Digital Equipment Corporation la variante de UNIX crea-
bros del TMRC se volvieron miembros del Laboratorio da en Berkeley se convirtió en el sistema hacker por exce-
de Inteligencia Arti cial del MIT y se llevaron con ellos lencia,* [12] y fue por esa época que Richard M. Stallman,
la tradición de jugarse bromas inocentes entre ellos, a las inventor del editor Emacs, creó la Free Software Founda-
cuales llamaban hacks. Fueron los miembros de este labo- tion
ratorio los primeros en autonombrarse hackers.* [∩] Esta
comunidad se caracteriza por el lanzamiento del movi-
miento de software libre. La World Wide Web e Internet 88.2.3 GNU
en sí misma son creaciones de hackers.* [∪]
En 19∪3 Stallman buscaba crear un propio sistema ope-
rativo de tipo UNIX que estuviese disponible de forma
88.2.1 ARPANET libre* [13], y fundó el proyecto GNU (acrónimo de GNU
No es UNIX). Stallman sustituyó el copyright o todos los
Después de 19∨9 el laboratorio de Inteligencia Arti cial derechos reservados, por el copyleft o todos los derechos
del MIT fue conectado a la ARPANET desde donde pudo reversados, con lo que buscaba que cualquier programa
tener contacto con otros departamentos de investigación publicado en la red por la FSF pudiera ser utilizado y
informática de otras universidades como Stanford y Bolt modi cado bajo una licencia de la Fundación y con la
Beranek & Newman. Con ésta nueva forma de comuni- condición de difundir las modi caciones que se llegasen
cación los estudiantes empezaron a colaborar con otros a a hacer al programa también respetando las libertades del
pesar de la distancia. A partir de este momento se empe- usuario. Otro de sus logros fue haber popularizado el tér-
zó a formar una cultura y nació el Jargon le, documento mino "software libre" en un intento de conseguir su ob-
que tenía una lista de términos que se usaban en su jer- jetivo y ponerle nombre al producto de toda cultura hac-
ga coloquial y que se originó en Standford en 19∪∩..* [9] ker.* [14]
1∨∪ CAPÍTULO 88. HACKER

88.2.4 LINUX muy poca ética”y la catalogan como“un grito de batalla

-que- no pone límites a los hackers”* [18] Sin embargo,
En 1991, un estudiante de la Universidad de Helsinki, para otras personas, como Linus Torvalds ésta ética va de
Linus Torvalds diseñaba su propio UNIX sobre la base acuerdo al trabajo del hacker que es “interesante, emo-
de la fundación y publicó la fuente de su código en la red cionante y algo que se goza”, adjetivos que en ocasiones
pidiendo ayuda para perfeccionarlo. Con ayuda de cien- son usados por los mismos hackers para describir su tra-
tos de programadores que se pusieron a la tarea de ayudar bajo, lo que también limita la restricción que tienen sobre
a Linux con el código, se desarrolla el sistema operativo la libertad de usar información.* [19]
Linux, que originalmente tenía el nombre de Freix. Hoy
De acuerdo a Raymond, la ética social del hacker se basa
en día es promocionado por diferentes gobiernos, como
en tres principios:
el de Francia, y siempre está en código abierto y sin de-
rechos de propiedad sobre él.* [1∧]
1. La creencia de que compartir información es bueno

2. Que los hackers tienen una responsabilidad ética de

88.3 Ética hacker compartir la información con la que trabajan

3. Que los hackers deberían facilitar el acceso a

computadoras cuando sea posible* [20]

88.4 Controversia
En la actualidad se usa de forma corriente para referir-
se mayormente a los criminales informáticos, debido a su
utilización masiva por parte de los medios de comunica-
ción desde la década de 19∪0.* [21] Según Helen Nissen-
baum que los hackers sean mal vistos ayuda al gobierno
y a los poderes privados con dos cosas: 1) a de nir lo que
es normal en el mundo computacional haciendo creer que
Steven Levy, autor de Hackers: heroes of the computer revolution un buen ciudadano es todo lo que el hacker no es; 2) a jus-
ti car la seguridad, la vigilancia y el castigo.* [22]
En 19∪4, Steven Levy publica el libro Hackers: heroes of
A los criminales se le pueden sumar los llamados "script
the computer revolution en el cual se ve por primera oca-
kiddies", gente que invade computadoras, usando progra-
sión la idea de la ética hacker, donde se mani esta una
mas escritos por otros, y que tiene muy poco conocimien-
ética de libre acceso a la información y código fuente del
to sobre cómo funcionan. Este uso parcialmente incorrec-
software. Levy se basó en entrevistas para poder identi -
to se ha vuelto tan predominante que, en general, un gran
car seis principios básicos relacionados con las creencias
segmento de la población no es consciente de que existen
y operaciones de hackers para hacer ésta ética.* [1∨] De
diferentes signi cados.
acuerdo a Levy los seis fundamentos del hacker son:
Mientras que los hackers a cionados reconocen los tres
1. El acceso a los computadores debe ser ilimitado y tipos de hackers y los hackers de la seguridad informá-
total. tica aceptan todos los usos del término, los hackers del
software libre consideran la referencia a intrusión infor-
2. Toda información debería ser libre mática como un uso incorrecto de la palabra, y se re-
eren a los que rompen los sistemas de seguridad como
3. Es necesario promover la descentralización y des- "crackers" (analogía de “safecracker”, que en español
con ar de las autoridades se traduce como “un ladrón de cajas fuertes”).
4. Los hackers deberían ser juzgados por su labor y no
por cosas como su raza, edad o posición social
88.4.1 Ambigüedad y debate
∧. Se puede crear arte y belleza en un computador
Los términos hacker y hack pueden tener connotaciones
∨. Las computadoras pueden cambiar tu vida para me- positivas y negativas. Los programadores informáticos
jor* [1∩][[Link]] suelen usar las palabras hacking y hacker para expresar
admiración por el trabajo de un desarrollador cuali cado
Sin embargo, la ética hacker genera controversia y hay de soporte lógico, pero también se puede utilizar en un
personas, como el estudiante de derecho Patrick S. Ryan sentido negativo (delincuentes informáticos) para descri-
que critican que la [[ética hacker]] y consideran que“hay bir una solución rápida pero poco elegante a un problema.
88.6. TERMINOLOGÍA 1∨9

Algunos* [¿quién?] desaprueban el uso del hacking como clasi cada que se considera debe estar, por de nición, a
un sinónimo de cracker, en marcado contraste con el resto disposición de la sociedad (casos de WikiLeaks o las l-
del mundo,* [¿dónde?] en el que la palabra hacker se uti- traciones de Snowden sobre las actividades militares y
liza normalmente para describir a alguien que se in ltra casos de espionaje gubernamentales).
en un sistema informático con el n de eludir o desactivar Por tanto, el fenómeno hacker tiene un importante com-
las medidas de seguridad.* [23] ponente de aperturismo y liberación de conocimientos e
En un principio se utilizaba “hack”como verbo para información que, a través del activismo de estos especia-
expresar “perder el tiempo”(e.j. “Puedo hackear con listas, bene cian a la sociedad en general.
el computador”), el signi cado del término ha cambiado En este caso, los roles de un hacker pueden entenderse en
a lo largo de décadas desde que empezó a utilizarse en un cuatro aspectos:
contexto informático. Como su uso se ha extendido más
ampliamente, el signi cado primario de la palabra, por
parte de los nuevos usuarios, ha pasado a uno que entra • Apoyar procesos de apropiación social o comunita-
en con icto con el énfasis original. ria de las tecnologías.

• Poner a disposición del dominio público el mane-

jo técnico y destrezas alcanzadas personal o grupal-
88.5 Activismo mente.

• Crear nuevos sistemas, herramientas y aplicaciones

técnicas y tecnológicas para ponerlas a disposición
del dominio público.

• Realizar acciones de hacktivismo tecnológico con el

n de liberar espacios y defender el conocimiento
común y abierto.

88.6 Terminología
En sentido amplio el término Hacker o Hacking se puede asociar
a movimientos sociales que promueven cambios en los modos de
88.6.1 OverHat
vida.
Un término acuñado a mediados del año 2014 por
Desde el año 2002-2003, se ha ido con gurando una pers- un Hacker de la comunidad Underground llamado
pectiva más amplia del hacker, pero con una orienta- T4r4t3uX* [24], quien de nió como “sobre el sombre-
ción a su integración al hacktivismo en tanto movimien- ro”a todos los profesionales vinculados con las artes Hac-
to. Aparecen espacios autónomos denominados hacklab king. En un corto escrito, explica como a través del tiem-
o hackerspace y los hackmeeting como instancias de diá- po deben comprender y aprender todas las formas exis-
logo de hackers. Desde esta perspectiva, se entiende al tentes de“Hackeo”. Lo cual causa una doble moral, por
hacker como una persona que es parte de una conciencia un lado existe la ética a la cual han sido eles y por ello
colectiva que promueve la libertad del conocimiento y la prestan servicios profesionales a miles de empresas en el
justicia social. mundo asegurando su infraestructura; por otro, conocer
y usar métodos propios de los BlackHat que incluyen ata-
Se entiende, por tanto, el Hacktivismo como el empleo de ques de denegación de servicio e ingeniería social agresi-
las destrezas técnicas más diversas, en pro de nes socia- va entre otros. Según el escrito, están por encima del bien
les, ecológicos, humanitarios o de cualquier otra índole y del mal electrónico, lo cual concluye que solo una am-
con repercusión o tendente a la defensa de los derechos plia capacidad moral autodeterminada por ellos mismos
humanos. los convierte en profesionales con la capacidad de deter-
Así, el Hacktivismo debe ser entendido no desde un pris- minar adecuadamente y con las regulaciones de la actual
ma reduccionista como equivalente siempre al desarrollo sociedad.
de actividades subversivas. Encontramos rami caciones
del hacktivismo en la liberación de conocimiento (como
puede ser la misma Wikipedia, en la que los conocimien- 88.6.2 White hat y black hat
tos informáticos y técnicos de sus creadores dieron lugar
a toda una revolución en el modo de crear y compartir- Un hacker de sombrero blanco (del inglés, white hat),
se el conocimiento humano más allá de barreras acadé- en jerga informática, se re ere a una ética hacker que se
micas o comerciales); O en la liberación de información centra en asegurar y proteger los sistemas de tecnologías
1∩0 CAPÍTULO 88. HACKER

de la información y la comunicación.* [2∧] Estas perso- 88.6.5 Lamer o script-kiddie

nas suelen trabajar para empresas de seguridad informá-
tica las cuales los denominan, en ocasiones, «zapatillas o Es un término coloquial inglés aplicado a una persona fal-
equipos tigre».* [26] ta de habilidades técnicas, generalmente no competente
Por el contrario, los hackers de sombrero negro (del en la materia, que pretende obtener bene cio del hac-
inglés, black hat), también conocidos como "crackers" king sin tener los conocimientos necesarios. Su alcance
muestran sus habilidades en informática rompiendo sis- se basa en a buscar y descargar programas y herramientas
temas de seguridad de computadoras, colapsando servi- de intrusión informática, cibervandalismo, propagación
dores, entrando a zonas restringidas, infectando redes o de software malicioso para luego ejecutarlo como simple
apoderándose de ellas, entre otras muchas cosas utilizan- usuario, sin preocuparse del funcionamiento interno de
do sus destrezas en métodos hacking. estos ni de los sistemas sobre los que funcionan. En mu-
chos casos presume de conocimientos o habilidades que
En los últimos años, los términos sombrero blanco y no posee.
sombrero negro han sido aplicados a la industria del
posicionamiento en buscadores (search engine optimiza-
tion, SEO), originando la denominación black hat SEO. 88.6.6 Newbie
Las tácticas de posicionamiento en buscadores de los hac-
kers de sombrero negro, también llamada spamdexing, in- Newbie es un alguien nuevo al hacking o al phreaking
tento de redireccionar los resultados de la búsqueda a pá- y que no posee casi nada de conocimiento o experien-
ginas de destino particular, son una moda que está en con- cia en el manejo de tecnología y hacking. El origen del
tra de los términos de servicio de los motores de busque- término es incierto. Usos más tempranos probablemente
da, mientras que los hackers de sombrero blanco, utilizan datan de nales del siglo XX Estados Unidos Fuerzas Ar-
métodos que son generalmente aprobados por los motores madas jerga , aunque posibles términos precursoras son
de búsqueda. mucho más temprano. Formas variantes del nombre in-
cluyen Newby y newbee, mientras que el término relacio-
nado novato (n00b menudo deletreado) se utiliza a me-
nudo en los juegos en línea.
88.6.3 Samurái

Normalmente es alguien contratado para investigar fallos 88.7 Véase también

de seguridad, que investiga casos de derechos de privaci-
dad, esté amparado por la primera enmienda estadouni-
dense o cualquier otra razón de peso que legitime accio-
88.8 Referencias
nes semejantes. Los samuráis desdeñan a los crackers y a
todo tipo de vándalos electrónicos. También se dedican a [1] Jargon le, The Jargon File, version 4.4.8, sitio digital
'Catb'.
hacer y decir cómo saber sobre la seguridad con sistemas
en redes* [2∩] [2] {{cita libro|apellidos1=Himanen|nombre1=Peka|título=La
ética del hacker y el espíritu de la era de la
información|fecha=2002|páginas=∧-11|fechaacceso=9 de
febrero de 201∧}}

88.6.4 Phreaker [3] {{cita libro|apellidos1=Raymond|nombre1=Eric|título=The

Art of Unix Programming|fecha=2003|páginas=∪∩-
De phone freak (“monstruo telefónico”). Son personas 91|url=[Link]
html/|fechaacceso=9 de febrero de 201∧}}
con conocimientos amplios tanto en teléfonos modulares
(TM) como en teléfonos móviles. [4] «Hacker culture(s): Origins». Archivado desde el original
La meta de los phreakers es generalmente superar retos el 30 de noviembre de 201∧.
intelectuales de complejidad creciente, relacionados con
[∧] [Link]
incidencias de seguridad o fallas en los sistemas telefóni-
hacker-history/[Link]
cos, que les permitan obtener privilegios no accesibles de
forma legal. [∨] «RFC 1392 - Internet Users\x2∩ Glossary».
El término “Phreak”es una conjunción de las palabras
[∩] Raymond, Eric (2003). The Art of Unix Programming. pp.
phone (teléfono en inglés), hack y freak (monstruo en in-
∪∩–91. Consultado el 9 de febrero de 201∧.
glés). También se re ere al uso de varias frecuencias de
audio para manipular un sistema telefónico, ya que la pa- [∪] {{cita web | url =[Link]
labra phreak se pronuncia de forma similar a frequency [Link]#what_is | título =How To Be-
(frecuencia). come A Hacker }}
88.9. DESCRIPCIÓN 1∩1

[9] {{cita libro|apellidos1=Raymond|nombre1=Eric|título=The [23] {{cita publicación|apellido=Rodríguez|nombre=Pablo

Art of Unix Programming|fecha=2003|páginas=∪∩- Gustavo|título=La criminalización discursiva de los
91|url=[Link] hackers en los medios de prensa|publicación=VII
html/|fechaacceso=9 de febrero de 201∧}} Jornadas Nacionales de Investigadores en Comunica-
ción|fecha=1∪ de septiembre de 2004|año=2004|url=http:
[10] Raymond, Eric Steven (2000). A Brief History of Hacker- //[Link]/handle/1091∧/∧34∩|fechaacceso=19
dom. de junio de 2014}}

[11] Raymond, Eric Steven (2000). A Brief History of Hacker- [24]

dom.
[2∧] [[Link]
[12] {{cita libro|apellidos1=Raymond|nombre1=Eric ,sid14_gci∧∧0∪∪2,[Link] ←Qué es sombrero blanco? -
Steven|título=A Brief History of Hacker- una de nición de [Link] (en inglés)]
dom|fecha=2000|fechaacceso=12 de febrero de 201∧}}
[2∨] [[Link]
[13] {{cita web|url=[Link] tiger team (en inglés)]

[14] {{cita libro|apellidos1=Raymond|nombre1=Eric|título=The [2∩] «Delitos Informaticos - Hacking». Consultado el 2009.

Art of Unix Programming|fecha=2003|páginas=∪∩-
91|url=[Link]
html/|fechaacceso=9 de febrero de 201∧}} 88.9 Descripción
[1∧] Castells, Manuel (2003). «Internet, libertady sociedad:
una perspectiva analítica». [Link] Latinoamericana. • De nición de hacker en el Jargon File (inglés)
Consultado el ∪ de febrero de 201∧.

[1∨] {{cita publicación|apellidos1=Greenhill|nombre1=Kathryn|título=Transformando

la biblioteca pública: de conservadores de edi-
88.10 Enlaces externos
ciones impresas a creadores de contenido digi-
tal|publicación=Congreso Nacional de Bibliotecas Públi- • Wikimedia Commons alberga contenido multi-
cas|fecha=2010|url=[Link]
media sobre HackerCommons.
docs/MC/2010/CongresoBP/KathrynGreenhill.
pdf|fechaacceso=9 de febrero de 201∧}} • O cina Federal de Investigaciones (en inglés) y (en
español)
[1∩] {{cita libro|apellidos1=Levy|nombre1=Steven|título=Hackers:
heroes of the computer revolu- •
tion|fecha=19∪4|fechaacceso=12 de febrero de 201∧}}

Contact Us En Español (Sic)

[1∪] {{cita publicación|apellidos1=Ryan|nombre1=Patrick|título=War,
Peace, or Stalemate: Wargames, Wardialing,
Wardriving and the Emergint Market for Hac-
ker Ethics.|publicación=[Link]|url=http:
//[Link]/sol3/[Link]?abstract_id=
∧∪∧∪∨∩|fechaacceso=∧ de febrero de 201∧}}

[19] {{cita publicación|apellidos1=Chance|nombre1=Tom|título=The

Hacker Ethic and Meaningful Work|fecha=200∧|url=http:
//[Link]/system/files/[Link]|fechaacceso=12
de febrero de 201∧}}

[20] {{cita publicación|apellidos1=Chance|nombre1=Tom|título=The

Hacker Ethic and Meaningful Work|fecha=200∧|url=http:
//[Link]/system/files/[Link]|fechaacceso=12
de febrero de 201∧}}

[21] {{cita libro|apellidos1=Himanen|nombre1=Peka|título=La

ética del hacker y el espíritu de la era de la
información|fecha=2002|páginas=∧-11|fechaacceso=9 de
febrero de 201∧}}

[22] {{cita publicación|apellidos1=Nissenbaum|nombre1=Helen|título=Hackers

and the contested ontology of cy-
berspace|publicación=New Media &
Society|fecha=2004|volumen=∨|número=2|páginas=19∧-
21∩|doi=10.11∩∩/14∨1444∪0404144∧|fechaacceso=12
de febrero de 201∧}}
Capítulo 89

Heisenbug

En jerga de programación, un heisenbug es un tipo de 89.2 Enlaces externos

bug que parece desaparecer o comportarse de otro modo
al intentar ser observado en detalle.* [1] El término es un • The Heisenberg Debugging Technology
juego de palabras a partir del nombre de Werner Heisen-
berg, el físico que dedujo el efecto de observación de la • A Story About Magic
mecánica cuántica, según el cual el mero hecho de ob-
servar un sistema de una manera determinada altera el
estado de este.
Términos similares como bohrbug, mandel-
bug,* [2]* [3]* [4] y schrödinbug* [∧]* [∨] han sido
propuestos ocasionalmente para otro tipo de bugs
inusuales;* [∩]* [∪] de todos modos, no son tan conocidos
ni empleados como el “heisenbug”.* [9]

89.1 Referencias
[1] «The Jargon File: heisenbug».
[2] «The Jargon File: Mandelbug». [Link]. Consultado el ∧
de septiembre de 2013.
[3] Raymond, Eric S.; The New Hacker's Dictionary, 3rd edi-
tion, 199∨
[4] Clarke, Arthur C., The Ghost from the Grand Banks, Ban-
tam Books, 1990
[∧] «The Jargon File: Schroedinbug». [Link]. Consultado el
∧ de septiembre de 2013.
[∨] Raymond, Eric S.; The New Hacker's Dictionary, 3rd edi-
tion, 199∨
[∩] The following article investigates the various de nitions
of bohrbug, mandelbug and heisenbug proposed in the li-
terature, as well as the statements made about the rela-
tionships between these fault types: Grottke, Michael; and
Trivedi, Kishor S.; Software Faults, Software Aging and
Software Rejuvenation, Journal of the Reliability Enginee-
ring Association of Japan, Vol. 2∩, No. ∩, pp. 42∧-43∪,
200∧.
[∪] Grottke, Michael; and Trivedi, Kishor S.; Fighting Bugs:
Remove, Retry, Replicate, and Rejuvenate, IEEE Computer
vol. 40, no. 2 (February 200∩), pp. 10∩-109
[9] A February 2012 Google Books search returns about ∩0
hits for “schroedinbug”, 100 for “mandelbug”, 400
for “bohrbug”or “heisenbug”.

1∩2
Capítulo 90

Hoja de estilo

Las hojas de estilo (style sheets) son conjuntos de ins- • Hojas de estilo para la Web: Trucos y sugerencias
trucciones, a veces en forma de archivo anexo, que se aso- para CSS (Este documento es una traducción del tu-
cian a los archivos de texto y se ocupan de los aspectos de torial “CSS tips & tricks”propiedad de Bert Bos
formato y de presentación de los contenidos: tipo, fuen- publicado en el sitio de W3C.)
te y tamaño de letras, alineación y posicionamiento del
texto, colores y fondos, etc. Las hojas de estilo permiten
liberar la composición del texto de los aspectos visuales 90.3 Referencias
y favorecen que se estructure y anote mediante códigos
que permiten un tratamiento más e caz de los contenidos.
El uso adecuado de las hojas de estilo es uno de los as-
pectos clave de la edición digital. Las hojas de estilo son
una herramienta de gran utilidad de los programas de
tratamiento de textos, como OpenO [Link] o Microsoft
Word. Asimismo, constituyen una parte esencial de los
lenguajes de marcas para edición digital: LaTeX, XML
y XHTML. Dos lenguajes de hojas de estilo son CSS y
XSL.

90.1 Véase también

• Em (tipografía)
• LaTeX
• XML
• XHTML
• CSS
• XSL
• CMS

90.2 Enlaces externos

• Ejercicios de Hojas de Estilo, preparados para un
curso de edición digital de la Universidad de Deus-
to.
• Tutorial de Hojas de Estilo, con ejemplos y el listado
de las propiedades reconocidas.
• Hojas de Estilo Web (Este documento es una traduc-
ción del documento“Web Style Sheets”propiedad
de Bert Bos publicado en el sitio de W3C.)

1∩3
Capítulo 91

Hola mundo

91.2 Enlaces externos

• Hello World! Más de 200 ejemplos de Hola Mundo
(en inglés). Versión del sitio guardada en el Internet
Archive.

• The Hello World Collection Otra extensísima lista

de ejemplos (en inglés).

Resultado de la ejecución de un programa Hola mundo en una

Interfaz grá ca de usuario. 91.3 Referencias
[1] González, Juan (200∪). «Taller de Robótica Básico - Sky-
En informática, un programa Hola mundo es el que im- bot v1.4. - SESION 3 - “Hola mundo“en Linux». Con-
prime el texto «¡Hola, mundo!» en un dispositivo de vi- sultado el 12 de abril de 2009.
sualización, en la mayoría de los casos una pantalla de
monitor. Este programa suele ser usado como introduc-
ción al estudio de un lenguaje de programación, siendo
un primer ejercicio típico, y se lo considera fundamental
desde el punto de vista didáctico.
El programa Hola Mundo también puede ser útil como
prueba de con guración para asegurar que el compilador,
el entorno de desarrollo y el entorno de ejecución estén
instalados correctamente y funcionando. En algunos len-
guajes, con gurar un conjunto de herramientas básicas
completo desde cero hasta el punto en que los progra-
mas triviales puedan ser compilados y ejecutados invo-
lucra una cantidad de trabajo sustancial. Por esta razón,
generalmente es usado un programa muy simple para pro-
bar un nuevo conjunto de herramientas.
En los sistemas basados en microcontroladores emplea-
dos para el aprendizaje, se suele considerar “Hola mun-
do”al programa que permite poner en modo intermitente
un led.* [1] El programa consiste en mandar alternativa-
mente un nivel alto y uno bajo por uno de los puertos del
sistema, dando a cada uno de dichos niveles un valor de
retardo.

91.1 Véase también

• Ejemplos de implementación del «Hola mundo»

1∩4
Capítulo 92

Homebrew

alterar el normal funcionamiento del ordenador en forma

de virus informático son en su mayoría programas home-
brew también. Este amplio colectivo ha dedicado su es-
fuerzo en forma de trabajo individual o en proyectos co-
munes que van acumulando en internet funcionalidades y
librerías de código abierto que son utilizadas y ampliadas
por nuevos programadores autodidactas.
El homebrew es importante porque: abre las puertas a que
muchos de los a cionados a desarrollarlo puedan conse-
guir un empleo remunerado y, además, a que otros desa-
rrolladores continúen ampliando el uso comercial de nue-
Captura de pantalla de Duck Attack!, homebrew para Atari
vos y viejos productos, a que surja la posibilidad profe-
2600. sional de nuevos sistemas operativos, se amplíe la oferta
de aplicaciones... etc. Lo que conlleva a la evolución tec-
nológica de la sociedad y al abaratamiento de recursos
Se suele denominar homebrew (software casero no o -
que de otra manera solo estarían disponibles para unos
cial) a las aplicaciones y juegos creados por programa-
pocos privilegiados.
dores -a cionados y expertos- para cualquier plataforma,
*
generalmente videoconsolas propietarias. [1] Reciente- Aunque su uso más conocido es la creación de softwa-
mente, se han desarrollado consolas diseñadas especí - re para videoconsolas recreativas portátiles o de sobre-
camente para la ejecución de software homebrew, el cual mesa, se ha adaptado software desarrollado para cual-
se caracteriza por ser gratuito y en su mayoría abierto. quier tipo de aparato; como software original libre en pro-
gramas operativos para maquinaria computerizada indus-
trial, diccionarios y agendas electrónicas, teléfonos, emi-
sores o receptores de gps, maquinaria de uso médico y
92.1 Generalidades ordenadores actuales o antiguos de los ∪0 y 90, que ya no
están a la venta por lo sencillo de su interfaz. El softwa-
Homebrew consiste en software de todo tipo creado por re nuevo original se ha desarrollado muchas veces como
programadores a cionados o expertos. Ya los primeros prácticas en lenguajes informáticos relativamente poco
programas desarrollados por la industria privada en los conocidos como C++, LUA, Palib, etc, o por otros mo-
inicios de la informática, eran juegos y, poco más tar- tivos. Son muy conocidos por ser noticia desarrollos de
de, aplicaciones de o mática hechas en casa por a cio- lenguajes de programación cuyo uso afecta a millones de
nados. Hoy en día, en la mayoría de los casos conocidos, personas o algoritmos con aplicaciones homebrew desti-
los programas homebrew son versiones de prueba com- nadas a la industria, agricultura, banca, tratamiento mé-
partidas como freeware o shareware que se distribuyen dico, lectura, enseñanza... y que vuelven millonarios a sus
libremente por internet. Muchas veces, estas herramien- creadores. Algunos autores incluso han realizado su soft-
tas han sido desarrolladas en importantes universidades ware para optar a premios de entidades públicas o priva-
por grupos de estudiantes que distribuyen versiones de das, obtener becas de especialización o conseguir un em-
prueba de su software bajo licencias de uso público y sin pleo remunerado. Aparte de la tradicional forma de pago,
afán de lucro, aunque también hay programadores a ni- existen otros autores que se conforman con menos, desde
vel individual que desarrollan interesantes aplicaciones los que llegan al presupuesto insertando publicidad en su
autodidactas que desde su domicilio particular llegan a software o los que se ven recompensados por el recono-
diversas partes del mundo y de este modo le dan a co- cimiento del público, como ocurrió en el caso del autor
nocer como autor creativo o prestigian el nivel tecnoló- de Facebook. Muchas de las licencias empleadas por los
gico del autor o de su país. Ejemplos muy conocidos son creadores permiten el uso gratuito de su software, siem-
Audacity y Emule. Los malwares que tienen por objeto

1∩∧
1∩∨ CAPÍTULO 92. HOMEBREW

pre y cuando se respeten sus derechos y se les acredite integrados para el usuario se utilizan dentro de los car-
como autores del mismo. Muchas veces podemos mandar tuchos de NES para ampliar las capacidades del sistema,
un mensaje de felicitación si nos ha gustado su trabajo o la mayoría son difíciles de replicar, excepto al eliminar
ponernos en contacto con el autor o los autores o con sus cartuchos usados. El mecanismo de bloqueo de hardware
representantes para nes particulares o comerciales. Mu- de la NES complica aún más la construcción de cartuchos
chas empresas privadas han comercializado legalmente el físicos utilizables. Sin embargo, la NES-101 elimina el
software creado en un principio como homebrew. chip de cierre 10NES para cualquier juego, ya sea home-
La palabra «homebrew» tiene relación con el Homebrew brew, sin licencia, o de otra región de un partido o cial,
se reproduce. El chip 10NES nalmente se puede desac-
Computer Club, aunque se desconoce si fue éste el ori-
gen. En Japón estos juegos son llamados Dojin Soft, que tivar de forma permanente mediante la realización de un
pequeño cambio en el hardware.
es la manera de decir que este software no es ilegal, en
principio, aunque depende del uso que se haga de él. Sue-
le cuestionarse la legalidad del homebrew; sin embargo,
su uso está muy extendido entre los usuarios avanzados. 92.2.3 Super Nintendo Entertainment
Además, su uso, excluyendo las copias de seguridad no System (SNES)
propietarias, es completamente legal.
Después de la interrupción de los juegos en 199∪, y la
producción en 1999, los fans de la Super Nintendo En-
92.2 Homebrew en diferentes con- tertainment System hicieron imágenes ROM homebrew,
incluso sin el apoyo de Nintendo para la consola. Des-
solas pués del lanzamiento de la SNES había un gran interés
en la ingeniería inversa del sistema para permitir jugar
92.2.1 Sega Dreamcast homebrew y copias de seguridad. Nintendo equipado la
máquina con varias medidas de seguridad, tales como el
La Sega Dreamcast (DC) es, en muchos aspectos, una de chip de bloqueo para evitar que código no autorizado que
las pioneras en incorporar homebrew. Para lograr correr se ejecuta en la máquina. Finalmente, la comunidad ho-
este tipo de software era necesario utilizar una puerta tra- mebrew descubierto cómo los juegos corrían en el hard-
sera que permitía iniciar la consola desde discos compac- ware SNES y fueron capaces de eludir sus mecanismos de
tos convencionales (la DC utilizaba un formato especial seguridad. Empresas como TAPÓN plugins hardware li-
llamado GD-ROM). berados como la serie SF doctor Game. Los usuarios que
pueden no solo los juegos de copia, sino también para eje-
• Aplicaciones: Reproductores de MP3 y de video, cutar juegos caseros elaborados en el hardware de SNES.
visores de Flash, y versiones de Linux entre otras. ROMs Homebrew se podrían convertir en el formato SF
Médico juego y poner en un 3 1/2 “disquete. Juegos tan
grandes como 12 Mbits (1.∧ megabytes) podrían poner-
• Emuladores: Con el tiempo, la consola ha llegado se en disquetes formateados de 1.∨ megabytes. Un dis-
a ejecutar emuladores de SNES, Genesis, NES, Neo positivo alternativo fue el Super Flash, por Tototek, que
Geo y Neo Geo CD, entre otros. permitía múltiples juegos para quemarla en un chip de
memoria ash de cartucho (que permite hasta 4∪Mbits).
• Juegos: Se han realizado ports del clásico Doom y Este chip es el rom máscara para el cartucho ash Súper
de la primera y segunda versión de Quake entre otras desarrollo. El dispositivo es fácil de usar y tiene una in-
adaptaciones. Además, se ha desarrollado un sinnú- terfaz de usuario en el extremo del ordenador. Conectar
mero de juegos freeware y de código abierto, des- el cartucho de Super Flash y cargar los juegos que quieras
tacándose los clones de Tetris y de juegos de naves simplemente. Esto permitió a los usuarios hacer un jue-
(shoot'em ups). go de SNES y juegan en un cartucho real en lugar de un
disquete. La legalidad de homebew SNES lanzamientos
de juegos no ha sido probado en los tribunales, y es dis-
92.2.2 Nintendo Entertainment System cutible si o no pasar por sus medidas de seguridad caería
(NES) en con icto con las leyes modernas de ingeniería inver-
sa. Presumiblemente juegos caseros se pueden producir
Varios compiladores están disponibles para la Nintendo legalmente los SNES, siempre y cuando se incluye nin-
Entertainment System, pero como el Atari 2∨00, la mayo- gún material con derechos de autor. Anteriormente, en la
ría del desarrollo se aplica directamente en lenguaje en- década de 1990, Nintendo demandó Color Dreams para
samblador. Un impedimento para la NES desarrollo ho- producir juegos de NES sin licencia o cial. El resultado
mebrew es la relativa di cultad involucrada con la pro- fue un acuerdo no revelado, pero los sueños de color si-
ducción de cartuchos físicos, aunque cartuchos ash de guió produciendo juegos sin licencia. La fuerza del color
terceros existen, haciendo posible homebrew en el hard- de la posición de los sueños se encuentra con que traba-
ware original de NES. Muchas variedades de circuitos jaron todo el código de chip de cierre 10NES en lugar de
92.2. HOMEBREW EN DIFERENTES CONSOLAS 1∩∩

duplicar ilegalmente. • Versiones: Han surgido in nidad de versiones

para este sistema PSP entre las que se inclu-
yen el primer homebrew que surgió llamado
92.2.4 Nintendo DS DevHook, seguido ya de otras generaciones y
los llamados CFW(Custom Firmwares), que han
Para ejecutar homebrew en la Nintendo DS se necesita tenido un gran desarrollo gracias a hackers como
una tarjeta o cartucho ash como M3 DS Real, Supercard, Dark_Alex, Total Noob, Virtuous Flame, Co-
acekard, ez- ash, R4DS o análogas.* [2] Dicha tarjeta se olbird, Neur0n y Lktd9 los cuales actualmente
usa como medio de almacenamiento para los programas, han sacado CFW rmados como por ejem-
los archivos multimedia y los juegos. plo: PRO-(A,A1,A2,A3..B,1,2,3,4,∧,∨,∩,∪,9,10
Existen muchos sitios en Internet dedicados a la distribu- ,TN-HEN/-A-B... , ME 1,2,3..(∨.39), CLFW
ción y difusión del homebrew. 1,2,3..(∨.39),LK-A,LK-II v1,Lk-B,etc

• Aplicaciones: Reproductores de música, Repro-

ductores de videos en muchos formatos, incluyendo
92.2.6 Microsoft Xbox
Avi, calculadoras gra cadoras, diccionarios interac-
Xbox ha sido una de las plataformas más prolí cas en ma-
tivos, lectores de libros electrónicos como DS Libris
teria de homebrew, dada su versatilidad y su arquitectura
para EPUB, linux, voip, aplicaciones...
x∪∨. Se logra ejecutar este tipo de software ya sea con un
modchip o aprovechando un agujero de seguridad. Se ha
• Emuladores: Emuladores de NES, Sega Megadri- desarrollado un kit de programación completamente libre
ve, Gameboy Color, Gameboy Advance, Amiga, llamado OpenXDK, para uso exclusivo con la consola.
NeoGeo, Master System, SuperNintendo, Amstrad,
Comodore, MAME, Scumm, Spectrum
• Aplicaciones: Reproductores de música y videos en
diversos formatos incluyendo DVD; administrado-
• Juegos: Muchos títulos caseros res de archivos y, más notoriamente, distribuciones
de Linux.
92.2.5 Sony PSP
• Emuladores: Emuladores de todo tipo han sido
Para ejecutar homebrew en la PSP es necesario tener un programados para esta consola, entre los que se des-
rmware alternativo llamado Custom Firmware. tacan PCSX y Surreal, de PSX y Nintendo ∨4 res-
pectivamente.
• Downgrades: Se llama“downgrade”al mecanismo
para bajar de versión a una PSP para así llegar a una • Juegos: Una serie de ports han sido adaptados para
versión con menores restricciones, pudiendo de es- Xbox, generalmente han sido más sencillos de desa-
ta manera instalar un rmware alternativo (Custom rrollar dada la mencionada potencia y versatilidad
Firmware) que sea capaz de hacer funcionar home- de la consola.
brew y copias de seguridad, entre otras funciones.

• Aplicaciones: Pequeños reproductores multimedia, 92.2.7 Microsoft Xbox 360

exploradores, programas de información, plugins
con diferentes funciones (como visualizar la panta- Xbox 3∨0, la sucesora directa de la Xbox, tenía un fallo
lla de la PSP en el PC, etc) aunque también dispone en el rmware o cial, que se solucionó con una posterior
-entre otras cosas- de completos shells que disponen actualización y que permite tener acceso a todo el hard-
de una gran variedad de funciones. ware. La explotación por parte de hackers de este fallo
pasó a conocerse como el hack Jtag.* [3]
• Emuladores: Los emuladores más importantes son
los de Game Boy Advance, Play Station, SNES , • Emuladores: Emuladores de todo tipo han sido
Genesis, Nintendo ∨4 entre otros. programados para esta consola, entre los pocos que
hay algunos son de Gameboy, Snes, NES, Sega, Etc.
• Plugins: Los plugins son pequeñas aplicaciones con
una función especí ca, en la PSP se ejecutan a través • Copias de seguridad: Existen aplicaciones que nos
del Recovery Mode (modo de recuperación). Su fun- permiten cargar copias de seguridad desde algún
ción en esta plataforma es bastante interesante, algu- disco duro externo, o desde el mismo disco duro de
nos plugins pueden, por ejemplo, permitir la ejecu- la consola, no está de más decir que cambiando el
ción de códigos gameshark, hacer capturas de pan- rmware del lector de la Xbox 3∨0 también podre-
talla o ampliar las funciones del rmware en general. mos cargar backups grabados en DVD doble capa.
1∩∪ CAPÍTULO 92. HOMEBREW

92.2.8 Nintendo Wii multiarcade Final Burn Arcade y del emulador mul-
tisistema Mednafen.
La Wii permite la incorporación de homebrew mediante
la explotación de diversos fallos, de acuerdo a la versión • Juegos: Existen ports del videojuego Doom, además
del software o cial que se posea.* [4] La ejecución de las de versiones de reconocidos juegos como Tetris, en-
diversas aplicaciones se realiza por medio del Homebrew tre otros.
Channel, programa que se puede instalar y ejecutar desde
el menú principal de la consola.* [∧]
92.3 Véase también
• Aplicaciones: Reproductores de MP3 y de vídeo
(desde SD, USB o DVD), editores de texto o uti-
• Homebrew Computer Club
lidades que utilizan las características especiales del
mando wii (tales como un módulo que permite dibu- • Sega Dreamcast
jar en la pantalla utilizando el mando como pincel.
• PlayStation Portable
• Emuladores: Existen emuladores de consolas co- • Anexo:Modchips para Wii
mo NES, SNES, Sega Genesis, Sega Master Sys-
tem, MSX, Game Boy Color, Game Boy Advance,
MAME, Neo Geo Pocket, Nintendo ∨4, PC Engi-
ne, PSX, SCUMM, ZX Spectrum, Chip-∪, Amstrad
92.4 Referencias
CPC, Atari 2∨00 y Neo Geo.
[1] «The Complete Guide to Whats Needed for Homebrew
on Each Console.» (en inglés). DC Emu UK. Archivado
• Juegos: Entre los juegos, nos encontramos desde desde el original el 2∪ de noviembre de 201∧. Consultado
clásicos como Pong, Asteroides o Tetris hasta otros el 12 de enero de 2011.
más modernos como Quake. Destacar el GuitarFun,
versión del Guitar Hero realizada por un español. [2] «Homebrew de NDS». El Otro Lado. 3 de abril de 2010.
Consultado el 12 de enero de 2011.

• Copias de seguridad: Además el Homebrew se [3] «Homebrew Xbox 3∨0». El Otro Lado. 30 de diciembre
puede utilizar para que la consola cargue copias de 2010. Consultado el 12 de enero de 2011.
de seguridad, sistema popularmente conocido co-
[4] «Cargar Homebrew en Wii». El Otro Lado. 1∪ de diciem-
mo piratear sin chip. O incluso instalar juegos de la bre de 2010. Consultado el 12 de enero de 2011.
Consola Virtual y WiiWare.
[∧] «Homebrew Channel». El Otro Lado. 9 de enero de 2011.
Consultado el 12 de enero de 2011.
92.2.9 PlayStation 3
[∨] «PS3 Jailbreak: un pendrive para hackear la PlayStation
3». Red Users. 21 de agosto de 2010. Consultado el 2∧ de
PlayStation 3 puede ser utilizada para homebrew median-
octubre de 2010.
te la utilización del dispositivo PS Jailbreak o sus deriva-
dos clónicos o de código abierto, únicamente con el rm- [∩] «PlayStation 3 ha sido hackeada». Meristation. 20 de
ware 3.41 o anteriores.* [∨]* [∩] Adicionalmente, es posi- agosto de 2010. Consultado el 2∧ de octubre de 2010.
ble realizar un downgrade desde las versiones 3.42 y 3.∧0.
[∪] «Hackers se hacen con las claves de seguridad secretas de
En este caso, se estaría ejecutando software no rmado.
PlayStation 3». Meristation. 3 de enero de 2011. Consul-
También es posible instalar y ejecutar homebrew hasta tado el ∨ de enero de 2011.
la versión de rmware 3.∧∧, a partir del descubrimiento
de las claves privadas de la consola que el hacker George
Hotz sacó a la luz con su rmware personalizado. versión
3.∧∧ GeoHot* [∪] En este caso, se estaría ejecutando soft-
ware rmado.

• Aplicaciones: Servidores FTP, cargadores de rm-

wares modi cados, y cargadores de juegos (Backup
Manager y Open Manager inicialmente; luego Mul-
timan, Gaia y Rogero).

• Emuladores: han sido lanzados emuladores de

NES, SNES, Sega Genesis, Game Boy Advance,
PSX, SCUMM, así como versiones del emulador
Capítulo 93

ICONIX

ICONIX es una metodología pesada-ligera de desarrollo • Modelo de casos de usos

del Software que se halla a medio camino entre un RUP
(Rational Uni ed Process) y un XP (eXtreme Program-
ming). 93.2.2 Fase 2: Análisis y diseño preliminar
Iconix deriva directamente del RUP y su fundamento es
Dentro de esta fase se realizan las siguientes tareas:
el hecho de que un ∪0% de los casos pueden ser resueltos
tan solo con un uso del 20% del UML, con lo cual se sim-
pli ca muchísimo el proceso sin perder documentación al • Descripción de los casos de uso
dejar solo aquello que es necesario. Esto implica un uso
dinámico del UML de tal forma que siempre se pueden • Diagramas de robustez
utilizar otros diagramas además de los ya estipulados si
se cree conveniente. Iconix se guía a través de casos de
uso y sigue un ciclo de vida iterativo e incremental. El 93.2.3 Fase 3: Diseño
objetivo es que a partir de los casos de uso se obtenga el
sistema nal. Dentro de esta fase se realiza la siguiente tarea:

• Diagramas de secuencia
93.1 Ventajas de Iconix
• Proceso ágil para obtener un sistema informático. 93.2.4 Fase 4: Implementación

• Dedicada a la construcción de sistemas de gestión de Dentro de esta fase se realiza la siguiente tarea:
pequeña y mediana complejidad con la participación
de los usuarios nales. • Escribir y generar código

Tareas de la metodología Iconix =

La metodología está formada por cuatro fases principales 93.3 Referencias
que son:
• 1. Rosenberg, Doug; Stephens, Matt (200∩). Use Ca-
se Driven Object Modeling with UML: Theory and
93.2 Tareas de la metodología Ico- Practice. Apress. ISBN 1∧90∧9∩∩4∧.
nix • 2. Rosenberg, Doug; Stephens, Matt; Collins-Cope,
Mark (200∧). Agile Development with ICONIX Pro-
La metodología está formada por cuatro fases principales cess. Apress. ISBN 1∧90∧94∨49.
que son:

93.2.1 Fase 1: Análisis de requisitos 93.4 Conceptos Relacionados

Dentro de esta fase se realizan las siguientes tareas: • Dynamic Systems Development Method (DSDM)

• Modelo del dominio • Extreme Programming

• Elaboración rápida de prototipos • Rational Uni ed Process

1∩9
1∪0 CAPÍTULO 93. ICONIX

• URDAD, the Use Case Driven Analysis and Design 93.7 Conceptos Relacionados
methodology is a methodology for technology neu-
tral design. • Dynamic Systems Development Method (DSDM)
• RATF, using Robustness Analysis in combination • Extreme Programming
with Technology Forecasting, to further investigate
future software evolution alternatives. • Rational Uni ed Process

• URDAD, the Use Case Driven Analysis and Design

methodology is a methodology for technology neu-
93.5 Enlaces externos tral design.

• RATF, using Robustness Analysis in combination

• Página o cial ICONIX with Technology Forecasting, to further investigate
future software evolution alternatives.
• Página de la ICONIX Process

• ICONIX UML and SysML Jumpstart Training

93.8 Enlaces externos
• Introducción a los Procesos ICONIX

• Robustness Diagrams • Página o cial ICONIX

• Página de la ICONIX Process

• Metodología ICONIX
• ICONIX UML and SysML Jumpstart Training
• Uso de la metodología ICONIX
• Introducción a los Procesos ICONIX

93.5.1 Fase 2: Análisis y diseño preliminar • Robustness Diagrams

• Metodología ICONIX
Dentro de esta fase se realizan las siguientes tareas:
• Uso de la metodología ICONIX
• Descripción de los casos de uso

• Diagramas de robustez

93.5.2 Fase 3: Diseño

Dentro de esta fase se realiza la siguiente tarea:

• Diagramas de secuencia

93.5.3 Fase 4: Implementación

Dentro de esta fase se realiza la siguiente tarea:

• Escribir y generar código

93.6 Referencias
• 1. Rosenberg, Doug; Stephens, Matt (200∩). Use Ca-
se Driven Object Modeling with UML: Theory and
Practice. Apress. ISBN 1∧90∧9∩∩4∧.

• 2. Rosenberg, Doug; Stephens, Matt; Collins-Cope,

Mark (200∧). Agile Development with ICONIX Pro-
cess. Apress. ISBN 1∧90∧94∨49.
Capítulo 94

Anexo:Implementaciones de Smalltalk

En informática, el lenguaje de programación Smalltalk,

está normalizado desde 199∪ en el estándar ANSI NCITS
319-199∪. Una implementación de Smalltalk es un siste-
ma de programación que conforma al estándar si imple-
menta todas las características de nidas tal como están
especi cadas en ese documento.
Cada implementación de Smalltalk, suele incluir como
propias:

• Una Máquina virtual.

• Un archivo llamado 'Archivo de imagen virtual' que

sirve como contenedor de objetos.

• Un Entorno de desarrollo que funciona como un

sistema en tiempo de ejecución, por ello de dice que
es interactivo. En el caso de no poseer un entorno in-
teractivo orientado a controles visuales, es llamado
de scripting.
• Una biblioteca de clases.

Esta página incluye un listado de implementaciones cono-

cidas del lenguaje de programación Smalltalk, y una ta-
bla comparativa de algunas características relevantes para
cada implementación:

1∪1
Capítulo 95

Anexo:Implementaciones para algoritmo

de rut

A continuación se presentan diversas implementaciones 95.3 Visual Basic MS Excel

de algoritmos validadores de RUN/RUT en algunos de
los más populares lenguajes de programación:
Public Function RutDigito(ByVal Rut As Long) As
String Dim Digito As Integer Dim Contador As In-
teger Dim Multiplo As Integer Dim Acumulador As
95.1 Objective-C Integer Contador = 2 Acumulador = 0 While Rut <>
0 Multiplo = (Rut Mod 10) * Contador Acumulador
//validation with parse logic from RUT string format = Acumulador + Multiplo Rut = Rut \ 10 Contador
[Link]-Y + (BOOL)validRUT:(NSString*)rut{ = Contador + 1 If Contador > ∩ Then Contador = 2
//remove any dots or signs from RUT string with format End If Wend Digito = 11 - (Acumulador Mod 11)
[Link]-Y //[Link] RutDigito = CStr(Digito) If Digito = 10 Then RutDigito
%C3%9Anico_Tributario rut = [rut stringByRepla- =“K”If Digito = 11 Then RutDigito =“0”End Function
cingOccurrencesOfString:@".”withString:@""]; rut
= [rut stringByReplacingOccurrencesOfString:@"-"
withString:@""]; //get rut validator digit (Y) char dv =
[rut characterAtIndex:[rut length]−1]; NSLog(@"DV:
%c”, dv); //get rut numeric value from ([Link])
int rutnumber = [[rut substringToIndex:[rut length]−1] 95.4 C#
integerValue]; NSLog(@"RUT NUMBER: %d”, rut-
number); //check valid RUT number ([Link])
with validator digit (Y) return [self validRUT:rutnumber private string digitoVeri cador(int rut) { int Digito;
with:dv]; } //algorithm module 11 based on the Java int Contador; int Multiplo; int Acumulador; string
version + (BOOL)validRUT:(int)rut with:(char)dv { //to RutDigito; Contador = 2; Acumulador = 0; while (rut
accept 'k' lowercase to avoid issues with “K”clients dv != 0) { Multiplo = (rut % 10) * Contador; Acumulador
= (dv == 'k')?'K':dv; NSLog(@"RUT DV: %c”, dv); int = Acumulador + Multiplo; rut = rut/10; Contador
m = 0, s = 1; for (; rut != 0; rut /= 10) { s = (s + rut % 10 = Contador + 1; if (Contador == ∪) { Contador =
* (9 - m++ % ∨)) % 11; } //generate DV to check char 2; } } Digito = 11 - (Acumulador % 11); RutDigi-
dvcheck = (char) (s != 0 ? s + 4∩ : ∩∧); NSLog(@"RUT to = [Link]().Trim(); if (Digito == 10 ) {
DV: %c”, dv); NSLog(@"GEN DV: %c”, dvcheck); RutDigito = “K"; } if (Digito == 11) { RutDigito
return dv == dvcheck; } = “0"; } return (RutDigito); } } } /// Una versión
mas corta public static string Dv(string r) { int suma
= 0; for (int x = [Link] - 1; x >= 0; x--) suma
+= [Link]([Link](r[x])?r[x].ToString():"0”) *
((([Link] - (x + 1)) % ∨) + 2); int numericDigito = (11 -
95.2 C++ suma % 11); string digito = numericDigito == 11 ?“0”:
numericDigito == 10 ?“K”: [Link]();
char digito_veri cador_rut(unsigned rut) { unsigned sum return digito; } /// Una versión funcional public static
= 0, factor = 2; while(rut) { sum += (rut%10)*factor; char GenerarDV (int num) { return “0K9∪∩∨∧4321”
rut/=10; factor = factor==∩ ? 2 : factor+1; } const [ [Link] (0, (int) [Link] (Math.Log10
unsigned res = 11 - sum%11; return res == 11? '0' : res (num)) + 2) .Select (i => ((i % ∨) + 2) * ((num / (int)
== 10? 'k' : res+'0'; } [Link] (10, i)) % 10)) .Sum () % 11]; }

1∪2
95.10. PSEINT 1∪3

95.5 Perl 6 h=r-(10^∩*a+10^∨*b+10^∧*c+10^4*d+10^3*e+100*f+10*g);

sum=h*2+g*3+f*4+e*∧+d*∨+c*∩+b*2+a*3;
#!/usr/bin/perl∨ my ($RUT, @RUT, $digito); $RUT = resto=sum- oor(sum/11)*11; verif=11-resto; disp('El
@*ARGS; # leemos el argumento pasado al programa numero veri cador es:') if (verif<10) disp(verif) end if
@RUT = $[Link]('').reverse; # lo pasamos a array y (verif==11) disp('0') end if (verif==10) disp('K') end
le damos la vuelta $digito = [+](@RUT <<*>> (2..∩)); #
cálculo del dígito veri cador $digito = 11 - $digito % 11;
$digito = ( 0 .. 9, 'K', 0 )[$digito]; say "$RUT-$digito";
# salida 95.10 PSeInt
Proceso digito_veri cador De nir rut, a1, pa, c, sum,
di, digi Como Enteros; Escribir “Este programa de ne
95.6 Javascript su dígito veri cador "; Escribir “Ingrese su rut sin el
dígito veri cador "; Leer rut; pa<-rut; c<−2; sum<−0;
dv = function(T) { var M=0,S=1; Mientras rut>0 Hacer a1<-rut%10; rut<-trunc(rut/10);
for(;T;T=Math. oor(T/10)) S=(S+T%10*(9- sum<-sum+(a1*c); c<-c+1; Si c=∪ Entonces c<−2; Fin-
M++%∨))%11; return S?S-1:'K'; } alert('El digito Si FinMientras di<-sum%11; digi<−11-di; Si digi=11
veri cador del rut ingresado es '+ dv(prompt('Ingrese rut Entonces Escribir “El dígito veri cador es 0"; Escribir
para mostrar su digito veri cador:'))); pa,"−0"; Sino Si digi=10 Entonces Escribir “El dígito
veri cador es K"; Escribir pa,"-K"; Sino Escribir “El
dígito veri cador es ",digi; Escribir pa,"-",digi; FinSi
FinSi FinProceso
95.7 PHP
function dv($r){ $s=1; for($m=0;$r!=0;$r/=10) 95.11 Python
$s=($s+$r%10*(9-$m++%∨))%11; echo 'El digito
veri cador del rut ingresado es ',chr($s?$s+4∩:∩∧); }
def digito_veri cador(rut): value = 11 - sum([
int(a)*int(b) for a,b in zip(str(rut).z ll(∪),
'32∩∨∧432')])%11 return {10: 'K', 11: '0'}.get(value,
str(value))
95.8 Transact-SQL
CREATE FUNCTION RutDigito (@Rut as integer)
RETURNS varchar(1) AS BEGIN declare @Digito as 95.12 Ruby
integer declare @Contador as integer declare @Multiplo
as integer declare @Acumulador as integer declare @re-
def digito_veri cador(rut) dv = (11-
torno as varchar(1) set @Contador = 2 set @Acumulador
([Link]('').map(&:to_i).reverse.each_with_index.map
= 0 WHILE @Rut <> 0 BEGIN set @Multiplo = (@Rut
{ |e, i| e*(2+i%∨) }).inject(:+))%11 if dv < 10 then
% 10) * @Contador set @Acumulador = @Acumulador
dv.to_s else 'k' end end
+ @Multiplo set @Rut = @Rut / 10 set @Contador =
@Contador + 1 If @Contador > ∩ set @Contador = 2
END set @Digito = 11 - (@Acumulador % 11) select
@retorno = case when @Digito = 10 then 'K' when
@Digito = 11 then '0' else cast(@Digito as varchar(1)) 95.13 Java
end return @retorno END
public static boolean ValidarRut(int rut, char dv) { int m
= 0, s = 1; for (; rut != 0; rut /= 10) { s = (s + rut % 10 *
(9 - m++ % ∨)) % 11; } return dv == (char) (s != 0 ? s +
95.9 MATLAB 4∩ : ∩∧); }

r=input('Ingrese rut:'); a= oor(r/10^∩); b= oor(r/10^∨)-

(10*a); c= oor(r/10^∧)-(100*a+10*b); d= oor(r/10^4)-
(10^3*a+100*b+10*c); e= oor(r/10^3)- 95.14 Pl/pgsql de PostgreSql
(10^4*a+10^3*b+100*c+10*d); f= oor(r/10^2)-
(10^∧*a+10^4*b+10^3*c+100*d+10*e); CREATE OR REPLACE FUNCTION sp_rut_cl(
g= oor(r/10^1)-(10^∨*a+10^∧*b+10^4*c+10^3*d+100*e+10*f); rut VARCHAR ) RETURNS CHARACTER(1) AS
1∪4 CAPÍTULO 95. ANEXO:IMPLEMENTACIONES PARA ALGORITMO DE RUT

$BODY$ DECLARE rec record; suma INTEGER :=

0; serie INTEGER := 2; resto INTEGER; dv CHA-
RACTER(1); BEGIN --raise notice 'rut: %',rut; if (rut
is null) then return null; end if; rut := btrim(rut); rut :=
replace(rut, '.', ''); if (rut is null) then return null; end
if; rut := btrim(rut); for rec in select * from ( select
substring(rut from i for 1)::char as bit from genera-
te_series(length(rut),1,−1) as i --where bit = '1' ) q1
LOOP --raise notice '1'; --raise notice '[Link]: %',[Link];
--raise notice '2'; if [Link] is not null and [Link] ~ '[0-9]+'
then suma := suma + [Link]::INTEGER * serie; end if;
--raise notice '3'; --raise notice 'serie: %',serie; if serie
= ∩ then serie := 1; end if; serie := serie + 1; end loop;
--raise notice 'suma: %',suma; resto := 11 - suma % 11;
--raise notice 'resto: %',resto; dv := case resto when 11
then '0' when 10 then 'K' else resto::CHARACTER end;
return dv; end; $BODY$ LANGUAGE 'plpgsql' volatile;
Capítulo 96

Inanición (informática)

En informática, inanición (starvation en inglés) es un

problema relacionado con los sistemas multitarea, donde
a un proceso o un hilo de ejecución se le deniega siempre
el acceso a un recurso compartido. Sin este recurso, la
tarea a ejecutar no puede ser nunca nalizada.
La inanición es una situación similar al interbloqueo, pero
las causas son diferentes. En el interbloqueo, dos procesos
o dos hilos de ejecución llegan a un punto muerto cuando
cada uno de ellos necesita un recurso que es ocupado por
el otro. En cambio, en este caso, uno o más procesos están
esperando recursos ocupados por otros procesos que no
se encuentran necesariamente en ningún punto muerto.
Un caso de inanición la ilustra perfectamente la paradoja
conocida como la cena de los lósofos de Edsger Dijkstra
cuando se da el caso de que todos los lósofos cogen el
tenedor a la vez.
La utilización de prioridades en muchos sistemas opera-
tivos multitarea podría causar que procesos de alta prio-
ridad estuvieran ejecutándose siempre y no permitieran
la ejecución de procesos de baja prioridad, causando ina-
nición en estos. Es más, si un proceso de alta prioridad
está pendiente del resultado de un proceso de baja priori-
dad que no se ejecuta nunca, entonces este proceso de alta
prioridad también experimenta inanición (esta situación
se conoce como inversión de prioridades). Para evitar es-
tas situaciones los plani cadores modernos incorporan al-
goritmos para asegurar que todos los procesos reciben un
mínimo de tiempo de CPU para ejecutarse.

1∪∧
Capítulo 97

Indirección

La in-dirección es una técnica de programación. El con-

cepto se basa en hacer referencia indirecta a los datos
usando las direcciones de memoria que los contienen o
mediante punteros que señalan hacia esos datos o a las
direcciones que los contienen.
En la memoria no sólo se almacenan datos de los
programas (como letras, caracteres grá cos, números na-
turales, números enteros, coma otante, etc.) sino tam-
bién direcciones de memoria, que al n y al cabo también
son datos.
Para efectos de almacenamiento y manipulación por
el microprocesador, todos estos datos no son más que
una secuencia de bytes en diferentes celdas. El que una
secuencia de bits determinada se intérprete como un
número o como una dirección depende del programador.
El mecanismo de in-dirección se puede encadenar de ma-
nera arbitrariamente larga. La dirección que contiene la
dirección de un dato, a su vez se puede almacenar de nue-
vo en memoria. Es posible almacenar las direcciones de
tal forma que haya que seguir un encadenamiento de in-
direcciones para llegar nalmente a acceder al dato.
En el siguiente ejemplo, la“celda”(dirección de memoria
0x00000100) contiene el dato 0x00000200 que a su vez
representa la dirección de la nueva“celda”que contiene
el dato que corresponde a una dirección que contiene un
dato que representa la dirección 0x00000400 que nal-
mente contiene el dato que nos interesa. Y así podemos
de nir a voluntad o conveniencia los diferentes niveles de
in-dirección que necesitemos.

1∪∨
Capítulo 98

Infraestructura de lenguaje común

2001. En abril del año 2003 ISO rati có este estándar con
el denominación ISO/IEC 232∩1:2003 .
Para comprender mejor la inclusión de cada una de las
partes principales de la arquitectura de CLI es interesante
analizar los objetivos de diseño que se plantearon desde
su concepción. Según su especi cación, la arquitectura de
CLI debe:

• Permitir escribir componentes ínteroperables inde-

pendientemente de la plataforma subyacente y del
lenguaje de programación utilizado.
• Exponer todas las entidades programáticas a través
de un único sistema uni cado de tipos (en la espe-
ci cación, este sistema es conocido como CTS, o
Common Type System).
• Empaquetar todos los tipos en unidades completa-
mente auto descriptivas y portables.
• Cargar los tipos de forma tal que se encuentren ais-
lados unos de otros en tiempo de ejecución, pero que
Representación visual, en inglés, de la infraestructura de lenguaje puedan a su vez compartir recursos.
común.
• Resolver dependencias entre tipos en tiempo de eje-
cución usando una política exible que pueda tener
La infraestructura de lenguaje común (en inglés Com- en cuenta la versión, atributos de localización y po-
mon Language Infrastructure o CLI) es una especi ca- líticas administrativas.
ción estandarizada que describe un entorno virtual para
la ejecución de aplicaciones, cuya principal característi- • Ejecutar aplicaciones bajo la supervisión de un en-
ca es la de permitir que aplicaciones escritas en distintos torno privilegiado que permita controlar y hacer
lenguajes de alto nivel puedan luego ejecutarse en múlti- cumplir políticas en tiempo de ejecución.
ples plataformas tanto de hardware como de software sin • Diseñar toda la infraestructura y servicios basándose
necesidad de reescribir o recompilar su código fuente. en metadatos extensibles, de manera tal que toda la
Si bien el CLI tuvo sus orígenes en Microsoft (en princi- arquitectura pueda acomodarse con poco impacto a
pio se pensaba desarrollar un entorno de ejecución com- nuevas incorporaciones y cambios.
partido para COM con el nombre de Common Object • Poder realizar tareas de bajo nivel, como carga de
Runtime, que luego se extendió y generalizó para dar tipos en memoria, enlace con librerías y compila-
lugar a CLI), sus especi caciones fueron llevadas an- ción a código nativo sólo cuando sea necesario (este
te ECMA (European Computer Manufacturers Associa- enfoque se conoce típicamente como“on demand”
tion), una importante organización europea de estánda- , o “just in time”).
res, para su estandarización en el año 2000. Luego de un
año de trabajo conjunto entre ECMA, Microsoft y otras • Proveer una serie de funcionalidades comunes me-
empresas que co-patrocinaron el proceso (Intel, HP, IBM diante un grupo de librerías de programación que
y Fujitsu entre otras), el estándar ECMA-33∧ que de - los desarrolladores puedan utilizar para construir sus
ne el entorno CLI nalmente vio la luz en diciembre de aplicaciones.

1∪∩
1∪∪ CAPÍTULO 98. INFRAESTRUCTURA DE LENGUAJE COMÚN

Microsoft .NET de hecho es un súper conjunto de es-

ta especi cación, es decir, provee todo lo necesario para
cumplir con la misma y además agrega una serie de he-
rramientas, librerías y funcionalidades no contempladas
por ella originalmente y que proveen una enorme utili-
dad y exibilidad a los desarrolladores (por ejemplo, li-
brerías para la creación de aplicaciones y servicios web,
acceso a motores de bases de datos, controles grá cos,
herramientas para desensamblar assemblies, debuggers,
etc.). Si bien es gratuito, su código fuente no es abierto,
y es distribuido por Microsoft en versiones para sistemas
operativos Windows 9∪ y sus sucesores únicamente.
La especi cación del CLI está formada por cuatro partes:

• Sistema común de tipos, en inglés Common Type

System (CTS).

• Metadatos.
• Especi caciones de lenguaje común, en inglés Com-
mon Language Speci cation (CLS).
• Sistema de ejecución virtual, del inglés Virtual Exe-
cution System (VES).

98.1 Véase también

• Microsoft .NET

• ECMA
Capítulo 99

Ingeniería de software

Ingeniería de software es la aplicación de un enfo- Indistintamente se utilizan los términos “ingeniería de

que sistemático, disciplinado y cuanti cable al desarrollo, software”o “ingeniería del software"; aunque menos
operación y mantenimiento de software,* [1] y el estudio común también se suele referenciar como“ingeniería en
de estos enfoques, es decir, la aplicación de la ingenie- software”.* [∧]* [∨]* [∩] En Hispanoamérica los términos
ría al software.* [2] Integra matemáticas, ciencias de la más comúnmente usados son los dos primeros.
computación y prácticas cuyos orígenes se encuentran en
La creación del software es un proceso intrínsecamente
la ingeniería.* [3] creativo y la ingeniería del software trata de sistematizar
Se citan las de niciones más reconocidas, formuladas por este proceso con el n de acotar el riesgo del fracaso en
prestigiosos autores: la consecución del objetivo, por medio de diversas técni-
cas que se han demostrado adecuadas sobre la base de la
• Ingeniería de software es el estudio de los principios experiencia previa.
y metodologías para el desarrollo y mantenimiento
La IS se puede considerar como la ingeniería aplicada al
de sistemas software (Zelkovitz, 19∩∪).
software, esto es, por medios sistematizados y con herra-
• Ingeniería de software es la aplicación práctica del mientas preestablecidas, la aplicación de ellos de la mane-
conocimiento cientí co al diseño y construcción de ra más e ciente para la obtención de resultados óptimos;
programas de computadora y a la documentación objetivos que siempre busca la ingeniería. No es sólo de la
asociada requerida para desarrollar, operar y mante- resolución de problemas, sino más bien teniendo en cuen-
nerlos. Se conoce también como desarrollo de soft- ta las diferentes soluciones, elegir la más apropiada.
ware o producción de software (Bohem, 19∩∨).
• La ingeniería de software trata del establecimiento
de los principios y métodos de la ingeniería a n de 99.1 Historia
obtener software de modo rentable, que sea able y
trabaje en máquinas reales (Bauer, 19∩2). Cuando aparecieron las primeras computadoras digitales
en la década de 1940,* [∪]el desarrollo de software era
• La ingeniería de software es la aplicación de un
algo tan nuevo que era casi imposible hacer prediccio-
enfoque sistemático, disciplinado y cuanti cable al
nes de las fechas estimadas de nalización del proyecto y
desarrollo, operación, y mantenimiento del softwa-
* muchos de ellos sobrepasaban los presupuestos y tiempo
re. [1]
estimados.. Los desarrolladores tenían que volver a escri-
bir todos sus programas para correr en máquinas nuevas
En 2004, la U. S. Bureau of Labor Statistics (O cina de
Estadísticas del Trabajo de Estados Unidos) contó ∩∨0 que salían cada uno o dos años, haciendo obsoletas las ya
∪40 ingenieros de software de computadora.* [4] El tér- existentes.
mino “ingeniero de software”, sin embargo, se utiliza El término Ingeniería del software apareció por primera
de manera genérica en el ambiente empresarial, y no to- vez en a nales de la década de 19∧0. La Ingeniería de
dos los que se desempeñan en el puesto de ingeniero de software fue estimulada por la crisis del software de las
software poseen realmente títulos de ingeniería de uni- décadas de entre 19∨0 y 19∪0. La Ingeniería del software
versidades reconocidas. viene a ayudar a identi car y corregir mediante princi-
Algunos autores consideran que“desarrollo de software” pios y metodologías los procesos de desarrollo y mante-
es un término más apropiado que“ingeniería de softwa- nimiento de sistemas de software.
re”para el proceso de crear software. Personas como Pete Aparte de la crisis del software de las décadas de entre
McBreen (autor de“Software Craftmanship”) cree que 19∨0 y 19∪0, la ingeniería de software se ve afectada por
el término IS implica niveles de rigor y prueba de proce- accidentes que conllevaron a la muerte de tres personas;
sos que no son apropiados para todo tipo de desarrollo de esto sucedió cuando la máquina de radioterapia Therac-
software. 2∧ emite una sobredosis masiva de radiación y afecto con-

1∪9
190 CAPÍTULO 99. INGENIERÍA DE SOFTWARE

tra la vida de estas personas.* [9] Esto remarca los riesgos ternet; esto hace que los desarrolladores tuviesen que ma-
de control por software,* [10] afectando directamente al nejar imágenes mapas y animaciones para optimizar la
nombre de la ingeniería de software. visualización/almacenamiento de imágenes (como el uso
A principios de los 19∪0, [11] la ingeniería del software de imágenes en miniatura). El uso de los navegadores y
*

ya había surgido como una genuina profesión, para estar utilización de lenguaje HTML cambia drásticamente la
al lado de las ciencias de la computación y la ingeniería visión y recepción de la información.
tradicional. Antes de esto, las tareas eran corridas ponien-Las amplias conexiones de red crea la proliferación de
do tarjetas perforadas como entrada en el lector de tarje- virus informáticos y la basura en los correos electrónicos
tas de la máquina y se esperaban los resultados devueltos (E-mail) esto pone en una carrera contra el tiempo los
por la impresora. desarrolladores para crear nuevos sistemas de bloqueo o
Debido a la necesidad de traducir frecuentemente el soft- seguridad de estas anomalías en la informática ya *que se
ware viejo para atender las necesidades de las nuevas má- volvían sumamente tediosas y difíciles de arreglar [10]
quinas, se desarrollaron lenguajes de orden superior. A Después de una fuerte y creciente demanda surge la
medida que apareció el software libre, las organizaciones necesidad de crear soluciones de software a bajo costo,
de usuarios comúnmente lo liberaban. esto conlleva al uso de metodologías más simples y
Durante mucho tiempo, solucionar la crisis del software rápidas que desarrollan software funcional. Cabe señalar
fue de suma importancia para investigadores y empresas que los sistemas más pequeños tenían un enfoque más
que se dedicaban a producir herramientas de software. simple y rápido para poder administrar el desarrollo de
cálculos y algoritmos de software.
Para la década de 19∪0, el costo de propiedad y mante-
nimiento del software fue dos veces más caro que el pro-
pio desarrollo del software, y durante la década de 1990,
el costo de propiedad y mantenimiento aumentó 30 %
con respecto a la década anterior. En 199∧, muchos de 99.2 Objetivos
los proyectos de desarrollo estaban operacionales, pero
no eran considerados exitosos. El proyecto de software La ingeniería de software aplica diferentes normas y mé-
medio sobrepasaba en un ∧0 % la estimación de tiempo todos que permiten obtener mejores resultados, en cuan-
previamente realizada, además, el ∩∧ % de todos los gran- to al desarrollo y uso del software, mediante la aplicación
des productos de software que eran entregados al cliente correcta de estos procedimientos se puede llegar a cum-
tenían fallas tan graves, que no eran usados en lo absolu- plir de manera satisfactoria con los objetivos fundamen-
to o simplemente no cumplían con los requerimientos del tales de la ingeniería de software.
cliente.* [10]
Entre los objetivos de la ingeniería de software están:
Algunos expertos argumentaron que la crisis del software
era debido a la falta de disciplina de los programadores.
• Mejorar el diseño de aplicaciones o software de tal
Cada nueva tecnología y práctica de la década de 19∩0 a
modo que se adapten de mejor manera a las nece-
la de 1990 fue pregonada como la única solución a todos
sidades de las organizaciones o nalidades para las
los problemas y el caos que llevó a la crisis del software.
cuales fueron creadas.
Lo cierto es que la búsqueda de una única clave para el
éxito nunca funcionó. El campo de la ingeniería de soft-
• Promover mayor calidad al desarrollar aplicaciones
ware parece un campo demasiado complejo y amplio pa-
complejas.
ra una única solución que sirva para mejorar la mayoría
de los problemas, y cada problema representa sólo una
pequeña porción de todos los problemas de software. • Brindar mayor exactitud en los costos de proyectos
y tiempo de desarrollo de los mismos.
El auge del uso del Internet llevó a un vertiginoso creci-
miento en la demanda de sistemas internacionales de des- • Aumentar la e ciencia de los sistemas al introducir
pliegue de información en la World Wide Web. Los desa- procesos que permitan medir mediante normas es-
rrolladores se vieron en la tarea de manejar ilustraciones, pecí cas, la calidad del software desarrollado, bus-
mapas, fotografías y animaciones, a un ritmo nunca antes cando siempre la mejor calidad posible según las ne-
visto, con casi ningún método para optimizar la visuali- cesidades y resultados que se quieren generar.
zación y almacenamiento de imágenes. También fueron
necesarios sistemas para traducir el ujo de información
• Una mejor organización de equipos de trabajo, en el
en múltiples idiomas extranjeros a lenguaje natural hu-
área de desarrollo y mantenimiento de software.
mano, con muchos sistemas de software diseñados para
uso multilenguaje, basado en traductores humanos.
• Detectar a través de pruebas, posibles mejoras pa-
La ingeniería de software contribuyo alrededor de 90,000 ra un mejor funcionamiento del software desarrolla-
millones de dólares por año ya que entra en juego el In- do.* [12]
99.5. NOTACIONES 191

99.3 Recursos proyectos exitosos donde se han usado métodos de inge-

niería de software incluyen a GNU/Linux, el software del
transbordador espacial, los cajeros automáticos y muchos
99.3.1 Recurso humano
otros.
Son todas aquellas personas que intervienen en la plani -
cación de cualquier instancias de software (por ejemplo:
gestor, ingeniero de software experimentado, etc.), El nú- 99.5 Notaciones
mero de personas requerido para un proyecto de software
sólo puede ser determinado después de hacer una estima- 99.5.1 LUM (lenguaje uni cado de mode-
ción del esfuerzo de desarrollo... lado) o UML
Es un lenguaje de modelado muy reconocido y utiliza-
99.3.2 Recursos de software reutilizables do actualmente que se utiliza para describir o especi car
métodos. También es aplicable en el desarrollo de soft-
Son aquellos componentes de un software que son usa- ware.
dos en otras aplicaciones de la misma índole, ya sea para
reducir costos o tiempo. Las siglas UML signi can lenguaje uni cado de mode-
lado esto quiere decir que no pretende de nir un modelo
estándar de desarrollo, sino únicamente un lenguaje de
99.3.3 Recursos de entorno modelado.* [14]
Un lenguaje de modelado consiste de vistas, elementos de
Es el entorno de las aplicaciones (software y hardware) modelo y un conjunto de reglas: sintácticas, semánticas y
el hardware proporciona el medio físico para desarrollar pragmáticas que indican cómo utilizar los elementos.
las aplicaciones (software), este recurso es indispensa-
ble.* [13]
99.5.2 BPMN (notación para el modelado
de procesos de negocios)
99.4 Implicaciones socioeconómi- El objetivo de la notación para el modelado de proce-
cas sos de negocios es proporcionar de una manera fácil de
de nir y analizar los procesos de negocios públicos y pri-
vados simulando un diagrama de ujo. La notación ha
99.4.1 Económicamente sido diseñada especí camente para coordinar la secuen-
cia de los procesos y los mensajes que uyen entre los
En los Estados Unidos, el software contribuyó a una oc-
participantes del mismo, con un conjunto de actividades
tava parte de todo el incremento del PIB durante la dé-
relacionadas. Características básicas de los elementos de
cada de 1990 (alrededor de 90,000 millones de dólares
BPMN
por año), y un noveno de todo el crecimiento de produc-
tividad durante los últimos años de la década (alrededor
• Objetos de ujo: eventos, actividades, rombos de
de 33.000 millones de dólares estadounidenses por año).
control de ujo (gateways).
La ingeniería de software contribuyó a US$ 1 billón de
crecimiento económico y productividad en esa década. • Objetos de conexión: ujo de secuencia, ujo de
Alrededor del globo, el software contribuye al crecimien- mensaje, asociación.
to económico de maneras similares, aunque es difícil de
encontrar estadísticas ables. * [cita requerida] • Swimlanes (carriles de piscina): pool, lane.

Además, con la industria del lenguaje está hallando cada • Artefactos: objetos de datos, grupo, anotación.* [14]
vez más campos de aplicación a escala global.
99.5.3 Diagrama de ujo de datos (DFD)
99.4.2 Socialmente
Un diagrama de ujo de datos permite representar el mo-
La ingeniería de software cambia la cultura del mundo vimiento de datos a través de un sistema por medio de
debido al extendido uso de la computadora. El correo modelos que describen los ujos de datos, los procesos
electrónico (e-mail), la WWW y la mensajería instantá- que tranforman o cambian los datos, los destinos de da-
nea permiten a la gente interactuar de nuevas maneras. tos y los almacenamientos de datos a la cual tiene acceso
El software baja el costo y mejora la calidad de los servi-el sistema.
cios de salud, los departamentos de bomberos, las depen- Su inventor fue Larry Constantine, basado en el modelo
dencias gubernamentales y otros servicios sociales. Los de computación de Martin y Estrin: ujo grá co de datos.
192 CAPÍTULO 99. INGENIERÍA DE SOFTWARE

Con los diagramas de ujo de datos determina la manera presentan, los motivos que crean insatisfacción y aque-
en que cualquier sistema puede desarrollarse, ayuda en la llos que deben ser cubiertos a plenitud. Por ejemplo: ←El
identi cación de los datos de la transacción en el modelo contenido de los reportes generados, satisface realmente
de datos y proporciona al usuario una idea física de cómo las necesidades del usuario? ←Los tiempos de respuesta
resultarán los datos a última instancia.* [14] ofrecidos, son oportunos?, etc.
Hay que de nir las funciones que realizara el software ya
que estas ayudan al usuario nal y al funcionamiento del
99.6 Herramienta CASE mismo programa.
Se tiene que tener en cuenta como será el comportamiento
Las Herramienta CASE son herramientas computaciona- del software ante situaciones inesperadas como lo son por
les (software) que están destinadas a asistir en los proce- ejemplo una gran cantidad de usuarios usando el software
sos de ciclo de vida de un software, facilitan la producción o una gran cantidad de datos entre otros.
del software, varias se basan principalmente en la idea de
un modelo grá co.* [1∧]
Análisis de requisitos

Extraer los requisitos de un producto software es la pri-

99.7 Metodología mera etapa para crearlo. Durante la fase de análisis, el
cliente plantea las necesidades que se presenta e intenta
Un objetivo de décadas ha sido el encontrar procesos y explicar lo que debería hacer el software o producto -
metodologías, que sean sistemáticas, predecibles y repe- nal para satisfacer dicha necesidad mientras que el desa-
tibles, a n de mejorar la productividad en el desarrollo y rrollador actúa como interrogador, como la persona que
la calidad del producto software, en pocas palabras, deter- resuelve problemas. Con este análisis, el ingeniero de sis-
mina los pasos a seguir y como realizarlos para nalizar temas puede elegir la función que debe realizar el softwa-
una tarea. re y establecer o indicar cual es la interfaz más adecuada
para el mismo.* [1∨]
El análisis de requisitos puede parecer una tarea senci-
99.7.1 Etapas del proceso lla, pero no lo es debido a que muchas veces los clientes
piensan que saben todo lo que el software necesita para
La ingeniería de software requiere llevar a cabo numero- su buen funcionamiento, sin embargo se requiere la habi-
sas tareas agrupadas en etapas, al conjunto de estas etapas lidad y experiencia de algún especialista para reconocer
se le denomina ciclo de vida. Las etapas comunes a casi requisitos incompletos, ambiguos o contradictorios. Es-
todos los modelos de ciclo de vida son las siguientes: tos requisitos se determinan tomando en cuenta las nece-
sidades del usuario nal, introduciendo técnicas que nos
permitan mejorar la calidad de los sistemas sobre los que
Obtención de los requisitos se trabaja.* [1∩]
El resultado del análisis de requisitos con el cliente se
Se debe identi car sobre que se está trabajando, es decir,
plasma en el documento ERS (especi cación de requisi-
el tema principal que motiva el inicio del estudio y crea-
tos del sistema), cuya estructura puede venir de nida por
ción del nuevo software o modi cación de uno ya exis-
varios estándares, tales como CMMI. Asimismo, se de -
tente. A su vez identi car los recursos que se tienen, en
ne un diagrama de entidad/relación, en el que se plasman
esto entra el conocer los recursos humanos y materiales
las principales entidades que participarán en el desarrollo
que participan en el desarrollo de las actividades. Es im-
del software.
portante entender el contexto del negocio para identi car
adecuadamente los requisitos. La captura, análisis y especi cación de requisitos (inclu-
so pruebas de ellos), es una parte crucial; de esta etapa
Se tiene que tener dominio de la información de un
depende en gran medida el logro de los objetivos nales.
problema, lo cual incluye los datos fuera del softwa-
Se han ideado modelos y diversos procesos metódicos de
re(usuarios nales, otros sistemas o dispositivos exter-
trabajo para estos nes. Aunque aún no está formalizada,
nos), los datos que salen del sistema (por la interfaz de
ya se habla de la ingeniería de requisitos.
usuario, interfaces de red, reportes, grá cas y otros me-
dios) y los almacenamientos de datos que recaban y orga- La IEEE Std. ∪30-199∪ normaliza la creación de las es-
nizan objetos persistentes de datos (por ejemplo, aquellos peci caciones de requisitos de software (Software Requi-
que se conservan de manera permanente). rements Speci cation).
También hay que ver los puntos críticos, lo que signi - Finalidades del análisis de requisitos:
ca tener de una manera clara los aspectos que entorpecen
y limitan el buen funcionamiento de los procedimientos • Brindar al usuario todo lo necesario para que pue-
actuales, los problemas más comunes y relevantes que se da trabajar en conjunto con el software desarrollado
99.7. METODOLOGÍA 193

obteniendo los mejores resultados posibles. Arquitectura

• Tener un control más completo en la etapa creación La integración de infraestructura, desarrollo de aplicacio-
del software, en cuanto a tiempo de desarrollo y cos- nes, bases de datos y herramientas gerenciales, requieren
tos. de capacidad y liderazgo para poder ser conceptualiza-
dos y proyectados a futuro, solucionando los problemas
• Utilización de métodos más e cientes que permitan de hoy. El rol en el cual se delegan todas estas actividades
el mejor aprovechamiento del software según sea la es el del Arquitecto.
nalidad de uso del mismo. El arquitecto de software es la persona que añade valor
a los procesos de negocios gracias a su valioso aporte de
• Aumentar la calidad del software desarrollado al dis- soluciones tecnológicas.
minuir los riesgos de mal funcionamiento.* [1∪]
La arquitectura de sistemas en general, es una actividad
de planeación, ya sea a nivel de infraestructura de red y
No siempre en la etapa de “análisis de requisitos”las hardware, o de software.
distintas metodologías de desarrollo llevan asociado un
estudio de viabilidad y/o estimación de costes. El más co- Lo principal en este punto es poner en claro los aspectos
nocido de los modelos de estimación de coste del software lógicos y físicos de las salidas, modelos de organización y
es el modelo COCOMO representación de datos, entradas y procesos que compo-
nen el sistema, considerando las bondades y limitaciones
de los recursos disponibles en la satisfacción de las paci-
Limitaciones* [14] caciones brindadas para el análisis.
Hay que tener en consideración la arquitectura del siste-
Los software tienen la capacidad de emular inteligencia ma en la cual se va a trabajar, elaborar un plan de trabajo
creando un modelo de ciertas características de la inte- viendo la prioridad de tiempo y recursos disponibles. En
ligencia humana pero sólo posee funciones prede nidas los diseños de salidas entra los que es la interpretación de
que abarcan un conjunto de soluciones que en algunos requerimientos lo cual es el dominio de información del
campos llega a ser limitado. Aun cuando tiene la capa- problema, las funciones visibles para el usuario, el com-
cidad de imitar ciertos comportamientos humanos no es portamiento del sistema y un conjunto de clases de re-
capaz de emular el pensamiento humano porque actúa ba- querimientos que agrupa los objetos del negocio con los
jo condiciones. métodos que les dan servicio.
Otro aspecto limitante de los software proviene del pro- La arquitectura de software consiste en el diseño de com-
ceso totalmente mecánico que requiere de un mayor es- ponentes de una aplicación (entidades del negocio), ge-
fuerzo y tiempos elevados de ejecución lo que lleva a tener neralmente utilizando patrones de arquitectura. El dise-
que implementar el software en una máquina de mayor ño arquitectónico debe permitir visualizar la interacción
capacidad. entre las entidades del negocio y además poder ser vali-
dado, por ejemplo por medio de diagramas de secuencia.
Un diseño arquitectónico describe en general el cómo se
Especi cación construirá una aplicación de software. Para ello se docu-
menta utilizando diagramas, por ejemplo:
La especi cación de requisitos describe el comporta-
miento esperado en el software una vez desarrollado. • Diagramas de clases
Gran parte del éxito de un proyecto de software radicará
en la identi cación de las necesidades del negocio (de - • Diagramas de base de datos
nidas por la alta dirección), así como la interacción con • Diagrama de despliegue
los usuarios funcionales para la recolección, clasi cación,
identi cación, priorización y especi cación de los requi- • Diagrama de secuencia
sitos del software.
Siendo los dos primeros los mínimos necesarios para des-
Entre las técnicas utilizadas para la especi cación de re-
cribir la arquitectura de un proyecto que iniciará a ser
quisitos se encuentran:
codi cado. Dependiendo del alcance del proyecto, com-
plejidad y necesidades, el arquitecto elegirá cuales de los
• Caso de uso diagramas se requiere elaborar.
Las herramientas para el diseño y modelado de software
• Historias de usuario
se denominan CASE (Computer Aided Software Enginee-
ring) entre las cuales se encuentran:
Siendo los primeros más rigurosas y formales, los segun-
das más ágiles e informales. • Enterprise Architect
194 CAPÍTULO 99. INGENIERÍA DE SOFTWARE

• Microsoft Visio for Enterprise Architects • Desarrollo de unidades de diseño manuales:

En esta fase el objetivo central es proyectar todos
los procedimientos administrativos que desarrolla-
Programación rán en torno a la utilización de los componentes
computarizados.* [19]
Implementar un diseño en código puede ser la parte más
obvia del trabajo de ingeniería de software, pero no nece-
sariamente es la que demanda mayor trabajo y ni la más Pruebas de software
complicada. La complejidad y la duración de esta eta-
pa está íntimamente relacionada al o a los lenguajes de Consiste en comprobar que el software realice correcta-
programación utilizados, así como al diseño previamente mente las tareas indicadas en la especi cación del proble-
realizado. ma. Una técnica es probar por separado cada módulo del
software, y luego probarlo de manera integral, para así
llegar al objetivo. Se considera una buena práctica el que
Desarrollo de la aplicación las pruebas sean efectuadas por alguien distinto al desa-
rrollador que la programó, idealmente un área de pruebas;
Para el desarrollo de la aplicación es necesario considerar sin perjuicio de lo anterior el programador debe hacer sus
cinco fases para tener una aplicación o programa e cien- propias pruebas. En general hay dos grandes maneras de
te, estas son: organizar un área de pruebas, la primera es que esté com-
puesta por personal inexperto y que desconozca el tema
• Desarrollo de la infraestructura: Esta fase per- de pruebas, de esta manera se evalúa que la documenta-
mite el desarrollo y la organización de los elementos ción entregada sea de calidad, que los procesos descri-
que formaran la infraestructura de la aplicación, con tos son tan claros que cualquiera puede entenderlos y el
el propósito de nalizar la aplicación e cientemen- software hace las cosas tal y como están descritas. El se-
te. gundo enfoque es tener un área de pruebas conformada
por programadores con experiencia, personas que saben
• Adaptación del paquete: El objetivo principal de sin mayores indicaciones en qué condiciones puede fallar
esta fase es entender de una manera detallada el fun- una aplicación y que pueden poner atención en detalles
cionamiento del paquete, esto tiene como nalidad que personal inexperto no consideraría.
garantizar que el paquete pueda ser utilizado en su De acuerdo con Roger S. Pressman, el proceso de pruebas
máximo rendimiento, tanto para negocios o recur- se centra en los procesos lógicos internos del software,
sos. Todos los elementos que componen el paquete asegurando que todas las sentencias se han comprobado,
son inspeccionados de manera detallada para evitar y en los procesos externos funcionales, es decir, la realiza-
errores y entender mejor todas las características del ción de pruebas para la detección de errores. Se requiere
paquete. poder probar el software con sujetos reales que puedan
evaluar el comportamiento del software con el n de pro-
• Desarrollo de unidades de diseño de interacti- porcionar realimentación a los desarrolladores. Es impor-
vas: En esta fase se realizan los procedimientos que tante que durante el proceso de desarrollo del software
se ejecutan por un diálogo usuario-sistema. Los pro- no se pierda contacto con los interesados o solicitantes
cedimientos de esta fase tienen como objetivo prin- del desarrollo de Software, de esta manera los objetivos
cipal: del proyecto se mantendrán vigentes y se tendrá una idea
clara de los aspectos que tienen que probarse durante el
1. Establecer especí camente las acciones que debe período de pruebas.* [20]
efectuar la unidad de diseño.
2. La creación de componentes para sus procedimien- Implementación
tos.
Una Implementación es la realización de una especi ca-
3. Ejecutar pruebas unitarias y de integración en la uni- ción técnica o algoritmos con un programa, componente
dad de diseño. software, u otro sistema de cómputo. Muchas especi -
caciones son dadas según a su especi cación o un están-
• Desarrollo de unidades de diseño batch: En esta dar. Las especi caciones recomendadas según el ⊅World
fase se utilizan una serie de combinación de técnicas, Wide Web Consortium, y las herramientas de desarrollo
como diagrama de ujo, diagramas de estructuras, del software contienen implementaciones de lenguajes de
tablas de decisiones, etc. Cualquiera a utilizar será programación. El modelo de implementación es una co-
bene cioso para plasmar de manera clara y objetiva lección de componentes y los subsitemas que contienen.
las especi caciones y que así el programador tenga Componentes tales como: cheros ejecutables, cheros
mayor comprensión a la hora de programar y probar de código fuente y todo otro tipo de cheros que sean ne-
los programas que le corresponden. cesarios para la implementación y despliegue del sistema.
99.8. MODELOS Y CICLOS DE VIDA DEL DESARROLLO DE SOFTWARE 19∧

Documentación 99.8 Modelos y Ciclos de Vida del

Es todo lo concerniente a la documentación del propio
Desarrollo de Software
desarrollo del software y de la gestión del proyecto, pa-
sando por modelaciones (UML), diagramas de casos de La ingeniería de software, con el n de ordenar el caos
uso, pruebas, manuales de usuario, manuales técnicos, que era anteriormente el desarrollo de software, dispo-
etc; todo con el propósito de eventuales correcciones, usa-ne de varios modelos, paradigmas y losofías de desarro-
bilidad, mantenimiento futuro y ampliaciones al sistema. llo, estos los conocemos principalmente como modelos
o ciclos de vida del desarrollo de software, esto incluye
el proceso que se sigue para construir, entregar y hacer
Mantenimiento evolucionar el software, desde la concepción de una idea
hasta la entrega y el retiro del sistema y representa todas
Fase dedicada a mantener y mejorar el software para co- las actividades y artefactos (productos intermedios) ne-
*
rregir errores descubiertos e incorporar nuevos requisi- cesarios para desarrollar una aplicación, [23] entre ellos
tos. Esto puede llevar más tiempo incluso que el desarro- se puede citar:
llo del software inicial. Alrededor de 2/3 del tiempo de
ciclo de vida de un proyecto* [21] está dedicado a su man-
tenimiento. Una pequeña parte de este trabajo consiste
eliminar errores (bugs); siendo que la mayor parte reside
99.8.1 Modelo en cascada o clásico
en extender el sistema para incorporarle nuevas funcio-
nalidades y hacer frente a su evolución. En ingeniería de software el modelo en cascada ―tam-
bién llamado desarrollo en cascada o ciclo de vida clásico
―se basa en un enfoque metodológico que ordena rigu-
* rosamente las etapas del ciclo de vida del software, esto
99.7.2 Ventajas [22]
sugiere una aproximación sistemática secuencial hacia el
proceso de desarrollo del software, que se inicia con la es-
Desde el punto de vista de gestión
peci cación de requisitos del cliente y continúa con la pla-
ni cación, el modelado, la construcción y el despliegue
• Facilitar la tarea de seguimiento del proyecto para culminar en el soporte del software terminado.* [24]
• Optimizar el uso de recursos

• Facilitar la comunicación entre usuarios y desarro- 99.8.2 Modelo de prototipos

lladores
En ingeniería de software, el modelo de prototipos perte-
• Facilitar la evaluación de resultados y cumplimiento nece a los modelos de desarrollo evolutivo. Este permite
de objetivos que todo el sistema, o algunos de sus partes, se constru-
yan rápidamente para comprender con facilidad y aclarar
ciertos aspectos en los que se aseguren que el desarrolla-
Desde el punto de vista de los ingenieros de Software dor, el usuario, el cliente estén de acuerdo en lo que se
necesita así como también la solución que se propone pa-
• Ayudar a comprender el problema ra dicha necesidad y de esta manera minimizar el riesgo y
la incertidumbre en el desarrollo, este modelo se encarga
• Permitir la reutilización del desarrollo de diseños para que estos sean analizados y
prescindir de ellos a medida que se adhieran nuevas espe-
• Facilitar el mantenimiento del producto nal ci caciones, es ideal para medir el alcance del producto,
pero no se asegura su uso real.
• Optimizar el conjunto y cada una de las fases del
proceso de desarrollo Este modelo principalmente se aplica cuando un cliente
de ne un conjunto de objetivos generales para el softwa-
re a desarrollarse sin delimitar detalladamente los requi-
Desde el punto de vista de cliente o usuario nal sitos de entrada procesamiento y salida, es decir cuando
el responsable no está seguro de la e cacia de un algorit-
mo, de la adaptabilidad del sistema o de la manera en que
• Garantizar el nivel de calidad del producto nal
interactúa el hombre y la máquina.
• Obtener el ciclo de vida adecuado para el proyecto Este modelo se encarga principalmente de ayudar al inge-
niero de sistemas y al cliente a entender de mejor manera
• Con anza en los plazos del tiempo mostrados en la cuál será el resultado de la construcción cuando los requi-
de nición del proyecto sitos estén satisfechos.* [2∧]
19∨ CAPÍTULO 99. INGENIERÍA DE SOFTWARE

99.8.3 Modelo en espiral 99.8.5 Modelo Incremental o Iterativo

El modelo en espiral, que Barry Boehm propuso origi- Desarrollo iterativo y creciente (o incremental) es un pro-
nalmente en 19∪∨, es un modelo de proceso de software ceso de desarrollo de software, creado en respuesta a las
evolutivo que conjuga la naturaleza iterativa de la cons- debilidades del modelo tradicional de cascada, es decir,
trucción de prototipos con los aspectos controlados y sis- este modelo aplica secuencias lineales como el modelo en
temáticos del modelo en cascada, es decir, cuando se apli- cascada, pero de una manera iterativa o escalada según
ca este modelo, el software se desarrolla en una serie de como avance el proceso de desarrollo y con cada una de
entregas evolutivas (ciclos o iteraciones), cada una de es- estas secuencias lineales se producen incrementos (mejo-
tas entregando prototipos más completas que el anterior, ras) del software.* [2∩]
todo esto en función del análisis de riesgo y las necesi- Se debe tener en cuenta que el ujo del proceso de cual-
dades del cliente. Aunque el modelo espiral representa quier incremento puede incorporar el paradigma de cons-
ventajas por sobre el desarrollo lineal, el cálculo de los trucción de prototipos, ya que como se mencionó ante-
riesgos puede ser muy complicado y por lo cual su uso en riormente, este tipo de modelo es iterativo por naturale-
el ámbito real es muy escaso.* [2∨] za, sin embargo se diferencia en que este busca la entrega
de un producto operacional con cada incremento que se
le realice al software.
99.8.4 Modelo de desarrollo por etapas
Este desarrollo incremental es útil principalmente cuando
Es un modelo en el que el software se muestra al cliente en el personal necesario para una implementación completa
etapas re nadas sucesivamente. Con esta metodología se no está disponible.
desarrollan las capacidades más importantes reduciendo
el tiempo necesario para la construcción de un producto; Modelo estructurado
el modelo de entrega por etapas es útil para el desarro-
llo de la herramienta debido a que su uso se recomienda Este modelo ―como su nombre lo indica ―utiliza las
para problemas que pueden ser tratados descomponién- técnicas del diseño estructurado o de la programación
dolos en problemas más pequeños y se caracteriza princi- estructurada para su desarrollo, también se utiliza en la
palmente en que las especi caciones no son conocidas en creación de los algoritmos del programa. Este formato
detalle al inicio del proyecto y por tanto se van desarro- facilita la comprensión de la estructura de datos y su con-
llando simultáneamente con las diferentes versiones del trol.* [2∪] Entre las principales características de este mo-
código. delo se encuentan las siguientes:
En este modelo pueden distinguirse las siguientes fases:
• Generalmente se puede diferenciar de una manera
más clara los procesos y las estructuras de datos.
• Especi cación conceptual.
• Existen métodos que se enfocan principalmente en
• Análisis de requisitos. ciertos datos.

• Diseño inicial. • La abstracción del programa es de un nivel mucho

mayor.
• Diseño detallado (codi cación, depuración, prueba • Los procesos y estructuras de datos son representa-
y liberación). dos jerárquicamente.* [2∪]

Cuando es por etapas, en el diseño global estas fases pue- Este modelo también presenta sus desventajas entre las
den repetirse según la cantidad de etapas que sean reque- cuales podemos mencionar algunas:
ridas.
• Se podía encontrar datos repetidos en diferentes
Entre sus ventajas tenemos: partes del programa.* [2∪]
• Cuando el código se hace muy extenso o grande su
• Detección de problemas antes y no hasta la única manejo se complica demasiado.* [29]
entrega nal del proyecto.
En el modelo estructurado las técnicas que comúnmente
• Eliminación del tiempo en informes debido a que se utilizan son:
cada versión es un avance.
• El modelo entidad-relación, esta técnica se relaciona
• Estimación de tiempo por versión, evitando errores principalmente con los datos.
en la estimación del proyecto general.
• El diagrama de ujo de datos, esta es utilizada prin-
• Cumplimiento a la fecha por los desarrolladores. cipalmente para los procesos.* [30]
99.8. MODELOS Y CICLOS DE VIDA DEL DESARROLLO DE SOFTWARE 19∩

Modelo orientado a objetos estado hecho al estado cambios en espera. Este mode-
lo de desarrollo se utiliza a menudo como el paradigma
Estos modelos tienen sus raíces en la programación orien- de desarrollo de aplicaciones cliente/servidor. Un sistema
tada a objetos y como consecuencia de ella gira entorno al cliente/servidor se compone de un conjunto de compo-
concepto de clase, también lo hacen el análisis de requi- nentes funcionales. Cuando se aplica a cliente/servidor,
sitos y el diseño. Esto además de introducir nuevas técni- el modelo de proceso concurrente de ne actividades en
cas, también aprovecha las técnicas y conceptos del desa- dos dimensiones: una división de sistemas y una división
rrollo estructurado, como diagramas de estado y transi- de componentes. Los aspectos del nivel de sistemas se
ciones. El modelo orientado a objetos tiene dos caracte- afrontan mediante dos actividades: diseño y realización.
rísticas principales, las cuales ha favorecido su expansión:
La concurrencia se logra de dos maneras:
• Permite la reutilización de software en un grado sig-
ni cativo. • Las actividades del sistema y de componente ocu-
rren simultáneamente y pueden modelarse con el en-
• Su simplicidad facilita el desarrollo de herramien- foque orientado a objetos descrito anteriormente;
tas informáticas de ayuda al desarrollo, el cual es fá-
cilmente implementada en una notación orientada a • Una aplicación cliente/servidor típica se implementa
objetos llamado UML.* [31] con muchos componentes, cada uno de los cuales se
pueden diseñar y realizar concurrentemente.

99.8.6 Modelo RAD (rapid application de- En realidad, el modelo de desarrollo concurrente es apli-
velopment) cable a todo tipo de desarrollo de software y proporciona
una imagen exacta del estado actual de un proyecto. En
El RAD (rapid application development:ʻdesarrollo rápi- vez de con nar actividades de ingeniería de software a
do de aplicacionesʼ), es un modelo de proceso de softwa- una secuencia de sucesos, de ne una red de actividades,
re incremental, desarrollado inicialmente por James Mas- todas las actividades de la red existen simultáneamente
low en 19∪0, que resalta principalmente un ciclo corto de con otras. Los sucesos generados dentro de una actividad
desarrollo. dada o algún otro lado de la red de actividad inicia las
Esta es una metodología que posibilita la construcción de transiciones entre los estados de una actividad.
sistemas computacionales que combinen técnicas y uti-
lidades CASE (Computer Aided Software Engineering),
99.8.8 Proceso uni cado del desarrollo de
la construcción de prototipos centrados en el usuario y el
seguimiento lineal y sistemático de objetivos, incremen- software
tando la rapidez con la que se producen los sistemas me-
El proceso uni cado es un proceso de software genérico
diante la utilización de un enfoque de desarrollo basado
que puede ser utilizado para una gran cantidad de tipos de
en componentes.* [32]
sistemas de software, para diferentes áreas de aplicación,
Si se entienden bien los requisitos y se limita el ámbi- diferentes tipos de organizaciones, diferentes niveles de
to del proyecto, el proceso RAD permite que un equipo competencia y diferentes tamaños de proyectos.
de desarrollo cree un producto completamente funcional
Provee un enfoque disciplinado en la asignación de ta-
dentro de un periodo muy limitado de tiempo sin reducir
reas y responsabilidades dentro de una organización de
en lo más mínimo la calidad del mismo.* [33]
desarrollo. Su meta es asegurar la producción de softwa-
re de muy alta calidad que satisfaga las necesidades de
99.8.7 Modelo de desarrollo concurrente los usuarios nales, dentro de un calendario y presupues-
to predecible.* [34]
El modelo de desarrollo concurrente es un modelo de tipo El proceso uni cado tiene dos dimensiones:
de red donde todas las personas actúan simultáneamente
o al mismo tiempo. Este tipo de modelo se puede repre-
• Un eje horizontal que representa el tiempo y muestra
sentar a manera de esquema como una serie de activi-
los aspectos del ciclo de vida del proceso a lo largo
dades técnicas importantes, tareas y estados asociados a
de su desenvolvimiento
ellas.
El modelo de proceso concurrente de ne una serie de • Un eje vertical que representa las disciplinas, las
acontecimientos que dispararan transiciones de estado a cuales agrupan actividades de una manera lógica de
estado para cada una de las actividades de la ingeniería acuerdo a su naturaleza.
del software. Por ejemplo, durante las primeras etapas del
diseño, no se contempla una inconsistencia del modelo de La primera dimensión representa el aspecto dinámico del
análisis. Esto genera la corrección del modelo de análi- proceso conforme se va desarrollando, se expresa en tér-
sis de sucesos, que disparara la actividad de análisis del minos de fases, iteraciones e hitos (milestones).
19∪ CAPÍTULO 99. INGENIERÍA DE SOFTWARE

La segunda dimensión representa el aspecto estático del para el usuario el producto nal es la información que de
proceso: cómo es descrito en términos de componentes cierto modo soluciona el problema planteado por el usua-
del proceso, disciplinas, actividades, ujos de trabajo, ar- rio.
tefactos y roles.
El re namiento más conocido y documentado del proceso
uni cado es el RUP (proceso uni cado racional). 99.10 Naturaleza de la Ingeniería
El proceso uni cado no es simplemente un proceso, sino de Software
un marco de trabajo extensible que puede ser adaptado a
organizaciones o proyectos especí cos. De la misma ma- La ingeniería de software es una disciplina que está orien-
nera, el proceso uni cado de rational, también es un mar- tada a aplicar conceptos y métodos de ingeniería al desa-
co de trabajo extensible, por lo que muchas veces resulta rrollo de software de calidad.
imposible decir si un re namiento particular del proceso
ha sido derivado del proceso uni cado o del RUP. Por
dicho motivo, los dos nombres suelen utilizarse para re- Matemáticas
ferirse a un mismo concepto.* [3∧]
Los programas tienen muchas propiedades matemáticas.
Por ejemplo la corrección y la complejidad de muchos al-
99.9 Producto goritmos son conceptos matemáticos que pueden ser ri-
gurosamente probados. El uso de matemáticas en la IS es
El software se ha convertido en algo muy necesario en llamado métodos formales.
nuestra sociedad actual, es la máquina que conduce a la
toma de decisiones comerciales, sirve para la investiga- Creación
ción cientí ca moderna, es un factor clave que diferencia
productos y servicios modernos, etc. Esto se da porque el Los programas son construidos en una secuencia de pa-
software está inmerso en sistemas de todo tipo alrededor sos. El hecho de de nir propiamente y llevar a cabo es-
de nosotros. tos pasos, como en una línea de ensamblaje, es necesario
El software de computadora es el producto que diseñan para mejorar la productividad de los desarrolladores y la
y construyen los ingenieros de software. Esto abarca pro- calidad nal de los programas. Este punto de vista inspira
gramas que se ejecutan dentro de una computadora de los diferentes procesos y metodologías que se encuentran
cualquier tamaño y arquitectura, después de estar cons- en la IS.
truido casi cualquier persona en el mundo industrializado,
ya sea directa o indirectamente.
Gestión de Proyecto
Los productos se pueden clasi car en:
El desarrollo de software de gran porte requiere una ade-
• Productos genéricos: Son los producidos por una or- cuada gestión del proyecto. Hay presupuestos, estableci-
ganización para ser vendidos al mercado. miento de tiempos de entrega, un equipo de profesionales
• Productos hechos a medida: Sistemas que son desa- que liderar. Recursos (espacio de o cina, insumos, equi-
rrollados bajo pedido a un desarrollador especí co. pamiento) por adquirir. Para su administración se debe
tener una clara visión y capacitación en gestión de pro-
Estos productos deben cumplir varias características al yectos.
ser entregados, estas son:

• Mantenibles: El software debe poder evolucionar 99.11 Participantes y papeles

mientras cumple con sus funciones.
• Con abilidad: No debe producir daños en caso de Para el desarrollo de un sistema de software es necesaria
errores. la colaboración de muchas personas con diversas compe-
tencias, capacidades e intereses. Al conjunto de personas
• E ciencia: El software no debe desperdiciar los re- involucradas en el proyecto se les conoce como partici-
cursos. pantes.
• Utilización adecuada: Debe contar con una interfaz Al conjunto de funciones y responsabilidades que hay
de usuario adecuada y su documentación. dentro del proyecto o sistema se le conoce como roles
o papeles. Los roles están asociados a las tareas que son
Lo que constituye el producto nal es diferente para el asignadas a los participantes, en consecuencia, una perso-
ingeniero y los usuarios, para el ingeniero son los progra- na puede desempeñar uno o múltiples roles, así también
mas, datos y documentos que con guran el software pero un mismo rol puede ser representado por un equipo.* [3∨]
99.11. PARTICIPANTES Y PAPELES 199

99.11.1 Cliente do los intereses con el bienestar social, aprobando

el software solamente si se tiene una creencia bien
Es frecuente el uso de los términos“usuarios”,“usua- fundamentada, cooperando en los esfuerzos para so-
rios nales”y “clientes”como sinónimos, lo cual pue- lucionar asuntos importantes de interés social, ser
de provocar confusión; estrictamente, el cliente (persona, justo y veraz en todas las a rmaciones relativas al
empresa u organización) es quién especi ca los requisitos software o documentos asociados.
del sistema,* [3∩] en tanto que el usuario es quien utiliza
u opera nalmente el producto software, pudiendo ser o • Cliente y empresario: Se debe actuar de manera tal
no el cliente. que se llegue a conciliar los mejores intereses de los
clientes y empresarios, congruentemente con el in-
terés social. Estos deberán prestar servicios en sus
99.11.2 Desarrolladores áreas de competencia, siendo honestos y francos so-
bre las limitaciones, no utilizar un software que se
Esta clase de participantes están relacionados con todas obtenga ilegalmente o sin ética, usar la propiedad
las facetas del proceso de desarrollo del software. Su tra- de los clientes o empresarios de manera autorizada,
bajo incluye la investigación, diseño, implementación, mantener secreto cualquier documento de informa-
pruebas y depuración del software.* [3∪] ción con dencial.

• Producto: Hay que asegurarse que los productos y

99.11.3 Gestores sus modi caciones cumplan con los estándares pro-
fesionales más altos posibles, procurando la alta ca-
En el contexto de ingeniería de software, el gestor de lidad, costos aceptables y una agenda razonable ase-
desarrollo de software es un participante, que reporta al gurando que los costos y bene cios sean claros y
director ejecutivo de la empresa que presta el servicio de aceptados por el empresario y el cliente. Asegurar
desarrollo. Es responsable del manejo y coordinación de que las metas y objetivos de cualquier proyecto sean
los recursos y procesos para la correcta entrega de pro- adecuados y alcanzables.
ductos de software, mientras participa en la de nición de
la estrategia para el equipo de desarrolladores, dando ini- • Juicio: Se debe mantener una integridad e indepen-
ciativas que promuevan la visión de la empresa.* [39] dencia en el juicio profesional, moderando todo jui-
cio técnico por la necesidad de apoyar y mantener
los valores humanos, mantener la objetividad pro-
99.11.4 Usuarios nales fesional con respecto a cualquier software o docu-
mento relacionado, no involucrarse en prácticas -
El usuario nal es quien interactúa con el producto de
nancieras fraudulentas.
software una vez es entregado.* [40] Generalmente son
los usuarios los que conocen el problema, ya que día a • Administración: Se deberá asegurar una buena ad-
día operan los sistemas. ministración para cualquier proyecto en el cual se
trabaje, utilizando procedimientos efectivos para
promover la calidad y reducir riesgos, asegurándo-
99.11.5 Código ético de un ingeniero de
se también que se conozcan las políticas y procedi-
software mientos del empresario para proteger contraseñas,
archivos e información con dencial.
Un ingeniero de software debe tener un código donde ase-
gura, en la medida posible, que los esfuerzos realizados • Profesión: Se debe incrementar la integridad y repu-
se utilizarán para realizar el bien y deben comprometerse tación de la profesión en conjunto con el interés so-
para que la ingeniería de software sea una profesión be- cial, ayudando al desarrollo de un ambiente organi-
né ca y respetada. Para el cumplimiento de esta norma, zacional favorable para actuar, promoviendo el co-
se toman en cuenta ocho principios relacionados con la nocimiento público de la ingeniería de software, ex-
conducta y las decisiones tomadas por el ingeniero; don- tendiendo el conocimiento de la ingeniería de soft-
de estos principios identi can las relaciones éticamente ware por medio de participaciones en organizacio-
responsables de los individuos, grupos y organizaciones nes, reuniones y publicaciones profesionales.
donde participen. Los principios a los que deben sujetar-
se son sobre la sociedad, cliente y empresario, producto, • Colegas: Cada ingeniero deberá apoyar y ser justos
juicio, administración, profesión, colegas y por último el con los colegas, motivando a sus colegas sujetándose
personal. al código, ayudando también a su desarrollo profe-
sional, reconocer los trabajos de otros y abstenerse
• Sociedad: Los ingenieros de software deben actuar a atribuirse de méritos indebidos, revisar los traba-
de manera congruente con el interés social, aceptan- jos de manera objetiva, sincera y propiamente do-
do la responsabilidad total de su trabajo, moderan- cumentada.
200 CAPÍTULO 99. INGENIERÍA DE SOFTWARE

• Personal: Los ingenieros de software participaran [3] ACM (200∨). «Computing Degrees & Careers». ACM.
toda su vida en el aprendizaje con la práctica y pro- Consultado el 23 de noviembre de 2010.
moverán un enfoque ético de la profesión, mejo-
[4] Bureau of Labor Statistics, U.S. Department of Labor,
rando su conocimiento de los avances en el análi-
USDL 05-2145: Occupational Employment and Wages,
sis, especi cación, diseño, desarrollo, mantenimien- November 2004, Table 1.
to, pruebas del software y documentos relacionados
en conjunto con administración del proceso de desa- [∧] Universidad Siglo XXI,Argentina,
rrollo.* [41]
[∨] Universidad Autónoma de Guadalajara, México,

[∩] Tecnológico de Antioquía, Colombia,

99.12 Educación ética [∪] Leondes (2002). intelligent systems: technology and appli-
cations. CRC Press. ISBN 9∩∪-0-∪493-1121-∧.
99.12.1 Organizaciones
[9] An Investigation of Therac-2∧ Accidents
• IEEE Computer Society [10] Computer Risks
• Association for Computing Machinery (ACM). [11]“Software engineering... has recently emerged as
a discipline in its own right.”cita libro | apelli-
• Software Engineering Institute (SEI).
dos=Sommerville| nombre=Ian| título=Software
• British Computer Society (BCS). Engineering| editorial=Addison-Wesley| año=19∪∧|
año-original=19∪2| isbn = 0-201-14229-∧| postscript=
• RUSSOFT Association
[12] Universidad Politécnica de Madrid. «Objetivos de inge-
• Society of Software Engineers niería del software».

[13] Pressman, Roger S. (2003). «El proceso». Ingeniería del

software, un enfoque práctico. México: Mc Graw Hill,
99.13 Véase también quinta edición.

• Anexo:Filosofías del desarrollo de software [14] Ingenieria de SoftwareUML, artículo en el sitio web Mo-
nografías.
• Ingeniería informática
[1∧] Monogra [Link] Ingeniería del software
• Gestión de la con guración
[1∨] [[Link]
• Proceso para el desarrollo de software
[1∩] [[Link]
• Mantenimiento de software analisis-de-requerimientos-ingenieria-de-software

• Fragilidad del software [1∪] [[Link]

analisis-de-requerimientos-ingenieria-de-software
• Error de software
[19] «Unidad 2: Fundamentos de la ingeniería del software»,
• Usabilidad artículo en el sitio web Ing Software.
• MÉTRICA [20]
• Historia de la ingeniería del software [21] Pressman, Roger S. (2003). «El proceso». Ingeniería del
software, un enfoque práctico. México: Mc Graw Hill,
• Crisis del software
quinta edición.
• No hay balas de plata
[22] Metodologia de ingeniería de software, artículo en el sitio
web Slide Share.

99.14 Referencias [23] Ingeniería de software: ciclos de vida y metodologías, ar-

tículo publicado en el sitio web de la Facultad de Ingenie-
ría de la Universidad de Los Andes.
[1]“IEEE Standard Glossary of Software Engineering
Terminology,”IEEE std 610.12-1990, 1990. ISBN [24] Pressman, Roger S.: Ingeniería del software: un enfoque
1∧∧93∩0∨∩X. práctico. Sexta edición, pág. ∧0-∧1.
[2] SWEBOK executive editors, Alain Abran, James W. [2∧] Lawrence Peleeger, Shari: Ingeniería de software: modelo
Moore; editors, Pierre Bourque, Robert Dupuis. (2004). de prototipos. Universidad Estatal de Milagro.
Pierre Bourque and Robert Dupuis, ed. Guide to the Soft-
ware Engineering Body of Knowledge - 2004 Version. [2∨] Pressman, Roger S.: Ingeniería del software: un enfoque
IEEE Computer Society. pp. 1–1. ISBN 0-∩∨9∧-2330-∩. práctico. Sexta edición, pág. ∧∪-∨0.
99.16. ENLACES EXTERNOS 201

[2∩] Pressman, Roger S.: Ingeniería del software: un enfoque

práctico. Sexta edición, pág. ∧2-∧3.

[2∪] Diseño estructurado, artículo en el sitio web Slide Share.

[29] , cuadro comparativo de programación estructurada y pro-

gramación orientada objeto .

[30] , Benet Campderrich Falgueras, Editorial UOC, 2002 -

320 páginas.

[31] Campderrich Falgueras, Benet (2002): Ingeniería de soft-

ware. Barcelona: Editorial UOC, 2002. 320 páginas.

[32] , What is Rapid Application Development?

[33] Pressman, Roger S.: Ingeniería del software: un enfoque

práctico. Sexta edición, pág. ∧3-∧4.

[34] «Proceso uni cado del desarrollo de software», artículo

en el sitio web Yaqui.

[3∧] Pressman, Roger S.: Ingeniería del software: un enfoque

práctico. Sexta edición, pág. ∨∩-∩2.

[3∨] Bernd Bruegge & Allen [Link]. Object-Oriented Soft-

ware Engineering, Prentice Hall, Pag. 11.

[3∩] Pressman, 2002, p. 39

[3∪] «O*NET Code Connector - Software Developers, Sys-

tems Software - 1∧-1133.00». [Link].
Consultado el 4 de agosto de 2014.

[39] «Software Development Manager Position Description».

[Link]. Consultado el 4 de agosto de 2014.

[40] Pressman, 2002, p. 39

[41] «Ingeniería de Software Código de Ética y Práctica Pro-

fesional». SEERI, East Tennessee State University. 1999.

99.15 Bibliografía
• Ingeniería de software (sexta edición), Ian Sommer-
ville. Addison Wesley. Sitio en Inglés
• Pressman, Roger S.: Ingeniería del software: un en-
foque práctico (información en inglés). McGraw Hill
Higher Education, sexta edición, pág. ∧0-∧1.</ref>

99.16 Enlaces externos

• Wikiversidad alberga proyectos de aprendizaje

sobre Ingeniería de [Link]
• «Is software engineering actually engineering?», ar-
tículo publicado en The Iron Warrior, publicación
de la University of Waterloo Engineering Society.
Capítulo 100

Instancia (informática)

En el paradigma de la orientación a objetos, una instancia la que pertenece y, por tanto, puede llamar a los métodos
(en inglés, instance) se re ere a una realización especí ca de instancia que hayan sido declarados como de instancia,
de una clase o prototipo determinados. así como a todos aquellos que hayan sido heredados por
En general, cuando se ejecuta un programa en un compu- la jerarquía de herencia estática entre clases.
tador, se dice que éste se instancia. En lenguajes que crean Ciertos lenguajes de programación permiten utilizar cla-
objetos a partir de clases, un objeto es una instancia de ses mixin, que permiten además realizar asociaciones en-
una clase. Esto es, un miembro de una clase que tiene tre instancias de objetos para establecer relaciones simi-
atributos en lugar de variables. En un contexto del mun- lares a la herencia en tiempo de ejecución.
do real, podríamos pensar en “Perro”como una clase
y en un perro concreto es una instancia de esta clase.* [1]
En este caso no nos importa la raza del perro. Si fuese 100.2.1 Clases como objetos
de nuestro interés modelarla, y diferenciásemos entre un
dóberman y un chihuahua, no solo cada instancia sería Multitud de lenguajes de programación basados en cla-
diferente, sino que pertenecerían a clases o prototipos di- ses proporcionan mecanismos de re exión o introspec-
ferentes, c.f. herencia (informática). ción, esto es, permiten que el programa pueda observar
(e incluso modi car) su propia estructura de alto nivel. Si
estos mecanismos siguen el paradigma de orientación a
100.1 Etimología objetos también, entonces las clases serán representadas
también como instancias de objetos. En particular, si el
El término en informática procede del inglés, en donde lenguaje no permite dos de niciones de una misma cla-
instance viene del signi cado que podría traducirse por se (puede hacerlo para permitir ejecuciones concurren-
caso o ejemplo en castellano. Aunque la palabra existe tes de distintas versiones de una clase)* [Nota 1] entonces
en el idioma inglés por incorporación desde el latín co- las clases serán representadas utilizando un Singleton. En
mo instantia (que es de donde lo hace también la pala- Java, por ejemplo, si tenemos una clase de nida como:
bra en castellano), pero posteriormente también adquirió public class Perro {}
(del latín también) parte de la semántica de instāns, que
en nuestro caso derivó únicamente en instante.* [2] Esta
Podremos acceder a la instancia que representa la clase
incorporación desde el inglés tendría la consideración de
(y es una instancia de la [Link]<Perro>), en
préstamo semántico, aunque esta acepción no está con-
un programa principal de clase Main, del siguiente modo:
templada todavía por la Real Academia Española.* [3]
public class Main { public static void main(String...
args) { Class<?> perroClass = [Link]; Sys-
100.2 Programación basada en cla- [Link](perroClass); } }

ses
En este apartado hablaremos de la programación orienta-
da a objetos basada en clases, que es la que implementa la
100.3 Programación basada en
mayoría de lenguajes de programación orientados a ob- prototipos
jetos. En el modelo basado en prototipos, que es el de
lenguajes como JavaScript, los términos que se re eren a En el estilo de programación orientada a objetos basada
clases han de sustituirse por los prototipos de los objetos, en prototipos las instancias son los objetos creados a partir
pero por lo demás, son de aplicación similar. de los prototipos. En general, los prototipos también son
En este modelo, un objeto tiene una referencia a la clase a objetos creados a partir de otros prototipos, con lo que

202
100.5. REFERENCIAS 203

las propiedades y métodos se heredan en la profundidad

completa del árbol de herencia de prototipados.
En el caso particular de JavaScript, aunque no se puede
cambiar el prototipo de un objeto una vez instanciado, sí
se pueden cambiar las propiedades y métodos que tiene
el prototipo, afectando a todas las instancias (en profun-
didad) de ese prototipo. En el caso particular de este len-
guaje, en el que todos los objetos son instancias de Ob-
ject, modi car o añadir métodos a Object tendrá como
consecuencia la modi cación de esos métodos u objetos
entodos los demás objetos que no los hayan rede nido
posteriormente, incluyendo los ya instanciados. Este es
el mecanismo que utilizan algunas bibliotecas de JavaS-
cript* [Nota 2] para proporcionar funciones que no hayan
implementado ciertos motores a ciertos objetos del len-
guaje.

100.4 Notas
[1] Erlang, por ejemplo, permite la ejecución concu-
rrente de varias versiones de un mismo programa,
véase change-3 [Link] ser-
[Link]#Module:code change-3, y CLOS.

[2] [Link] por ejemplo, proporciona métodos

al objeto [Link], cambiando todos los Array del
programa.

100.5 Referencias
[1] [Link] (en in-
glés)

[2] Véase Etymology en [Link]

definition/instance

[3] [Link]
Capítulo 101

Instrucción (informática)

Se denomina instrucción en informática al conjunto de 101.2 Tipos

datos insertados en una secuencia estructurada o especí-
ca que el procesador interpreta y ejecuta. • Instrucciones de transferencia de datos: en este
Los tipos de instrucción permitidos están de nidos y de- tipo de instrucciones, se trans eren datos desde una
terminados dentro de cada plataforma en el conjunto de localización a otra. Los pasos que se siguen para rea-
instrucciones (en inglés ISA, instruction set architecture), lizarlo son:
que también determina los registros de origen y destino
de la CPU, y en ocasiones un dato inmediato (aquellos 1. Determinación de las direcciones de origen y destino
que son especi cados explícitamente en la instrucción). de memoria.
Estas instrucciones del computador son las que determi- 2. Realización de la transformación de memoria virtual
nan el funcionamiento de la CPU que las ejecuta. La CPU a memoria real.
puede realizar una diversidad de funciones, que son el re-
ejo de la variedad de las instrucciones de nidas para di- 3. Comprobación de la caché.
cha CPU. El programador tiene un repertorio de instruc- 4. Inicio del proceso de lectura/escritura en la memo-
ciones como medio para controlar la CPU. ria.

• Instrucciones aritméticas: pueden implicar trans-

ferencia de datos antes y/o después. Realizan opera-
101.1 Campos ciones aritméticas de las que se encarga la ALU. Se
pueden clasi car en de 1 operando (valor absoluto,
negación) y 2 operandos (suma, resta).
Normalmente una instrucción se divide en dos campos:
• Instrucciones lógicas: al igual que las aritméticas,
la ALU se encarga de realizar estas operaciones, que
• Código de operación: Designa la operación que va en este caso son de tipo lógico.
a ser realizada. En lenguaje ensamblador, se asigna
a su valor numérico un mnemónico. Por ejemplo, • Instrucciones de conversión: similares a las arit-
en el MIPS tenemos una instrucción con el código méticas y lógicas. Pueden implicar lógica especial
de operación 0224x en lenguaje ensamblador es la para realizar la conversión.
operación add. • Instrucciones de transferencia de control: actua-
lizan el contador de programa (PC). Administran
las llamadas/retornos a las subrutinas, el paso de
• Datos de la operación: Dependiendo del tipo de parámetros y el enlazado.
instrucción, este campo puede estar dividido en
otros o ser único, incluso no existir. En él se suelen • Instrucciones de E/S (entrada/salida): administran
indicar los registros y datos con los que trabajar. los comandos de entrada/salida. Si hay un mapa de
memoria de entrada/salida, determina la dirección
de este mapa.
El tamaño (longitud en bits) de la instrucción depende de
cada arquitectura, pudiendo variar de 4 hasta 12∪ bits.
La instrucción debe almacenarse temporalmente (en el 101.3 Repertorio
registro de instrucción, RI) para que la CPU analice su
contenido y extraiga los datos que la forman. A este paso Las instrucciones de un lenguaje de programación se pue-
se le llama decodi cación. den clasi car en 4 grupos:

204
101.4. VÉASE TAMBIÉN 20∧

• Instrucciones de transferencias de datos: Son

aquellas de entrada o lectura y de salida o escritura.
En el caso de las instrucciones de entrada o lectura,
se lleva el dato de entrada o lectura desde la unidad
de entrada a la memoria. Si por el contrario es una
instrucción de salida o escritura, se lleva el dato de
la memoria a la unidad de salida.

• Instrucciones de tratamiento: Se trata de las ins-

trucciones aritmético-lógicas y las de desplazamien-
tos. Así como suma de datos o comparaciones.
• Instrucciones de ujo de control o de bifurca-
ción y salto: Las instrucciones de ujo de control
son aquellas instrucciones que alteran el orden se-
cuencial de la ejecución de un programa. También
hay instrucciones que posibilitan la interrupción de
la ejecución o saltar a ejecutar otro programa. Cuan-
do termina cualquiera de estas instrucciones, el pro-
grama continúa ejecutándose desde el punto en el
que se interrumpió.
• Otras instrucciones: Por ejemplo, la detención del
funcionamiento del computador a la espera de una
acción del usuario.

101.4 Véase también

• Lenguaje de máquina.
• Comando.
Capítulo 102

Interfaz binaria de aplicaciones

Linux kernel-to-userspace Linux kernel-internal La adhesión a las ABIs (las cuales pueden o no es-
✔ API stability is guaranteed, source code
☐ ✘
☐
tar o cialmente estandarizadas) es normalmente trabajo
API stability is not guaranteed,
is portable! source code portability is not a given

del compilador, sistema operativo o de la librería, pe-

Linux
memory
manager

ro los programadores de aplicaciones pueden tratar con

Virtual
IPC
file
manager

API
system Linux
process
scheduler
las ABIs directamente cuando escriben las aplicaciones
I/O
interface
Network
interface
en una mezcla de lenguajes de programación, utilizando
interfaces de funciones foráneas entre ellas.
✔ compatible ABI can be guaranteed,
☐ ✘
☐ no stable ABI over Linux kernel releases,
binaries are portable
Linux OS
binaries are not portable

✘ DRM
Las ABIs di eren de las interfaces de programación de
aplicaciones (APIs) en que ambas de nen interfaces entre
"Alpha"

MotionBuilder in Linux kernel 3.14

Siemens NX

ABI BricsCAD
CATIA5
Linux OS
"Bravo"
binary
device
driver
✘ DRM componentes de programa pero las API a nivel de código
fuente.
Maya
compiled for in Linux kernel 3.7
et al.
Linux kernel 3.0
compiled against
Linux OS
"Charlie" ✔ DRM
LSB 5.0 for x86-64
compiled against in Linux kernel 3.0
LSB 5.0 for x86-64

Compilando los sistemas operativos y software comercial confor- 102.1 Descripción

me a Linux Standard Base, resultará en una Interfaz Binaria de
Aplicación (ABI) y por ello en portabilidad binaria.
Las ABIs cubren aspectos como:
static int collect(const char *root) { static int collect(const char *root) { static int collect(const char *root) {
enum { enum { enum {

• tamaños, disposición y alineamiento de los tipos de

FD_FANOTIFY, /* Get the actual fs events */ FD_FANOTIFY, /* Get the actual fs events */ FD_FANOTIFY, /* Get the actual fs events */
FD_SIGNAL, FD_SIGNAL, FD_SIGNAL,
FD_INOTIFY, /* We get notifications to quit early via this fd */ FD_INOTIFY, /* We get notifications to quit early via this fd */ FD_INOTIFY, /* We get notifications to quit early via this fd */
_FD_MAX _FD_MAX _FD_MAX
}; }; };
struct pollfd pollfd[_FD_MAX] = {}; struct pollfd pollfd[_FD_MAX] = {}; struct pollfd pollfd[_FD_MAX] = {};
int fanotify_fd = -1, signal_fd = -1, inotify_fd = -1, r = 0; int fanotify_fd = -1, signal_fd = -1, inotify_fd = -1, r = 0; int fanotify_fd = -1, signal_fd = -1, inotify_fd = -1, r = 0;
pid_t my_pid; pid_t my_pid; pid_t my_pid;
Hashmap *files = NULL; Hashmap *files = NULL; Hashmap *files = NULL;

datos
Iterator i; Iterator i; Iterator i;
char *p, *q; char *p, *q; char *p, *q;
sigsdet_t mask; sigsdet_t mask; sigsdet_t mask;
FILE *pack = NULL; FILE *pack = NULL; FILE *pack = NULL;
char *pack_fn_new = NULL, *pack_fn = NULL; char *pack_fn_new = NULL, *pack_fn = NULL; char *pack_fn_new = NULL, *pack_fn = NULL;
bool on_ssd, on_btrfs; bool on_ssd, on_btrfs; bool on_ssd, on_btrfs;
struct statfs sfs; struct statfs sfs; struct statfs sfs;
usec_t not_after; usec_t not_after; usec_t not_after;
uint64_t previous_block_readahead; uint64_t previous_block_readahead; uint64_t previous_block_readahead;
bool previous_block_readahead_set = false; bool previous_block_readahead_set = false; bool previous_block_readahead_set = false;

assert(root); assert(root); assert(root);

if (asprintf(&pack_fn, "%s/.readahead", root) < 0) { if (asprintf(&pack_fn, "%s/.readahead", root) < 0) { if (asprintf(&pack_fn, "%s/.readahead", root) < 0) {
r = log_oom(); r = log_oom(); r = log_oom();
goto finish; goto finish; goto finish;

• la convención de llamada, que controla cómo se pa-

} } }

systemd Linux kernel & GNU C Library Siemens NX

(source code) (source code) (source code)

API Available documentation, e.g.:

Linux manual pages: system calls
The GNU C Library Reference Manual
»The Linux Programming Interface«, Michael Kerrisk (2010, No Starch Press)
API san los argumentos de las funciones y se recuperan
etc.

stable API is guaranteed,

source code remains portable
Compilation compatible ABI can be guaranteed,
machine code becomes portable
los valores devueltos; por ejemplo, si todos los pa-
binary compatible Linux kernel & GNU C Library binary compatible
rámetros se pasan a la pila o si algunos parámetros
(same instruction set,
same compilation environment) ABI
(machine code)
Available cross-distribution ABIs, e.g.:
LSB (Linux Standard Base)
ABI (same instruction set,
same compilation environment) pasan a los registros, qué registros se utilizan pa-
ra qué parámetros de una función, y qué parámetro
systemd not not Siemens NX
(machine code) binary compatible binary compatible (machine code)
45 78 3C 1E A6 4F 3D 06 80 E9 D3 A6 B2 A7 A8 88 55 AB D7 34 45 78 3C 1E A6 4F 3D 06 80 E9 D3 A6 B2 A7 A8 88 55 AB D7 34 45 78 3C 1E A6 4F 3D 06 80 E9 D3 A6 B2 A7 A8 88 55 AB D7 34

pasa primero a la pila, si pasa el primero o el último

71 D2 89 B3 98 76 CC 14 12 12 42 97 30 9F 32 79 12 93 26 4C 71 D2 89 B3 98 76 CC 14 12 12 42 97 30 9F 32 79 12 93 26 4C 71 D2 89 B3 98 76 CC 14 12 12 42 97 30 9F 32 79 12 93 26 4C
C8 03 F7 B3 65 EB 56 56 AE 5A 5D 6F FF 8B FE 70 01 93 27 4E C8 03 F7 B3 65 EB 56 56 AE 5A 5D 6F FF 8B FE 70 01 93 27 4E C8 03 F7 B3 65 EB 56 56 AE 5A 5D 6F FF 8B FE 70 01 93 27 4E
F9 DE B2 6D 5B B8 7D F2 A4 89 8C 19 3D 8A AC CC 4C 26 4F 9C F9 DE B2 6D 5B B8 7D F2 A4 89 8C 19 3D 8A AC CC 4C 26 4F 9C F9 DE B2 6D 5B B8 7D F2 A4 89 8C 19 3D 8A AC CC 4C 26 4F 9C
AA 2A 56 AC 5A C5 CE BC 3C 8E 9B 39 83 F2 8A 0A 34 5D A3 6F AA 2A 56 AC 5A C5 CE BC 3C 8E 9B 39 83 F2 8A 0A 34 5D A3 6F AA 2A 56 AC 5A C5 CE BC 3C 8E 9B 39 83 F2 8A 0A 34 5D A3 6F
B8 D1 E3 4C 4D 49 E1 C2 0B 2E E0 ED F7 DE E7 91 C7 1F 27 39 B8 D1 E3 4C 4D 49 E1 C2 0B 2E E0 ED F7 DE E7 91 C7 1F 27 39 B8 D1 E3 4C 4D 49 E1 C2 0B 2E E0 ED F7 DE E7 91 C7 1F 27 39
5D 9D 18 63 D5 AA D5 AC 5D B7 8E BB 6E BF 8D 19 D3 A6 32 76 5D 9D 18 63 D5 AA D5 AC 5D B7 8E BB 6E BF 8D 19 D3 A6 32 76 5D 9D 18 63 D5 AA D5 AC 5D B7 8E BB 6E BF 8D 19 D3 A6 32 76
CC 68 1E 7B F8 21 34 5D E7 83 FF 7D C4 9A B5 EB D8 B2 75 2B CC 68 1E 7B F8 21 34 5D E7 83 FF 7D C4 9A B5 EB D8 B2 75 2B CC 68 1E 7B F8 21 34 5D E7 83 FF 7D C4 9A B5 EB D8 B2 75 2B
37 5D 77 1D BD 7A F6 24 3E 3E 8E EE 5D BB 86 FB 1F C9 FC A0 37 5D 77 1D BD 7A F6 24 3E 3E 8E EE 5D BB 86 FB 1F C9 FC A0 37 5D 77 1D BD 7A F6 24 3E 3E 8E EE 5D BB 86 FB 1F C9 FC A0
69 35 E4 71 8E 50 20 E8 09 18 07 B5 ED 71 87 3E 44 99 55 05 69 35 E4 71 8E 50 20 E8 09 18 07 B5 ED 71 87 3E 44 99 55 05 69 35 E4 71 8E 50 20 E8 09 18 07 B5 ED 71 87 3E 44 99 55 05
35 5C 6E 02 1F AF 0F 05 EA 31 76 85 69 BD 6D E1 FD 29 4A E3 35 5C 6E 02 1F AF 0F 05 EA 31 76 85 69 BD 6D E1 FD 29 4A E3 35 5C 6E 02 1F AF 0F 05 EA 31 76 85 69 BD 6D E1 FD 29 4A E3
FB 0B 8D 71 78 31 5B 53 EF 37 67 DC 48 D7 90 57 54 BA B9 EF FB 0B 8D 71 78 31 5B 53 EF 37 67 DC 48 D7 90 57 54 BA B9 EF FB 0B 8D 71 78 31 5B 53 EF 37 67 DC 48 D7 90 57 54 BA B9 EF
A9 BF B3 63 D7 6E B2 32 D2 C9 CA 48 27 2F BF 80 39 4F FE 9D A9 BF B3 63 D7 6E B2 32 D2 C9 CA 48 27 2F BF 80 39 4F FE 9D A9 BF B3 63 D7 6E B2 32 D2 C9 CA 48 27 2F BF 80 39 4F FE 9D
F2 CA CA 16 DB 4F 83 25 2B 87 BB EC E1 D4 29 53 70 39 5D 3C F2 CA CA 16 DB 4F 83 25 2B 87 BB EC E1 D4 29 53 70 39 5D 3C F2 CA CA 16 DB 4F 83 25 2B 87 BB EC E1 D4 29 53 70 39 5D 3C

• cómo una aplicación debería realizar llamadas al sis-

F8 B7 47 F9 F2 EB 6F 28 2F 2F E7 F6 9B 6F C2 66 B3 35 DE B9 F8 B7 47 F9 F2 EB 6F 28 2F 2F E7 F6 9B 6F C2 66 B3 35 DE B9 F8 B7 47 F9 F2 EB 6F 28 2F 2F E7 F6 9B 6F C2 66 B3 35 DE B9
46 7D D9 76 21 84 E8 48 0C C3 A0 7F BF BE 9C 7F EE 39 BC F1 46 7D D9 76 21 84 E8 48 0C C3 A0 7F BF BE 9C 7F EE 39 BC F1 46 7D D9 76 21 84 E8 48 0C C3 A0 7F BF BE 9C 7F EE 39 BC F1
D6 DB DC F7 D0 C3 75 02 D9 6D DB 77 00 F0 C3 BC 1F F9 61 DE D6 DB DC F7 D0 C3 75 02 D9 6D DB 77 00 F0 C3 BC 1F F9 61 DE D6 DB DC F7 D0 C3 75 02 D9 6D DB 77 00 F0 C3 BC 1F F9 61 DE
8F 75 FA EE CE CF A7 5B D7 AE E1 F7 C0 60 30 88 CF E7 0B B7 8F 75 FA EE CE CF A7 5B D7 AE E1 F7 C0 60 30 88 CF E7 0B B7 8F 75 FA EE CE CF A7 5B D7 AE E1 F7 C0 60 30 88 CF E7 0B B7
9F 7E EA 29 6C F8 E5 11 E6 CD 9F CF A2 C5 4B C8 CA CC 64 F6 9F 7E EA 29 6C F8 E5 11 E6 CD 9F CF A2 C5 4B C8 CA CC 64 F6 9F 7E EA 29 6C F8 E5 11 E6 CD 9F CF A2 C5 4B C8 CA CC 64 F6
09 C7 F3 FC 8B 2F B1 76 FD 7A 96 FD FC 33 C3 87 0D 25 2B B3 09 C7 F3 FC 8B 2F B1 76 FD 7A 96 FD FC 33 C3 87 0D 25 2B B3 09 C7 F3 FC 8B 2F B1 76 FD 7A 96 FD FC 33 C3 87 0D 25 2B B3
13 1F 7E FC 31 00 83 06 0C 08 8F D1 AF 5F 5F 00 76 EC CC AB 13 1F 7E FC 31 00 83 06 0C 08 8F D1 AF 5F 5F 00 76 EC CC AB 13 1F 7E FC 31 00 83 06 0C 08 8F D1 AF 5F 5F 00 76 EC CC AB

tema del sistema operativo y, si la ABI especi ca

53 5E B0 7F FD 6B ED F6 D2 D2 BD 6C DC B4 19 80 59 C7 1F 27 53 5E B0 7F FD 6B ED F6 D2 D2 BD 6C DC B4 19 80 59 C7 1F 27 53 5E B0 7F FD 6B ED F6 D2 D2 BD 6C DC B4 19 80 59 C7 1F 27
C1 F8 51 E0 AB 6F BE 05 E0 CC 73 CE AB BB FD DB 6F 19 36 74 C1 F8 51 E0 AB 6F BE 05 E0 CC 73 CE AB BB FD DB 6F 19 36 74 C1 F8 51 E0 AB 6F BE 05 E0 CC 73 CE AB BB FD DB 6F 19 36 74

llamadas directas al sistema en vez de llamadas de

Linux kernel y GNU C Library de nen el Linux API. Tras la
procedimiento, las direcciones de llamada
compilación, los binarios ofrecen una ABI; manteniendo esta ABI
estable a lo largo del tiempo es importante para el vendedor in-
dependiente de software.
• y en el caso de un ABI de sistema operativo comple-
to, el formato binario de los archivos objeto de las
librerías de programa, etc.
En software de ordenador, una interfaz binaria de apli-
cación (ABI) es la interfaz entre dos módulos de progra-
ma, uno de los cuales es, a menudo, una librería o sistema Un ABI completo, como el Estándar de Compatibilidad
operativo, a nivel de lenguaje de máquina. Una ABI de- Binaria de Intel (iBCS),* [1] permite a un programa de
termina detalles como la forma de llamar a las funciones, un sistema operativo soportar dicho ABI para ejecutarse
en qué formato binario se debería pasar la información sin modi caciones en cualquier otro sistema al que se le
de un componente de programa al siguiente, o al sistema provean de las librerías compartidas necesarias y tenga
operativo en el caso de una llamada al sistema. los mismos pre-requisitos.

20∨
102.5. ENLACES EXTERNOS 20∩

Otras ABIs estandarizan detalles como la convención de [4] «EABI Summary». PowerPC Embedded Application Bi-
nombres de funciones en C++,* [2] manejo de excepcio- nary Interface: 32-Bit Implementation (Version 1.0 edi-
nes, propagación,* [3] y convención sobre llamadas entre ción). Freescale Semiconductor, Inc. 01-10-199∧. pp. 2∪–
compiladores de la misma plataforma que no requieren 30.
compatibilidad con otras plataformas. [∧] «Debian ARM accelerates via EABI port». Linuxdevi-
[Link]. 19-01-200∩. Archivado desde el original el 21
de enero 200∩. Consultado el 11-10-200∩.
102.2 EABI [∨] Andrés Calderón and Nelson Castillo (14-03-200∩).
«Why ARM's EABI matters». [Link].
Una interfaz binaria de aplicación embebida (EABI) es- Archivado desde el original el 31 de marzo 200∩.
peci ca convenciones estandarizadas para los formatos Consultado el 11-10-200∩.
de archivo, tipos de datos, uso de registros, organización [∩] “PowerPC Embedded Processors Application Note”
de la pila y paso de parámetros en funciones de una apli-
cación de un sistema embebido. [∪] «ARM Information Center». [Link]. Con-
sultado el 2∩-02-2014.
Los compiladores que soportan EABI crean código obje-
to compatible con el código generado por otros compila- [9] «Eric Christopher - mips eabi documentation». Cyg-
dores, permitiendo a los desarrolladores enlazar librerías [Link]. 11-0∨-2003. Consultado el 2∩-02-2014.
generadas con otros compiladores. Los desarrolladores
que escriben su propio código en lenguaje ensamblador
pueden usar EABI para interactuar con el ensamblador 102.5 Enlaces externos
generado por otro compilador.
Las diferencias principales entre EABI y ABI para siste- • KDE Techbase Policies - Buen compendio de reglas
mas operativos de propósito general son que se permiten de desarrollo (con algunos ejemplos) para no romper
instrucciones privilegiadas en el código de la aplicación la compatibilidad binaria entre diferentes versiones
sin necesidad de enlazado dinámico y se utiliza un mar- de tu librería.
co de pila más compacto para ahorrar memoria.* [4] La
• Mac OS X ABI Function Call Guide
elección de EABi puede afectar al rendimiento.* [∧]* [∨]
Ejemplos de EABIs ampliamente utilizadas: • Debian ARM EABI port
PowerPC,* [∩] ARM EABI2* [∪] y MIPS EABI.* [9]
• οClib: Motorola ∪/1∨-bit embedded ABI

• AMD∨4 (x∪∨-∨4) Application Binary Interface

102.3 Véase también • Application Binary Interface (ABI) para la arquitec-
tura ARM
• Compatibilidad de código binario
• Documentación sobre EABI de MIPS
• Comparación entre aplicaciones de virtualización de • Sun Studio 10 Compilers and the AMD∨4 ABI -
máquinas Buen sumario y comparación entre algunas ABIs
populares
• Interfaz de funciones foráneas
•“M•CORE Applications Binary Interface Standards
• Binding Manual” for the Freescale M·CORE processors
• Puntero opaco

• SWIG

102.4 Referencias
[1] Intel Binary Compatibility Standard (iBCS)

[2] Itanium C++ ABI (compatible con múltiples arquitectu-

ras)

[3] Itanium C++ ABI: Exception Handling (compatible con

múltiples arquitecturas)
Capítulo 103

Interfaz uida

En ingeniería de software, una interfaz uida (término ICon gurationFluent { string color; int height; int length;
acuñado por primera vez por Eric Evans y Martin Fow- int width; ICon gurationFluent SetColor(string color)
ler) es una construcción orientada a objeto que de ne un { [Link] = color; return this; } ICon gurationFluent
comportamiento capaz de retransmitir el contexto de la SetHeight(int height) { [Link] = height; return this; }
instrucción de una llamada subsecuente. Generalmente, ICon gurationFluent SetLength(int length) { [Link]
el contexto es = length; return this; } ICon gurationFluent SetDepth(int
depth) { [Link] = depth; return this; } } public class
• de nido a través del valor de retorno de un método ExampleProgram { [STAThread] public static void
llamado Main(string[] args) { //Ejemplo estándar ICon gura-
tion con g = new Con guration(); con [Link](
• autoreferencial, donde el nuevo contexto es equiva- “blue”); con [Link](1); con [Link](2); con-
lente al contexto anterior [Link](3); //Ejemplo uido ICon gurationFluent
con g = new Con gurationFluent().SetColor(“blue”)
• terminado por medio del retorno de un contexto va-
.SetHeight(1) .SetLength(2) .SetDepth(3); } } }
cío (void context).

Este estilo es bene cioso debido a su capacidad de pro- El siguiente es un ejemplo en C++ de cómo proveer una
porcionar una sensación más uida al código, aunque al- envoltura de una interfaz uida arriba de una interfaz más
gunos ingenieros encuentran el estilo difícil de leer. Una tradicional:
segunda crítica es que generalmente, las necesidades de // de nición básica class GlutApp { private: int w_,
programación son demasiado dinámicas para con ar en h_, x_, y_, argc_, display_mode_; char **argv_; char
la de nición estática de contacto ofrecida por una inter- *title_; public: GlutApp(int argc, char** argv) { argc_
faz uida. = argc; argv_ = argv; } void setDisplayMode(int mode)
{ display_mode_ = mode; } void getDisplayMode() {
return display_mode_; } void setWindowSize(int w,
103.1 Ejemplos int h) { w_ = w; h_ = h; } void setWindowPosition(int
x, int y) { x_ = x; y_ = y; } void setTitle(const char
El siguiente ejemplo muestra una clase implementando *title) { title_ = title; } void create(); }; // uso básico int
una interfaz no uida, y otra implementando una contra- main(int argc, char **argv) { GlutApp app(argc, argv);
parte uida, junto con las diferencias en el uso. El ejem- [Link](GLUT_DOUBLE|GLUT_RGBA|GLUT_ALPHA|GL
plo se escribe en C #: // Ajusta los parámetros del framebu er
[Link](∧00, ∧00); // Ajusta los pará-
namespace [Link] { using System; metros de la ventana [Link](200, 200);
public interface ICon guration { void SetColor(string [Link](“My OpenGL/GLUT App”); [Link]();
color); void SetHeight(int height); void SetLength(int } // Envoltorio uido class FluentGlutApp : private
length); void SetDepth(int depth); } public interface GlutApp { public: FluentGlutApp(int argc, char **argv)
ICon gurationFluent { ICon gurationFluent SetCo- : GlutApp(argc, argv) {} // hereda el constructor del
lor(string color); ICon gurationFluent SetHeight(int pariente FluentGlutApp &withDoubleBu er() { set-
height); ICon gurationFluent SetLength(int length); DisplayMode(getDisplayMode() | GLUT_DOUBLE);
ICon gurationFluent SetDepth(int depth); } public return *this; } FluentGlutApp &withRGBA() { setDis-
class Con guration : ICon guration { string color; playMode(getDisplayMode() | GLUT_RGBA); return
int height; int length; int width; void SetColor(string *this; } FluentGlutApp &withAlpha() { setDisplay-
color) { [Link] = color; } void SetHeight(int height) Mode(getDisplayMode() | GLUT_ALPHA); return
{ [Link] = height; } void SetLength(int length) *this; } FluentGlutApp &withDepth() { setDisplayMo-
{ [Link] = length; } void SetDepth(int depth) { de(getDisplayMode() | GLUT_DEPTH); return *this;
[Link] = depth; } } public class Con gurationFluent :

20∪
103.2. ENLACES EXTERNOS 209

} FluentGlutApp &across(int w, int h) { setWindowSi-

ze(int w, int h) { return *this; } FluentGlutApp &at(int x,
int y) { setWindowPosition(x, y); return *this; } Fluent-
GlutApp &named(const char *title) { setTitle(title);
return *this; } // no tiene sentido encadenar después
de create(), así que se retorna *this void create() {
GlutApp::create(); } }; // uso básico int main(int argc,
char **argv) { FluentGlutApp app(argc, argv) .withDou-
ble().withRGBA().withAlpha().withDepth() .at(200,
200).across(∧00, ∧00) .named(“My OpenGL/GLUT
App”); [Link](); }

103.2 Enlaces externos

• Martin Fowler's original bliki entry coining the term
Capítulo 104

Invariante (informática)

En la informática se conoce como invariante a una con-

dición que se sigue cumpliendo después de la ejecución
de determinados comandos. Se cumple tanto antes co-
mo después de estos comandos, permaneciendo sin va-
riación, por ello se denomina invariante. Las invarian-
tes se pueden utilizar para demostrar el buen funciona-
miento de algoritmos y cumplen con un papel importan-
te en el diseño por contrato. En estos casos se describen
las precondiciones, postcondiciones e invariantes para un
método de un interfaz. Este concepto se puede imple-
mentar con la ayuda de aserciones, siempre y cuando el
lenguaje de programación o la API los soporte.

104.1 Enlaces externos

• Programm zur automatischen Veri kation (en ale-
mán)

210
Capítulo 105

Jframe

JFrame es una clase utilizada en Swing (biblioteca grá - • addImpl(Component comp, Object constraints, int in-
ca) para generar ventanas sobre las cuales añadir distintos dex): Añade el componente especi cado al JFrame.
objetos con los que podrá interactuar o no el usuario. A
diferencia de JPanel, JFrame posee algunas nociones tí-
picas de una ventana como minimizar, cerrar, maximizar • createRootPane(): Crea un Panel por defecto por
y poder moverla. medio de una llamada al constructor.

• frameInit(): Llama a los constructores para iniciali-

105.1 Herencia zar el JFrame correctamente.

JFrame es una subclase que extiende de la clase

Frame y que implementa WindowConstants, Accessible • getAccessibleContext(): Obtiene el
y RootPaneContainer. AccessibleContext asociado a dicho JFrame.

105.2 Constructores • getContentPane(): Devuelve el contenido del JFra-

me.
Existen 4 tipos de constructores para inicializar un objeto
JFrame: • getDefaultCloseOperation(): Devuelve la operación
por defecto cuando se cierra el JFrame.
• JFrame(): Construye un nuevo marco que es
inicialmente invisible.
• getGlassPane(): Devuelve el objeto glassPane que
corresponde a este JFrame.
• JFrame(GraphicsCon guration): Crea una ventana
con la con guración grá ca especi cada en el
objeto GraphicsCon guration. • getGraphics(): Obtiene las características grá cas
del JFrame.
• JFrame(Cadena de texto): Crea una nueva ventana
a la que se le pone por título la cadena de texto que
• getJMenuBar(): Devuelve la barra de menú del
se le indique.
JFrame.

• JFrame(Cadena de texto, GraphicsCon guration):

Crea una nueva ventana con el título y la con gura- • getLayeredPane(): Obtiene el objeto layeredPane
ción grá ca especi cados. del JFrame.

• getRootPane(): Obtiene el objeto rootPane del

JFrame.
105.3 Métodos propios de la clase
Además de los métodos heredados, JFrame implementa • getTransferHandler(): Devuelve el objeto
una serie de métodos propios de esta, que se describen a transferHandler del JFrame.
continuación:

211
212 CAPÍTULO 105. JFRAME

• isDefaultLookAndFeelDecorated(): Comprueba si • setRootPane(JRootPane root): Establece el rootPane

la apariencia de la ventana JFrame es la apariencia de la ventana .
por defecto; en caso a rmativo será cierto.

• setRootPaneCheckingEnabled(boolean enabled):
• isRootPaneCheckingEnabled(): Devuelve un valor Establece si las llamadas add y setLayout se remiten
de cierto si las llamadas add y setLayout se remiten o no a la contentPane.
a la contentPane.
• setTransferHandler(TransferHandler newHandler):
• paramString(): Devuelve una representación en De ne el transferHandler, que es un mecanismo
cadena de texto del JFrame. de soporte de transferencia de datos dentro del
JFrame.

• processWindowEvent(WindowEvent e): Procesa los

eventos que se producen en el JFrame. • update(Graphics g): Hace una llamada al método
paint(g).

• remove(Component comp): Elimina el componente

que se especi ca de la ventana JFrame.
105.4 Enlaces externos
• repaint(long time, int x, int y, int width, int height):
Redibuja el rectángulo especi cado del JFrame en • [Link]
el tiempo indicado en milisegundos. swing/[Link]

• setContentPane(Container contentPane): Establece

el contentPane especi cado en JFrame.

• setDefaultCloseOperation(int operation): Especi ca

la operación por defecto al cerrar el JFrame.

• setDefaultLookAndFeelDecorated(boolean de-
faultLookAndFeelDecorated): Establece la apa-
riencia que debe tener el JFrame, como bordes,
botones para distintos usos, título...

• setGlassPane(Component glassPane): Establece las

propiedades del objeto glassPane.

• setIconImage(Image image): De ne el icono que se

mostrará en la parte superior izquierda del marco
del JFrame.

• setJMenuBar(JMenuBar menubar): Establece la

barra de menú del JFrame.

• setLayeredPane(JLayeredPane layeredPane): De -
ne el objeto layeredPane del JFrame.

• setLayout(LayoutManager manager): Establece la

forma en que se mostrarán los distintos objetos
añadidos al JFrame.
Capítulo 106

Usuario discusión:Juliasocorro

Hola, Julia. Olvidé introducir el aviso «en obras». Por ello 3. Conocimiento de los CMS.
hubo un con icto de edición. Si te convencen los cambios,
mi versión era ésta: 4. Dominio de las API de las redes sociales importan-
tes: Facebook, Twitter, LinkedIn, Instagram, You-
Agente SEO es un profesional que gestiona el tube, Google Plus... otras.
posicionamiento SEO de los sitios web y blogs en
los motores de búsqueda de Internet, tales como Google, ∧. Programador Web.
Bing y Yahoo.
• Personal:
Si se considera una puesta en común de las ofertas genera-
les recientes a nivel nacional, el per l laboral del Agente
SEO, según la demanda de empleabilidad actual de las 1. Positivo, creativo, estratega.
empresas en cuanto a conocimientos, habilidades y des- 2. Metódico, ordenado, esquemático.
trezas, es el siguiente:
3. Proactivo, que asista a congresos SEO, Analytic, So-
• Experto en Marketing online y en Analítica Web: cial Media, Adwords.
4. Dominio del estrés y de la presión de trabajo, ya que
1. Análisis e investigación de las palabras claves: Mar- muchas veces se labora contra el paso del robot de
keting online & SEO. Google y de otros buscadores.
2. Experiencia demostrable con SEMrush, Webmaster ∧. Capacidad de aprendizaje continuo, pasión por el
Tools, Google Analytics, Ahref y otras herramientas trabajo, sin límite de horario.
de auditoría y gestión SEO.
∨. Trabajo por resultados.
3. Diseño de estrategias de enlaces – linkbuilding.
El Agente SEO puede ser:
4. Testeo de la web, mantenimiento de backlinks.

∧. Previsor de penalizaciones. • Contratado:

∨. Estratega y Auditor. 1. Freelance, con herramientas propias para trabajar

∩. Dominio de: por nichos de mercado y empresas.
2. Por una empresa de alto nivel que empiece a expan-
(a) Robots y algoritmos de buscadores tales como
dir sus departamentos porque debe atender un alto
Google, Bing y Yahoo.
porcentaje de marketing digital.
(b) Técnicas White Hat SEO y Black Hat SEO.

∪. Experiencia SEO acreditada en Google y en otros • Parte de una Agencia.

motores de búsqueda.
Es una profesión nueva. Muchas empresas solicitan que
el Agente SEO sepa también de PPC (presupuesto por
• Webmaster:
campaña). En ese caso el per l laboral sería de Agente
SEM.
1. SEO on page, optimización de la web, Web perfor-
mance (HTML, PCHP, CCS, Bootstrap y Respon- El Agente SEO es un per l profesional novel. Data de po-
sive Design). cos años en el mercado nacional. Su demanda empieza a
a orar ahora mismo. En el transcurso del tiempo surgi-
2. Bases de datos, MysQL. rán muchos cambios y especialidades. Porque, si bien en

213
214 CAPÍTULO 106. USUARIO DISCUSIÓN:JULIASOCORRO

SEO estamos en la etapa de madurez, en un momento que

el SEO participa de un porcentaje del trabajo webmaster,
con una porción del marketing digital, también es cierto
que en España comienza a a orar en Internet en cuanto a
subida de los negocios al mundo online y más con sitios
web con Diseño Web adaptado a dispositivos móviles.
A medida que se implemente este per l profesional se
con rmará cada una de sus aptitudes. Una faceta positiva
adicional de Wikipedia es su apertura a la visión y a valo-
res a nivel nacional de todos y cada uno de nosotros. Por
otra parte, no necesariamente el per l del Agente SEO
ha de ser equiparable con el inherente al Agente SEM.
Es positivo comenzar a diseñar las líneas que los cruzan
y de otras que los separan.
Esta es una propuesta para empezar a diseñar el per l la-
boral del Agente SEO, que no se imparte en las escuelas,
sino en los negocios.

•
•

•
•

•
Capítulo 107

Kanban (desarrollo)

Este artículo se re ere a la gestión de procesos y método 107.2 Los principios del método
de mejora. Para el proceso de manufactura esbelta, con-
sulte Kanban.
Kanban
Kanban es un método para gestionar el trabajo intelec-
El método Kanban tiene sus raíces en cuatro principios
tual, con énfasis en la entrega justo a tiempo, mientras no
básicos:
se sobrecargan a los miembros del equipo. En este enfo-
que, el proceso, desde la de nición de una tarea hasta su
entrega al cliente, se muestra para que los participantes lo 1. Comience con lo que hace ahora
vean y los miembros del equipo tomen el trabajo de una
cola. El método Kanban se inicia con las fun-
ciones y procesos que ya se tienen y esti-
Kanban se puede dividir en dos partes:
mula cambios continuos, incrementales
y evolutivos a su sistema.
• Kanban - Un sistema de gestión de proceso visual
que le indica qué producir, cuándo producirlo, y 2. Se acuerda perseguir el cambio incremental y evo-
cuánto producir. lutivo

• El método Kanban - Una aproximación a la mejora La organización (o equipo) deben estar

del proceso evolutivo e incremental para las organi- de acuerdo que el cambio continuo, gra-
zaciones. dual y evolutivo es la manera de hacer
mejoras en el sistema y debe apegarse a
ello. Los cambios radicales pueden pare-
cer más e caces, pero tienen una mayor
107.1 El método Kanban tasa de fracaso debido a la resistencia y
el miedo en la organización. El método
Kanban anima a los pequeños y conti-
En el desarrollo de software, utilizamos un sistema Kan-
nuos cambios incrementales y evolutivos
ban virtual para limitar el trabajo en curso. A pesar de
a su sistema actual.
que el nombre se origina del idioma japonés“Kanban”,
y se traduce aproximadamente como“tarjeta de señal”,
3. Respetar el proceso actual, los roles, las responsabi-
y hay tarjetas utilizadas en la mayoría de las implementa-
lidades y los cargos
ciones de Kanban en desarrollo de software, estas tarjetas
no funcionan en realidad como señales para realizar más
Tenemos que facilitar el cambio futu-
trabajo. Representan los elementos de trabajo. De ahí el
ro; acordando respetar los roles actuales,
término “virtual”porque no existe una tarjeta física.
responsabilidades y cargos, eliminamos
El método Kanban formulado por David J. Ander- los temores iniciales. Esto nos debería
son* [1]* [2] es una aproximación al proceso gradual, evo- permitir obtener un mayor apoyo a nues-
lutivo y al cambio de sistemas para las organizaciones. tra iniciativa Kanban.
Utiliza un sistema de extracción limitada del trabajo en
curso como mecanismo básico para exponer los proble- 4. Liderazgo en todos los niveles
mas de funcionamiento del sistema (o proceso) y estimu-
lar la colaboración para la mejora continua del sistema. Se debe alentar hechos de liderazgo en
Un ejemplo del sistema de extracción es el sistema Kan- todos los niveles de la organización de
ban, y es después de esta popular forma de trabajo en los contribuyentes individuales a la alta
curso, que se ha denominado el método. dirección.

21∧
21∨ CAPÍTULO 107. KANBAN (DESARROLLO)

107.3 Cinco prácticas centrales del consenso. El método Kanban sugiere que
un enfoque cientí co sea utilizado para
método Kanban implementar los cambios continuos, gra-
duales y evolutivos. El método no pres-
Anderson identi có cinco características básicas que ha- cribe un método cientí co especí co pa-
bían sido observadas en cada implementación correcta ra utilizarlo.
del método Kanban. Posteriormente fueron etiquetadas
como prácticas y se ampliaron con la adición de una sex-
ta característica.* [3] 107.4 Comportamiento emergente
1. Visualizar con Kanban
Visualizar el ujo de trabajo y hacerlo Hay una creciente lista de comportamientos emergentes
visible es la base para comprender cómo que hemos llegado a esperar de la implementación de
avanza el trabajo. Sin comprender el u- Kanban, tales como* [4]
jo de trabajo, realizar los cambios ade-
cuados es más difícil. Una forma común
• Proceso único a la medida de cada cadena de valor
de visualizar el ujo de trabajo es el uso
de columnas. Las columnas representan • Cadencias desacopladas
los diferentes estados o pasos en el ujo
de trabajo. • Trabajo programado por el costo de la demora

2. Limitar el trabajo en curso • Valor optimizado con clases de servicio

Limitar el trabajo en curso implica que • Gestión de riesgo con asignación de capacidad
un sistema de extracción se aplica en la • Tolerancia en la experimentación de procesos
totalidad o parte del ujo de trabajo. El
sistema de extracción actúa como uno de • Gestión cuantitativa
los principales estímulos para los cam-
bios continuos, incrementales y evoluti- • Propagación viral de Kanban en toda la organización
vos en el sistema. • Pequeños equipos fusionados para crear bolsas de
3. Dirigir y gestionar el ujo trabajo más uidas.

Se debe supervisar, medir y reportar el

ujo de trabajo a través de cada esta- 107.5 La implementación del méto-
do. Al gestionar activamente el ujo, los
cambios continuos, graduales y evoluti- do Kanban
vos del sistema pueden ser evaluados pa-
ra tener efectos positivos o negativos. Algunos profesionales han implementado Kanban en fí-
sico utilizando notas adhesivas, o tableros con ranuras.
4. Hacer las Políticas de Proceso Explícitas Más a menudo la señal es generada por un software de
seguimiento de trabajos especiales, tales como:* [∧]
Con gure las reglas y directrices de su
trabajo. Entienda las necesidades y ase-
gúrese de seguir las reglas. Las políticas • Kanban Tool
de nirán cuándo y por qué una tarjeta • JIRA Greenhopper
debe pasar de una columna a otra. Escrí-
balas. Cambie las reglas cuando la reali- • Cardmapping
dad cambie.
• Tablero Kanban online
∧. Utilizar modelos para reconocer oportunidades de
mejora • Targetprocess

Cuando los equipos tienen un entendi-

miento común de las teorías sobre el tra- 107.6 Referencias
bajo, el ujo de trabajo, el proceso y el
riesgo, es más probable que sea capaz [1] Anderson, David (septiembre de 2003). Agile Manage-
de construir una comprensión comparti- ment for Software Engineering: Applying the Theory of
da de un problema y proponer acciones Constraints for Business Results. Prentice Hall. ISBN 0-
de mejora que puedan ser aprobadas por 13-1424∨0-2.
107.7. VÉASE TAMBIÉN 21∩

[2] Anderson, David (abril de 2010). Kanban - Successful

Evolutionary Change for your Technology Business. Blue
Hole Press. ISBN 0-9∪4∧214-0-2.

[3] [Link]
principles-kanban-method David Anderson “The
principles of the Kanban method”December 10, 2010

[4] Anderson, David (septiembre de 2010). Kanban - Suc-

cessful Evolutionary Change for your Technology Business.
Blue Hole Press. ISBN 9∩∪-0-9∪4∧214-0-1.

[∧] Robson, Sean (enero de 2013). Agile SAP: Introducing Fle-

xibility, Transparency and Speed to SAP Implementations.
IT Governance Ltd. ISBN 9∩∪-1-∪492∪-44∨-2.

107.7 Véase también

• Kanban
• Sistema de producción Toyota

• Desarrollo ágil de software

• Proceso para el desarrollo de software

• Metodología de desarrollo de software

• Scrum
Capítulo 108

Kit de desarrollo de software

“SDK”redirige aquí. puede incluir también el software añadido en sí para ser

usado para el desarrollo pero no necesariamente para la
Un kit de desarrollo de software o SDK (siglas en in- redistribución. Una situación interesante surge aquí en-
glés de software development kit) es generalmente un con- tre plataformas donde es posible desarrollar aplicaciones
junto de herramientas de desarrollo de software que le que pueden iniciar la con guración de un sistema sin que
permite al programador o desarrollador de software crear esté instalado el add-on, y usar una rutina de petición de
aplicaciones para un sistema concreto, por ejemplo cier- entorno de tipo Gestalt (de Mac OS) para determinar si
tos paquetes de software, frameworks, plataformas de dicho add-on está instalado, y otros donde la aplicación
hardware, computadoras, videoconsolas, sistemas opera- simplemente fallará al iniciarse. En otras palabras, es po-
tivos, etcétera. sible construir un único binario que funcione en con -
guraciones donde el add-on esté presente o no, con una
Es algo tan sencillo como una interfaz de programación funcionalidad reducida en este último caso.
de aplicaciones o API (del inglés application programing
interface) creada para permitir el uso de cierto lenguaje
de programación, o puede, también, incluir hardware so-
sticado para comunicarse con un determinado sistema
108.3 Términos más especí cos
embebido. Las herramientas de desarrollo de software
más comunes incluyen soporte para la detección de erro- Los proveedores de SDK para ciertos sistemas o subsiste-
res de programación como un entorno de desarrollo inte- mas pueden utilizar un término más especí co que el de
grado o IDE (del inglés Integrated Development Environ- “software”. Por ejemplo, tanto Microsoft como Apple
ment) y otras utilidades. Los SDK frecuentemente tam- proveen Driver Development Kits (DDK) o kits para el
bién incluyen códigos de ejemplo y notas técnicas de so- desarrollo de drivers o controladores de dispositivos para
porte u otra documentación de soporte para ayudar a cla- desarrollar drivers para dispositivos, y PalmSource distri-
ri car ciertos puntos del material de referencia primario. buye su propio kit de desarrollo como el PalmOS Deve-
lopment Kit (PDK) o kit de desarrollo para PalmOS.

108.1 Incompatibilidad de licen-

108.4 Ejemplos
cias
• El SDK de Virtual Earth de Microsoft.* [1]
Los SDK pueden incluir licencia de software que los ha-
cen incompatibles para crear software que se pretenda • El SDK de DirectX de Microsoft, en el que se basan,
hacer para una licencia no compatible. Por ejemplo: un por ejemplo, la mayoría de juegos para Windows ac-
SDK propietario probablemente será incompatible para tuales.
el desarrollo de software gratuito. Y un SDK bajo la li-
• EL .Net Framework de Microsoft, en el que se basan
cencia GPL posiblemente será incompatible con el desa-
muchas aplicaciones basadas en formularios.
rrollo de software propietario. Sin embargo, los SDK ba-
jo la licencia LGPL suelen ser seguros para el desarrollo • El 'SDK Java* [2] de Sun Microsystems, en el que se
de software propietario. basa, por ejemplo, la herramienta de lucha contra el
vandalismo de CryptoDerk.

108.2 SDK para añadidos • Los kits de herramientas de Widgets, en los que se
basan muchas utilidades desarrolladas con lenguajes
de programación orientados a objetos.
Un SDK para un añadido (add-on) de un determinado sis-
tema operativo (por ejemplo, QuickTime para Mac OS) • Turbo Pascal.

21∪
108.7. ENLACES EXTERNOS 219

• Clipper.

• Delphi.
• El Source SDK, una herramienta diseñada por Valve
en el que se puede diseñar mods y mapas para juegos
del motor Source. Disponible en Steam al comprar
un juego que use el motor Source.
• El SDK de Android, elaborado por Google para su
sistema homónimo.

108.5 Referencias
[1] [Link]

[2] Java 2 Software Development Kit.

108.6 Véase también

• Ambiente de desarrollo integrado
• Interfaz de programación de aplicaciones

108.7 Enlaces externos

• DirectX SDK de Microsoft.
• Framework SDK para sistemas X∪∨ Framework
SDK para sistemas X∪∨ a ∨4 bits y Framework SDK
para sistemas IA∨4 de Microsoft.

• Java 2 SDK de Sun Microsystems.

• Software Development Kits de ABBYY para Cap-
tura de Datos y Conversión de Documentos.
• SDKs para Cámaras y voz de Olympus.

• SDK para emuladores de terminales de Cybele Soft-

ware.
Capítulo 109

Kommander

Kommander es de nido con un conjunto de herramien- También hay un página de fans de Kommander
tas que permite la construcción de interfaces para scripts.
[Link]
Estos scripts pueden tener interacción con aplicaciones
propias del entorno de KDE y programas compilados en Y ahora se une Famelix, con un wiki especial para Kom-
algún lenguaje como por ejemplo C, C++, Phyton, etc. mander en español
Estas propiedades lo hacen ser muy útil al momento de [Link]
integrar soluciones.
Ahora Kommander, en términos más técnicos, consta de
dos componentes: Editor y Ejecutor.

109.1 El editor
Es la interfaz disponible para el programador, en la cual
se crean las ventanas o cuadros de diálogo. Dentro de los
cuadros de diálogo se pueden insertar controles o widget,
tales como barras de progreso, botones, cuadros de ima-
gen, etc.

109.2 El ejecutor
Es simplemente el motor que ejecuta el código generado
por el editor.

109.3 Direcciones de Kommander

El paquete que contiene a Kommander es kdewebdev
(web development apps from the o cial KDE release)
[Link]
La última versión está disponible en:
[Link]
Lista de correos para usuarios y desarrolladores
[Link]
kommander
[Link]
kommander-devel
Un listado de muchas aplicaciones de Kommander en:
[Link]

220
Capítulo 110

Last Error (informática)

Last Error en computación, especí camente en el cam- 110.2 En DELPHI

po de la programación en Windows se conoce como Last
Error al último error sucedido al utilizar una de las API de function MuestraError(error: DWORD): String; var
Windows. Los códigos de error son particulares de cada pString: array[0..MAX_PATH] of char; begin Format-
Thread que esté en ejecución. Message(FORMAT_MESSAGE_FROM_SYSTEM,
Cuando una Api falla, es muy común que devuelva los Nil, error, 0, pString, MAX_PATH, Nil); Result :=
valores NULL o –1. Además puede registrar el error pa- pString; end;
ra ser identi cado por el programa que la utiliza. Este se
obtiene haciendo una llamada a la API GetLastError, la
cual devuelve el código de error. Otra forma es usando
directamente el TIB, aunque este método puede ser en- 110.3 Enlaces externos
gorroso o incluso imposible en algunos lenguajes de alto
nivel. • Last Error explicación
• Winerror.h

• Listado de Errores
• Ejemplo de FormatMessage en Delphi
110.1 Errores personalizados

Una función propia o de un programa por defecto de Win-

dows puede hacer uso de la Api SetLastError para infor-
mar que error ha ocurrido o en el caso de no haber error
puede usarse para poner en cero el último error ocurrido.
Una vez hecho esto, el error de la función anteriormente
utilizada no se podrá determinar.
Estos errores son enteros de 32 bits. Si se quiere usar
SetLastError para “nuevos”errores propios de la apli-
cación se debe de activar el bit 29 ya que el sistema no
usa errores con ese bit activado.
Bit 29 00100000 00000000 00000000 00000000
Bit 31, el más signi cativo Bit 0, el menos signi cativo

Una vez activado los números serán mayores o iguales que

20000000H (en hexadecimal) o ∧3∨∪∩0912D (en deci-
mal).
El último error provocado por el sistema es un número
entero que esta en el rango de (0 a 1∧999) según la lista
publicada en Microsoft
El código de error obtenido por cualquiera de las dos vías
puede ser mostrado al usuario usando la API Format-
Message la cual nos da un texto explicando el error.

221
 Capítulo 111

Línea de código fuente

La de nición de línea de código fuente es esencialmente for (i=0; i<100; ++i) {printf(“hola”);} /* ←Cuántas
ambigua para la mayor parte del software. Su signi cado líneas tiene este programa? */
varía de un lenguaje de programación a otro, pero tam-
bién dentro de un mismo lenguaje de programación. Proviene de las siglas en inglés de Source Lines of Code
Una línea de código fuente es cada una de las líneas de (SLC), en español, “Líneas de Código Fuente”(LCF)
un archivo de código fuente de un programa informático. o “Líneas de Código Fuente Únicas”(LCFU).
Habitualmente en cada línea se ejecuta una instrucción
que tiene que ejecutar el programa. También es habitual
tabular las estructuras de control del programa en cuestión 111.1 El uso de medidas de LCF
para una lectura más fácil. Viene a ser como la oración en
libros y textos escritos en general.
De acuerdo a Andrew Tanenbaum, los valores de líneas
En ocasiones los programadores hablan del número de de código fuente para diferentes sistemas operativos de
“líneas de código”que tiene cierto programa para hablar la línea de productos de Microsoft Windows NT son las
de la magnitud o complejidad de este. siguientes:
En computación, el número de línea de una instrucción es
un punto bastante útil a la hora de compilar el programa
porque habitualmente los compiladores detectan errores David A. Wheeler ha estudiado el sistema operativo Red
de programación mostrando el número de línea donde se Hat (distribución de los sistemas operativos de Linux) e
ha encontrado el error que el programador deberá corregir informó que Red Hat versión ∩.1 (lanzado en abril de
para una compilación satisfactoria. 2001) contiene cerca de 30 millones de LCFU físicos.
Como curiosidad, algunos programadores se divierten También extrapoló que, de haber sido desarrollado por
complicando la forma de programar, bien por diversión, medios convencionales de propiedad (medida de tiempo-
como reto entre programadores, o para que sea imposible persona) habría requerido de unos ∪.000 años/persona de
de entender para un programador poco experimentado. esfuerzo y desarrollo y hubiesen costado más de mil mi-
A este pasatiempo se le denomina programación ofusca- llones de dólares (cotizados en el año 2000).
da y uno de los puntos más habituales para programar Un estudio similar, reveló que Debian versión 2.2 (cono-
ofuscadamente es no escribir una instrucción por línea cido por su nombre clave “Potato”) contiene unos ∧∧
y no hacer tabulaciones, en ocasiones se escriben varias millones de LCFU y de haber sido realizado mediante las
instrucciones por línea o a veces se corta una instrucción
propiedades convencionales, hubiese tardado unos 1400∧
en varias líneas. Los más experimentados en este tipo de años/persona y costado unos 1900 millones de dólares.
pasatiempos, se atreven incluso a realizar obras de AsciiMás tarde se ejecutó una de las herramientas utilizadas
art con las líneas de su código fuente. en el informe para la siguiente versión y se reportó que
En el lenguaje de programación C, por ejemplo, una línea Debian posee 104 millones de LCFU, y a partir del año
de código puede ser: 200∧, las siguientes versiones poseerán, al menos, más de
213 millones de LCFU.
1. una instrucción acabada en un salto de línea, Se pueden encontrar las cifras de los principales sistemas
operativos (las distintas versiones de Windows se han pre-
2. una instrucción acabada en un punto y coma, sentado en una tabla de arriba).
3. cualquier línea del programa que acabe en un salto
de línea (comentarios incluidos).
En comparación, las cifras de algunas herramientas grá-
Por ejemplo: cas.

222
111.3. VÉASE TAMBIÉN 223

Get-ChildItem -recurse -include *.cxx,*.cpp,*.h,*.c

| Get-Content | Measure-Object -line ls -r -i
*.cxx,*.cpp,*.h,*.c | gc | measure-object -l
111.2 Programas para contar lí-
neas de código 111.2.3 Comerciales
Existen diversas tipos y aplicaciones disponibles con el • EZ-Metrix is a commercial web-based source code
propósito de contar y expresarlas líneas de código conte- counting utility that measures more than ∩∧ di e-
nidas en el código fuente en forma automática. Entre los rent languages, and compares two le lists to quan-
requerimientos necesarios para una herramienta métrica tify di erences (i.e., new, modi ed, deleted, unmo-
de este tipo, debería incluir la habilidad necesaria para di ed).
procesar varios lenguajes de código fuente y no depen-
der de un sistema operativo especí co. • Resource Standard Metrics is a commercial tool de-
signed to process ANSI C, ANSI C++, C#, and Ja-
Las compañías que usan una herramienta en C para Win-
va 2.0+ while operating on Windows, UNIX, Linux
dows, otra en C para UNIX y una tercera en Java para
and Mac OS X.
Linux, no desarrollan una estimación básica para sus me-
didas del CMMI. • Another program for Windows, Code Counter Pro,
which counts physical KLOCs and supports langua-
ges like C, C++, C#, Java, Cobol, Delphi, VB, ASP,
111.2.1 Software Libre/Open Source
PHP and Fortran.
• La orden más simple en UNIX para contar las líneas
de código es wc. Por ejemplo, para contar el núme-
ro de líneas en todos los archivos .cxx, .cpp, .h y .c 111.2.4 Basados en web
dentro y debajo del directorio actual, se pueden usar
los comandos POSIX: nd y wc • Ohloh extracts LOC and other software metrics
of open source projects from publicly accessible
revision control repositories. It generates analyses
nd . \( -name '*.[ch]' -o -name '*.cxx' -o -name '*.cpp'
and reports of development activity available as
\) | xargs wc -l
graphs and API-based web-services.

111.2.2 Freeware (software no libre) 111.3 Véase también

• K-LOC Calculator* [∧] es una herramienta para
Windows para contar líneas de código físicas. • Código fuente

• Code Analyzer* [∨] es una herramienta escrita en Ja-

va para contar líneas de código. Para varios lengua-
jes.
111.4 Referencias
• LinesOfCodeWichtel* [∩] es una herramienta escri- [1] How Many Lines of Code in Windows?, [Link],
ta en java para contar LoC. Para varios lenguajes ∨ de diciembre de 200∧, archivado del original
el 23 de noviembre de 201∧, [Link]
• LocMetrics* [∪] es una herramienta gratuita para org/web/[Link]
LoC en Windows en los lenguajes C#, Java, o C++ c4bdc∩93-bbcf-4fff-∪1∨∩-[Link], consul-
code. tado el 1∪ de octubre de 200∩
This in turn cites Vincent Maraia's The Build Master as
• Source Line of Code Counter* [9] es una herramienta the source of the information.
para contar LoC basada en .net, admite concordan-
cias en expresiones, trae un navegador de directorio. [2] González-Barahona, Jesús M., Miguel A. Ortuño Pérez,
*
Pedro de las Heras Quirós, José Centeno González, and
• Source Monitor [10] es una herramienta gratuita pa- Vicente Matellán Olivera. «Counting potatoes: the size of
ra Windows que cuenta las líneas de código y medi- Debian 2.2». [Link]. Archivado desde el original el
das derivadas de los lenguajes C++, C, C#, Java, y 23 de noviembre de 201∧. Consultado el 12 de agosto de
de otro código fuente 2003.

• Dos maneras de contar LCFU en Windows PowerS- [3] Robles, Gregorio. «Debian Counting». Archivado desde
hell en todos los archivos .cxx, .cpp, .h, and .c dentro el original el 23 de noviembre de 201∧. Consultado el 1∨
y debajo del directorio. de febrero de 200∩.
224 CAPÍTULO 111. LÍNEA DE CÓDIGO FUENTE

[4] Jobs, Steve (agosto de 200∨). «Live from WWDC 2006:

Steve Jobs Keynote». Consultado el 1∨ de febrero de 200∩.
«86 million lines of source code that was ported to run on
an entirely new architecture with zero hiccups. Possibly in-
cluding the whole iLife suite, not just the operating system
and usually bundled applications».

[∧] [Link]
contents/download/program/[Link]

[∨] [Link]
com/sivaram_subr/codeanalyzer/[Link]

[∩] [Link]
[Link]

[∪] [Link]

[9] [Link]
200∩/12/2∨/source-line-of-code-counter

[10] [Link]

111.5 Enlaces externos

• De niciones útiles sobre código fuente Recurse
Standard Metrics (RSM) de ne “líneas de código
fuente e caces”con un realista medida, indepen-
dientemente del estilo de programación.
• Líneas de código fuente efectivas de eLOC Me-
trics para el popular software libre Linux Ker-
nel 2.∨.1∩, Firefox, Apache HPPD, MySQL, PHP
usando RSM.

• Wheeler, David A. «LCFUCount». Consultado el

12 de agosto de 2003.

• Wheeler, David A. (junio de 2001). «Contando lí-

neas de código fuente. (LCFU)». Consultado el 12
de agosto de 2003.
• Tanenbaum, Andrew S. Sistemas operativos moder-
nos (segunda edición). Prentice Hall. ISBN 0-13-
092∨41-∪.

• Howard Dahdah (24 de enero de 200∩).

«Tanenbaum outlines his vision for a grandma-proof
OS». Consultado el 29 de enero de 200∩.
• C. M. Lott: Herramientas de colección métrica para
códigos fuente para C y C++
Capítulo 112

Macintosh Toolbox

El Macintosh Toolbox es un conjunto de APIs con un

mecanismo de acceso particular. Estas APIs implementan
varias de las características de alto nivel de Mac OS.
El Toolbox consiste en una serie de “gestores”respon-
sables de generar los grá cos en pantalla (componentes
de software como QuickDraw), y el Gestor de Menú, que
mantiene las estructuras de datos que describen la barra
de menú.

22∧
 Capítulo 113

Macro

Para la fotografía, véase Macrofotografía. 113.2 Macros en programación

Para el museo, véase Museo de Arte Contempo-
ráneo de Rosario. 113.3 Macros ocultas
Las macros ocultas son órdenes complejas de tipo macro
Una macro (del griego μακ , makro, que signi ca que se han declarado en el código fuente pero que per-
ʻgrandeʼ) ―abreviatura de macroinstrucción―es una manecen ocultas por motivos de seguridad, por acceso
serie de instrucciones que se almacenan para que se pue- restringido, etc.
dan ejecutar de manera secuencial mediante una sola lla-
mada u orden de ejecución. Dicho de otra manera, una Este término ha sido popularizado por la película de c-
macroinstrucción es una instrucción compleja, formada ción Tron, ambientada en un mundo informático virtual,
en la que se puede escuchar una voz fuera de campo
por otras instrucciones más sencillas. Esto permite la au-
tomatización de tareas repetitivas. (probablemente de un programa dependiente del Control
Central) que advierte a los habitantes de ese mundo que
Las macros tienden a almacenarse en el ámbito del pro- tengan cuidado con las macros ocultas.
pio programa que las utiliza y se ejecutan pulsando una
combinación especial de teclas o un botón especialmente
creado y asignado para tal efecto.
113.4 Véase también
La diferencia entre una macroinstrucción y un programa
es que en las macroinstrucciones la ejecución es secuen- • Script
cial y no existe otro concepto del ujo de programa.
• Macro ensamblador
• Microsoft Macro Assembler
113.1 Macros de aplicaciones • Visual Basic for Applications

Son un grupo de instrucciones que se ejecutan secuencial- Ejemplos de Macros

mente y se utilizan para economizar tareas. Una macro no
es más que un conjunto de instrucciones (tales como «bo-
rrar archivo», «añadir registro», etc.), y que se almacenan
en una ubicación especial. Por ejemplo, en Microsoft Ac-
cess se observa que hay una zona para crear macros. Una
macro en Access trabajando para una base de datos po-
dría ser un archivo que, al llamarse desde otra instrucción,
borrara los registros de un cliente o accionista, luego bo-
rrara ciertos registros en otras tablas.
Excel tiene incorporado el editor de VBA, se pueden
crear macros con la grabadora de macros o escribiendo
directamente los códigos en el Editor de VBA, esta últi-
ma opción es más potente, ya que la grabadora de macros
se limita a grabar cosas repetitivas que se hacen con el te-
clado, al escribir el código nos permite hacer otras cosas
conviertiendo a Excel en una aplicación super potente al
permitir programar macros mediante vba.

22∨
Capítulo 114

Malla de triángulos 3D

La Malla de triángulos 3D es una colección de DirectX, no son compatibles con las mallas arbitrarias de
triángulos y vértices que aproximan una super cie en 3D. triángulos. Sin embargo, estructuras como tiras de trián-
Aunque el campo de aplicación de la generación auto- gulos - (donde cada triángulo, comparte un vértice con un
mática de una malla triangular, ha sido tradicionalmen- vecino y otro con el próximo) y el abanicos de triángulos
te la obtención de modelos digitales de elevaciones del (un conjunto de triángulos conectados por un vértice cen-
tral) se tratan de manera e ciente con la necesidad de sólo
terreno, su aplicación es mucho más amplia. Cualquier
variable espacial relacionada con una cierta tipología, es procesar N+2 vértices para dibujar N triángulos.
susceptible de ser modelizada como una super cie tridi- Una malla de triángulos, construida a partir de tiras, en
mensional, en la que la cota de cada punto es el valor de abanico y posiblemente triángulos independientes, gene-
la variable a estudiar. ralmente se obtienen mediante un mosaico de objetos po-
Para saber cómo podríamos descomponer un objeto con ligonales.
todas sus partes, la mínima regla es la teoría del sistema Otra forma de evitar la redundancia de procesamiento de
de visión humano. Para interpretar cómo los seres huma- vértices es compartiendo vértices explícitos. La de ni-
nos pueden descomponer un objeto en mallas, podríamos ción de los vértices está separada de la descripción trián-
desarrollar un algoritmo de segmentación de malla ya que gulo. Todo el conjunto de triángulos se de ne por un con-
además éste nos permite obtener un nivel superior de des- junto de índices en una matriz de vértices. El sistema grá-
cripciones del objeto en cuestión. co procesa los vértices primero y hace el render de los
triángulos después, utilizando el conjunto de índices tra-
bajando sobre la transformación de datos.

114.1 Aplicaciones
Una utilidad de las mallas de triángulos podría ser para
114.2 Obtención de las mallas
sistemas de reconocimiento de objetos, la comprensión
de una escena, y las características del modelado. Para la generación automática de una malla triangular
existen distintos estudios y algoritmos. Por ejemplo, hay
Los grá cos por ordenador también utilizan mallas de algoritmos que parten de una nube de puntos irregular-
triángulos. Se componen de un conjunto de triángulos
mente distribuidos y procurando de nir cada triángulo lo
(normalmente en tres dimensiones) que están conectados más regular posible (el caso óptimo, triánguos equiláte-
por sus vértices.
ros) permiten la creación de una malla de triángulos.
Muchos paquetes de software de grá cos y dispositivos Partiendo de una distribución irregular de puntos a los
de hardware puede funcionar de manera más e ciente que se les ha asociado una cierta variable, por ejemplo su
en triángulos que se agrupan en mallas que en un gru- cota, si estamos hablando de un terreno o el valor de la
po de triángulos que se presentan individualmente. Esto contaminación acústica en una cierta zona urbana, exis-
es porque normalmente los grá cos por ordenador hacen ten técnicas para interpolar dicha variable en cualquier
operaciones sobre los vértices (en las esquinas de trián- otro punto de la zona en la que no disponemos de su va-
gulos). Con cada uno de los triángulos, el sistema tiene lor mediante un proceso de medición directo. Mientras
que funcionar en tres vértices de cada triángulo. En una que algunos de estos métodos están desarrollados a par-
gran malla, puede haber ocho o más triángulos reunidos tir de una interpolación que utiliza algoritmos de ʻpat-
en un único vértice. Así, procesando los vértices una sola chesʼ, super cies cuadráticas, interpolaciones polinómi-
vez, es posible hacer una fracción del trabajo y lograr un cas, etc.; la técnica habitualmente utilizada es la basada
efecto idéntico. en los polígonos de Voronoi y la triangulación de Delau-
Las dos interfaces de programación de aplicaciones nay para así obtener una malla triangular, lo más regular
(APIs) más importantes del mercado grá co, OpenGL y posible, tal que los vértices de los triángulos que confor-

22∩
22∪ CAPÍTULO 114. MALLA DE TRIÁNGULOS 3D

man la malla sean los puntos inicialmente dados.

114.3 Compresión
Un método de compresión de una malla con pluralidad
de vértices, es decir, que cada vértice se caracteriza por
un grado igual al número de bordes incidentes y con la
casi totalidad de vértices en un orden consecutivo. Así
generamos una lista con la tipología de los grados de los
vértices en orden consecutivo y el código de secuencia de
señales con la tipología de la lista.
Capítulo 115

Mapeo objeto-relacional

El mapeo objeto-relacional (más conocido por su nom- lares simples en el programa. El mapeo objeto-relacional
bre en inglés, Object-Relational mapping, o sus siglas es utilizado para implementar la primera aproximación.
O/RM, ORM, y O/R mapping) es una técnica de pro- El núcleo del problema reside en traducir estos objetos a
gramación para convertir datos entre el sistema de tipos formas que puedan ser almacenadas en la base de datos
utilizado en un lenguaje de programación orientado a ob-
para recuperarlas fácilmente, mientras se preservan las
jetos y la utilización de una base de datos relacional como propiedades de los objetos y sus relaciones; estos objetos
motor de persistencia. En la práctica esto crea una base
se dice entonces que son persistentes.
de datos orientada a objetos virtual, sobre la base de da-
tos relacional. Esto posibilita el uso de las características
propias de la orientación a objetos (básicamente herencia
y polimor smo). Hay paquetes comerciales y de uso libre 115.2 Implementaciones
disponibles que desarrollan el mapeo relacional de ob-
jetos, aunque algunos programadores pre eren crear sus
Los tipos de bases de datos usados mayoritariamente son
propias herramientas ORM.
las bases de datos SQL, cuya aparición precedió al cre-
cimiento de la programación orientada a objetos en los
1990s. Las bases de datos SQL usan una serie de tablas
115.1 El problema para organizar datos. Los datos en distintas tablas están
asociados a través del uso de restricciones declarativas en
En la programación orientada a objetos, las tareas de lugar de punteros o enlaces explícitos. Los mismos da-
gestión de datos son implementadas generalmente por la tos que pueden almacenarse en un solo objeto podrían
manipulación de objetos, los cuales son casi siempre va- requerir ser almacenados a través de varias tablas.
lores no escalares. Para ilustrarlo, considere el ejemplo de Una implementación del mapeo relacional de objetos po-
una entrada en una libreta de direcciones, que representa dría necesitar elegir de manera sistemática y predictiva
a una sola persona con cero o más números telefónicos qué tablas usar y generar las sentencias SQL necesarias.
y cero o más direcciones. En una implementación orien-
Muchos paquetes han sido desarrollados para reducir el
tada a objetos, esto puede ser modelado por un “obje-
to persona”con “campos”que almacenan los datos de tedioso proceso de desarrollo de sistemas de mapeo re-
lacional de objetos proveyendo bibliotecas de clases que
dicha entrada: el nombre de la persona, una lista de nú-
meros telefónicos y una lista de direcciones. La lista de son capaces de realizar mapeos automáticamente. Dada
una lista de tablas en la base de datos, y objetos en el pro-
números telefónicos estaría compuesta por “objetos de
números telefónicos”y así sucesivamente. La entrada de grama, ellos pueden automáticamente mapear solicitudes
la libreta de direcciones es tratada como un valor único de un sentido a otro. Preguntar a un objeto persona por
por el lenguaje de programación (puede ser referenciada sus números telefónicos resultará en la creación y envío
por una sola variable, por ejemplo). Se pueden asociar va- de la consulta apropiada a la base de datos, y los resulta-
rios métodos al objeto, como uno que devuelva el número dos son traducidos directamente en objetos de números
telefónico preferido, la dirección de su casa, etc.. telefónicos dentro del programa.

Sin embargo, muchos productos populares de base de da- Desde el punto de vista de un programador, el sistema
tos, como los Sistemas de Gestión de Bases de Datos debe lucir como un almacén de objetos persistentes. Uno
SQL, solamente pueden almacenar y manipular valores puede crear objetos y trabajar normalmente con ellos, los
escalares como enteros y cadenas, organizados en tablas cambios que sufran terminarán siendo re ejados en la ba-
normalizadas. El programador debe convertir los valores se de datos.
de los objetos en grupos de valores simples para almace- Sin embargo, en la práctica no es tan simple. Todos los
narlos en la base de datos (y volverlos a convertir luego de sistemas ORM tienden a hacerse visibles en varias for-
recuperarlos de la base de datos), o usar sólo valores esca- mas, reduciendo en cierto grado la capacidad de ignorar

229
230 CAPÍTULO 115. MAPEO OBJETO-RELACIONAL

la base de datos. Peor aún, la capa de traducción puede ser 115.3 Bases de datos distintas a
lenta e ine ciente (comparada en términos de las senten-
cias SQL que escribe), provocando que el programa sea
SQL
más lento y utilice más memoria que el código “escrito
a mano”. Las bases de datos como Caché no necesitan mapeo
objeto-relacional manual. El acceso del SQL a los valo-
Un buen número de sistemas de mapeo objeto-relacional res no escalares ya ha sido construido. Caché permite a
se han desarrollado a lo largo de los años, pero su efec- los desarrolladores diseñar cualquier combinación de pro-
tividad en el mercado ha sido diversa. NeXT's Enter- gramación orientada a objetos y almacenamiento estruc-
prise Objects Framework (EOF) fue una de las prime- turado en tablas en la misma base de datos en lugar de
ras implementaciones, pero no tuvo éxito debido a que depender de herramientas externas.
estaba estrechamente ligado a todo el kit de NeXT's,
OpenStep * [cita requerida]. Fue integrado más tarde en Otra solución puede ser el uso de un sistema de adminis-
NeXT's WebObjects, el primer servidor web de apli- tración de base de datos orientada a objetos (OODBMS:
caciones orientado a objetos. Desde que Apple compró Object-oriented database management system), lo cual,
NeXT's en 199∩, EOF proveyó la tecnología detrás de los como el nombre lo sugiere, es una base de datos diseña-
sitios web de comercio electrónico de Apple: los servicios da especí camente para trabajar con valores orientados a
.Mac y la tienda de música iTunes. Apple provee EOF en objetos. Usar un OODBMS puede eliminar la necesidad
dos implementaciones: la implementación en Objective- de convertir datos desde y hacia su forma SQL, y los da-
C que viene con Apple Developers Tools y la implemen- tos pueden ser almacenados en su representación original
tación Pure Java que viene en WebObjects ∧.2. Inspirado como objetos.
por EOF es el open source Apache Cayenne. Cayenne Las bases de datos orientadas a objetos aún no han con-
tiene metas similares a las de EOF e intenta estar acorde seguido una alta aceptación y uso. Una de las principales
a los estándares JPA. limitaciones reside en que, cambiar de un sistema de ad-
Una aproximación alternativa ha sido tomada por tecno- ministración de base de datos SQL a un sistema orienta-
logías como RDF y SPARQL, y el concepto de“triplesto- do totalmente a objetos implica que se pierde la capaci-
re”. RDF es una serialización del concepto objeto-sujeto- dad de crear sentencias SQL, un método ya probado para
predicado, RDF/XML es una representación en XML de obtener combinaciones especí cas de datos. Por esta ra-
aquello, SPARQL es un lenguaje de consulta similar al zón, muchos programadores se encuentran más a gusto
SQL, y un “triplestore”es una descripción general de trabajando con un sistema de mapeo de objetos y SQL,
una base de datos que trabaja con un tercer componente. aún cuando la mayoría de las bases de datos comerciales
orientadas a objetos son capaces de procesar consultas
Más recientemente, un sistema similar ha comenzado a SQL de manera limitada.
evolucionar en el mundo Java, conocido como Java Da-
ta Objects (JDO). A diferencia de EOF, JDO es un es-
tándar, y muchas implementaciones están disponibles por
parte de distintos distribuidores de software. La especi - 115.4 Véase también
cación 3.0 de Enterprise Java Beans (EJB) también cubre
la misma área. Han existido algunos con ictos de están- • Propel (PHP)
dares entre ambas especi caciones en términos de pre-
• Doctrine (PHP)
eminencia. JDO tiene muchas implementaciones comer-
ciales, mientras que EJB 3.0 está aún en desarrollo. Sin • JPA (Java)
embargo, recientemente otro estándar ha sido anuncia-
do por JCP para abarcar estos dos estándares de manera • Hibernate (Java)
conjunta y lograr que el futuro estándar trabaje en diver- • [Link] Entity Framework (C#)
sas arquitecturas de Java. Otro ejemplo a mencionar es
Hibernate, el framework de mapeo objeto-relacional más • LINQ to SQL (C# sólo para SQL Server) su sintaxis
usado en Java que inspiró la especi cación EJB 3. es similar a JPA
En el framework de desarrollo web Ruby on Rails, el ma- • NHibernate (C#)
peo objeto-relacional juega un rol preponderante y es ma-
nejado por la herramienta ActiveRecord. Un rol similar • peewee (Python)
es el que tiene el módulo DBIx::Class para el framework
basado en Perl Catalyst, aunque otras elecciones también
son posibles. 115.5 Enlaces relacionados
• Patrón de diseño Association Table Mapping:
• Introducción a JPA
Capítulo 116

Máquina de estados

Se denomina máquina de estados a un modelo de com- compleja, depender de la entrada actual (no sólo del
portamiento de un sistema con entradas y salidas, en don- estado) y pudiendo también prescindirse de un esta-
de las salidas dependen no sólo de las señales de entradas do inicial.
actuales sino también de las anteriores.
Las máquinas de estados se de nen como un conjunto de La bibliografía a veces llama autómata finito a las acep-
estados que sirve de intermediario en esta relación de en- toras, mientras que en otros casos se emplea autómata
tradas y salidas, haciendo que el historial de señales de como sinónimo de máquina de estados sin importar su
entrada determine, para cada instante, un estado para la tipo.
máquina, de forma tal que la salida depende únicamente Las aceptoras son los de mayor interés en la Teoría de
del estado y las entradas actuales. la Computación, más precisamente en la Teoría de autó-
Una máquina de estados se denomina máquina de esta- matas, siendo éstas ramas de la matemática. Las trans-
dos finitos (FSM por nite state machine) si el conjunto ductoras, en cambio, lo son en la electrónica digital y la
de estados de la máquina es nito, este es el único tipo de computación práctica. Es por eso que, por lo general, en
máquinas de estados que podemos modelar en un compu- los textos sobre matemática y ciencias de la computación
tador en la actualidad; debido a esto se suelen utilizar los se suele hablar de autómatas (y se re eren a las acepto-
términos máquina de estados y máquina de estados ni- ras) mientras que los de electrónica y computación prác-
tos de forma intercambiable. Sin embargo un ejemplo de tica hablan de máquinas de estados (y se re eren a los
una máquina de estados infinitos sería un computador transductoras).
cuántico esto es debido a que los Qubit que utilizaría es- En UML (Lenguaje Uni cado de Modelado), dice que
te tipo de computadores toma valores continuos, en con- una máquina de estado es aquel comportamiento que per-
traposición los bits toman valores discretos (0 ó 1). Otro mite hacer un seguimiento de la vida de un objeto en el
buen ejemplo de una máquina de estados in nitos es una transcurso de un tiempo nito.
Máquina universal de Turing la cual se puede de nir teó-
ricamente con una “cinta”o memoria in nita.
La representación de una máquina de estados se realiza
mediante un Diagrama de estados, sin embargo también
es posible utilizar un Diagrama de ujo.
Es posible clasi car las máquinas de estados en aceptoras
o transductoras:

• Aceptoras (también llamadas reconocedoras o

discriminadoras): Son aquellas en donde la salida
es binaria (sí/no), depende únicamente del estado y
existe un estado inicial. Puede decirse, entonces, que
cuando la máquina produce una salida“positiva”(es
decir, un“si”), es porque ha“reconocido”o“acep-
tado”la secuencia de entrada. En las máquinas de
estados aceptoras, los estados con salida “positiva”
se denominan estados nales.

• Transductoras: Son las más generales, que convier-

ten una secuencia de señales de entrada en una se-
cuencia de salida, pudiendo ésta ser binaria o más

231
Capítulo 117

Máquina desnuda

En informática, cuando no hay un núcleo (S.O.) instalado

en el hardware, se suele decir que es una máquina des-
nuda. Suelen ser sistemas sencillos, que ejecutan alguna
tarea cuando se produce una interrupción, y que el resto
del tiempo ejecutan una tarea idle muy básica, normal-
mente que no hace nada.
Suelen usarse en los sistemas en tiempo real, cuando el
número y complejidad de las tareas es pequeño.
En las máquinas desnudas suelen usarse las máquinas de
estados. Es decir, se supone que el comportamiento de
nuestra máquina puede modelarse como una máquina de
estados. La rutina de interrupción lo que nos daría es el
estado al que tiene que cambiar. Esto fue muy popular,
incluso hay herramientas que generan automáticamente
el código de cambios entre estados. Pero no es buena idea
para las aplicaciones complejas.

232
Capítulo 118

MCML

MCML (acrónimo del inglés Media Center Markup

Language, Lenguaje de Formato para Centro de Multime-
dios en español) es el lenguaje de formato para la interfaz
de usuario para el centro de Multimedios (Media Center)
de Windows Vista, el cual es la forma nativa en la cual
se crean las interfaces de usuarios en este ambiente de
desarrollo.
MCML es un lenguaje declarativo basado en XML, op-
timizado para describir grá camente interfaces de usua-
rios visuales ricas desde el punto de vista grá co, tales co-
mo las creadas por medio de Macromedia Flash. XAML,
XUL y UIML son otros ejemplos de lenguajes de interfaz
basados en XML.
En su uso típico, los archivos tipo MCML serían produ-
cidos por una herramienta de desarrollo, como Microsoft
Visual Studio. El XML resultante es interpretado en
forma instantánea por un sub-sistema de despliegue de
Windows Vista denominado Windows Media Center, el
cual está orientado a la visualización del contenido del
computador a mayor distancia que la normal, similar a la
que se acostumbra para un aparato de televisión y utili-
zando un control remoto en lugar de un teclado y un mou-
se. Debido a esto las interfaces de usuario para Media
Center están construidas bajo premisa diferentes, pues
deben tomar en cuenta el hecho de que sus usuarios esta-
rán utlizándolas a una distancia mayor y por medio de dis-
positivos de control no convencionales. Los elementos de
XAML se interconectan con objetos del Entorno Común
de Ejecución para Lenguajes. Los atributos se conectan
con propiedades o eventos de esos objetos.
MCML fue diseñado para soportar las clases y métodos
de la plataforma de desarrollo .NET que tienen relación
con la interacción con el usuario, en especial el despliegue
en pantalla.

118.1 Véase también

• Media Center

• Xbox 3∨0
• XAML

233
Capítulo 119

Metaprogramación

La metaprogramación consiste en escribir programas

que escriben o manipulan otros programas (o a sí mis-
mos) como datos, o que hacen en tiempo de compilación
parte del trabajo que, de otra forma, se haría en tiempo
de ejecución. Esto permite al programador ahorrar tiem-
po en la producción de código.
Un ejemplo sencillo de un metaprograma sería este script
de Bash:
#!/bin/bash # metaprogram echo '#!/bin/bash' >program
for ((I=1; I<=992; I++)); do echo“echo $I”>>program
done chmod +x program

Este script genera un nuevo programa que imprime por

pantalla los números 1 a 992. Esto es sólo una muestra de
cómo usar código para escribir más código, no la forma
más e ciente de imprimir una lista de números. En cual-
quier caso, un buen programador puede escribir y eje-
cutar este metaprogama en apenas un par de minutos, y
habrá generado exactamente 1000 líneas de código en esa
cantidad de tiempo.
La herramienta de metaprogramación más común es el
compilador, el cual permite al programador escribir un
programa relativamente corto en un lenguaje de alto ni-
vel para, posteriormente, escribir un programa equivalen-
te en lenguaje ensamblador o lenguaje máquina. Esto, por
lo general, signi ca un buen ahorro de tiempo si se com-
para con la posibilidad de escribir el programa en lengua-
je máquina de forma directa.
Otro ejemplo bastante común de metaprogramación se
puede encontrar en el uso de Lex (véase también: Flex) y
Yacc (véase también: bison), que son usados para generar
compiladores e intérpretes.

119.1 Enlaces externos

234
Capítulo 120

Microformatos Dublin Core

Microformatos Dublin Core, es un proyecto cuyo ob-

jetivo es usar los elementos de la Iniciativa de Metadatos
de Dublin Core, con la sintaxis de los microformatos, con
el propósito general de describir recursos, especialmente
recursos bibliográ cos.
Para codi car un Microformato Dublin Core, debemos
crear un elemento de [X]HTML contenedor (por ejemplo
el elemento DL) de la clase dublincore.
Dentro de este elemento contenedor, debemos indicar de
forma inequívoca el concepto que se va a expresar a través
del microformato (por ejemplo, título).
Por último, debemos usar una etiqueta de [X]HTML con
una clase cuyo valor sea uno de los elementos de la Inicia-
tiva de Metadatos de Dublin Core, y son los siguientes:
- Elementos del conjunto de metadatos de Dublin Co-
re: contributor, coverage, creator, date, description, for-
mat, identi er, language, publisher, relation, rights, sour-
ce, subject, title y type.
- Otros elementos y elementos re nados de Dublin Core:
abstract, accessRights, accrualMethod, accrualPolicy, al-
ternative, audience, avaliable, bibliographicCitation, con-
formsTo, created, dateAccepted, dateCopyrighted, date-
Submited, educationLevel, extent, hasFormat, hasPart,
hasVersion, instructionalMethod, isFormatOf, isPartOf,
isReferencedBy, isReplacedBy, isRequiredBy, issued, is-
VersionOf, license, mediator, medium, modi ed, prove-
nance, references, replaces, requires, rightsHolder, spa-
tial, tableOfContents, temporal y valid.

23∧
Capítulo 121

Modelo de prototipos

El Modelo de prototipos, en Ingeniería de software, per- La construcción de prototipos se puede utilizar como un
tenece a los modelos de desarrollo evolutivo. El prototipo modelo del proceso independiente, se emplea más co-
debe ser construido en poco tiempo, usando los progra- múnmente como una técnica susceptible de implemen-
mas adecuados y no se debe utilizar muchos recursos. tarse dentro del contexto de cualquiera de los modelos
del proceso expuestos. Sin importar la forma en que és-
El diseño rápido se centra en una representación de aque-
llos aspectos del software que serán visibles para el cliente te se aplique, el paradigma de construcción de prototipos
ayuda al desarrollado de software y al cliente a entender
o el usuario nal. Este diseño conduce a la construcción
de un prototipo, el cual es evaluado por el cliente para una de mejor manera cuál será el resultado de la construcción
cuando los requisitos estén satisfechos. De esta manera,
retroalimentación; gracias a ésta se re nan los requisitos
del software que se desarrollará. La interacción ocurre este ciclo de vida en particular, involucra al cliente más
profundamente para adquirir el producto.
cuando el prototipo se ajusta para satisfacer las necesi-
dades del cliente. Esto permite que al mismo tiempo el
desarrollador entienda mejor lo que se debe hacer y el
cliente vea resultados a corto plazo. 121.3 Inconvenientes
• El usuario tiende a crearse unas expectativas cuando
ve el prototipo de cara al sistema nal. A causa de la
121.1 Etapas intención de crear un prototipo de forma rápida, se
suelen desatender aspectos importantes, tales como
• Plan rápido. la calidad y el mantenimiento a largo plazo, lo que
obliga en la mayor parte de los casos a reconstruirlo
• Modelado, diseño rápido
una vez que el prototipo ha cumplido su función. Es
• Construcción del Prototipo frecuente que el usuario se muestre reacción a ello y
pida que sobre ese prototipo se construya el sistema
• Desarrollo, entrega y retroalimentación nal, lo que lo convertiría en un prototipo evoluti-
vo, pero partiendo de un estado poco recomendado.
• Comunicación
• En aras de desarrollar rápidamente el prototipo, el
• Entrega del desarrollo nal desarrollador suele tomar algunas decisiones de im-
plementación poco convenientes (por ejemplo, ele-
gir un lenguaje de programación incorrecto porque
proporcione un desarrollo más rápido). Con el paso
121.2 Ventajas del tiempo, el desarrollador puede olvidarse de la ra-
zón que le llevó a tomar tales decisiones, con lo que
• Este modelo es útil cuando el cliente conoce los ob- se corre el riesgo de que dichas elecciones pasen a
jetivos generales para el software, pero no identi ca formar parte del sistema nal...
los requisitos detallados de entrada, procesamiento
o salida.

• También ofrece un mejor enfoque cuando el respon-

121.4 Conclusiones
sable del desarrollo del software está inseguro de la
e cacia de un algoritmo, de la adaptabilidad de un A pesar de que tal vez surjan problemas, la construcción
sistema operativo o de la forma que debería tomar de prototipos puede ser un paradigma efectivo para la in-
la interacción humano-máquina geniería del software. La clave es de nir las reglas del
juego desde el principio; es decir, el cliente y el desarro-
• Se puede reutilizar el codigo llador se deben poner de acuerdo en:

23∨
121.5. VÉASE TAMBIÉN 23∩

• Que el prototipo se construya y sirva como un me-

canismo para la de nición de requisitos.
• Que el prototipo se descarte, al menos en parte.

• Que después se desarrolle el software real con un

enfoque hacia la calidad.

121.5 Véase también

• Ingeniería de software

• Ingenierías del software

Capítulo 122

Modi cador

Un modi cador es un conjunto de funciones de

programación del lenguaje C que se aplican a las variables
dentro de la estructura de un programa antes de que éste
sea mostrado.
Los modi cadores pueden ir encadenados, y son rutinas
que distorsionan la forma de los objetos de una manera
determinada, sin cambiar su naturaleza. Así por ejemplo
CALIF_FINAL es una variable numérica y su modi ca-
dor informará si se utilizará en todo el programa o solo
en parte de él.

122.1 Enlaces externos

• Lenguaje C: Ámbito de funciones y variables, Ri-
chard A. Sequera.

23∪
Capítulo 123

Modularidad

La modularidad es la capacidad que tiene un sistema 123.3 Modularidad en Economía y

de ser estudiado, visto o entendido como la unión de va-
rias partes que interactúan entre sí y que trabajan para
en la Empresa
alcanzar un objetivo común, realizando cada una de ellas
una tarea necesaria para la consecución de dicho objeti- En economía y en la empresa, la modularidad de los pro-
vo. Cada una de esas partes en que se encuentre dividido ductos, servicios y procesos es un factor clave en el desa-
* *
el sistema recibe el nombre de módulo. Idealmente un rrollo tecnológico, económico y social. [1] [2]
módulo debe poder cumplir las condiciones de caja ne-
gra, es decir, ser independiente del resto de los módulos
y comunicarse con ellos (con todos o sólo con una parte) 123.4 Modularidad en el diseño
a través de unas entradas y salidas bien de nidas.

123.1 Modularidad en Ciencias de

la Computación

Modularidad en Ciencias de la computación es la ca-

racterística por la cual un programa de computador
está compuesto de porciones que se conocen como
módulos. El diseño estructurado es la técnica de diseño
El llamado Phonebloks es un buen ejemplo de un diseño modu-
de algoritmos en que se basa la programación modular,
lar.
paradigma de programación que persigue desarrollar pro-
gramas modulares
La modularidad en el diseño permite diseñar bienes ba-
sados en la modulación reticular de espacios que permi-
tan optimizar el tiempo de construcción y debido a que
son transportables, desarmables y reorganizables permi-
ten impulsar múltiples funcionalidades y su reutilización
al generar un nuevo uso diferente al que fueron fabrica-
123.2 Modularidad en Biología dos. Un ejemplo podría ser el proyecto Phonebloks, que
permitiría diseñar un teléfono móvil en piezas separadas
que el usuario podría intencambiar entre sí.
En biología, la modularidad es una propiedad de los orga-
nismos (y de sus partes) por la cual estos pueden descom-
ponerse en módulos. Los módulos son unidades coheren-
tes que a su vez forman parte de unidades más amplias: las 123.5 Referencias
células son parte de los tejidos, que a su vez son partes de
los órganos, que a su vez son partes de los organismos. La [1] Baldwin, Carliss (2000) Design Rules, Vol. 1: The Power
modularidad aparece también en el desarrollo; son módu- of Modularity
los los campos morfogenéticos, los patrones de desarro-
llo, los discos imaginales, los linajes celulares o los para- [2] Carliss Y. Baldwin Home Page en la Harvard Business
segmentos de los insectos. School [Link]

239
240 CAPÍTULO 123. MODULARIDAD

123.6 Véase también

• Módulo
• Programación modular

• Morfología (biología)
• Diseño modular
Capítulo 124

Módulo (informática)

En programación un módulo es una porción de un lles internos de otros módulos. Como consecuencia
programa de ordenador. De las varias tareas que debe de la independencia modular un módulo cumplirá:
realizar un programa para cumplir con su función u ob-
jetivos, un módulo realizará, comúnmente, una de dichas • Características de caja negra, es decir
tareas (o varias, en algún caso). abstracción (ver abstracción en progra-
En general (no necesariamente relacionado con la pro- mación orientada a objetos).
gramación), un módulo recibe como entrada la salida que • Aislamiento de los detalles mediante en-
haya proporcionado otro módulo o los datos de entrada al capsulamiento (ver encapsulamiento en
sistema (programa) si se trata del módulo principal de és- programación orientada a objetos).
te; y proporcionará una salida que, a su vez, podrá ser uti-
lizada como entrada de otro un módulo o bien contribuirá La independencia modular mejora el ren-
directamente a la salida nal del sistema (programa), si
dimiento humano, pudiendo realizarse pro-
se retorna al módulo principal. gramación en equipo y desarrollar módu-
Particularmente, en el caso de la programación, los mó- los paralelamente. También contribuye a la
dulos suelen estar (no necesariamente) organizados jerár- reutilización de software.
quicamente en niveles, de forma que hay un módulo prin-
cipal que realiza las llamadas oportunas a los módulos de
nivel inferior. 124.2 Véase también
Cuando un módulo es convocado, recibe como entrada
los datos proporcionados por otro del mismo o superior • Algoritmo
nivel, el que ha hecho la llamada; luego realiza su tarea.
A su vez este módulo convocado puede llamar a otro u • Programa
otros módulos de nivel inferior si fuera necesario; cuando • Modularidad
ellos nalizan sus tareas, devuelven la salida pertinente al
módulo inmediato llamador, en secuencia reversa, nal- • Diseño estructurado
mente se continúa con la ejecución del módulo principal.
• Programación modular

124.1 Características de un módu-

lo
Cada uno de los módulos de un programa idealmente de-
bería cumplir las siguientes características:

• Tamaño relativamente pequeño.- Esto facilita

aislar el impacto que pueda tener la realización de un
cambio en el programa, bien para corregir un error,
o bien por rediseño del algoritmo correspondiente.

• Independencia modular.- Cuanto más indepen-

dientes son los módulos entre sí más fácil y exible-
mente se trabajará con ellos, esto implica que para
desarrollar un módulo no es necesario conocer deta-

241
Capítulo 125

Monitor (concurrencia)

En la programación paralela, los monitores son objetos 125.2 Exclusión mutua en un mo-
destinados a ser usados sin peligro por más de un hilo de
ejecución. La característica que principalmente los de ne
nitor
es que sus métodos son ejecutados con exclusión mutua.
Lo que signi ca, que en cada momento en el tiempo, un Los monitores están pensados para ser usados en entor-
hilo como máximo puede estar ejecutando cualquiera de nos multiproceso o multihilo, y por lo tanto muchos pro-
sus métodos. Esta exclusión mutua simpli ca el razona- cesos o threads pueden llamar a la vez a un procedimiento
miento de implementar monitores en lugar de código a del monitor. Los monitores garantizan que en cualquier
ser ejecutado en paralelo. momento, a lo sumo un thread puede estar ejecutando
dentro de un monitor. Ejecutar dentro de un monitor sig-
En el estudio y uso de los semáforos se puede ver que las ni ca que sólo un thread estará en estado de ejecución
llamadas a las funciones necesarias para utilizarlos que- mientras dura la llamada a un procedimiento del moni-
dan repartidas en el código del programa, haciendo difícil tor. El problema de que dos threads ejecuten un mismo
corregir errores y asegurar el buen funcionamiento de los procedimiento dentro del monitor es que se pueden dar
algoritmos. Para evitar estos inconvenientes se desarro- condiciones de carrera, perjudicando el resultado de los
llaron los monitores. El concepto de monitor fue de nido cálculos. Para evitar esto y garantizar la integridad de los
por primera vez por Charles Antony Richard Hoare en un datos privados, el monitor hace cumplir la exclusión mu-
artículo del año 19∩4.* [1] La estructura de los monitores tua implícitamente, de modo que sólo un procedimiento
se ha implementado en varios lenguajes de programación, esté siendo ejecutado a la vez. De esta forma, si un thread
incluido Pascal concurrente, Modula-2, Modula-3 y Java, llama a un procedimiento mientras otro thread está dentro
y como biblioteca de programas. del monitor, se bloqueará y esperará en la cola de entrada
hasta que el monitor quede nuevamente libre. Aunque se
la llama cola de entrada, no debería suponerse ninguna
política de encolado.
125.1 Componentes Para que resulten útiles en un entorno de concurrencia, los
monitores deben incluir algún tipo de forma de sincroni-
Un monitor tiene cuatro componentes: inicialización, da- zación. Por ejemplo, supóngase un thread que está dentro
tos privados, métodos del monitor y cola de entrada. del monitor y necesita que se cumpla una condición para
poder continuar la ejecución. En ese caso, se debe contar
con un mecanismo de bloqueo del thread, a la vez que se
• Inicialización: contiene el código a ser ejecutado debe liberar el monitor para ser usado por otro hilo. Más
cuando el monitor es creado tarde, cuando la condición permita al thread bloqueado
continuar ejecutando, debe poder ingresar en el monitor
en el mismo lugar donde fue suspendido. Para esto los
• Datos privados: contiene los procedimientos priva- monitores poseen variables de condición que son accesi-
dos, que sólo pueden ser usados desde dentro del bles sólo desde adentro. Existen dos funciones para ope-
monitor y no son visibles desde fuera rar con las variables de condición:

• Métodos del monitor: son los procedimientos que • cond_wait(c): suspende la ejecución del proceso que
pueden ser llamados desde fuera del monitor. la llama con la condición c. El monitor se convierte
en el dueño del lock y queda disponible para que otro
proceso pueda entrar.
• Cola de entrada: contiene a los hilos que han llama-
do a algún método del monitor pero no han podido • cond_signal(c): reanuda la ejecución de algún pro-
adquirir permiso para ejecutarlos aún. ceso suspendido con cond_wait bajo la misma con-

242
125.4. VERIFICACIÓN DE MONITORES 243

dición c. Si hay varios procesos con esas caracterís- ejecutarlo a seguir con el proceso despertante.
ticas elige uno. Si no hay ninguno, no hace nada.
Desventajas:
Nótese que, al contrario que los semáforos, la llamada a
cond_signal(c) se pierde si no hay tareas esperando en la
• Si el proceso que ejecuta cond_signal no terminó
variable de condición c.
con su ejecución se necesitarán dos cambios de con-
Las variables de condición indican eventos, y no poseen texto para que vuelva a tomar el lock del monitor.
ningún valor. Si un thread tiene que esperar que ocurra
un evento, se dice espera por (o en) la variable de condi- • Al despertar a un thread que espera en una variable
ción correspondiente. Si otro thread provoca un evento, de condición, se debe asegurar que reanude su ejecu-
simplemente utiliza la función cond_signal con esa con- ción inmediatamente. De otra forma, algún otro th-
dición como parámetro. De este modo, cada variable de read podría cambiar la condición. Esto implica que
condición tiene una cola asociada para los threads que es- la plani cación debe ser muy able, y di culta la im-
tán esperando que ocurra el evento correspondiente. Las plementación.
colas se ubican en el sector de datos privados visto ante-
riormente.
La política de inserción de procesos en las colas de las
125.3.2 Tipo Mesa
variables condición es la FIFO, ya que asegura que ningún
Butler W. Lampson y David D. Redell en 19∪0 desarro-
proceso caiga en la espera inde nida, cosa que sí ocurre
llaron una de nición diferente de monitores para el len-
con la política LIFO (puede que los procesos de la base
guaje Mesa que lidia con las desventajas de los monitores
de la pila nunca sean despertados) o con una política en
de tipo Hoare y añade algunas características.
la que se desbloquea a un proceso aleatorio.
En los monitores de Lampson y Redell el thread que eje-
cuta cond_signal sobre una variable de condición conti-
125.3 Tipos de monitores núa con su ejecución dentro del monitor. Si hay otro th-
read esperando en esa variable de condición, se lo des-
pierta y deja como listo. Podrá intentar entrar el monitor
Antes se dijo que una llamada a la función cond_signal
cuando éste quede libre, aunque puede suceder que otro
con una variable de condición hacía que un proceso que
thread logre entrar antes. Este nuevo thread puede cam-
estaba esperando por esa condición reanudara su ejecu-
biar la condición por la cual el primer thread estaba dur-
ción. Nótese que el thread que reanuda su ejecución nece-
miendo. Cuando reanude la ejecución el durmiente, debe-
sitará obtener nuevamente el lock del monitor. Surgen las
ría veri car que la condición efectivamente es la que ne-
siguientes preguntas: ←Qué sucede con el thread que hizo
cesita para seguir ejecutando. En el proceso que durmió,
el cond_signal? ←Pierde el lock para dárselo al thread que
por lo tanto, es necesario cambiar la instrucción if por
esperaba? ←Qué thread continúa con su ejecución? Cual-
while, para que al despertar compruebe nuevamente la
quier solución debe garantizar la exclusión mutua. Según
condición, y de no ser cierta vuelva a llamar a cond_wait.
quién continúa con la ejecución, se diferencian dos tipos
de monitores: Hoare y Mesa. Además de las dos primitivas cond_wait(c) y
cond_signal(c), los monitores de Lampson y Redell
poseen la función cond_broadcast(c), que noti ca a los
125.3.1 Tipo Hoare threads que están esperando en la variable de condición
c y los pone en estado listo. Al entrar al monitor,
En la de nición original de Hoare, el thread que ejecuta cada thread veri cará la condición por la que estaban
cond_signal le cede el monitor al thread que esperaba. El detenidos, al igual que antes.
monitor toma entonces el lock y se lo entrega al thread
Los monitores del tipo Mesa son menos propensos a erro-
durmiente, que reanuda la ejecución. Más tarde cuando
res, ya que un thread podría hacer una llamada incorrecta
el monitor quede libre nuevamente el thread que cedió el
a cond_signal o a cond_broadcast sin afectar al thread en
lock volverá a ejecutar.
espera, que veri cará la condición y seguirá durmiendo
Ventajas: si no fuera la esperada.

• El thread que reanuda la ejecución puede hacerlo

inmediatamente sin jarse si la condición se cum- 125.4 Veri cación de monitores
ple, porque desde que se ejecutó cond_signal hasta
que llegó su turno de ejecutar ningún proceso puede
cambiarla. La corrección parcial de un monitor se puede demostrar
veri cando que los invariantes de representación del mo-
• El thread despertado ya estaba esperando desde an- nitor se cumplen en cualquier caso. El Invariante de re-
tes, por lo que podría suponerse que es más urgente presentación es el conjunto de estados del monitor que lo
244 CAPÍTULO 125. MONITOR (CONCURRENCIA)

hacen correcto. Dicha veri cación se puede realizar me- en espera vuelva a ser ejecutado, debe garantizarse que el
diante axiomas y reglas de inferencia como, por ejemplo, invariante del monitor sigue siendo válido.
los propuestos por la Lógica de Hoare. {IM ∧ L}wait(){IM ∧ L}
Los procesos bloqueados, se desbloquean con
125.4.1 Inicialización de las variables del cond_signal o con cond_broadcast pero, esta vez,
monitor el proceso que llama a cond_signal sigue ejecutándose y
utilizando el monitor. Es decir, en éste tipo de monitores,
El código de inicialización debe incluir la asignación de señalar a otro proceso no puede provocar un cambio
las variables del monitor antes de que los procedimientos ni en las variables locales el procedimiento ni en las
del monitor puedan ser usados. La inicialización de éstas variables del monitor. * [2]
variables debe estar acorde al Invariante de representa-
ción del monitor.
{V }inicializacion{IM } 125.5 Véase también
Donde IM es el invariante del monitor.
• Semáforos
• Cierres de exclusión mutua (Locks)
125.4.2 Monitores tipo Hoare
En monitores con señales desplazantes, cond_signal y
cond_wait hacen referencia a estados visibles del progra- 125.6 Referencias
ma. cond_wait implica la cesión de la exclusión mútua
del monitor. Por lo tanto, debe veri car el Invariante del [1] Hoare, Charles Antony (octubre de 19∩4). «Monitors: An
monitor antes de que pueda ejecutarse. Operating System Structuring Concept». ACM 17: ∧49–
∧∩. Consultado el 9 de diciembre de 2012.
{IM ∧ L}wait(){C ∧ L}
[2] Capel Tuñón, Rodríguez Valenzuela (2012). Sistemas
Donde: Concurrentes y Distribuídos. Copicentro. pp. ∪9–92. ISBN
9∩∪-∪4-1∧∧3∨-∨∪-0.
• L son el invariante del conjunto de variables locales
del procedimiento.
• C es la condición de desbloqueo, que se hace cierta
tras terminar la ejecución de cond_wait.

En cuanto a la operación signal en señales desplazantes.

Cuando se llama a cond_signal, se produce la interrup-
ción inmediata del procedimiento señalador y la reanu-
dación de un proceso bloqueado en la cola de condición.
Por lo tanto, todos los invariantes que eran ciertos antes
de la ejecución de signal, se mantendrán, igualmente, co-
mo ciertos en el proceso señalado, tras la ejecución de
cond_wait.
{¬vacio(colaCondicion) ∧ L ∧ C}signal(){IM ∧ L}
Nótese que la precondición de cond_signal coincide con
la postcondición de wait, así como la precondición de
cond_wait coincide con la postcondición de signal.
La razón por la cual la condición de desbloqueo, c, no
forma parte de la postcondición de signal es que, una vez
que el proceso señalado ha reanudado su ejecución, puede
hacer falsa ésta condición. Luego, no es posible garanti-
zar que el invariante de la condición de desbloqueo sea
cierto.* [1]

125.4.3 Monitores tipo Mesa

cond_wait, al igual que con señales desplazantes, bloquea
el proceso y cede el uso del monitor. Cuando el proceso
Capítulo 126

Anexo:Motores de persistencia

Esta es una lista alfabética de los principales motores • Ebean

de mapeo objeto relacional, indicando si son libres o
comerciales. • Enterprise Objects Framework

• FireStorm/DAO
126.0.1 ColdFusion • Hibernate, , muy usado.
• Arf ARF - Active Record Factory • Hydrate
• CFCPowerTools Generación Batch de tu capa de • iBATIS
datos en pocos minutos.
• intelliBO de Signsoft , implementación de JDO.
• Reactor Reactor es un sencillo API para ColdFu-
sion que abstrae la base de datos al vuelo según se • Java Data Objects (JDO)
necesite.
• JDBCPersistence
• objectBreeze objectBreeze crea objetos directa-
mente desde tu capa de persistencia. • JDX

• Transfer Transfer es una librería para generar obje- • JPOX

tos de negocio al vuelo y abstraer las transacciones
sobre ellos. • Kōdō

• Lychee
126.0.2 Common Lisp • OpenAccess
• CLSQL • OJB,
• cl-perec • OpenJPA,
• elephant • POEM,
• postmodern • PriDE
• submarine
• SavePoint

• SimpleORM
126.0.3 Java
• Speedo
• BuzzSQL
• TopLink de Oracle
• Carbonado
• Torque de ASF
• Castor
• WebObjects de Apple.
• Cayenne
• CocoBase PURE POJO V∧ For JPA Primera he-
rramienta ORM Java (199∩) 126.0.4 JavaScript
• CrossDB • GearsORM

24∧
24∨ CAPÍTULO 126. ANEXO:MOTORES DE PERSISTENCIA

126.0.5 .NET • [Link] (open source)

• .netTiers • [Link]

• Briyante Integration Environment • [Link] (open source)

• Business Logic Toolkit for .NET (open source) • Signum Framework (open source)

• Castle ActiveRecord (open source) • Sooda (open source)

• CodeFluent Entities • Subsonic (DAL) (open source)

• Data Tier Modeler , reemplazado por Euss. • Wilson ORMapper for .NET

• DataBlock (open source)

126.0.6 Perl
• [Link]
• Class::DBI (open source)
• dOOdads , (freeware)
• Rose::DB::Object (open source)
• [Link] (open source)
• OOPS (open source)
• EntitySpaces
• ORM (open source)
• eXpress Persistent Objects for .NET
• DBIx::Class (open source)
• Euss (Evaluant Universal Storage Services) (open
source) • Alzabo (open source)
• Genom-e • Tangram (Perl) (open source)
• [Link] (open source)
• GenWise Studio 126.0.7 PHP
• GURA • ADOdb Active Record , (open source)

• Habanero • CakePHP (open source)

• [Link] • Doctrine (open source)

• IdeaBlade DevForce • DB DataObject (open source)

• [Link] • EZPDO (open source)

• LightSpeed • Junction PHP (open source)

• LLBLGen Pro • KohanaPHP (open source)

• LLBLGen (open source) • Metastorage (open source)

• NConstruct • PhpMyObject (open source)

• Neo (open source) • PHP Object Generator (POG) (open source)

• NHibernate (open source) • [Link] (open source)

• NJDX • Propel (open source)

• Nolics • QCodo (open source)

• Opf3 • Symfony (open source)

• ObjectMagix • Syrius (open source)

• ObjectMapper .NET (open source) • xPDO (open source)

• [Link] (open source) • Xyster Framework (open source)
• OpenAccess • Yupp PHP Framework (open source)
 24∩

126.0.8 Python
• Axiom
• Ape , para [[Zope]
• SQLAlchemy (open source)
• SQLObject (open source)
• PyDO (open source)
• PyDO2
• MiddleKit, parte de Webware (open source)
• Modeling
• ForgetSQL (open source)
• QLime (open source)
• Storm (open source)
• The open source Django web framework
• Dejavu
• Twisted Asynchronous Database Api (open source)
• PyDAO

126.0.9 Ruby
• Active Record , parte de Ruby on Rails (open sour-
ce)
• Og part of Nitro (open source)
• Rubernate
• Lafcadio
• Sequel
• DataMapper
• Momomoto , para PostgreSQL
• Kansas

126.0.10 Smalltalk
• GLORP (open source)

126.0.11 C++
• DTL
• DataXtend CE for C++
• Object Builder
• SOCI
• StactiveRecord (open source)
Capítulo 127

Método de depuración del patito de goma

• Revision estructurada
• Programación en pareja

127.2 Referencias
[1] The Pragmatic Programmer: From Journeyman to Master.
Addison Wesley. ISBN 9∩∪-0201∨1∨224. p. 9∧, footnote.

[2] Baker, SJ, The Contribution of the Cardboard Cutout Dog

to Software Reliability and Maintainability, [Link]
[Link]/humor/cardboard_dog.html.

127.3 Enlaces externos

• «Description of the method», Cant LUG, Ethernal,
[Link]
El patito de goma es usado por un desarrollador para ayudar en msg001∩[Link].
la revisión de código
• Rubber duck debugging, [Link]
El método de depuración del patito de goma es un tér- [Link]/: site honoring the
mino informal utilizado en ingeniería de software para method.
describir un método de revisión de código. El nombre es
una referencia a una historia del libro The Pragmatic Pro- • Rubber Duck Problem Solving, http:
grammer en donde un programador toma un patito de go- //[Link]/blog/2012/03/
ma y revisa su código forzándose a sí mismo a explicarlo, [Link]: Coding
línea por línea, al pato.* [1] Existen otros muchos térmi- Horror blog.
nos para esta técnica, que a menudo tienen que ver con
objetos inanimados.
Muchos programadores han tenido una experiencia de
explicar un problema de programación a alguien más,
posiblemente a alguien que no sabe nada sobre progra-
mación, y luego encuentran la solución en el proceso de
explicar el problema. Al comparar lo que supuestamen-
te hace el código con lo que hace en realidad, cualquier
incongruencia resulta nítida.* [2] Usando un objeto inani-
mado, el programador puede tratar de completar esto sin
tener que involucrar además a otra persona.

127.1 Véase también

• Revisión de código

24∪
Capítulo 128

Net Yaroze

La Net Yaroze (ネットやろうぜ netto yarōze* ?) era • 1 cable de comunicación, para conectar la consola al
un kit de desarrollo de software de Sony Computer En- PC mediante tipo serie
tertainment creado en 199∩ para juegos de PlayStation.
Estaba enfocado a los desarrolladores a cionados. Yaro- • 1 guía de iniciación
ze signi ca “Vamos a hacerlo juntos”.* [1]
• 1 manual de bibliotecas
Costaba alrededor de los $∩∧0 USD. El pack incluía, ade-
más de la consola, que era idéntica a la Playstation pero • 1 guía de usuario
en negro, documentación y software. No incluía bloqueo
regional.* [2] Para usarla, el usuario necesitaba tener un A pesar de ser un kit de desarrollo para juegos de PlayS-
ordenador personal IBM, Macintosh o NEC PC-9∪01. tation, la Net Yaroze carecía de varias características
Así, el usuario, en el propio ordenador escribía el códi- que sí tenían los desarrolladores de PlayStation. No tenía
go del juego, lo compilaba y lo enviaba a la Net Yaroze hardware avanzado, software, bibliotecas, herramientas
para probarlo. varias y una amplia asistencia técnica de Sony. Además,
A pesar de no tener bloqueo regional, existían tres ver- los grupos de Usenet existentes, estaban restringidos a los
siones, la japonesa, la americana y la europea/australiana. miembros de Net Yaroze, lo que provocó que la colabo-
La principal diferencia entre ellas era que, las versiones ración entre usuarios fuese poco práctica.
europea/australiana era en modo Pal mientras que la ver- La memoria principal de la Net Yaroze era la misma que
sión japonesa y americana tenía modo NTSC. Entre la la de la PlayStation, de 2 Megabytes. Sin embargo, la Net
versión japonesa y americana, la diferencia estaba en el Yaroze tenía una memoria secundaria extra que ofrecía
idioma del manual, el software para PC japoneses, discos 1,∧ megabytes más a la consola. Así pues, contaba con
y los diferentes dibujos en las calcomanías. Extrao cial- un total de 3,∧ megabytes de memoria RAM. Esta capa-
mente, la versión japonesa es llamada DTL-3000 en lugar cidad era la que marcaba el espacio total del juego, es de-
de DTL-H3000. cir, lo que tenía que ocupar como mucho su código fuen-
La Net Yaroze estaba sólo disponible a través de pedido te, grá cos, música y bibliotecas, pues todo esto debía
por correo. No obstante, Sony, proporcionó este kit a al- de instalarse para poder ser probado. No obstante, exis-
gunas universidades del Reino Unido, Francia (Epita) y ten muchos títulos comerciales que están completamente
Japón.* [3] instalados en la RAM, a excepción del sonido, y podrían
haber sido desarrollados complemente con la Net Yaroze.
El kit europeo de la Net yaroze contenía:
Muchos títulos desarrollados por a cionados con la Net
Yaroze fueron distribuidos con la PlayStation: The O -
• 1 Net Yaroze (textura negro mate) cial Magazine en Europa desde diciembre de 199∩ hasta
• 2 controladores de PlayStation (textura negro mate) marzo de 2004. El último número o cial revista PlayS-
tation del Reino Unido, la número 10∪, presentó una re-
• Un cable de alimentación de corriente alterna (con copilación con muchos juegos de la Net Yaroze. Algunos
enchufe para Reino Unido y adaptador para Francia) títulos que salieron con la revista fueron:

• Un conector AV • Haunted maze

• 1 disco de arranque (un CD de PlayStation verde) • Terra Incognita
• 1 CD con el software de desarrollo de Net Yaroze • Blitter Boy
para PC
• The Incredible CONEMAN
• 1 tarjeta de acceso negra, necesaria para el modo
control remoto • Hover car racing

249
2∧0 CAPÍTULO 128. NET YAROZE

• A dog tale

• Adventure game
• Rocksʼn'Gems

• Psychon
• Pushy II

• Between the eyes

• Super bub

• Clone
• Gravitation

• Mah Jongg

No fueron muchos, pero algunos de estos juegos pros-

peraron a nivel comercial, siendo el más famoso de ellos
Devil Dice (Xi en Japón), que entonces llevaba el nombre
de Para-Dice.

128.1 Véase también

• PlayStation

128.2 Enlaces externos

• Sitio de desarrollo no o cial de PlayStation 1
• Sitio no o cial de desarrollo de Net Yaroze

• Net Yaroze (FAQ) Document

• Video mostrando el contenido del kit Net Yaroze

128.3 Referencias
[1] Absolute PlayStation, Section I. «PlayStation FAQ». Ar-
chivado desde el original el 23 de noviembre de 201∧.
Consultado el 1∧ de Junio, 2012.

[2] IGN UK. «NET Yaroze». Archivado desde el original el

23 de noviembre de 201∧. Consultado el 1∧ de Junio,
2012.

[3] IGN UK. «NET Yaroze». Consultado el 1∧ de Junio,

2012.
Capítulo 129

Nodo (informática)

En informática y en telecomunicación, de forma muy ge-

neral, un nodo es un punto de intersección, conexión o
unión de varios elementos que con uyen en el mismo lu-
gar. Ahora bien, dentro de la informática la palabra nodo
puede referirse a conceptos diferentes según el ámbito en
el que nos movamos:

• En redes de computadoras cada una de las máqui-

nas es un nodo, y si la red es Internet, cada servidor
constituye también un nodo. El concepto de red pue-
de de nirse como:

• En estructuras de datos dinámicas un nodo es un

registro que contiene un dato de interés y al menos
un puntero para referenciar (apuntar) a otro nodo. Si
la estructura tiene sólo un puntero, la única estruc-
tura que se puede construir con él es una lista, si el
nodo tiene más de un puntero ya se pueden construir
estructuras más complejas como árboles o grafos.

129.1 Referencias
[1] Castells, Manuel (199∩). La era de la información. Eco-
nomía, sociedad y cultura. Vol I: La sociedad red. Madrid:
Alianza Editorial. ISBN ∪4-20∨-424∩-9.

129.2 Enlaces externos

• Nodo

2∧1
Capítulo 130

Notación Reddick

La notación Reddick en programación informática, es

un sistema usado normalmente para crear los nombres
de variables e identi car rápidamente su tipo de dato. El
nombre de la notación proviene de su inventor Greg Red-
dick.
Esta convención es muy utilizada en las nuevas versiones
de Visual Basic y Visual Basic 200∧. También es muy uti-
lizada por los programadores de Microsoft y en tecnolo-
gías .NET. Consiste en“tags”de tres letras en minúsculas
que se añaden a los nombres de las variables, y que indi-
can su tipo. El resto del nombre indica, lo más claramente
posible, la función que realiza la variable.

130.1 Ejemplo
• intContador: una variable del tipo INTEGER que se
usa como un contador.
• strNombre: variable del tipo STRING que se usa pa-
ra almacenar un nombre.

130.2 Notación para objetos

Esta notación se ha expandido para ser usadas por tipos
de objetos:
En Visual Basic, la notación se ha adaptado a la siguiente:
Object Tag Example Chart (graph) cht chtSales Check
box chk chkReadOnly Combo box cbo cboIndustry
Command button cmd cmdCancel Frame (object) fra
fraPhoto Label lbl lblHelpMessage Line lin linVertical
List box lst lstPolicyCode Option button opt optFrench
Option group grp grpLanguage Page break brk brkPage1
Shape shp shpNamePanel Subform/report sub subCon-
tact Text box txt txtLoginName Toggle button tgl tglForm

130.3 Enlaces externos

• Convenciones RVBA

2∧2
Capítulo 131

Notación húngara

En programación informática, la notación húngara es editores de código inteligente que utilicemos, la mayo-
un sistema usado normalmente para crear los nombres de ría de proyectos siempre acaban teniendo ciertas partes
variables. También se utiliza para nombrar las instancias escritas en lenguajes dinámicamente tipados, en espe-
de objetos en lenguajes de programación visuales, como cial JavaScript, el único implementado por la mayoría de
por ejemplo Delphi. El nombre de la notación proviene navegadores web para ejecutar código en cliente
del hecho de que su inventor, Charles Simonyi, nació en
Puesto que a la hora de realizar proyectos se suelen esta-
Hungría. blecer previamente unas Coding Style Guidelines (Guías
Esta convención es muy poco utilizada en las viejas ver- de estilo de programación), no conviene hacerlas distin-
siones de Delphi pero es muy utilizada por los programa- tas para cada lenguaje y se podría de nir un estándar de
dores de Microsoft y, en particular, en la programación notación húngara que tenga un ligero compromiso con
del sistema operativo Windows. la facilidad de reconocimiento de tipos, sin que llegue a
Consiste en pre jos en minúsculas que se añaden a los suponer un in erno sobre la complejidad de lectura de
nombres de las variables y que indican su tipo. El resto código.
del nombre indica, lo más claramente posible, la función
que realiza la variable. 131.2.1 Ejemplo notaciones de 1 carácter
Este ejemplo de notación húngara no parecerá tan crítico
131.1 Ejemplos y extraño como el que se ha puesto de ejemplo al principio
del artículo, en el cual se llegaban a utilizar hasta cuatro
• nContador: la variable es un entero que se usará co- letras para denotar el tipo.
mo contador.

• szNombre: una cadena terminada con cero la cual

almacena un nombre.
131.3 Véase también
• bRespuesta: una variable booleana que almacena • Programación
una respuesta.
• Sistema operativo
• txtHora: una instancia de un objeto textbox que al-
macena la hora.

131.2 Situación actual

Hoy día existen más detractores que impulsores de la no-
tación húngara. De hecho, se suele cali car de una téc-
nica que a la larga provoca más complejidad que ayu-
da a la mantenibilidad. Máxime cuando la mayoría de
entornos de desarrollo actuales, en particular los que se
usan con lenguajes estáticamente tipados, ofrecen meca-
nismos sencillos para averiguar el tipo de las variables sin
recurrir a la búsqueda de su declaración.
Sin embargo, parece que, como en la mayoría de las si-
tuaciones, en el medio está la virtud, pues por muchos

2∧3
Capítulo 132

Null

El término null o nulo o DG es a menudo utilizado en la

computación, haciendo referencia a la nada.
En programación, null resulta ser un valor especial apli-
cado a un puntero (o referencia) usado para indicar que el
puntero no apunta a un objeto o dato válido. Usualmente
se utiliza el valor 0 (cero) para signi car null, debido a que
muchos sistemas operativos consideran el intentar acce-
der a una dirección de memoria tan baja como un error.
Null es también utilizado en varias otras disciplinas y no
únicamente en programación.
En contexto de bases de datos null se utiliza para indicar
la ausencia de valor asociado a un campo para un deter-
minado registro.
Así mismo se de nen los resultados para null en opera-
ciones lógicas:

Operación “O” Verdadero O null = Verdadero

Falso O null = null

Operación “Y” Verdadero Y null = null

Falso Y null = Falso

2∧4
Capítulo 133

NWNScript

NWNScript es el lenguaje interpretado empleado en el

videojuego Neverwinter Nights y Neverwinter Nights 2.

133.1 Enlaces externos

• NWN Lexicon Referencia online o cial.

2∧∧
Capítulo 134

Objeto todopoderoso

En programación orientada a objetos, un objeto todo- 134.2 Referencias

poderoso (en inglés God Object) es un objeto que conoce
demasiado o hace demasiado. El objeto todopoderoso es • Ravioli code, patrones opuestos.
un ejemplo de un anti-patrón.

134.3 Enlaces externos

• Riel, Arthur J. (199∨). «Chapter 3: Topologies
134.1 Historia of Action-Oriented Vs. Object-Oriented Applica-
tions». Object-Oriented Design Heuristics. Boston,
La idea básica detrás de la Programación Estructurada es: MA: Addison-Wesley. ISBN 0201∨33∪∧X. «3.2: Do
un gran problema se divide en muchos pequeños proble- not create god classes/objects in your system. Be
mas (estrategia Divide y Vencerás) y las soluciones son very suspicious of an abstraction whose name con-
creadas para cada uno de ellos. Una vez que los pequeños tains Driver, Manager, System, or Subsystem.»
problemas han sido resueltos, el gran problema ha sido • Anti-Patterns and Worst Practices – Monster Ob-
resuelto como un todo. Sin embargo hay un solo objeto jects
el cual necesita saber todo: el objeto en sí. De esta ma-
nera, hay un solo grupo de problemas que el objeto debe
resolver: sus propios problemas.
El Código del Objeto todopoderoso no sigue esta regla.
En su lugar, la funcionalidad entera del programa está co-
di cada en un solo objeto que hace todo, el cual mantiene
toda la información del programa entero y contiene todos
los métodos y subrutinas para manipular los datos. Como
el objeto contiene muchos datos y requiere muchos mé-
todos, su rol en el programa se convierte en Objeto Todo-
poderoso (Abarca todo). En lugar de objetos comunicán-
dose entre ellos directamente, los objetos en el programa
se cuelgan del Objeto Todopoderoso para manejar su in-
formación e interacción. Como el Objeto Todopoderoso
es referenciado por casi todo el código, el mantenimiento
se vuelve mucho más difícil, que el diseño del código de
un programa mejor dividido
El objeto todopoderoso es el fallo de usar subrutinas de
lenguajes procedurales en orientación a objetos o de usar
demasiadas variables globales para almacenar informa-
ción de estados
Crear un Objeto todopoderoso es típicamente conside-
rado una mala práctica de programación, esta técnica
es usada ocasionalmente para entornos de programación
ajustados, donde el aumento de rendimiento ligero y la
centralización es más importante que el mantenimiento y
la elegancia de programación.

2∧∨
Capítulo 135

Oday

Oday fue un descomunal bug que afectó a los sistemas

operativos Windows XP y que permitía a quien lo aprove-
chaba escalar privilegios y acceder como SYSTEM en su
ordenador (SYSTEM es la cuenta de Windows que más
privilegios tiene, y que no pertenece a ningún usuario sino
al sistema). El bug ya fue arreglado, pero en su día podía
aprovecharse con un exploit llamado AT-EXPLOIT, con
un programa en batch especí co o con el modo manual
echando mano del [Link].

2∧∩
Capítulo 136

O set (informática)

En informática, un offset dentro de un array u otra

estructura de datos es un entero que indica la distancia
(desplazamiento) desde el inicio del objeto hasta un pun-
to o elemento dado, presumiblemente dentro del mismo
objeto. El concepto de distancia es solamente válido si
todos los elementos del objeto son del mismo tamaño (tí-
picamente dados en bytes o palabras).
Por ejemplo, dado un array de caracteres“A”que conten-
ga“abcdef”, se puede decir que el elemento que contiene
la letra “c”tiene un o set de 2 desde el comienzo de A.
En ingeniería informática y programación de bajo nivel
(como el lenguaje ensamblador), un o set normalmente
indica el número de posiciones de memoria sumadas a
una dirección base para conseguir una dirección absolu-
ta especí ca. Con este signi cado (que es el original) de
o set, sólo se usa la unidad básica de direccionamiento,
normalmente el byte de ∪ bits, para especi car el tama-
ño del o set. En este contexto se puede llamar a veces
dirección relativa.

136.1 Véase también

• O set

136.2 Referencias

2∧∪
Capítulo 137

OGNL

Object-Graph Navigation Language (OGNL), creado 137.3 Proyectos que usan OGNL
por OGNL Technology, es un Lenguaje de Expresiones
de código abierto para Java,el cual, mediante el uso de ex- • WebWork
presiones más simples que el amplio espectro que soporta
Java, permite obtener y establecer propiedades (a través • Struts 2 (sucesor del anterior)
de métodos ya de nidos getProperty y setProperty simila-
• Tapestry
res a los presentes en todos los JavaBeans) y la ejecución
de métodos de clases Java. • Spring Web Flow

• Apache Click
137.1 Aplicaciones • NReco (.NET integration framework for lightweight
MDD)
Algunas de las ventajas de OGNL sobre Java son:
• op4j (extensión op4j-ognl) - implementación de in-
• Las transformaciones entre tipos son más senci- terfaz uida de Java.
llas.
• MyBatis - framework de mapeo SQL
• Es un lenguaje de fuente de datos útil para mapear
• The Thymeleaf Template Engine - motor de planti-
columnas de una tabla con su TableModel en Swing.
llas Java XML/XHTML/HTML∧
• Es un sustituto del lenguaje de obtención de propie-
dades usado en el paquete BeanUtils. • Unitils - marco (framework) de testeo modular para
Java

137.2 Cadenas (chains)

137.4 Enlaces externos
Son la unidad fundamental de navegación. [Pueden con-
tener: • (en inglés) Página principal de OGNL
• (en inglés) WebWork (usando OGNL)
• Nombres de propiedades.

[Link]

• Llamadas a métodos.

hashCode()

• Índices de Array.

listeners[0]
Ejemplo:
[Link]()[0].[Link]()
Se pasa a String la propiedad “name”de la que se toma
el carácter de la posición 0 y se obtiene su valor numérico
que se pasa a String nuevamente.

2∧9
Capítulo 138

OpenACS

OpenACS del inglés Open Architecture Community Sys- comenzó a reescribir ACS en Java dando lugar a Red Hat
tem (Arquitectura Abierta para Sistemas de Comunida- CMS. La comunidad de OpenACS asumió mantenimien-
des) es un kit de herramientas libre (de código abierto) to del código escrito en Tcl.
para el desarrollo rápido de aplicaciones web, con licen-
cia GPL.
138.3 Véase también
138.1 Arquitectura • Sistema de gestión de contenido (en inglés CMS:
Content Management System)
OpenACS utiliza el servidor web AOLserver y como base
de datos tanto Oracle como PostgreSQL.
OpenACS proporciona: 138.4 Enlaces externos

• Un gran conjunto de aplicaciones que pueden ser • [Link]

usadas para desarrollar sitios web, siendo espe-
cialmente útil para aquellos que son colaborativos.
Algunas de las aplicaciones más importantes son
.LRN, dotFolio, WorkFlow, CMS, blogger, comer-
cio electrónico, foros.
• Un so sticado kit de herramientas que proporciona
un gran conjunto de APIs y servicios para el desa-
rrollo rápido de nuevas aplicaciones.
• Un modelo de datos que escribe la losofía de
orientación a objetos desde SQL estándar y méto-
dos PL/SQL, haciendo elegante el soporte a distintas
bases de datos (actualmente PostgreSQL y Oracle).
• Un sistema robusto con capacidad de soportar una
gran cantidad de trá co sin una baja considerable de
desempeño gracias a ser un sistema multi-thread.
• Un sistema de documentación integrado que permi-
te buscar fácilmente sobre el código existente en el
sistema.

138.2 Historia
OpenACS era originalmente desarrollado con el ArsDi-
gita Community System, teniendo como base de datos
Oracle. ACS fue la razón por la que AOLServer fue libe-
rado. OpenACS surgió como un fork para soportar ACS
con PostgreSQL. Después RedHat compró ArsDigita y

2∨0
Capítulo 139

Operaciones con archivos (informática)

Los archivos informáticos son el medio de que dis-

ponemos para almacenar información no volátil en un
dispositivo de almacenamiento. Los Sistemas de archi-
vos de que disponen los sistemas operativos disponen de
mecanismos para que un usuario pueda manipular los ar-
chivos (seleccionar, editar, ejecutar, borrar, ...). Desde el
punto de vista de un programador un archivo es un me-
dio para poder leer datos de entrada para su programa o
donde poder guardar los resultados de su ejecución. Todo
lenguaje de programación debe disponer de algún meca-
nismo para que el programador pueda manipular archivos
desde un programa. Estos mecanismos pueden ser más o
menos so sticados o versátiles dependiendo del lenguaje
de programación que estemos considerando, pero deben
haber unas funciones básicas para poder acceder a un ar-
chivo, estas son:

• Lectura (consulta).- Esta operación consiste el leer

la información contenida en chero sin alterarla.
• Escritura (modi cación).- Consiste en actualizar
el contenido del chero bien añadiéndole nuevos da-
tos o borrando parte de los que contenía.

• Apertura.- Antes de acceder a un chero, tanto pa-

ra consultar como para actualizar su información,
es necesario abrirlo. Esta operación se debe realizar
previamente a las operaciones de lectura o escritura.

• Cierre.- Cuando se ha terminado de consultar o mo-

di car un chero, por lo general, del mismo modo
que se tuvo que abrir para realizar alguna operación
de lectura/escritura sobre él, éste deberá ser cerrado.

139.1 Véase también

• Programación
• Lenguajes de programación

• Archivo informático
• Sistema de archivos

2∨1
Capítulo 140

Operador

rés en un espacio de Banach. En este espacio, existe una

norma y podemos de nir una esfera de radio unidad. Se
llama operador lineal acotado al operador lineal que está
acotado en esta esfera. Los operadores lineales acotados
entre dos espacios de Banach forman a su vez un espacio
de Banach cuyo estudio es bastante interesante. Una ex-
tensión de la derivada real a los operadores es la derivada
de Frechet que es un operador lineal acotado.
No todos los operadores lineales interesantes son acota-
dos: hay muchos ejemplos de operadores importantes en
mecánica cuántica que no son acotados.
El ejemplo más típico de operador lineal no acotado es
la derivada -considerada como una aplicación entre dos
espacios de funciones reales-. El operador diferencial, dx
d

, actúa sobre la función f (x) que se escribe a su derecha,

produciendo una nueva función derivada: f ′ (x)
Si un operador está de nido entre dos espacios vectoria-
Operadores suma,resta, multiplicación y división les de funciones, actúa transformando unas funciones en
otras.
En matemáticas, el término operador puede emplearse
con diversas acepciones .
Algunas veces, un operador es un símbolo matemático 140.2 Operadores bilineales o biva-
que indica que debe ser llevada a cabo una operación riantes
especi cada* [1] sobre un cierto número de operandos
(número, función, vector, etc.).
(Para de niciones más estrictas sobre linealidad y
Los operadores suelen interpretarse como funciones, por bilinealidad, véanse los temas relacionados)
ejemplo la suma + o el producto ·pueden ser entendidas
como funciones de dos argumentos.O una aplicación de Su nombre depende del autor, son los operadores que
CxC en C. actúan sobre dos objetos (escritos, generalmente, a am-
bos lados del operador) produciendo un único resultado.
Véanse los casos siguientes.
140.1 Operadores en un espacio
vectorial 140.3 Tipos generales de operado-
Un uso frecuente del término operador es aplicación en- res
tre dos espacios vectoriales. Se usa con más frecuencia
cuando alguno de ellos tiene dimensión in nita. Este sue- 140.3.1 Operadores de condición
le ser el caso de un espacio vectorial cuyos elementos son
funciones. Si se trata de una aplicación lineal, podemos Relacionan un término A con otro B estableciendo su
llamarle operador lineal. igualdad, jerarquía o cualquier otra relación posible, co-
El estudio de los operadores lineales es de particular inte- mo ejemplos tenemos:

2∨2
140.4. OTROS OPERADORES 2∨3

• A = B establece que A es igual que B. lógicos nos proporcionan un resultado a partir de que se
cumpla o no una cierta condición. Esto genera una se-
En este caso hay que distinguir en- rie de valores que, en los casos más sencillos, pueden ser
tre operador = de asignación y el parametrizados con los valores numéricos 0 y 1, como se
operador = de comparación. El pri- puede apreciar en los ejemplos de abajo. La combinación
mero toma el valor de B y se lo asig- de dos o más operadores lógicos conforma una función
na a A; el segundo solamente com- lógica.
para los valores de A y B sin mo-
di carlos y devuelve un valor lógi- • Los más sencillos son (nótese su relación con los
co o de verdad verdadero si ambos operadores relacionales):
valores son iguales o falso si dichos
valores no son iguales. • Operador NO-lógico: '¬A' signi ca todo lo
que no es A'
• A ≠ B o desigualdad. • Operador Y-lógico: 'A B' signi ca 'A y B a
la vez'; resultando FALSO (0) si no se cumple
Este caso es justamente el opues- y VERDADERO (1) si lo hace.
to al anterior, aunque aquí no po-
• Operador O-lógico: 'A B' signi ca 'O bien
demos hablar de asignación, pero si
A, o bien B, o bien los dos'; resultando FALSO
de comparación. Ahora el resulta-
(0) si no se dan ni A ni B y VERDADERO (1)
do de esta operación será F si los
si se da alguno de los dos o los dos a la vez.
valores A y B son iguales y V si son
distintos. • Operador =: 'A = B' signi ca 'A debe ser igual
a B'; resultando FALSO (0) si esto no es así y
VERDADERO (1) en caso contrario.
140.3.2 Operadores de orden • Operador <: 'A < B' signi ca 'A debe ser me-
nor que B'; resultando FALSO (0) si no se sa-
Los operadores de orden establecen o veri can clasi ca- tisface y VERDADERO (1) en caso contrario.
ciones entre números (A < B, A > B, etc.) u otro tipo de
• Operador >: 'A > B' signi ca 'A debe ser ma-
valores (caracteres, cadenas, ...).
yor que B'; resultando FALSO (0) si no se sa-
tisface y VERDADERO (1) en caso contrario.
Todo tipo de dato susceptible de
ser ordenado por cualquier crite-
rio puede ser comparado con estos • Los operadores más complejos se construyen a
operadores; como los anteriores de- partir de los anteriores (podría incluirse alguno
vuelven un valor de verdad en fun- más) y ya entran dentro de lo que sería una
ción del resultado que tenga la com- función lógica. Un ejemplo muy utilizado sería
paración en cada caso. 'SI(condición;A;B)' ('IF condición THEN A ELSE
B' en la mayoría de los lenguajes de programación)
• A > B Devuelve V si A es es-
cuyo resultado sería A si se satisface la 'condición' o
trictamente mayor que B y F
B en caso contrario.
en caso contrario
• A < B Devuelve V si A es es-
trictamente menor que B y F 140.3.4 Operaciones aritméticas
en caso contrario
• A ≥ B Devuelve V si A es ma- Las operaciones aritméticas pueden ser entendidas, des-
yor o igual que B y F en caso de un punto de vista operacional, como operadores biva-
contrario riantes o como operadores a derecha. Por ejemplo, '2 ×
• A ≤ B Devuelve V si A es me- 3' puede ser el operador bivariante de la multiplicación
nor o igual que B y F en caso actuando sobre los números 2 y 3, o el operador '2 ×' que
contrario actúa sobre 3. En este grupo se encuentran la adición, la
sustracción, multiplicación y la división.
• Otros operadores relacionales menos usuales son los Otras operaciones, derivadas de las operaciones arit-
llamados operadores geométricos: paralelismo (A || méticas usuales son la potenciación, radicación y
B), perpendicularidad y otros logaritmación.

140.3.3 Operadores lógicos

140.4 Otros operadores
Muy utilizados en Informática, lógica proposicional y
álgebra booleana, entre otras disciplinas. Los operadores • Operador autoadjunto
2∨4 CAPÍTULO 140. OPERADOR

• Operador diferencial

• Operador hermítico
• Operador cuántico

• Operador lineal
• Operador norma

• Operador nabla
• Gradiente

• Divergencia
• Rotacional

• Laplaciano

• Transformada integral
• Sumatorio

• Productorio

140.5 Temas relacionados

• Aplicación lineal

• Forma bilineal de nida

• Cálculo

• Cálculo lógico

140.6 Referencias
[1] Domingo Agustín Vázquez. «Diccionario de ciencias».
Capítulo 141

Operando

En matemáticas, un operando es una de las entradas (ar- 141.2.2 Informática

gumentos o variables) de un operador. Por ejemplo, en
• Expresiones y Atribuições Escales - Fortran en
UFPEL. Acessado en 23 de febrero de 200∪.
3+6=9 • Lenguaje Java en SENAC - Río Grande del Sur.
Acedido el 23 de febrero de 200∪.
" + " es el operador, " 3 " y " 6 " son los operandos. Si
el operando va acompañado de un signo menos (" − ") se
considera que es un operando negativo, en caso contrario
se considera operando positivo o simplemente operando.
La cantidad de operandos de un operador es denominada
aridad. Basándose en la aridad, los operadores son clasi-
cados como unarios, binarios, ternarios etc.

141.1 En informática
En los lenguajes de programación de computadora, las
de niciones de operador y operando son casi las mismas
que las de matemáticas.
Adicionalmente, en lenguaje máquina, un operando es
un valor (un argumento) con el cual la instrucción, nom-
brada por un mnemónico, opera. El operando puede ser
un registro, una dirección de memoria, una constante lite-
ral, o una etiqueta. Un ejemplo simple en la arquitectura
PC es

MOV DS, AX

donde el valor en el operando del registro AX debe ser

movido al registro DS. Dependiendo de la instrucción,
puede haber cero, uno, dos o más operandos.

141.2 Conexiones externas

141.2.1 Matemática
• Otávio N. Cipriani; José Monserrat N.; Ila M. S. de
Souza. Construyendo un Juego Para Uso en la Edu-
cación Matemática en UFLA. Accedido el 23 de fe-
brero de 200∪.

2∨∧
Capítulo 142

Paquetes en PL/SQL

Los paquetes en PL/SQL tienen el objetivo de agru- sores... subprogramas en PLSQL END nombre_paquete
par procedimientos y funciones de forma lógica. De es-
ta manera, se consigue agrupar en un único objeto, to- Para realizar llamadas a objetos dentro de un paquete, ha-
da la casuística asociada a un determinado tipo de tarea. bría que diferenciar si la llamada es desde un subprogra-
Por ejemplo, si tenemos un conjunto de procedimientos y
ma dentro del mismo paquete o si la llamada es externa
funciones para realizar cálculos matemáticos complejos, al paquete:
los podemos poner en un paquete.
La ventaja de los paquetes es que la primera vez que se • Llamada interna
invoca, es cargado en memoria, por lo que las siguien-
tes veces ya no será necesario hacerlo de nuevo. Además, Se pone el nombre del subprograma y entre pa-
el paquete mantiene una copia en memoria para todos réntesis los parámetros que se deben pasar.
los usuarios. Otra ventaja, es que podemos encapsular Por ej. para llamar a la función “Multipli-
procedimientos y funciones que no forman parte de la in- ca(real r1, real r2)" desde la función “Cal-
terfaz de usuario. Podemos ocultar ciertos objetos y solo culaBene cios”, se pondría “r3:= Multipli-
hacer públicos los que se necesiten. También se permite ca(2.∧,3.∧)"
la sobrecarga dentro de los paquetes. El paquete se divide
en especi cación y cuerpo. • Llamada externa

Hay que preceder el nombre del paquete al

142.1 Especi cación nombre del procedimiento o función. Además,
el subprograma llamado debe ser público para
Es obligatorio en la creación de un paquete (PACKAGE). que pueda ser referenciado.
Se declaran todos los subprogramas públicos. Lo lógico Por ejemplo para llamar a la función Multiplica
es declarar en esta sección aquellos procedimientos o fun- que se encuentra en el paquete“Operaciones-
ciones que actúan como interfaz. También se declaran las Matematicas”desde un procedimiento externo
variables o constantes que se quieren tratar como globales al paquete sería “r3:= OperacionesMatemati-
y que se puedan cambiar o referenciar fuera del paquete. [Link](2.∧,3.∧)"
La sintaxis sería la siguiente:
Para eliminar un paquete de la base de datos tanto la es-
CREATE [OR REPLACE] PACKAGE nom- peci cación como el cuerpo:
bre_paquete IS | AS declaraciones de variables,
DROP PACKAGE nombre_paquete
cursores... subprogramas en PLSQL END nom-
bre_paquete
Oracle proporciona algunos paquetes que permiten la rea-
lización de distintas tareas muy comunes al desarrollar o
administrar la base de datos. Entre estos paquetes se pue-
142.2 Cuerpo den destacar:

• DBMS_SQL: para acceder a la base de datos con

En el cuerpo es donde se de nen los procedimientos y SQL dinámico.
funciones públicos y privados.
• DBMS_UTILITY: para el análisis de objetos. Por
La sintaxis sería: ejemplo se pueden compilar todos los objetos que
CREATE [OR REPLACE] PACKAGE BODY se encuentran en un determinado esquema de base
nombre_paquete IS | AS declaraciones de variables, cur- de datos.

2∨∨
142.2. CUERPO 2∨∩

• UTL_FILE: añade capacidades de entrada/salida a

cheros.
Capítulo 143

Pascal Casing

Pascal Casing es un procedimiento de programación co-

mún en el lenguaje Java y .Net. Es parecido al Camel ca-
sing con la excepción que la letra inicial del identi cador
debe estar en mayúscula.
La nomenclatura está compuesta por tantas palabras co-
mo sean necesarias. La primera letra de cada una de las
palabras irá siempre en mayúsculas. Tanto para Pascal
Casing como para Camel casing, se obvia el uso de artícu-
los. Un uso correcto de nomenclatura sería WriteInfor-
mation y no WriteTheInformation, WriteInformation y
no writeInformation o Writeinformation.

143.1 Enlaces externos

• History around Pascal Casing and Camel Casing

2∨∪
Capítulo 144

Patch (Unix)

Patch es un comando de Unix y Unix-like que actualiza

cheros de texto de acuerdo a las instrucciones conteni-
das en un archivo separado, llamado archivo de parche.
Este archivo (denominado patch) es un archivo de texto
que consiste en una lista de las diferencias entre cheros y
se produce mediante la ejecución del comando di com-
parando con el chero original y actualizándolo con los
argumentos de di .
El programa original fue escrito por Larry Wall (creador
del lenguaje de programación Perl) en mayo de 19∪∧. Una
nueva versión del programa es parte del proyecto GNU y
es mantenido por la FSF.

144.1 Contexto de uso

El comando se utiliza con frecuencia para la actualización
del código fuente a una versión más reciente. Debido a
esto es utilizado frecuentemente en sistemas de control de
código fuente como CVS. El programa no solo es capaz
de añadir texto como puede intuirse, también es capaz de
eliminarlo.
Ejemplo de uso:
Creación del chero:
$ di -u oldFile newFile > [Link]
Aplicación del parche:
$ patch < [Link]

144.2 Enlaces externos

• Man linux

• Código fuente en GNU

2∨9
Capítulo 145

Phrogram

Phrogram (anteriormente Kid's Programming Lan- mado el núcleo del Phrogram Team (Equipo Phrogram),
guage, or KPL) es un lenguaje de programación dise- trabajando en el producto (como extensiones llamadas
ñado para ser inteligible y fácil para los niños. La versión add-in libraries) como un programa comercial destinado
1 (KPL) fue nalizada en Agosto de 200∧, y la versión 2 a la enseñanza del software y para dar valor a Phrogram
(Phrogram) es ahora mismo la versión más actual. con respecto a lenguaje de programación.
El principal objetivo de The Phrogram Company es dis-
tribuir un simple pero poderoso grupo de herramientas
145.1 Detalles técnicos que hacen del aprender a programar algo fácil y diverti-
do. Phrogram (KPL) se ha convertido en una gran herra-
Phrogram es un lenguaje de programación y un IDE que mienta para los programadores novatos por la facilidad
guarda cierta similitud con Visual Basic. El lenguaje so- para crear programas multi-media con sprites, música,
porta un número de datos complejos, incluyendo estruc- efectos sonoros, animaciones y algunas opciones más.
turas. El objetivo secundario de Phrogram es proveer un len-
Phrogram depende de Microsoft .NET Framework y pro- guaje moderno con algunas opciones de lenguajes avan-
vee muchas funciones y métodos para interactuar con esa zados como C++, Java, Visual Basic y C#, y la sintaxis
plataforma. Por esto, Phrogram actualmente sólo puede de Visual Basic, para hacer la transición entre estos len-
usarse en la serie de sistemas operativos Microsoft Win- guajes lo más sencilla posible. Phrogram (KPL) sopor-
dows que [Link] Framework. ta programación orientada a objetos (OOP) y permite la
de nición de clases y de sus propiedades y métodos aso-
Un programa de Phrogram es una colección de bloques
ciados, los cual provee a los programadores principiantes
anidados. En el nivel mayor hay un bloque Program, y
una introducción a la programación OOP.
dentro de este, otros bloques Method y Function son de -
nidos. Las funciones y los métodos (functions y methods) Para lograr estos objetivos, los desarrolladores de Phro-
son ambos un conjunto de acciones reusables, pero exis- gram construyeron la Versión 2 sobre el reciente .NET
te una diferencia: las funciones devuleven un valor y los Framework Version 2 (Noviembre de 200∧). Phrogram
métodos no tienen esa obligación. Las estructuras (struc- intenta ser completamente compatible con otros lengua-
tures) son declaradas fuera de métodos y funciones. Las jes que [Link] Framework, por lo que esas“runtime
variables deben ser declaradas en el momento de decla- libraries”pueden ser redistribuidas donde o a quien se
ración. quiera.

145.2 ¡Hola, Mundo! en KPL 145.4 Otra información

Program Hello_World Method Main() PrintLine“Hello,
( Phrogram es un software comercial con 30 días de prue-
World”) End Method End Program ba. La interfaz de usuario de Phrogram está disponible
en 1∪ idiomas entre ellos inglés, español, ruso, chino y
catalán. La web de KPL está actualmente disponible en
145.3 Filosofía inglés, español, francés, portugués y otros ∧ idiomas. To-
das las traducciones (menos inglés, que no es traducción)
Jonah Stagner comenzó a desarrollar Phrogram (KPL) han sido creadas por una comunidad global de volunta-
cuando quiso enseñar a sus hijos a programar. Descubrió rios, y la compañía anima a los usuarios a traducir.
que las herramientas y tecnologías no son en absoluto fá- A pesar de que KPL fue diseñada originalmente para ni-
ciles de usar para los principiantes. Desde entonces Jo- ños de entre 10 y 14 años (de ahí su nombre, “Lenguaje
nah, Jon Schwartz, Walt Morrison y David Witus han for- de Programación para Niños”), es apropiado para pro-

2∩0
145.6. ENLACES EXTERNOS 2∩1

gramadores principiantes de cualquier edad, y de ahí el

cambio de nombre. Es usado por mucha gente adulta que
lo han descargado para aprender, o para sus hijos o es-
tudiantes. Phrogram puede ser usado como lenguaje de
programación a aprender en la escuela, en cualquier ni-
vel de educación, desde primaria y secundaria hasta la
Universidad. Actualmente es usado en las universidades
de muchos países como Estados Unidos, Gran Bretaña,
Canadá, México, Colombia, Rusia, Japón, Islandia, Sue-
cia, República Checa, Eslovaquia, Portugal, Brasil, Chi-
na, Guam, las Filipinas y Nueva Zelanda.* [cita requerida]

145.5 The Phrogram Company

KPL versión 2 fue liberada, renombrada como Phro-
gram. La nueva web de la comunidad es The Phrogram
Company.

145.6 Enlaces externos

• The Phrogram Company, website o cial de Phro-
gram y la Comunidad Phrogram
• La antigua website de KPL

• Morrison Schwartz Inc

• Diapositivas introductorias a KPL para profesores y

padres (<1 MB)

• Diapositivas introductorias a KPL para programa-

dores (1.∩ MB)

• KPL podcast by ComputerWorld

• Video de KPL en Channel 9 (Requiere Windows
Media Player)
Capítulo 146

Plataforma de desarrollo

En informática, una plataforma de desarrollo es el

ambiente o entorno de software común en el cual se
desenvuelve la programación de un grupo de nido de
aplicaciones. Comúnmente se encuentra relacionada di-
rectamente a un sistema operativo; sin embargo, también
es posible encontrarla ligada a una familia de lenguajes de
programación o a una interfaz de programación de apli-
caciones (API, por las siglas en inglés: Application Pro-
gramming Interface). Cabe recordar que funciona como
sistema plataforma o multiusuario.

146.1 Véase también

• Multiplataforma

• Entorno de desarrollo integrado

2∩2
Capítulo 147

Plataforma virtual didáctica

Las plataformas virtuales se re eren a la tecnología uti- 147.4 Autores y contribuyentes

lizada para la creación y desarrollo de cursos o módulos
didácticos en la Web (sibal) que se usan de manera más Muchas organizaciones para el desarrollo colaboran con
amplia en la Web 2.0 mejora de la comunicación apren- voluntarios en línea para desarrollar plataformas de capa-
dizaje y enseñanza. citación en un intento por aumentar la capacidad de las
comunidades locales, instructores y personas responsa-
bles de la toma de decisiones de países en desarrollo para
147.1 Historia ayudar a enfrentar los desafíos de desarrollo.* [1]

Con la llegada de Internet se produce un importante aba-

ratamiento de los costos de desarrollo de programas, por 147.5 Ventajas
lo que resulta más sencilla la creación de materiales cuyo
objetivo es ser utilizados en línea. Sin embargo se siguen 1. Ahorro en gastos de libros, libretas y material para
necesitando conocimientos avanzados de programación escribir
para crear un curso o un módulo didáctico, y por tanto
estos cursos no son accesibles a todo el mundo. Desde 2. Se disminuyen los tiempos de transporte de los usua-
mediados de los años 90 empiezan a surgir plataformas rios que utilizan las plataformas virtuales didácticas
didácticas que permiten la creación y la gestión de cursos 3. Posibilidad de utilizar los dispositivos digitales para
completos para la web sin que sean necesarios conoci- acceder a las plataformas
mientos profundos de programación o de diseño grá co.
4. Uso de diferentes recursos didácticos, tales como:
videos, audios, libros electrónicos, pruebas digita-
les, que permitirán realizar un seguimiento a los
147.2 Herramientas que las com- alumnos que utilizan las plataformas.
ponen
1. Herramientas de comunicación, como foros, chats, 147.6 Enlaces externos
correo electrónico.
• Plataforma virtual didáctica para instituciones
2. Herramientas de los estudiantes, como autoevalua-
ciones, zonas de trabajo en grupo, per les.

3. Herramientas de productividad, como calendario, 147.7 Bibliografía

marcadores, ayuda.
• DILLENBOUG, P (2000) Virtual learning environ-
4. Herramientas de administración, como autoriza- ments pdf
ción.

∧. Herramientas del curso, como tablón de anuncios, • GÓMEZ, F (200∧) Plataformas Virtuales y Diseño
evaluaciones. De Cursos, Chile, Universidad Ponti cia Católica de
Valparaíso: Online

• MOLIST, M. (13-4-200∨) " Institutos y universida-

147.3 Para que sirven des apuestan por la plataforma libre de e-learning
Moodle " en CiberP@í[Link]
Sirven para acortar distancias y prolongar la comunica-
ción sin necesidad de estar presencialmente. oñiutk.uñ[Link]

2∩3
2∩4 CAPÍTULO 147. PLATAFORMA VIRTUAL DIDÁCTICA

147.8 Véase también

• Comunidad de aprendizaje de idiomas

[1] Boletín del Servicio Voluntariado en Línea

Capítulo 148

Polling

Polling en computación hace referencia a una operación 148.2 Polling del registro de Win-
de consulta constante, generalmente hacia un dispositivo
de hardware, para crear una actividad sincrónica sin el
dows
uso de interrupciones, aunque también puede suceder lo
mismo para recursos de software. En cualquier versión del sistema operativo Microsoft
Windows desde la versión 3.11 podemos encontrar apli-
Esto, aplicado a programación puede ser visto como una caciones pobremente desarrolladas que consultan repe-
pobre implementación en búsqueda del sincronismo de titivamente llaves del registro de Windows en busca de
procesos. Por ejemplo, se podría consultar constantemen- cambios, degradando el rendimiento general del sistema.
te un directorio del sistema de archivos para indicarle al En versiones antiguas este modelo de implementación era
usuario cuando lleguen nuevos contenidos a la misma sin la única alternativa, pero ahora en versiones modernas de
embargo estas constantes consultas degradarían el rendi- Windows desde NT 3.1 o Windows 9∪ en adelante exis-
miento del equipo y probablemente sería mejor imple- te la función RegNotifyChangeKeyValue* [1] dentro de
mentar la solución por otro medio, en particular, pidién- la biblioteca Advapi32, la cual forma parte de la API de
dole al sistema operativo que informe de transferencias a Windows. Esta función permite hacer una especie de“in-
ese directorio en particular. terrupción de software”la cual nos avisará ante cambios
en el contenido de una clave de registro sin tener que con-
sultarla directamente ni periódicamente.
A pesar de la función comentada anteriormente hay apli-
caciones que siguen haciendo un mal uso de los recursos
del equipo e incluso programas de Microsoft (como MSN
Desktop Search) pobremente desarrollados que producen
polling.* [2]
148.1 Historia
148.3 Soluciones para el polling
En los primeros sistemas de computación cuando una En sistemas de código abierto la solución simplemen-
aplicación necesitaba leer la pulsación de una tecla, inte- te abarca la corrección sobre el código de las funciones
rrogaba continuamente al teclado esperando hasta que la que generen el problema, empleando funciones como las
tecla fuera presionada. Debido a la ausencia de sistemas nombradas anteriormente o en su defecto las apropiadas
multitarea, mientras se esperaba una tecla, no se podían según la plataforma utilizada.
ejecutar otras tareas.
El problema se torna más interesante en aplicaciones de
La solución a este problema apareció con la llamada código cerrado, en este caso la solución generalmente está
interrupción de teclado en donde el controlador del dis- en manos de la empresa desarrolladora, sin embargo, es
positivo, en este caso el teclado, es quien genera una posible aplicar prácticas de ingeniería inversa para lograr
interrupción sólo cuando el dispositivo está listo para cambiar el comportamiento que causa el problema.
transferir datos. La CPU maneja estas interrupciones que
el sistema operativo sabe como priorizar y obtener infor-
mación de ellas.
148.4 Referencias
Estas múltiples consultas pueden referirse a uso excesivo
de recursos de red, registros o cheros, aunque también [1] RegNotifyChangeKeyValue Function (Windows)
pueden relacionarse con actividades de más bajo nivel del
equipo. [2] Mark's Blog : Polling and MSN Desktop Search

2∩∧
2∩∨ CAPÍTULO 148. POLLING

148.5 Enlaces externos

• Demostración de cómo solucionar el polling en apli-
caciones de Windows
Capítulo 149

Poltergeist (informática)

En Programación orientada a objetos el antipatrón de di- • Análisis y diseño de modelo inestables.

seño poltergeist es una clase de objetos de corta dura-
ción, normalmente sin estado, que se utiliza para reali- • Pobre funcionamiento del sistema. Se generan ins-
zar la inicialización o para invocar a los métodos de otras tancias y se realizan llamadas innecesarias.
clases. La de nición original es de Michael Akroyd en la • Di cultad de ampliar el programa y de realizar un
Object World West Conference de 199∨: buen mantenimiento.

“Como un poltergeist que aparece y desaparece

misteriosamente, lo mismo ocurre con el obje- 149.2 Solución
to de breve duración. Como consecuencia, el
código es más difícil de mantener y hay un des- • Eliminar clases externas, que no tengan relevancia,
perdicio de recursos innecesario. La causa ha- clases transitorias y operacionales (Init, Manager,
bitual de este antipatrón es un pobre diseño de Controller, etc).
objetos.”
• Eliminar otras clases con poco tiempo de vida y ca-
Las clases poltergeist se pueden identi car por su nom- rencia de responsabilidades.
bre. A menudo se llaman “manager_”, “controller_”
, “start_process”, etcétera.
A veces, las clases poltergeist demuestran la necesidad de
149.3 Véase también
una arquitectura más compleja. Por ejemplo, un polter-
geist surge si el mismo método actúa como el cliente y • Antipatrón de diseño
el invocador en un patrón de comando, y el programador • Patrón de diseño
separa las dos fases. Sin embargo, esta arquitectura más
compleja puede que nunca llegue a materializarse. • Modelo-vista-controlador
No se debe confundir con objetos de larga duración que
almacenan el estado de un patrón como es el caso de
Modelo-vista-controlador, que traspasa el ujo de infor- 149.4 Enlaces externos
mación entre las tres clases principales.
Para eliminar un poltergeist, se debe de eliminar la clase • Antipattern poltergeists by Sourcemaking Teaching
llamadora y tratar de insertar su funcionalidad dentro de IT Professionals
la clase invocada mediante herencia. • Development Antipatterns poltergeists

149.1 Consecuencias
• Proliferación de clases.

• Clases con poca duración, sin estados y pocas res-

ponsabilidades.

• Complejidad excesiva. Difícultad de comprender la

arquitectura del programa, las asociaciones de clases
y las llamadas que se realizan entre ellas.

2∩∩
Capítulo 150

Portabilidad

La portabilidad (en inglés portability) es uno de los con- 150.1 Véase también
ceptos clave en la programación de alto nivel.
Se de ne como la característica que posee un software • Interoperatividad.
para ejecutarse en diferentes plataformas, el código fuen-
te del software es capaz de reutilizarse en vez de crearse
un nuevo código cuando el software pasa de una platafor- 150.2 Referencias
ma a otra (ver la nota, a continuación de este párrafo). A
mayor portabilidad menor es la dependencia del software • Diccionario de Informática. “Portabilidad”. Pági-
con respecto a la plataforma. na 2∧4. Editorial Cultural. 1999. Madrid, España.
(Nota: la portabilidad no tiene relación directa con el có- ISBN ∪4-∪0∧∧-2∧∨-∧
digo fuente de una aplicación y, por eso, tampoco tiene
• Mooney (199∩). "Bringing Portability to the Softwa-
relación directa con la reutilización del mismo. En cam-
re Process" (PDF). West Virginia University. Dept.
bio, la portabilidad se re ere exclusivamente a la propie-
of Statistics and Computer Science. Revisado el 1∩
dad que posee un software que le permite ser ejecutado
de marzo de 200∪.
en diferentes plataformas y/o sistemas operativos. De es-
te modo, si un determinado software compilado pudie- • Garey (200∩),“Software Portability: Weighing Op-
re ser ejecutado en cualquier sistema operativo, diríamos tions, Making Choices”, The CPA Journal ∩∩(11):
que ese software es 100% portable. Éste es el núcleo del 3
concepto de portabilidad. En este sentido, la a rmación
precedente: “el código fuente del software es capaz de
reutilizarse en vez de crearse un nuevo código cuando el
software pasa de una plataforma a otra”, tiene como su-
puesto erróneo que tenemos acceso al código fuente, el
cual podría reutilizarse (como es la meta que buscan los
diseñadores de los lenguajes cuyos códigos corren sobre
máquinas virtuales, como es el caso de Java y la familia
DOT NET). Esto es incorrecto: la portabilidad es un con-
cepto que se re ere exclusivamente a la relación software
<-> plataforma).
El prerrequisito para la portabilidad es la abstracción ge-
neralizada entre la aplicación lógica y las interfaces del
sistema. Cuando un software se puede compilar en diver-
sas plataformas (x∪∨, IA∨4, amd∨4, etc.), se dice que es
multiplataforma. Esta característica es importante para
el desarrollo de reducción costos, cuando se quiere hacer
una misma aplicación.
En algunos casos el software es “independiente”de
la plataforma y puede ejecutarse en plataformas diver-
sas sin necesidad de ser compilado especí camente pa-
ra cada una de ellas, a este tipo de software se le llama
interpretado, donde un "intérprete" traduce (propiamente
interpreta) las instrucciones en tiempo de ejecución para
que sean entendidas por diferentes plataformas.

2∩∪
Capítulo 151

Postcondición

En programación, una postcondición es una condición o

predicado lógico que siempre debe cumplirse justamen-
te después de la ejecución de una sección de código o
de una operación (especi cación formal). Las postcondi-
ciones se prueban a veces mediante aserciones incluidas
en el código. A menudo, las postcondiciones se incluyen
simplemente en la documentación de la correspondiente
sección de código.
Por ejemplo: el resultado de un factorial es siempre un
entero mayor o igual que 1. De este modo un programa
que calcula el factorial de un número dado tendría como
postcondiciones que el resultado debe ser un entero y que
éste debe ser mayor o igual que 1.

151.1 Véase también

• Precondición
• Diseño por Contrato

• Lógica de Hoare
• Invariantes mantenidas por condiciones

• Disparador (Bases de datos)

2∩9
Capítulo 152

Pragma

La palabra griega pragma ( αγμα), pragmata en plu-

ral ( αγματα), que signi ca: 'lo que ha sido hecho', un
acto, un hecho, y cuyas connotaciones y los sentidos más
ampliados cubren una riqueza de sentidos a este signi ca-
do, incluso: acción, asunto, negocio, circunstancia, preo-
cupación, conveniencia, innovación, trabajo, necesidad,
objeto, objetivo, ocupación, o cina, papel, o trabajo de
vida, asuntos privados, cosa, problema.
También el pragma es un tipo de Arquetipos amatorios.

152.1 Programación
Los pragmas son sentencias especiales que controlan el
comportamiento del compilador, es decir son directivas
de compilador. Tienen esta forma estándar:
pragma Nombre (lista_de_argumentos);

La lista_de_argumentos es opcional, no todos los pragmas

necesitan argumentos.

152.2 Véase también

• Resultado

• Efecto
• Pragmatismo

152.3 Enlaces externos

• Wikcionario tiene de niciones y otra informa-

ción sobre [Link]

2∪0
Capítulo 153

Precondición

Una precondición es una condición que ha de satisfacerse

justo antes del comienzo de la ejecución de una porción
de código (normalmente un subprograma o método).
Por ejemplo: el factorial de un número sólo está de nido
para valores positivos (o cero). Por tanto, un subprograma
que calcule el factorial de un número exigirá que dicho
número sea mayor o igual que cero.
Existen lenguajes de programación que incorporan cons-
trucciones sintácticas para re ejar las precondiciones de
sus subprogramas o métodos. El cálculo del factorial en
el lenguaje Ei el, por ejemplo, quedaría así:
factorial(n: INTEGER): INTEGER -- Calcula el factorial
de un número. No está de nido para cantidades negativas.
require no_negativo: n >= 0 do if n = 0 then Result := 1
else Result := n * factorial(n - 1) end end
En donde la palabra require introduce la precondición del
método factorial.

153.1 Véase también

• Postcondición

• Diseño por Contrato

• Lógica de Hoare

• Invariantes mantenidas por condiciones

• Disparador (Bases de datos)

2∪1
Capítulo 154

Primitiva de sincronización rendezvous

Rendezvous es una primitiva de sincronización asimétri-

ca que permite a dos procesos concurrentes, el solicitante
y el llamado, intercambiar datos de forma coordinada. El
proceso que solicita el rendezvous debe esperar en el pun-
to de reencuentro hasta que el proceso llamado llegue allí.
Igualmente el proceso llamado puede llegar al rendezvous
antes que el solicitante y debe esperar que él llegue al
punto de encuentro para poder continuar procesando. La
imagen de esperar en el punto de encuentro corresponde
a colocar un proceso en espera inactiva hasta que la ci-
ta se cumpla. Durante el rendezvous los procesos pueden
intercambiar datos.
Los datos intercambiados corresponden a parámetros de
una llamada (desde el solicitante hacia el proceso llama-
do) y a resultados de una llamada (desde el proceso llama-
do hacia el solicitante), sin necesidad de almacenamiento
intermediario.
La desventaja de la abstracción rendezvous es que no
contempla pasaje de mensajes de forma asíncrona, como
en el caso de las colas. En el lenguaje de programación
Ada es preciso implementar comunicación asíncrona y
otras abstracciones de comunicación a partir de rende-
vouz combinados con procesos intermedios y encapsula-
miento.

154.1 Ejemplo
Ejemplo en Ada donde el proceso Cola acepta un rende-
vouz de nombre agregar:
task type Cola is entry agregar(n: in Integer); entry eli-
minar(x: out Integer); ... end Cola -- Implementación de
Cola task body Cola is begin ... accept agregar(n: in In-
teger) do ... -- Cuerpo de la operación end agregar; ...
end Cola; --LLamada desde otro proceso: begin ... Co-
[Link](n) end

154.2 Enlaces externos

• RendezVous, Portland Pattern Repository's Wiki

2∪2
Capítulo 155

Proceso (informática)

Este artículo se re ere al proceso Un proceso se rige en pequeñas porciones, conocidas co-
informático, para otros usos véase mo páginas, y cada proceso tiene su propia tabla de pa-
Proceso. ginación, fungiendo como una optimización del sistema
operativo ante los fallos de página.
Un proceso puede informalmente entenderse como un Esta de nición varía ligeramente en el caso de sistemas
programa en ejecución. Formalmente un proceso es“Una operativos multihilo, donde un proceso consta de uno o
unidad de actividad que se caracteriza por la ejecución más hilos, la memoria de trabajo (compartida por todos
de una secuencia de instrucciones, un estado actual, y un los hilos) y la información de plani cación. Cada hilo
conjunto de recursos del sistema asociados”.* [1] consta de instrucciones y estado de ejecución.
Para entender lo que es un proceso y la diferencia entre Los procesos son creados y eliminados por el sistema
un programa y un proceso, A. S. Tanenbaum propone la operativo, así como también éste se debe hacer cargo
analogía “Un cientí co computacional con mente culi- de la comunicación entre procesos, pero lo hace a peti-
naria hornea un pastel de cumpleaños para su hija; tiene ción de otros procesos (interrupción o tiempo de reloj).
la receta para un pastel de cumpleaños y una cocina bien El mecanismo por el cual un proceso crea otro proceso
equipada con todos los ingredientes necesarios, harina, se denomina bifurcación (fork). El proceso de arranque
huevo, azúcar, leche, etcétera.”Situando cada parte de la de GNU/Linux inicia con un sólo proceso (init) y después
analogía se puede decir que la receta representa el progra- comienza a crear los hilos necesarios para tener el sistema
ma (el algoritmo), el cientí co computacional es el pro- listo para su uso. Los nuevos procesos pueden ser inde-
cesador y los ingredientes son las entradas del programa. pendientes y no compartir el espacio de memoria con el
El proceso es la actividad que consiste en que el cientí - proceso que los ha creado o ser creados en el mismo es-
co computacional vaya leyendo la receta, obteniendo los pacio de memoria.
ingredientes y horneando el pastel.
En los sistemas operativos multihilo es posible crear tan-
Cada proceso tiene su contador de programa, registros to hilos como procesos. La diferencia estriba en que un
y variables, aislados de otros procesos, incluso siendo el proceso solamente puede crear hilos para sí mismo y en
mismo programa en ejecución 2 veces. Cuando este úl- que dichos hilos comparten toda la memoria reservada
timo caso sucede, el sistema operativo usa la misma re- para el proceso.
gión de memoria de código, debido a que dicho código
Los procesos pueden ser cooperativos o independientes.
no cambiará, a menos que se ejecute una versión distinta
Dos o más procesos pueden cooperar mediante señales
del programa.
de forma que uno obliga a detenerse a los otros hasta que
Los procesos son gestionados por el sistema operativo y reciban una señal para continuar.
están formados por:
• Se usa una variable de tipo semáforo para sincroni-
• Las instrucciones de un programa destinadas a ser zar los procesos.
ejecutadas por el microprocesador. • Si un proceso está esperando una señal, se suspende
hasta que la señal se envíe.
• Su estado de ejecución en un momento dado, esto
es, los valores de los registros de la unidad central • Se mantiene una cola de procesos en espera en el
de procesamiento para dicho programa. semáforo.

• Su memoria de trabajo (memoria crítica), es decir, • La forma de elegir los procesos de la cola en espera
la memoria que ha reservado y sus contenidos. es mediante una política rst in rst out.

• Otra información que permite al sistema operativo La sincronización explícita entre procesos es un caso par-
su plani cación. ticular del estado “bloqueado”. En este caso, el suceso

2∪3
2∪4 CAPÍTULO 155. PROCESO (INFORMÁTICA)

que permite desbloquear un proceso no es una operación Salida normal, ésta se presenta cuando el proceso termi-
de entrada/salida, sino una señal generada a propósito por na de forma voluntaria, por ejemplo, cuando se cierra en
el programador desde otro proceso. navegador web o el procesador de textos.
Hay cuatro eventos principales que provocan la creación Salida por error, ésta se presenta cuando el proceso tie-
de procesos: ne que salir debido a insu ciencia de datos, por ejemplo,
cuando solicita un archivo que no existe.
• El arranque del sistema. Error fatal, éste sucede por un error en el programa, como
las divisiones entre 0 o requerimiento de memoria inac-
• La ejecución, desde un proceso, de una llamada al cesible.
sistema para la creación de otro proceso.
Eliminado por otro proceso, éste es sumamente útil cuan-
• Una petición de usuario para crear un proceso. do un proceso se queda colgado, es decir, sin terminar,
pero tampoco responde. En Unix un ejemplo es cuando
• El inicio de un trabajo por lotes. se utiliza el comando kill para terminar procesos abrup-
tamente.
Los procesos pueden contener uno o más hilos, hacien-
do más e ciente las tareas, asimismo la complejidad de
los algoritmos de sincronización, ya que podría ocurrir la
condición de carrera muy a menudo, inclusive los inde-
155.3 Estados de un proceso
seados interbloqueos.
Los estados de un proceso obedecen a su participación y
disponibilidad dentro del sistema operativo y surgen de la
155.1 Creación de un proceso necesidad de controlar la ejecución de cada proceso. Los
procesadores sólo pueden ejecutar un solo proceso a la
vez, turnándolos para el uso de éste. Existen procesos no
Básicamente hasta el día de hoy existen sólo 4 formas de apropiativos o cooperativos que básicamente ocupan todo
crear un proceso: el tiempo del procesador hasta que ellos deciden dejarlo.
Los procesos apropiativos son aquellos que ocupan por
• Arranque del sistema. un período de tiempo el procesador hasta que una inte-
rrupción o señal llega al procesador para hacer el cambio
• En la ejecución, desde un proceso, de una llamada de proceso, a esto se le conoce como cambio de contexto.
al sistema para la creación del proceso.
Los posibles estados que puede tener un proceso son eje-
• Una petición deliberada del usuario para crear un cución, bloqueado y listo:
proceso.

• El inicio de un trabajo por lotes. • Ejecución, es un proceso que está haciendo uso del
procesador.
La forma de creación de procesos en Unix es a través de • Bloqueado, No puede ejecutarse hasta que un evento
una llamada al sistema fork la cual creará un proceso hijo externo sea llevado a cabo.
en total semejanza al padre, hasta que el recién proceso
decida cambiar su imagen en memoria, incluso obtener • Listo, ha dejado disponible al procesador para que
sus propios descriptores de archivos abiertos. otro proceso pueda ocuparlo.

Las posibles transiciones son 4. La primera se realiza

155.2 Terminación de un proceso cuando el sistema operativo determina que el proceso no
puede continuar justo en ese momento, en algunos siste-
El ciclo de vida de un proceso es sencillo, consta de la mas se puede hacer una llamada al sistema“pause”para
creación, la ejecución de instrucciones y la terminación. pasar al estado bloqueado, en Unix cuando el proceso está
Cabe señalar que un proceso en el transcurso de su ciclo leyendo datos provenientes de una canalización o de un
puede estar en diferentes estados. archivo especial (terminal) y no hay entrada disponible,
el proceso se bloquea de forma automática.
• Salida normal. Las transiciones 2 y 3 son llevadas a cabo por el plani -
cador de procesos, siendo que el proceso no tiene conoci-
• Salida por error.
miento de éste. La transición 2 se da cuando el plani ca-
• Error fatal. dor de procesos decide que el proceso ya estuvo el tiem-
po su ciente en ejecución y debe dar paso a la ejecución
• Eliminado por otro proceso. de otros procesos (adquieran tiempo del procesador). La
155.7. BIBLIOGRAFÍA 2∪∧

transición 3 se realiza cuando todos los procesos han ocu-

pado tiempo del procesador y debe retomarse el primer
proceso.
La transición 4 ocurre cuando se produce un evento ex-
terno por el que un proceso estaba en espera, por ejem-
plos, introducir datos desde la terminal. Si no hay otro
proceso en ejecución en ese instante, la transición 3 se
activa y el proceso comienza a ejecutarse; también po-
dría pasar al estado de “listo”y esperar un momento
para iniciar la ejecución.

155.4 Tipos de procesos

Existen dos tipos de procesos, aquellos que se ejecutan en
modo kernel y aquellos que se ejecutan en modo usuario.
Los primeros son más lentos por las llamadas al sistema
que realizan, sin embargo, son más seguros por la inte-
gridad que representan. Cuando hablamos de los proce-
sos de usuario, podemos decir que el sistema operativo
podría no ser multiproceso, ya que se vale de librerías
(como pthread) para hacer un multiplexado y dar la apa-
riencia de trabajar como multiproceso.
Podría pensarse en otra clasi cación, como son los pro-
cesos en primer plano y procesos en segundo plano. Los
primeros interactúan con el usuario, es decir, el usuario
proporciona los datos que el proceso utilizará. Los segun-
dos, son creados para tareas bien de nidas y no necesitan
la intervención del usuario, por ejemplo, se puede tener
un proceso en segundo plano para revisar la temperatura
el disco duro constantemente, éstos también son conoci-
dos como demonios.

155.5 Véase también

• Memoria virtual
• Multiproceso

• Unix

• Paginación

155.6 Referencias
[1] Stallings ∧º edición pag. 109

155.7 Bibliografía
Tanenbaum, Andrew S. (2009). «2 Procesos e hilos». Sis-
temas operativos modernos (3 edición). Prentice Hall. p.
10∩∨.
Capítulo 156

Proceso para el desarrollo de software

El Proceso para el desarrollo de software, también de- 156.2 Actividades del desarrollo de
nominado ciclo de vida del desarrollo de software es
una estructura aplicada al desarrollo de un producto de
software
software. Hay varios modelos a seguir para el estableci-
miento de un proceso para el desarrollo de software, cada
uno de los cuales describe un enfoque diferente para di-
ferentes actividades que tienen lugar durante el proceso.
Algunos autores consideran un modelo de ciclo de vida
un término más general que un determinado proceso para
el desarrollo de software. Por ejemplo, hay varios proce-
sos de desarrollo de software especí cos que se ajustan a
un modelo de ciclo de vida de espiral.

156.1 Generalidades

La gran cantidad de organizaciones de desarrollo de soft- Actividades del proceso de desarrollo de software representados
ware implementan metodologías para el proceso de desa- en el desarrollo en cascada. Hay algunos modelos más para re-
presentar este proceso.
rrollo. Muchas de estas organizaciones pertenecen a la in-
dustria armamentística, que en los Estados Unidos nece-
sita un certi cado basado en su modelo de procesos para
poder obtener un contrato. 156.2.1 Plani cación
El estándar internacional que regula el método de selec-
ción, implementación y monitoreo del ciclo de vida del La importante tarea a la hora de crear un producto de
software es ISO 1220∩. software es obtener los requisitos o el análisis de los re-
quisitos. Los clientes suelen tener una idea más bien abs-
Durante décadas se ha perseguido la meta de encontrar
tracta del resultado nal, pero no sobre las funciones que
procesos reproducibles y predecibles que mejoren la pro-
debería cumplir el software.
ductividad y la calidad. Algunas de estas soluciones inten-
tan sistematizar o formalizar la aparentemente desorgani- Una vez que se hayan recopilado los requisitos del cliente,
zada tarea de desarrollar software. Otros aplican técnicas se debe realizar un análisis del ámbito del desarrollo. Este
de gestión de proyectos para la creación del software. Sin documento se conoce como especi cación funcional.
una gestión del proyecto, los proyectos de software co-
rren el riesgo de demorarse o consumir un presupuesto
mayor que el planeado. Dada la cantidad de proyectos 156.2.2 Implementación, pruebas y docu-
de software que no cumplen sus metas en términos de mentación
funcionalidad, costes o tiempo de entrega, una gestión de
proyectos efectiva es algo que a menudo falta. La implementación es parte del proceso en el que los
Algunas organizaciones crean un grupo propio (Software ingenieros de software programan el código para el pro-
Engineering Process Group, abreviado SEPG) encargado yecto.
de mejorar los procesos para el desarrollo de software en Las pruebas de software son parte esencial del proceso
la organización. de desarrollo del software. Esta parte del proceso tiene la

2∪∨
156.3. MODELOS DE DESARROLLO DE SOFTWARE 2∪∩

función de detectar los errores de software lo antes posi-

ble.
La documentación del diseño interno del software con el
objetivo de facilitar su mejora y su mantenimiento se rea-
liza a lo largo del proyecto. Esto puede incluir la docu-
mentación de un API, tanto interior como exterior.

156.2.3 Despliegue y mantenimiento

El despliegue comienza cuando el código ha sido su cien-

temente probado, ha sido aprobado para su liberación y
ha sido distribuido en el entorno de producción.
Entrenamiento y soporte para el software es de suma im-
portancia y algo que muchos desarrolladores de softwa-
re descuidan. Los usuarios, por naturaleza, se oponen al
cambio porque conlleva una cierta inseguridad, es por Si se aplica este paradigma, unos de los principales pro-
ello que es fundamental instruir de forma adecuada a los blemas , es que las etapas realizadas no son autónomas de
futuros usuarios del software. las siguientes, creando una dependencia estructural y en
El mantenimiento o mejora del software de un software el acaso de un error atrasaría todo el proyecto. Se tiene
con problemas recientemente desplegado, puede requerir que tener pautas bien de nidas, y que no se incurra a mo-
más tiempo que el desarrollo inicial del software. Es po- di cación porque implicaría en que el software no cumpla
sible que haya que incorporar código que no se ajusta al con su ciclo de vida. Tener en cuenta
*
que el cliente no se
diseño original con el objetivo de solucionar un problema vea afectado por la impaciencia. [3]
o ampliar la funcionalidad para un cliente. Si los costes 2. Paradigma Orientado a Objetos: Estos modelos se ba-
de mantenimiento son muy elevados puede que sea opor- san en la Programación orientada a objetos; por lo tanto,
tuno rediseñar el sistema para poder contener los costes se re ere al concepto de clase, el análisis de requisitos y el
de mantenimiento. diseño. El modelo o paradigma orientado a objetos posee
dos características principales, las cuales son:

• Permite la re-utilización de software.

• Facilita el desarrollo de herramientas informáticas

156.3 Modelos de Desarrollo de de apoyo al desarrollo, el cual es simple al imple-
mentarla en una notación orientado a objetos llama-
Software do UML.* [4]

Los modelos de desarrollo de software son una represen- 3. Paradigma de Desarrollo →gil: Es un paradigma de las
tación abstracta de una manera en particular. Realmente Metodologías De Desarrollo basado en procesos ágiles.
no representa cómo se debe desarrollar el software, sino Estos intentan evitar los tediosos caminos de las meto-
de un enfoque común. Puede ser modi cado y adaptado dologías tradicionales enfocándose en las personas y los
de acuerdo a las necesidades del software en proceso de resultados. Usa un enfoque basado en el Valor para cons-
desarrollo. * [1] Hay varios modelos para per lar el pro- truir software, colaborando con el cliente e incorporando
ceso de desarrollo, cada uno de las cuales cuenta con pros los cambios continuamente.* [∧]
y contras. El proyecto debería escoger el más apropiado
para sus necesidades. En ocasiones puede que una com-
binación de varios modelos sea apropiado. Existen tres 156.3.1 Modelo de cascada
paradigmas de los modelos de desarrollo de software:
El modelo de cascada de ne las siguientes etapas que de-
1. Paradigma Tradicional: ben cumplirse de forma sucesiva:
Es uno de los paradigmas más antiguo, se inventó durante
la creación del método estructurado. Si se elige un pro- 1. Especi cación de requisitos
yecto, el método varia en etapas.* [2] Como todo modelo,
existen sus pros y contras al usar este paradigmas: 2. Diseño del software
2∪∪ CAPÍTULO 156. PROCESO PARA EL DESARROLLO DE SOFTWARE

3. Construcción o Implementación del software 1. El énfasis se sitúa en el análisis de riesgo, y por lo

tanto requiere de clientes que acepten este análisis y
4. Integración actúen en consecuencia. Para ello es necesaria con-
anza en los desarrolladores así como la predispo-
∧. Pruebas (o validación)
sición a gastar más para solventar los temas, por lo
∨. Despliegue (o instalación) cual este modelo se utiliza frecuentemente en desa-
rrollo interno de software a gran escala.
∩. Mantenimiento
2. Si la implementación del riesgo de análisis afecta-
rá de forma esencial los bene cios del proyecto, no
Siguiendo el modelo de cascada de forma estricta, sólo
debería utilizarse este modelo.
cuando se naliza una fase, comienza la otra. En ocasio-
nes se realiza una revisión antes de iniciar la siguiente 3. Los desarrolladores de software han de buscar de
fase, lo que permite la posibilidad de cambios (lo que forma explícita riesgos y analizarlos de forma ex-
puede incluir un proceso de control formal de cambio). haustiva para que este modelo funcione.
Las revisiones también se utilizan para asegurar que la
fase anterior ha sido totalmente nalizada; los criterios
para completar una fase se conocen frecuentemente con La primera fase es la búsqueda de un plan para conseguir
el término inglés“gate”(puerta). Este modelo desacon- los objetivos con las limitaciones del proyecto para así
seja revisitar y revisar fases que ya se han completado. buscar y eliminar todos los riesgos potenciales por medio
Esta falta de exibilidad en un modelo de cascada puro de un cuidadoso análisis, y si fuera necesario incluyendo
ha sido fuente de crítica de los defensores de modelos la fabricación de un prototipo. Si es imposible descartar
más exibles. algunos riesgos, el cliente ha de decidir si es convenien-
te terminar el proyecto o seguir adelante ignorando los
riesgos. Por último, se evalúan los resultados y se inicia
156.3.2 Modelo de espiral el diseño de la siguiente fase.

La principal característica del modelo en espiral es la ges-

tión de riesgos de forma periódica en el ciclo de desarro- 156.3.3 Desarrollo iterativo e incremental
llo. Este modelo fue creado en 19∪∪ por Barry Boehm,
combinando algunos aspectos clave de las metodologías El desarrollo iterativo recomienda la construcción de sec-
del modelo de cascada y del desarrollo rápido de aplica- ciones reducidas de software que irán ganando en tamaño
ciones, pero dando énfasis en un área que para muchos no para facilitar así la detección de problemas de importan-
jugó el papel que requiere en otros modelos: un análisis cia antes de que sea demasiado tarde. Los procesos itera-
iterativo y concienzudo de los riesgos, especialmente en tivos pueden ayudar a desvelar metas del diseño en el caso
el caso de sistema complejos de gran escala. de clientes que no saben cómo de nir lo que quieren.* [∨]
La espiral se visualiza como un proceso que pasa a tra-
vés de algunas interaciones con el diagrama de los cuatro 156.3.4 Desarrollo ágil
cuadrantes representativos de las siguientes actividades:
El desarrollo ágil de software utiliza un desarrollo itera-
1. crear planes con el propósito de identi car los obje- tivo como base para abogar por un punto de vista más li-
tivos del software, seleccionados para implementar gero y más centrado en las personas que en el caso de las
el programa y clari car las restricciones en el desa- soluciones tradicionales. Los procesos ágiles utilizan re-
rrollo del software; troalimentación en lugar de plani cación, como principal
mecanismo de control. La retroalimentación se canaliza
2. Análisis de riesgos: una evaluación analítica de pro- por medio de pruebas periódicas y frecuentes versiones
gramas seleccionados, para evaluar como identi car del software.
y eliminar el riesgo;
Hay muchas variantes de los procesos ágiles:
3. la implementación del proyecto: implementación del
desarrollo del software y su pertinente veri cación; • En el caso de la programación extrema (XP), las fa-
ses se realizan en pasos muy cortos (o “continuos”
Modelo de espiral con énfasis en los riesgos, haciendo ) con respecto al anterior. El primer paso (intencio-
hincapié en las condiciones de las opciones y limitacio- nalmente incompleto) por los pasos puede ocurrir
nes para facilitar la reutilización de software, la calidad en un día o en una semana, en lugar de los meses o
del software puede ayudar como una meta propia en la años de cada paso completo en el modelo en casca-
integración en el desarrollo del producto. Sin embargo, da. En primer lugar, se crean pruebas automatizadas
el modelo en espiral tiene algunas limitaciones, entre las para proveer metas concretas al desarrollo. Después
que destacan: se programa el código, que será completo cuando
156.4. MODELOS DE MEJORA DE PROCESOS 2∪9

todas las pruebas se superan sin errores, y los desa- 156.4 Modelos de mejora de proce-
rrolladores ya no sabrían como mejorar el conjun-
to de pruebas necesario. El diseño y la arquitectura
sos
emergen a partir de la refactorización del código, y
se da después de programar. El diseño lo realizan Capability Maturity Model Integration El Capability
los propios desarrolladores del código. El sistema, Maturity Model Integration (CMMI), en español
incompleto, pero funcional se despliega para su de- «Integración de Modelos de Madurez de Capaci-
mostración a los usuarios (al menos uno de los cua- dades» es uno de los modelos líderes basados en
les pertenece al equipo de desarrollo). Llegado es- mejores prácticas. Son evaluaciones independientes
te punto, los profesionales comienzan a escribir las las que con rman el grado con el que una organi-
pruebas para la siguiente parte del sistema de más zación siguen sus propios procesos, que no evalúa
importancia. la calidad de los procesos o del software que se
produce. CMMI ha reemplazado a CMM y tiene
un ámbito global, no sólo en procesos destinados al
desarrollo del software.

156.3.5 Codi cación y corrección ISO 9000 ISO 9000 describe estándares para un proce-
so organizado formalmente para resultar en un pro-
El desarrollo de codi cación y corrección (en inglés“Co- ducto y los métodos de gestión y monitoreo del pro-
de and x”) es, más que una estrategia predeterminada, greso. Aunque este estándar se creó inicialmente pa-
el resultado de una falta de experiencia o presión que se ra el sector de producción, los estándares de ISO
ejerce sobre los desarrolladores para cumplir con una fe- 9000 también se han aplicado al desarrollo del soft-
cha de entrega.* [∩] Sin dedicar tiempo de forma explícita ware. Al igual que CMMI, que una organización está
para el diseño, los programadores comienzan de forma in- certi cada con el ISO 9000 no garantiza la calidad
mediata a producir código. Antes o después comienza la del resultado nal, sólo con rma que se ha seguido
fase de pruebas de software (a menudo de forma tardía) los procesos establecidos.
y los inevitables errores que se encuentran han de elimi-
narse antes de poder entregar el software. ISO 15504 ISO 1∧∧04, también conocido como Soft-
ware Process Improvement Capability Determination
(SPICE), en español «Determinación de la Capaci-
dad de Mejora del Proceso de Software» es un mar-
co para la evaluación de procesos de software. Este
156.3.6 Orientado a la Reutilización estándar tiene como objetivo un modelo claro pa-
ra poder comparar procesos. SPICE se utiliza como
La reutilización de software es un proceso donde se recu- en el caso de CMMI. Modela procesos para gestio-
rre al uso de activos de software en las especi caciones de nar, controlar, guiar y monitorear el desarrollo del
análisis, diseños, implementación y pruebas de una apli- software. Este modelo se utiliza entonces para me-
cación o sistemas de software.* [∪] dir lo que una organización o proyecto hace durante
el desarrollo del software. Esta información se ana-
La reutilización tiene ciertos Indicadores por ejemplo: liza para identi car puntos débiles y de nir acciones
1. Entre el 40% y ∨0% de una aplicación es re-utilizable para subsanarlos. También identi ca puntos fuertes
en otra. que pueden adoptarse en el resto de la organización.
2. Aproximadamente el ∨0% de una aplicación adminis-
trativa es re-utilizable.
3. Aproximadamente el ∩∧% de las funciones son comu-
156.5 Métodos formales
nes a más de un programa.
Los métodos formales son soluciones matemáticas pa-
4. Solo el 1∧% del código encontrado en muchos sistemas ra resolver problemas de software y hardware a nivel de
es único y novedoso a una aplicación especi ca. requisitos, especi cación y diseño. Ejemplos de méto-
El rango general de uso recurrente esta entre el 1∧% y dos formales incluyen el Método B, la red de Petri, la
∪∧%.* [9] demostración automática de teoremas, RAISE y el VDM.
La reutilización tiene Principios como la existencia de Hay varias notaciones de especi caciones formales, ta-
parecidos en distintos sistemas de un mismo dominio, les como el lenguaje Z. Más generalmente, se puede uti-
donde el software puede representarse como una com- lizar la teoría de autómatas para aumentar y validar el
binación de módulos y los sistemas nuevos se puede ca- comportamiento de la aplicación diseñando un sistema
racterizar por diferencias respecto a los antiguos siste- de autómata nito.
mas.* [10] Las metodologías basadas en los autómatas nitos permi-
290 CAPÍTULO 156. PROCESO PARA EL DESARROLLO DE SOFTWARE

ten especi cación de software ejecutable y evitar la crea- [∩] McConnell, Steve. «∩: Lifecycle Planning». Rapid Deve-
ción convencional de código. lopment. Redmond, Washington: Microsoft Press. p. 140.
Los métodos formales se suelen aplicar en software de [∪] [Link] engineering with reusable compo-
aviación, especialmente si es software de seguridad críti- nents. Springer Verlag, Agosto 199∩
co. Los estándares de aseguramiento del software de se-
[9] Jonas A. Montilva, Nelson Arape y Juan Andres Colme-
guridad, tales como DO1∩∪B demandan métodos forma-
nares. (14 de noviembre de2003). «Desarrollo de softwa-
les en el nivel más alto de categorización (Nivel A).
re basado en componentes». Consultado el 2 de abril de
La formalización del desarrollo de software está ganando 2014.
en fuerza poco a poco, en otros ámbitos, con la aplica-
[10] «Ciclo de vida del Software». Archivado desde el original
ción del lenguaje de especi cación OCL2.0 (y especiali- el 2∪ de noviembre de 201∧. Consultado el 2 de abril de
zaciones tales como Java Modeling Language) y particu- 2014.
larmente con Model-driven Architecture, que permite la
ejecución de diseños, incluso especi caciones.
Otra tendencia que está surgiendo en el desarrollo de soft- 156.8 Enlaces externos
ware es la redacción de especi caciones en algún tipo de
lógica (normalmente una variación de FOL), para acto • No Silver Bullet: Essence and Accidents of Software
seguido ejecutar esa lógica como si se tratase de un pro- Engineering", 19∪∨
grama. El lenguaje OWL, basado en lógica descriptiva,
es un buen ejemplo. También se está trabajando en en- • Gerhard Fischer,“The Software Technology of the
lazar un idioma natural de forma automática con lógica, 21st Century: From Software Reuse to Collaborati-
lógica que puede ejecutarse. Ejemplo en este campo es ve Software Design”, 2001
el Attempto Controlled English, una lógica de negocios de
Internet, que no busca controlar el vocabulario o la sin- • Lydia Ash: The Web Testing Companion: The Insi-
taxis. Una características de los sistemas que apoyan el der's Guide to E cient and E ective Tests, Wiley,
vínculo bidireccional inglés-lógica y ejecución directa de May 2, 2003. ISBN 0-4∩1-43021-∪
la lógica es que pueden explicar sus resultados en inglés • [Link] ̶Software as a Service Systems
en un nivel de negocios o cientí co. Development Life Cycle Project
• Software development life cycle (SDLC) [visual
156.6 Véase también image], software development life cycle

• Ingeniería de software
• Anexo:Filosofías del desarrollo de software
• Scrum
• Metodología de desarrollo de software
• Desarrollo ágil de software
• Programación extrema
• Prototipo
• Desarrollo de software

156.7 Referencias
[1]

[2] [[Link]

[3]

[4] Ingeniería de software

[∧] Ingeniería de software

[∨] [Link]
Capítulo 157

Programa informático

den ejecutar con la ayuda de un intérprete, o pueden ser

empotrados directamente en hardware.
De acuerdo a sus funciones, los programas informáti-
cos se clasi can en software de sistema y software de apli-
cación. En las computadoras de 201∧, al hecho de ejecu-
tar varios programas de forma simultánea y e ciente, se
lo conoce como multitarea.

157.1 Programación
La programación de computadoras es el proceso iterati-
vo de escribir o editar código fuente. Dicha edición de
código fuente implica probar, analizar y perfeccionar, y,
a veces, coordinar con otros programadores, en el caso
de un programa desarrollado en conjunto. Una persona
que practica esta técnica se le conoce como programador
de computadoras, desarrollador de software, o codi ca-
Un programa informático escrito en un estilo orientado a objetos. dor. El proceso, a veces a largo plazo, de programación de
computadoras normalmente se lo conoce como desarrollo
Un programa informático o programa de computado- de software. El término ingeniería de software se está
ra es una secuencia de instrucciones, escritas para rea- convirtiendo en muy popular, ya que esta actividad es vis-
lizar una tarea especí ca en una computadora.* [1] Es- ta como una disciplina de ingeniería.
te dispositivo requiere programas para funcionar, por lo
general, ejecutando las instrucciones del programa en un
procesador central.* [2] El programa tiene un formato eje- 157.1.1 Paradigmas
cutable que la computadora puede utilizar directamen-
te para ejecutar las instrucciones. El mismo programa Los programas de ordenador se pueden clasi car según
en su formato de código fuente legible para humanos, el paradigma del lenguaje de programación utilizado pa-
del cual se derivan los programas ejecutables (por ejem- ra producirlos. Dos de los principales paradigmas son
plo, compilados), le permite a un programador estudiar y imperativos y declarativos.
desarrollar sus algoritmos. Una colección de programas Los programas escritos con un lenguaje imperativo espe-
de computadora y datos relacionados se conoce como ci can un algoritmo utilizando declaraciones, expresio-
software. nes e informes.* [4] Una declaración asocia un nombre de
Generalmente, el código fuente lo escriben profesionales variable a un tipo de datos. Por ejemplo: var x: integer; .
conocidos como programadores de computadora.* [3] Es- Una expresión produce un valor. Por ejemplo: 2 + 2 pro-
te código se escribe en un lenguaje de programación que duce 4. Por último, una declaración puede asignar una
sigue uno de los siguientes dos paradigmas: imperativo expresión a una variable o usar el valor de una variable
o declarativo, y que posteriormente puede ser converti- para alterar las estructuras de control del programa. Por
do en un archivo ejecutable (usualmente llamado un pro- ejemplo: x := 2 + 2; if x = 4 then hacer_algo(); Una crí-
grama ejecutable o un binario) por un compilador y más tica de los lenguajes imperativos es el efecto secundario
tarde ejecutado por una unidad central de procesamien- de una sentencia de asignación en una clase de variables
to. Por otra parte, los programas de computadora se pue- llamadas variables no locales.* [∧]

291
292 CAPÍTULO 157. PROGRAMA INFORMÁTICO

Los programas escritos en un lenguaje declarativo espe- representación intermedia e ciente para la ejecución fu-
ci can las propiedades que tienen o que deben cumplir- tura. BASIC, Perl y Python son ejemplos de programas de
se para la salida. No especi can detalles expresados en computadora ejecutados inmediatamente. Por otra parte,
términos de ujo de control de la máquina de ejecución los programas de computadora de Java se compilan antes
pero sí de las relaciones matemáticas entre los objetos de tiempo y se almacena como un código independien-
declarados y sus propiedades. Los lenguajes funcionales te de la máquina llamado bytecode. Entonces, dicho by-
y lógicos son dos amplias categorías de lenguajes declara- tecode es ejecutado a petición de un intérprete llamado
tivos. El principio detrás de los lenguajes funcionales (co- máquina virtual.
mo Haskell) es el de no permitir efectos secundarios, lo
La principal desventaja de los intérpretes es que los pro-
que hace que sea más fácil para razonar sobre los progra-gramas de computadora corren más lento que cuando son
mas como si se tratasen de funciones matemáticas.* [∧] El
compilados. La interpretación de código resulta más lenta
principio detrás de los lenguajes lógicos (como Prolog) es
que la ejecución de la versión compilada porque el intér-
de nir el problema a ser resuelto - la meta - y dejar la so-
prete debe decodi car cada declaración cada vez que se
lución detallada al propio sistema Prolog.* [∨] El objetivo
carga y luego realizar la acción deseada. Sin embargo, el
se de ne proporcionando la lista de sub-objetivos. Luego,desarrollo de software puede ser más rápido usando un in-
cada subobjetivo se de ne más arriba, proporcionando la térprete porque la prueba es inmediata cuando se omite el
lista de sus sub-objetivos, etc. Si la ruta de sub-objetivos
paso de la compilación. Otra desventaja de los intérpretes
no encuentra una solución, entonces ese subobjetivo se es que debe estar presente al menos uno en la computado-
retrocede y otra vía se intenta sistemáticamente. ra durante la ejecución del programa de computadora. Por
La forma en que se crea el programa puede ser textual o el contrario, los programas de computadora compilados
visual. En un programa de lenguaje visual, los elementos no necesitan compilador presente durante la ejecución.
en vez de ser textualmente especi cados son manipulados No se requieren propiedades de un lenguaje de progra-
grá camente. mación si se está compilado exclusivamente o interpre-
tándose exclusivamente. Por lo general, la clasi cación
re eja el método más popular de ejecución del lenguaje.
157.1.2 Compilado o interpretando
Por ejemplo, BASIC se considera un lenguaje interpreta-
do y C un lenguaje compilado, a pesar de la existencia de
Un programa de computadora bajo la forma de lengua-
compiladores de BASIC e intérpretes de C. Algunos sis-
je de programación de computadoras legible por un hu-
temas utilizan compilación en tiempo de ejecución (JIT)
mano, se lo llama código fuente. Dicho código fuen-
mediante la cual las secciones de la fuente se compilan
te se puede convertir en una imagen ejecutable por un
'sobre la marcha' y se almacenan para ejecuciones poste-
compilador o ejecutarse inmediatamente con la ayuda de
riores.
un intérprete.
Cualquiera de los programas compilados o interpretados
pueden ser ejecutados en un proceso por lotes sin inter- 157.1.3 Programas que se auto-modi can
vención humana, pero los programas interpretados le per-
miten al usuario escribir comandos en una sesión interac- Un programa informático en ejecución normalmente es
tiva. En este caso, los programas son los comandos sepa- tratado como algo diferente de los datos con los cuales
rados, cuya ejecución se produce secuencialmente, y por opera. Sin embargo, en algunos casos ésta distinción es
lo tanto simultáneamente. Cuando se utiliza un lenguaje ambigua, especialmente cuando un programa se modi ca
para dar órdenes a una aplicación de software (como un a sí mismo. El programa modi cado es ejecutado secuen-
shell de Unix u otra interfaz de línea de comandos), se le cialmente como parte del mismo programa. En el caso de
llama un lenguaje de scripts. programas escritos en código máquina, lenguaje ensam-
Los compiladores se utilizan para traducir el código fuen- blador, Lisp, C, COBOL, PL/1 y Prolog y JavaScript (la
te de un lenguaje de programación, ya sea en código ob- función eval), entre otros, es posible tener código que se
jeto o código máquina.* [∩] El código objeto de objeto auto-modi ca.
necesita procesamiento adicional para convertirse en có-
digo máquina, y el código máquina es el código nativo de
la unidad central de procesamiento, listo para su ejecu-
ción. Los programas de computadora compilados se co-
157.2 Ejecución y almacenamiento
nocen comúnmente como ejecutables, imágenes binarias, de los programas
o simplemente como binarios ̶una referencia al formato
de archivo binario utilizado para almacenar el código eje- Típicamente, los programas se almacenan en una
cutable. memoria no volátil (por ejemplo un disco), para que luego
Los programas de computadora ̶interpretados en un lo- el usuario de la computadora, directa o indirectamente,
te o una sesión interactiva ̶o bien se descodi can y lue- solicite su ejecución. Al momento de dicha solicitud, el
go ejecutados inmediatamente o se decodi can en alguna programa es cargado en la memoria de acceso aleatorio
157.2. EJECUCIÓN Y ALMACENAMIENTO DE LOS PROGRAMAS 293

o RAM del equipo, bajo el control del software llama-

do sistema operativo, el cual puede acceder directamente
al procesador. El procesador ejecuta (corre) el programa,
instrucción por instrucción hasta que termina. A un pro-
grama en ejecución se le suele llamar también proceso.
Un programa puede terminar su ejecución en forma nor-
mal o por causa de un error, dicho error puede ser de
software o de hardware.

157.2.1 Programas empotrados en hard-

ware
Interruptores para la carga manual en una Data General Nova
3.

programa, se establecía la dirección de inicio mediante

interruptores y se presionaba el botón de ejecución.* [10]

157.2.3 Programas generados automática-

mente

La programación automática es un estilo de

programación que crea código fuente mediante
clases genéricas, prototipos, plantillas, aspectos, y
generadores de código para aumentar la productivi-
El microcontrolador a la derecha de la Memoria USB está con- dad del programador. El código fuente se genera con
trolada por un rmware empotrado. herramientas de programación tal como un procesador
de plantilla o un IDE. La forma más simple de un
Algunos programas están empotrados en el hardware. generador de código fuente es un procesador macro, tal
Una computadora con arquitectura de programas alma- como el preprocesador de C, que reemplaza patrones de
cenados requiere un programa inicial almacenado en su código fuente de acuerdo a reglas relativamente simples.
ROM para arrancar. El proceso de arranque es para iden- Un motor de software da de salida código fuente o
ti car e inicializar todos los aspectos del sistema, desde lenguaje de marcado que simultáneamente se vuelve
los registros del procesador, controladores de dispositi- la entrada de otro proceso informático. Podemos pen-
vos hasta el contenido de la memoria RAM.* [∪] Seguido sar como analogía un proceso manejando a otro sien-
del proceso de inicialización, este programa inicial carga do el código máquina quemado como combustible. Los
al sistema operativo e inicializa al contador de programa servidores de aplicaciones son motores de software que
para empezar las operaciones normales. Independiente de entregan aplicaciones a computadoras cliente. Por ejem-
la computadora, un dispositivo de hardware podría tener plo, un software para wikis es un sevidor de aplicacio-
rmware empotrado para el control de sus operaciones. nes que permite a los usuarios desarrollar contenido di-
El rmware se utiliza cuando se espera que el programa námico ensamblado a partir de artículos. Las Wikis ge-
cambie en raras ocasiones o nunca, o cuando el programa neran HTML, CSS, Java, y Javascript los cuales son
no debe perderse cuando haya ausencia de energía.* [9] interpretados por un navegador web.

157.2.2 Programas cargados manualmen- 157.2.4 Ejecución simultánea

te
Muchos programas pueden ejecutarse simultáneamente
Históricamente, los programas eran cargados al procesa- en la misma computadora, hecho al cual se lo conoce
dor central de forma manual mediante interruptores. Una como multitarea, pudiéndose lograr mediante mecanis-
instrucción se representaba por una con guración de es- mos de software o de hardware. Los sistemas operativos
tados de interruptores de abierto o cerrados. Después de modernos pueden ejecutar varios programas a través del
establecer la con guración, se ejecutaba un botón de eje- plani cador de procesos ̶un mecanismo de software pa-
cución. Este proceso era repetitivo. Asimismo, los pro- ra conmutar con frecuencia la cantidad de procesos del
gramas se cargaban manualmente mediante una cinta de procesador de modo que los usuarios puedan interactuar
papel o tarjetas perforadas. Después de que se cargaba el con cada programa mientras estos están corriendo.* [11]
294 CAPÍTULO 157. PROGRAMA INFORMÁTICO

También se puede lograr la multitarea por medio del [4] Wilson, Leslie B. (1993). Comparative Programming Lan-
hardware; las computadoras modernas que usan varios guages, Second Edition (en inglés). Addison-Wesley. p. ∩∧.
procesadores o procesadores con varios núcleos pueden ISBN 0-201-∧∨∪∪∧-3.
correr muchos programas a la vez.* [12]
[∧] Wilson, Leslie B. (1993). Comparative Programming Lan-
guages, Second Edition (en inglés). Addison-Wesley. p.
213. ISBN 0-201-∧∨∪∪∧-3.
157.3 Categorías funcionales
[∨] Wilson, Leslie B. (1993). Comparative Programming Lan-
guages, Second Edition (en inglés). Addison-Wesley. p.
Los programas se pueden categorizar aplicando criterios
244. ISBN 0-201-∧∨∪∪∧-3.
funcionales. Estas categorías funcionales son software de
sistema y software de aplicación. El software de sistema [∩] «What is a Compiler?» (en inglés). Consultado el 10 de
incluye al sistema operativo el cual acopla el hardware enero de 2012.
con el software de aplicación.* [13] El propósito del siste-
ma operativo es proveer un ambiente en el cual el softwa- [∪] Silberschatz, Abraham (1994). Operating System Con-
re de aplicación se ejecuta de una manera conveniente y cepts, Fourth Edition (en inglés). Addison-Wesley. p. 30.
*
e ciente. [13] Además del sistema operativo, el softwa- ISBN 0-201-∧04∪0-4.
re de sistema incluye programas utilitarios que ayudan a
[9] Tanenbaum, Andrew S. (1990). Structured Computer Or-
manejar y con gurar la computadora. Si un programa no
ganization, Third Edition. Prentice Hall. p. 11. ISBN 0-
es software de sistema entonces es software de aplicación. 13-∪∧4∨∨2-2. (en inglés).
El middleware también es un software de aplicación que
acopla el software de sistema con la interfaz de usuario. [10] Silberschatz, Abraham (1994). Operating System Con-
También son software de aplicación los programas utili- cepts, Fourth Edition (en inglés). Addison-Wesley. p. ∨.
tarios que ayudan a los usuarios a resolver problemas de ISBN 0-201-∧04∪0-4.
aplicaciones, como por ejemplo la necesidad de ordena-
miento. [11] Silberschatz, Abraham (1994). Operating System Con-
cepts, Fourth Edition (en inglés). Addison-Wesley. p. 100.
ISBN 0-201-∧04∪0-4.

157.4 Véase también [12] Akhter, Shameem (200∨). Multi-Core Programming (en
inglés). Richard Bowles (Intel Press). pp. 11–13. ISBN 0-
• Algoritmo para la relación entre los programas in- 9∩∨4∪32-4-∨..
formáticos y algoritmos
[13] Silberschatz, Abraham (1994). Operating System Con-
• Aplicación informática cepts, Fourth Edition (en inglés). Addison-Wesley. p. 1.
ISBN 0-201-∧04∪0-4.
• Archivo cabra para un tipo especí co de programa
informático utilizado solo para liberar y estudiar los
efectos de virus informáticos en los sistemas físicos 157.6 Bibliografía
y virtuales

• Estructura de datos • Knuth, Donald E. (199∩). The Art of Computer Pro-

gramming, Volume 1, 3rd Edition (en inglés). Bos-
• Inteligencia arti cial ton: Addison-Wesley. ISBN 0-201-∪9∨∪3-4.
• Sistema multi-agente
• Knuth, Donald E. (199∩). The Art of Computer Pro-
• Software gramming, Volume 2, 3rd Edition (en inglés). Bos-
ton: Addison-Wesley. ISBN 0-201-∪9∨∪4-2.

• Knuth, Donald E. (199∩). The Art of Computer Pro-

157.5 Referencias gramming, Volume 3, 3rd Edition (en inglés). Bos-
ton: Addison-Wesley. ISBN 0-201-∪9∨∪∧-0.
[1] Stair, Ralph M., et al. (2003). Principles of Information
Systems, Sixth Edition (en inglés). Thomson Learning, Inc.
p. 132. ISBN 0-∨19-0∨4∪9-∩.
157.7 Enlaces externos
[2] Silberschatz, Abraham (1994). Operating System Con-
cepts, Fourth Edition (en inglés). Addison-Wesley. p. ∧∪.
ISBN 0-201-∧04∪0-4. • De nición de“Programa”en Webopedia (en inglés)

[3] «Algorithms and Computer Programming» (en inglés). • De nición de “Computer Program” en dictio-
Consultado el ∪ de setiembre de 2014. [Link] (en inglés)
157.7. ENLACES EXTERNOS 29∧

• Esta obra deriva de la traducción total de Computer

program de Wikipedia en inglés, concretamente
de esta versión, publicada por sus editores ba-
jo la Licencia de documentación libre de GNU
y la Licencia Creative Commons Atribución-
CompartirIgual 3.0 Unported.
Capítulo 158

Programa interactivo

Un programa interactivo aquél que necesita la • Como programa interactivo, se irán solicitando al
realimentación continúa del usuario para poder ejecutar- usuario los distintos parámetros en distintos menús.
se. Este concepto se enfrenta al de procesamiento por
lotes en el cual se le indica al programa todo lo que debe
hacer antes de empezar, con lo cual el usuario se puede
desentender de la máquina. Sin embargo esto último
requiere mayor plani cación.

158.1 Frente a Procesamiento por

lotes

158.1.1 Ventajas

• No es necesario conocer todas las opciones, ya que

las distintas interfaces grá cas irán preguntando to-
do. Luego es adecuado para tareas que no se van a
ejecutar muy a menudo y no merece la pena perder
mucho tiempo en aprenderlas.

158.1.2 Inconvenientes

• Requieren una mayor velocidad, ya que hay que evi-

tar el cansancio del usuario.

• Obliga a hacer tareas repetitivas al usuario.

158.2 Ejemplos

158.2.1 Cajero automático

• Un sistema de menú guía al usuario para conseguir

distintos propósitos: Cargar el móvil, sacar dinero,
transferencia...

158.2.2 Compresor de archivos

• Se le dirá al programa qué debe comprimir, cuál es

el archivo de salida, tasa de compresión y algunos
parámetros extra.

29∨
Capítulo 159

Programación lineal paramétrica

Programación lineal paramétrica, el análisis de sensi-

bilidad requiere el cambio de un parámetro a la vez en
el modelo original para examinar su efecto sobre la so-
lución óptima. Por el contrario, la programación lineal
paramétrica (o programación paramétrica en forma más
corta) se re ere al estudio sistemático de los cambios en
la solución óptima cuando cambia el valor de muchos pa-
rámetros al mismo tiempo, dentro de un intervalo. Este
estudio proporciona una extensión muy útil al análisis de
sensibilidad; por ejemplo, se puede veri car el efecto de
cambios simultáneos en parámetros“correlacionados”,
causados por factores exógenos tales como el estado de la
economía. sin embargo, una aplicación más importante
es la investigación de los trueques entre los valores de los
parámetros. por ejemplo, si los valores de cj representan
la ganancia unitaria de las actividades respectivas, es po-
sible aumentar el valor de alguna cj a costa de disminuir
el de otras mediante un intercambio apropiado de perso-
nal y equipo entre las actividades. De manera parecida,
si los valores de bi representan las cantidades disponibles
de los respectivos recursos, es imposible aumentar alguna
bi si se está de acuerdo en disminuir algunas otras.
En algunos casos, el propósito del estudio es determinar
el trueque más apropiado entre dos factores básicos como
costos y bene cios. la forma usual de hacerlo es expresar
uno de estos factores en funciónobjetivo (como minimizar
el costo total) e incorporar el otro a las restricciones (por
ejemplo, bene cio >= nivel mínimo aceptable).
La técnica algorítmica para programación lineal paramé-
trica es una extensión natural del análisis de sensibilidad,
por lo que también está basada en el método simplex.

159.1 Referencias
• HILLER - LIEBERMAN. INVESTIGACIÓN DE
OPERACIONES. Mc Graw Hill Interamericana Edi-
tores S.A. OCLC 1∨∪224∪∩. Texto « edición: Sépti-
ma

» ignorado (ayuda)

29∩
Capítulo 160

Programación visual

La programación visual brinda los conocimientos nece- la programación orientada a objetos y permiten aprove-
sarios para diseñar y desarrollar aplicaciones con un en- char al máximo toda la funcionalidad que ofrecen estos
torno visual amigable y fácil de utilizar para el usuario. lenguajes para el desarrollo de aplicaciones de gestión.
Los lenguajes de programación visual tienden a facilitar
la tarea de los programadores, dado que con los primeros
lenguajes de programación crear una ventana era tarea de 160.2 Véase también
meses de desarrollo y de un equipo de trabajo.
• Diagrama de ujo
• Gambas lenguaje de programación visual libre deri-
160.1 Programación orientada a vado de Basic
objetos • Lenguaje Uni cado de Modelado

• snapp es un sistema de programación visual derivado

• De ne los programas en términos de "clases de ob-
de Google Blockly
jetos”, objetos que son entidades que combinan es-
tado (es decir, datos), comportamiento (esto es, pro- • VisSim es un lenguaje de programación visual.
cedimientos o métodos) e identidad (propiedad del
objeto que lo diferencia del resto). La programación
orientada a objetos expresa un programa como un
conjunto de estos objetos, que colaboran entre ellos
para realizar tareas.

• La técnica de programación orientada a objetos, se

basa en fundamentos de diseño, técnicas y metodo-
logías uni cadas (UML).

• Lenguajes visuales como Visual [Link], Borland

Delphi, incorporan una completa implementación
de la programación orientada a objetos y permi-
ten aprovechar al máximo toda la funcionalidad que
ofrecen estos lenguajes para el desarrollo de aplica-
ciones de gestión.

De ne los programas en términos de “clases de obje-

tos”, objetos que son entidades que combinan estado (es
decir, datos), comportamiento (esto es, procedimientos
o métodos) e identidad (propiedad del objeto que lo di-
ferencia del resto). La programación orientada a objetos
expresa un programa como un conjunto de estos objetos,
que colaboran entre ellos para realizar tareas. La técni-
ca de programación orientada a objetos, se basa en fun-
damentos de diseño, técnicas y metodologías uni cadas
(UML). Lenguajes visuales como Visual [Link], Bor-
land Delphi, incorporan una completa implementación de

29∪
Capítulo 161

Programador

Un programador o una programadora es aquella per-

sona que escribe, depura y mantiene el código fuente de
un programa informático, es decir, el conjunto de instruc-
ciones que ejecuta el hardware de una computadora, para
realizar una tarea determinada.
Un programador o programadora, es la persona que ela-
bora programas de computadora.* [1]
Los programadores también son denominados
desarrolladores de software, aunque estrictamen-
te forman parte de un equipo de personas de distintas
especialidades (mayormente informáticas), y siendo que
el equipo es propiamente el desarrollador.
La programación es una de las principales disciplinas
dentro de la informática.
En muchos países, el/la programador/a es también una
categoría profesional reconocida.

161.1 Reseña histórica

Ada Lovelace, hija del prestigioso poeta Lord Byron, es
considerada la primera programadora de la historia. Su Retrato de Ada Lovelace.
contribución más notable consistió en elaborar un méto-
do para calcular los números de Bernoulli en la máquina blema y describirlo con el propósito de ser solucio-
analítica de Charles Babbage. En homenaje a Ada Love- nado mediante un sistema de información.
lace, fue puesto el nombre al lenguaje de programación
Ada. • El programador, cuya única función consistía en
trasladar las especi caciones del analista en código
ejecutable para la computadora. Dichas especi ca-
161.2 Funciones del programador ciones se recogen en un documento denominado
cuaderno de carga, medio de comunicación entre
ambos.
El programador se encarga de la implementación de
prototipos mediante un lenguaje de programación, que
Hoy día se reconoce que este enfoque no es válido para
compilados pueda entender la computadora.
organizar tareas de tipo intelectual, como es el desarro-
Inicialmente, la profesión se formalizó desde el enfoque llo de software. De manera que la profesión de progra-
tayloriano de la especialización de funciones en la em- mador ha ido evolucionando. Las di cultades de comu-
presa. Así, el proceso de producción de software se con- nicación entre analistas y programadores (un mero docu-
cibe como un conjunto de tareas altamente especializadas mento no basta para describir lo que se quiere hacer) dio
donde está claramente de nido el papel de cada categoría origen a una categoría de profesional intermedia, deno-
profesional: minada analista-programador. La concepción original
del programador ha desaparecido siendo sustituida por la
• El analista, tiene como cometido analizar un pro- de un profesional mucho más formado y con unas funcio-

299
300 CAPÍTULO 161. PROGRAMADOR

nes menos “mecánicas”. 161.4 Notas y referencias

La profesión de analista también ha evolucionado, sur-
giendo el concepto diseñador (de software). Esto se debe [1] Real Academia Española (2014), «programador»,
Diccionario de la lengua española (23.ª edición), Madrid:
a los avances de la ingeniería del software donde se reco-
Espasa, [Link]
noce que el análisis es una actividad compleja y distinta
del diseño. Escuetamente, el análisis describe el problema
(es decir, “qué”hacer) mientras que el diseño describe
la solución (“cómo”hacerlo). 161.5 Véase también
En la mayoría de países industrializados esto ha dado lu-
• Ambiente de desarrollo integrado
gar a la categoría diseñador o arquitecto del software.
• Código fuente
• Ingeniería del software
161.3 Especialidades
• Interfaz de programación de aplicaciones

Estrictamente hablando, la profesión de programador si • Lenguaje de programación

conoce especialidades. No obstante, existen diversas ra-
mas por las que se decantan los propios profesionales y • Programación
que se ven re ejadas en la oferta de empleo. Así, es po- • Software
sible mencionar algunas:

• Programadores de mainframe: aunque se cree extin-

ta la actividad en los viejos grandes sistemas infor-
máticos, lo cierto es que aún existen muchos en fun-
cionamiento que requieren mantenimiento. La tec-
nología que manejan estos programadores es radi-
calmente distinta a la del resto, motivo por el que
se puede considerar esta como la rama más especia-
lizada. Entre sus conocimientos se cuenta COBOL,
RPG, JCL, base de datos jerárquicas, etc.

• Programadores de“nuevas tecnologías": esta es una

rama que gira en torno a Internet, los nuevos ser-
vicios como la Web 2.0 y los negocios por medios
electrónicos o e-commerce. Entre sus conocimientos
destacan lenguajes del lado del servidor como Java,
ASP, .NET, JSP, PHP, Ruby, Python o Perl, y len-
guajes del lado de cliente como HTML, XHTML,
CSS, Javascript ó AJAX (conjunto de tecnologías
existentes como XML y Javascript).

• Programadores de rmware y videojuegos, o

desarrollador de videojuegos: destacan sus co-
nocimientos de hardware, microprocesadores,
ensamblador y C.

• Programadores de “sistemas abiertos": rama aso-

ciada a la Arquitectura Cliente-Servidor. Requie-
re conocimientos de lenguaje de programación C,
lenguaje de programación Pascal, etc.

• Programadores de sistemas de control y adquisición

de datos: además de conocimientos de hardware,
microprocesadores, ensamblador y algunos otros
lenguajes, requieren formación especí ca de física
e ingeniería de control.
Capítulo 162

Pseudocódigo

En ciencias de la computación, y análisis numérico, el introducción y que explica las convenciones particulares
pseudocódigo (o falso lenguaje) es una descripción de en uso. El nivel de detalle del pseudocódigo puede, en al-
alto nivel compacta e informal* [1] del principio operati- gunos casos, acercarse a la de formalizar los idiomas de
vo de un programa informático u otro algoritmo. propósito general.
Utiliza las convenciones estructurales de un lenguaje de Un programador que tiene que aplicar un algoritmo es-
programación real,* [2] pero está diseñado para la lectura pecí co, sobre todo uno desfamiliarizado, generalmente
humana en lugar de la lectura mediante máquina, y con comienza con una descripción en pseudocódigo, y luego
independencia de cualquier otro lenguaje de programa- “traduce”esa descripción en el lenguaje de programación
ción. Normalmente, el pseudocódigo omite detalles que meta y lo modi ca para que interactúe correctamente con
no son esenciales para la comprensión humana del algorit- el resto del programa. Los programadores también pue-
mo, tales como declaraciones de variables, código especí- den iniciar un proyecto describiendo la forma del código
co del sistema y algunas subrutinas. El lenguaje de pro- en pseudocódigo en el papel antes de escribirlo en su len-
gramación se complementa, donde sea conveniente, con guaje de programación, como ocurre en la estructuración
descripciones detalladas en lenguaje natural, o con nota- de un enfoque de Top-down y Bottom-up arriba hacia
ción matemática compacta. Se utiliza pseudocódigo pues abajo.
este es más fácil de entender para las personas que el có-
digo del lenguaje de programación convencional, ya que
es una descripción e ciente y con un entorno indepen-
diente de los principios fundamentales de un algoritmo.
Se utiliza comúnmente en los libros de texto y publica-
ciones cientí cas que se documentan varios algoritmos, 162.2 Sintaxis
y también en la plani cación del desarrollo de programas
informáticos, para esbozar la estructura del programa an-
tes de realizar la efectiva codi cación. En la actualidad y por lo general, el pseudocódigo, como
su nombre lo indica, no obedece a las reglas de sintaxis de
No existe una sintaxis estándar para el pseudocódigo,
ningún idioma en particular ni es de forma estándar sis-
aunque los ocho IDE's que manejan pseudocódigo tengan
temática, a pesar de que cualquier escritor en particular
su sintaxis propia. Aunque sea parecido, el pseudocódi-
vaya a pedir prestado las estructuras de control general,
go no debe confundirse con los programas esqueleto que
la sintaxis y el estilo, por ejemplo, de algún lenguaje de
incluyen código cticio, que pueden ser compilados sin
programación convencional. Pero en caso de que se quie-
errores. Los diagramas de ujo y UML pueden ser con-
ra ejecutar, se debe llevar a forma tipo, para que no genere
siderados como una alternativa grá ca al pseudocódigo,
mensajes de error. Las fuentes populares incluyen la sin-
aunque sean más amplios en papel.
taxis de Pascal, BASIC, C, C++, Java, Lisp, y ALGOL.
Por lo general, se omiten las declaraciones de variables.
A veces, las llamadas a funciones, los bloques de código
162.1 Aplicaciones y el código contenido dentro de un loop se remplazan por
una sentencia de una línea en lenguaje natural.

Generalmente se utiliza pseudocódigo en los libros de Dependiendo del escritor, el pseudocódigo puede variar
texto y publicaciones cientí cas relacionadas con la in- mucho en su estilo, yendo desde en un extremo, una imi-
formática y la computación numérica, para la descripción tación casi exacta de un lenguaje de programación real,
de algoritmos, de manera que todos los programadores hasta al acercarse a una descripción en prosa de formato
puedan entenderlo, aunque no todos conozcan el mismo de pseudocódigo en el otro extremo.
lenguaje de programación. Generalmente, en los libros Este es un ejemplo de pseudocódigo (para el juego mate-
de texto se adjunta una explicación que acompaña a la mático bizz buzz):

301
302 CAPÍTULO 162. PSEUDOCÓDIGO

162.3 De nición de datos del pseu-

docódigo
La de nición de datos se da por supuesta, sobre todo en
las variables sencillas, si se emplea formaciones: pilas, co-
las, vectores o registros, se pueden de nir en la cabecera
del algoritmo, y naturalmente cuando empleemos el pseu-
docódigo para de nir estructuras de datos, esta parte la
desarrollaremos adecuadamente.

162.4 Funciones y operaciones

Cada autor usa su propio pseudocódigo con sus respecti-
vas convenciones. Por ejemplo, la instrucción“reempla-
ce el valor de la variable x por el valor de la variable y "
puede ser representado como:

• asigne a x el valor de y

Diagrama de ujo que muestra el funcionamiento de la instruc-

Las operaciones aritméticas se representan de la forma
ción condicional.
usual en matemáticas.

162.5 Estructuras de control

En la redacción del pseudocódigo se utiliza tres tipos de
estructuras de control: las secuenciales, las selectivas y las
iterativas.

162.5.1 Estructuras secuenciales

Las instrucciones se siguen en una secuencia ja que nor-

malmente viene dada por el número de renglón. Es decir
que las instrucciones se ejecutan de arriba hacia abajo.

162.5.2 Estructuras selectivas

Las instrucciones selectivas representan instrucciones que

pueden o no ejecutarse, según el cumplimiento de una
condición.
La condición es una expresión booleana. Instrucciones es Diagrama de ujo que muestra el funcionamiento de la instruc-
ejecutada sólo si la condición es verdadera. ción condicional.

Selectiva doble (alternativa) Selectiva múltiple

La instrucción alternativa realiza una instrucción de dos También es común el uso de una selección múltiple que
posibles, según el cumplimiento de una condición. equivaldría a anidar varias funciones de selección.
La condición es una variable booleana o una función re- En este caso hay una serie de condiciones que tienen que
ducible a booleana (lógica, Verdadero/Falso). Si esta con- ser mutuamente excluyentes, si una de ellas se cumple las
dición es cierta se ejecuta Instrucciones1 , si no es así, en- demás tienen que ser falsas necesariamente, hay un caso
tonces se ejecuta Instrucciones2 . si no que será cierto cuando las demás condiciones sean
162.6. DESARROLLO DE ALGORITMOS 303

falsas. Bucle hacer

En esta estructura si Condición1 es cierta, entonces se eje-
cuta sólo Instrucciones1 . En general, si Condiciónᵢ es ver- El Bucle hacer se utiliza para repetir un bloque de código
dadera, entonces sólo se ejecuta Instruccionesᵢ mientras se cumpla cierta condición.

Selectiva múltiple-Casos Bucle para

Una construcción similar a la anterior (equivalente en al- Una estructura de control muy común es el ciclo para,
gunos casos) es la que se muestra a continuación. la cual se usa cuando se desea iterar un número conoci-
do de veces, empleando como índice una variable que se
En este caso hay un Indicador es una variable o una fun-
incrementa (o decrementa): Plantilla:Definiciones
ción cuyo valor es comparado en cada caso con los va-
lores "Valorᵢ", si en algún caso coinciden ambos valores, la cual se de ne como:
entonces se ejecutarán las Instruccionesᵢ correspondien-
tes. La sección en otro caso es análoga a la sección si no
del ejemplo anterior. Bucle para cada

Por último, también es común usar la estructura de con-

162.5.3 Estructuras iterativas trol para cada. Esta sentencia se usa cuando se tiene una
lista o un conjunto L y se quiere iterar por cada uno de
Las instrucciones iterativas representan la ejecución de sus elementos:
instrucciones en más de una vez.
Si asumimos que los elementos de L son L0 , L1 , . . . , Ln
, entonces esta sentencia equivaldría a:
Bucle mientras Que es lo mismo que:

El bucle se repite mientras la condición sea cierta, si al Sin embargo, en la práctica existen mejores formas de
llegar por primera vez al bucle mientras la condición es implementar esta instrucción dependiendo del problema.
falsa, el cuerpo del bucle no se ejecuta ninguna vez. Es importante recalcar que el pseudocódigo no es un len-
guaje estandarizado. Eso signi ca que diferentes autores
podrían dar otras estructuras de control o bien usar estas
mismas estructuras, pero con una notación diferente. Sin
embargo, las funciones matemáticas y lógicas toman el
signi cado usual que tienen en matemática y lógica, con
las mismas expresiones.

162.5.4 El anidamiento

Cualquier instrucción puede ser sustituida por una estruc-

tura de control. El siguiente ejemplo muestra el pseudo-
código del ordenamiento de burbuja, que tiene varias es-
tructuras anidadas. Este algoritmo ordena de menor a ma-
yor los elementos de una lista L .
En general, las estructuras anidadas se muestran inden-
tadas, para hacer más sencilla su identi cación a simple
vista. En el ejemplo, además de la indentación, se ha co-
Diagrama de ujo que muestra el funcionamiento de la instruc- nectado con echas los pares de delimitadores de cada
ción mientras nivel de anidamiento.

Bucle repetir
162.6 Desarrollo de algoritmos
Existen otras variantes que se derivan a partir de la an-
terior. La estructura de control repetir se utiliza cuando Con este pseudocódigo se puede desarrollar cualquier al-
es necesario que el cuerpo del bucle se ejecuten al menos goritmo que:
una vez y hasta que se cumpla la condición:
La estructura anterior equivaldría a escribir: • Tenga un único punto de inicio.
304 CAPÍTULO 162. PSEUDOCÓDIGO

• Tenga un número nito de posibles puntos de tér- 162.9 Enlaces externos

mino.
• Pseudocódigo - Diagramas de ujo, programación
• Haya un número nito de caminos, entre el punto de
básica
inicio y los posibles puntos de término.
• Sintaxis del pseudocódigo CEE (C en español)

162.7 Funciones y procedimientos • Foro Programación, tutoriales y ejemplos

• PSEINT - PIPEH pseudointérprete

Muchas personas pre eren distinguir entre funciones y
procedimientos. Una función, al igual que una función ma- • Ejercicios de programación en peseudocódigo
temática, recibe uno o varios valores de entrada y regresa • Intérprete de algoritmos en español
una salida mientras que un procedimiento recibe una en-
trada y no genera ninguna salida aunque en algún caso po-
dría devolver resultados a través de sus parámetros de en-
trada si estos se han declarado por referencia (ver formas 162.10 Referencias
de pasar argumentos a una función o procedimiento).
[1] «Pseudocódigo - Estructuras condicionales». Consultado
En ambos casos es necesario dejar en claro cuáles son el ∩ de diciembre de 2012.
las entradas para el algoritmo, esto se hace comúnmen-
te colocando estos valores entre paréntesis al principio o [2] «Instroducción al PseudoCódigo». Consultado el ∩ de di-
bien declarándolo explícitamente con un enunciado. En ciembre de 2012.
el caso de las funciones, es necesario colocar una palabra
como regresar o devolver para indicar cuál es la salida
generada por el algoritmo. Por ejemplo, el pseudocódi- 162.11 Bibliografía
go de una función que permite calcular an (un número a
elevado a potencia n ). 1. Peña Marí, Ricardo (200∧). Diseño de programas:
Un ejemplo de procedimiento seria el algoritmo de formalismo y abstracción (3 edición). Pearson Al-
Ordenamiento de burbuja, por el que partiendo de una hambra. p. 4∪∪. ISBN 9∩∪-∪4-20∧-4191-4.
lista de valores estos se ordenan, nótese que en un proce- 2. Pseudocódigos y programación estructurada (1 edi-
dimiento, no se calcula el valor de una función, sino que ción). Centro Técnico Europeo de Enseñanzas Pro-
se realiza una acción, en este caso ordenar la lista. fesionales. 2 de 199∩. ISBN 9∩∪-∪4-∪199-0∨∧-2.
3. Brassard, Gilles; Bratley, Paul (199∨). Algorítmica:
162.8 Ventajas del pseudocódigo concepción y análisis. Peña Mari, Ricardo Tr. (1 edi-
ción). Masson, S.A. p. 3∪4. ISBN 9∩∪-∪4-4∧∪-0∧3∧-0.
sobre los diagramas de ujo
4. Rodeira, ed. (∨ de 1994). Pseudocódigos e progra-
Los pseudocódigos presentan los siguientes bene cios: mación estructurada (en gallego) (1 edición). ISBN
9∩∪-∪4-∪11∨-2∪∩-∧.

1. Ocupan mucho menos espacio en el desarrollo del ∧. Edebé, ed. (∪ de 1993). Pseudocódigos y programa-
problema. ción estructurada (1 edición). ISBN 9∩∪-∪4-23∨-312∨-
1.
2. Permite representar de forma fácil operaciones re-
petitivas complejas.
3. Es más sencilla la tarea de pasar de pseudocódigo a 162.12 Véase también
un lenguaje de programación formal.
4. Si se siguen las reglas de identación se puede obser-
var claramente los niveles en la estructura del pro-
grama.
∧. En los procesos de aprendizaje de los alumnos de
programación, éstos están más cerca del paso si-
guiente (codi cación en un lenguaje determinado,
que los que se inician en esto con la modalidad Dia-
gramas de Flujo).
∨. Mejora la claridad de la solución de un problema.
Capítulo 163

Puente de aplicación

En informática, un puente de aplicación o application

bridge es el código que conecta diferentes entornos de un
lenguaje con otros lenguajes.
Los puentes, delimitan el trá co entre redes a las redes
que tiene acceso directo y deben preservar las caracterís-
ticas de las LANs que interconectan (retardo de transmi-
sión, capacidad de transmisión, probabilidad de pérdida,
etc.).
La conexión es utilizada exclusivamente para transmitir
llamadas a métodos con sus propios parámetros y retornar
los valores de un entorno de lenguaje a otro. Por ejemplo,
se necesita un puente para acceder desde Delphi a la API
de OpenO [Link].

30∧
Capítulo 164

Puntero inteligente

En programación, un puntero inteligente (o smart poin- auto_ptr<algun_tipo> funcion_obvia1();

ter) es un tipo abstracto de datos que simula el compor-
tamiento de un puntero corriente pero añadiendo nuevas La función hace explícitamente que el“llamador”tenga
características adicionales, como recolector de basura au- la propiedad del resultado y, además, si no se hace nada,
tomático y comprobador de límites. Estas características no se ltrará memoria. Del mismo modo, si la intención
adicionales tienen como objetivo reducir errores causa-
es devolver un puntero a un objeto gestionado en otros
dos por el mal uso de punteros, manteniendo la e ciencia. lugares, la función podría devolver una referencia:
Los punteros inteligentes suelen llevar un registro de los
objetos a los que apunta con el próposito de gestionar la algun_tipo& funcion_obvia2();
memoria.
El mal uso de los punteros suele ser la mayor fuente de
errores: asignaciones constantes, liberación de memoria
y la referencia, que debe ser realizada por un progra- 164.1 Punteros inteligentes en
ma usando punteros, introduce el riesgo de pérdidas de Boost
memoria. Los punteros inteligentes intentan prevenir las
pérdidas de memoria, liberando automáticamente los re- La biblioteca Boost de C++ nos ofrece varios tipos de
cursos: cuando un puntero (o el último de una serie de punteros inteligentes, los más importantes son:
punteros) a un objeto es destruido, porque por ejemplo
se sale del ámbito, el objeto apuntado también se elimi- • Scoped Pointer: Puntero no copiable
na.
• Shared Pointer: Puntero copiable
Existen varios tipos de punteros inteligentes. Algunos tra-
bajan llevando la cuenta de referencias, otros mediante
asignación de un objeto a un único puntero. Si el lengua- 164.1.1 Scoped pointer
je soporta recolector de basura automático (por ejemplo,
Java), el uso de los punteros inteligentes es innecesario. Un scoped pointer es una clase de puntero inteligente que
En C++, los punteros inteligentes pueden ser implemen- no puede copiarse, por lo que solo puede existir un punto
tados como una“template class”que imita, mediante so- de acceso al objeto que apunta. Cuando el puntero sale
brecarga de operadores, el comportamiento de los punte- del ámbito, el objeto se destruye y la memoria se libera.
ros tradicionales, pero proporcionando algoritmos de ad- Sintaxis:
ministación de memoria.
boost::scoped_ptr<MiClase> MiPuntero (new MiCla-
Los punteros inteligentes pueden facilitar la programa- se(1)); [Link](new MiClase(2));
ción internacional expresando el uso de un puntero en su
propio tipo. Por ejemplo, si una función de C++ devuelve
un puntero, no hay forma de saber cuando se debe libe- Se puede acceder al contenido usando el operador *, ac-
rar la memoria, cuando se ha terminado con el uso de la ceder a la dirección con & y acceder al puntero en bruto
información. con el metodo get().

algun_tipo* function_ambigua(); // ←Qué se debería Ejemplo:

hacer con el resultado? #include <iostream> using namespace std; #include
<boost/scoped_ptr.hpp> /* Vamos a crear una clase
Tradicionalmente, esto se habría resuelto con comenta- que informe de cuándo se crea y cuando se destruye,
rios, pero esto puede ser propenso a errores. Devolviendo y lleve un contador de elementos creados. */ class
un auto_pr de C++: Elemento { static int counter; int n; public: Elemen-
to():n(++counter){ cout << "* Creando Elemento " <<

30∨
 164.2. ENLACES EXTERNOS 30∩

n << endl; }; void lanzar(const char * msg){ cout << "* boost::shared_ptr<Observado> fan; Mirador(){ cout <<
Elemento " << n << " says: " << msg << endl; }; virtual tab() << "+ Creando Mirador”<< endl; } ~Mirador(){
~Elemento(){ cout << "* So Long, Elemento " << n << cout << tab() << "- Borrando Mirador”<< endl; } }; /*
endl; }; }; int Elemento::counter = 0; int main(int argc, La función popular rellena el atributo del Mirador con
char *argv[]) { /* Utilizamos corchetes para abrir un un shared pointer a Observado. */ void popular(Mirador
nuevo entorno (scope) Vemos que al terminar el scope, el & m1, Mirador & m2){ boost::shared_ptr<Observado>
scoped pointer se libera automáticamente, mientras que O(new Observado); [Link] = O; [Link] = O; } int
en el caso del puntero clásico, si no liberamos manulmen- main(int argc, char *argv[]) { tabulados = 0; cout <<
te se produciría una fuga de memoria. */ cout <<“Inicio "-- Inicio”<< endl; { tabulados ++; cout << tab() <<
del scope”<< endl; { boost::scoped_ptr<Elemento> "-- Inicio del primer scope”<< endl; Mirador M1; {
miElemento(new Elemento()); miElemento -> lanzar( tabulados ++; cout << tab() << "-- Inicio del segundo
“Mensaje desde myFun_1”); Elemento * classic- scope”<< endl; Mirador M2; popular(M1, M2); cout <<
Pointer = new Elemento(); classicPointer -> lanzar ( tab() << "-- Fin del segundo scope”<< endl; } tabulados
“Mensaje del elemento con puntero clásico”); delete --; cout << tab() << "-- Final del primer scope”<< endl;
classicPointer; // Necesario borrarlo manualmente! } } tabulados--; cout << "-- Fin”<< endl; return 0; }
cout << “Fin del scope”<< endl; /* Si tenemos un
scoped pointer como atributo de una clase, o como
variable suelta, es posible asignarle un valor utilizando
el método reset, que borrará lo que estuviera contenido 164.2 Enlaces externos
en el puntero previamente. */ boost::scoped_ptr<string>
ptrCadena; [Link](new string(“Hola”)); /*
• Capítulo de muestra "Smart Pointers" del libro
Los operadores habituales se conservan. En el caso del
Modern C++ Design: Generic Programming and
*, se devuelve una referencia &. Para acceder al puntero
Design Patterns Applied por Andrei Alexandrescu,
en bruto se utiliza el método get(), aunque NO SE RE-
Addison-Wesley, 2001.
COMIENDA, ya que hacer modi caciones o borrar el
objeto apuntado a través de get() puede producir errores. • Código de ejemplo "[Link]" del libro The
*/ cout << “Longitud de cadena: " << ptrCadena -> C++ Standard Library - A Tutorial and Reference
length() << endl; cout << *ptrCadena << endl; return 0; } por Nicolai M. Josuttis
• Artículo "Smart Pointers in Boost"

• Artículo "The New C++: Smart(er) Pointers" por

164.1.2 Shared pointer Herb Sutter

Un shared pointer es un tipo de puntero inteligente que • "Smart Pointers - What, Why, Which?" por Yonat
guarda un contador de referencias al objeto al que apunta. Sharon
Cada vez que se hace una copia del puntero, se aumenta el • "Smart Pointers Overview" por John M. Dlugosz
contador. Cuando se destruye uno de los shared pointer,
el contador disminuye. • YASPER library otra implementación de punteros
inteligentes en C++
Cuando el contador llega a cero, quiere decir que no hay
más punteros apuntando al objeto, por lo que este puede • Smart Pointers en Delphi
destruirse y liberar la memoria que ocupa. Todo esto se
hace de forma transparente al usuario.
Sintaxis:
boost::shared_ptr<MiClase> MiPuntero (new MiCla-
se(1)); boost::shared_ptr<MiClase> OtroPuntero =
MiPuntero; [Link](new MiClase(2));

Ejemplo:
#include <iostream> #include <string> using namespace
std; int tabulados; #include <boost/shared_ptr.hpp>
/* Tenemos dos clases. La clase Mirador tiene un
shared pointer a Observado. */ string tab(){ return
string(tabulados, '\t'); } struct Observado{ Obser-
vado(){ cout << tab() << "+ Creando Observado”
<< endl; } ~Observado(){ cout << tab() << "- Bo-
rrando Observado”<< endl; } }; struct Mirador{
Capítulo 165

Pure data

construcción para programas escritos en el software. Es-

to hace el programa arbitrariamente extensible a través de
una API pública, y alienta a los desarrolladores a añadir
sus propias rutinas de audio y control, ya sea en el lengua-
je de programación C o, con la ayuda de otros externos,
en Python, Javascript, Ruby, y potencialmente otros len-
guajes también. Sin embargo, Pd es un lenguaje de pro-
gramación en sí mismo. Unidades de código modulares
y reusables, escritas nativamente en Pd, llamadas “par-
ches”o “abstracciones”, son usadas como programas
independientes y compartidas libremente entre la comu-
nidad de usuarios de Pd, y ninguna otra habilidad de pro-
gramación es requerida para usar Pd pero ayuda.
Con la adición del externo“Entorno Grá co para Multi-
media”(GEM, por su nombre en inglés), y otros externos
diseñados para trabajar con él (como Pure Data Packet,
Captura de pantalla de Pure Data. PiDiP para Linux, framestein para Windows, GridFlow
para proceso de matrices n-dimensionales que integra Pu-
Pure Data (o Pd) es un lenguaje de programación grá- re Data con el lenguaje de programación Ruby, etc.), es
co desarrollado por Miller Puckette durante los años 90 posible crear y manipular vídeo, grá cos OpenGL, imá-
para la creación de música por ordenador interactiva y genes, etc, en tiempo real con aparentemente in nitas po-
obras multimedia. Aunque Puckette es el principal autor sibilidades de interactividad con audio, sensores exter-
del software, Pd es un proyecto de código abierto y tie- nos, etc.
ne una gran base de desarrolladores trabajando en nuevas Adicionalmente, Pd está diseñado nativamente para per-
extensiones al programa. Está publicado bajo una licen- mitir colaboración en vivo a través de redes o de Internet,
cia similar a la licencia BSD. permitiendo a músicos conectados vía LAN, o incluso en
Pd es muy similar en alcance y diseño al programa ori- distintas partes del mundo, hacer música juntos en tiem-
ginal de Puckette, Max(desarrollado cuando él estaba po real.
en IRCAM), y es hasta cierto grado interoperable con Las unidades donde se programa el código se llaman
Max/MSP, el sucesor comercial del lenguaje Max. Am- “patch”o abstracciones, son utilizadas como programas
bos Pd y Max son ejemplos discutibles de lenguajes de independientes y compartidos libremente entre la comu-
programación de “ ujo de datos”. En este tipo de len- nidad de usuarios de Pd. Los patchs constan de diferentes
guajes, funciones u“objetos”son conectados o“parchea- objetos interconectados entre ellos. En su parte superior
dos”unos con otros en un ambiente grá co que modela encontraremos las entradas, donde se les enviaran valores
el ujo del control y el audio. A diferencia de la versión numéricos u otros tipos de datos, y en la inferior la salida
original de Max, sin embargo, Pd siempre fue diseñado de estos.
para hacer procesado de señales y tasas de control en la
También existe la posibilidad de crear patchs secundarios
CPU nativa, en vez de descargar la síntesis y el proceso
conocidos como subpatchs. Están dentro del patch prin-
de señales a un tablero de PDS (como el Ariel ISPW que
cipal. Se crean escribiendo en un objeto las letras “pd”
era usado para Max/FTS). El código de Pd es la base de
seguidas de un espacio y el nombre que se le quiera dar a
las extensiones MSP de David Zicarelli al lenguaje Max
ese subpatch, como se muestra en la gura. Clicando en-
para hacer proceso de audio en software.
cima se nos abre la ventana donde encontramos el código
Como Max, Pd tiene una base modular de código con de nuestro subpatch.
externos u objetos que son utilizados como bloques de

30∪
165.2. OBJETOS MÁS IMPORTANTES 309

Objeto: Su comportamiento dependerá del texto que ten-

ga introducido en él mismo. El programa tiene unos ob-
jetos prede nidos, programados por terceras personas en
diferentes lenguajes como puede ser C. El Pd reconoce
el tipo de objeto y esa caja ya se comporta como tal.
Números: Su utilidad puede ser diversa, desde la de con-
trolar el valor que tiene la señal en diferentes puntos del
patch, hasta la de inicializar valores que se pasan a obje-
tos que controlan, por ejemplo, un nivel de opacidad de
Subpatch. una imagen.
Mensajes: Están provistos de información que se pasa a
El programa tiene dos estados en los que se puede en- los objetos.
contrar el usuario. En modo de edición o en modo de Símbolo: Este objeto guarda un símbolo hasta que recibe
ejecución. Para cambiar de un estado a otro teclearemos un [bang] u otro símbolo. Es entonces cuando este sím-
Ctrl+E. Cuando estamos en el modo edición, podemos bolo sale del objeto, por la parte inferior de la caja. Estos
modi car el contenido de las cajas, o la conexión entre objetos se ofrecen solo en Pd si tienes descargada y co-
ellas. En el modo de ejecución tenemos la posibilidad de rrectamente instalada la biblioteca apropiada. No tienen
poner en marcha todo el patch, e ir modi cando valores porqué existir en las bibliotecas sencillas, aunque acos-
durante su reproducción o cuando este, esté parado. Po- tumbran a estar incluidas en los archivos de instalación.
demos enviar bangs, modi car valor de variables dentro
de los objetos“números”, o activar y desactivar sectores Comentario: lo utilizaremos para incluir aclaraciones
del código con el objeto [toggle], activado cuando tiene dentro de los diferentes pasos que sigue nuestro código.
una cruz y desactivado cuando no.

165.2 Objetos más importantes

165.1 Tipos de objetos

Oscilador.

El objeto [osc~] nos genera una señal sinusoidal. La fre-

cuencia de oscilación dependerá del valor que se intro-
duzca en la entrada que tiene el objeto en la parte su-
perior izquierda. Siempre que coloquemos un oscilador,
tenemos que colocar también un multiplicador y un con-
vertidor digital analógico(dac~). Esto se hace porque el
“osc~”por defecto posee la amplitud máxima en 1, por
eso la multiplicamos por 0.01 para reducir su amplitud y
luego enviarla al “dac~”. El objeto “dac~”tiene dos
entradas que hacen referencia a los dos canales de salida
de la tarjeta de sonido de tu máquina.
Un [bang] tiene como función la activación de la acción
que tiene inmediatamente conectada después.
Metro: Envía series de [bang] periódicamente. Lo crea-
remos escribiendo la palabra “metro”dentro de un ob-
Objetos de Pd. jeto. Este objeto tiene dos entradas, la de la izquierda
310 CAPÍTULO 165. PURE DATA

mérica dada inicialmente. Lo creamos introduciendo la

palabra “select (espacio)condición”. De esta manera
cuando el valor de entrada sea igual a la condición, por la
salida de la izquierda se enviará un bang. Si no coinciden
el bang será enviado por la salida de la derecha. Se pue-
den introducir varias condiciones simultáneas separadas
por espacios. Se crearan tantas salidas como condiciones
más una nal. Cuando el valor coincida con una de las
condiciones, el bang será enviado por la salida que corres-
ponda con dicho valor. Si no coincide, el [bang] siempre
será enviado por la última salida, la de más a la derecha.
Bang.
Moses: Escribiremos la palabra“moses”dentro de un ob-
jeto para poder tenerlo operativo. Contiene dos entradas
y dos salidas. En la entrada de la izquierda conectamos el
valor que está en el proceso y en la derecha el valor que
queremos que actúe de frontera. Si el valor del proceso
es inferior a la frontera, nos saca el valor de entrada por
la salida de la izquierda. En cambio, si el valor es igual o
metro_pd. superior al valor que actúa de frontera, nos sacará el nú-
mero por la salida de la derecha. Podríamos asemejar el
[moses] a un ltro paso bajo y paso alto simultáneo.
acepta [bangs]. Hace que el metro empiece a funcionar;
asimismo acepta mensajes con el texto “stops”, dete-
niendo el funcionamiento del metro. También podemos
enviarle cualquier número diferente de cero para activar-
lo. Si se le envía un cero el metro deja de enviar [bangs].
En la entrada de la derecha le introducimos el número
que rige la periodicidad del envío de bangs, la unidad de
este valor son los milisegundos. Dentro de la misma ca- 165.3 Instalación en GNU posibles
ja de [metro], después de la palabra metro y seguido de problemas y soluciones
un espacio se introduce un número que el objeto ya lo
entiende como el periodo.
Para instalar Pd en GNU deberemos descomprimir el pa-
quete descargado con el programa y ejecutar el archivo
con extensión“.deb”. El primer posible problema con el
que nos podemos encontrar, es que la distribución Ubun-
tu Studio ya lleva un Pure Data instalado de serie. Debi-
do a que es recomendable utilizar la versión Pd_extended
(aunque esto es algo que varia muy a menudo) tendremos
que desinstalar el Pure Data de GNU/linux Ubuntu, para
que, al instalar el nuevo, no tengamos problemas con el
Start
hecho de compartir de carpetas. Otro factor muy común e
Start: Ejecuta los objetos del patch que tiene conectado importante cuando instalemos programas en GNU son las
a él mismo. El objeto [start] lo crearemos escribiendo la dependencias de bibliotecas secundarias que puedan exis-
palabra “start”dentro de un mensaje. tir. Es necesario instalarlas para el buen funcionamiento
del programa. En el caso de Pure Data y de algunas bi-
Stop: Detiene la ejecución del patch que está en funcio- bliotecas externas (externals), se tienen que instalar algu-
namiento. Lo crearemos escribiendo la palabra “stop” nas dependencias mediante el gestor de paquetes llamado
dentro de un mensaje. Synaptic. Ahí podemos buscar cuales son las que necesi-
tamos.
Una vez probado el correcto funcionamiento del Pd, pa-
ra optimizar los recursos del programa, cargamos, en el
start up, las bibliotecas más comunes que se usaran, para
evitar tener que importarlas cada vez que se quieran usar.
De este modo al arrancar Pd en tu máquina ya se cargan
Selector. automáticamente.
Select: Nos actúa de selector según una condición nu- Linux
165.6. PATCH PATRONES 311

Test audio/MIDI.
Objeto de PDP que te crea una cuadrícula que divide la imagen.

165.4 Introducción rápida comandos, quedando así lista para su uso.

Una vez ya tenemos el Pd estable en nuestra máquina se

procede a hacer un primer test del programa para com-
probar que la conexión con nuestra tarjeta de sonido es
correcta. Este lo encontraremos en Media>test audio and
MIDI. Ahí podemos generar una señal de test (un tono,
ruido rosa,…) escuchándola por nuestros altavoces, com-
probando así que todo funciona correctamente.
Para empezar a conocer el entorno de Pd, podemos em-
pezar abriendo ejemplos que encontraremos en los archi-
vos de documentación que hay dentro de la carpeta de Pd.
Allí hay patchs de audio y de vídeo que sirven para fami-
liarizarse con el programa. Cuando queramos crear nues-
tro propio patch, en la ventana de Pd vamos a File>New
y se nos abre la ventana donde introduciremos nuestros
objetos que conectaremos entre ellos creando así nuestra
aplicación. pdp_opencv distrains.

También existe otra biblioteca referente al video llama-

da OpenCV. Es una biblioteca abierta desarrollada por
165.5 Bibliotecas pdp, pidip y Intel. Esta biblioteca proporciona un alto nivel de fun-
ciones de procesado de imágenes. Permite al programa-
opencv dor crear aplicaciones en el dominio de la visión digital.
OpenCV es Open Source permitiendo así poder funcio-
La biblioteca PDP es una colección de objetos que se uti- nar en muchas plataformas. Esta biblioteca nos permite
liza para procesar numerosos datos. Funciona en Linux hacer operaciones básicas, procesado de imágenes, aná-
y la mayoría de objetos también trabajan en Mac OSX. lisis de reconocimiento del modelo, análisis estructural,
Una vez descargado, la instalación en Linux se hace a tra- reconstrucción 3D, calibración de la cámara, análisis de
vés del terminal, compilando y ejecutando el archivo de movimiento, interfaz grá ca y adquisición, etc. Imple-
instalación que viene adjuntado, de la siguiente manera: menta una gran variedad de herramientas para la inter-
./con gure pretación de la imagen, como por ejemplo, detección de
facciones o análisis de la forma (geometría, contorno que
sudo make procesa en ese instante), entre otras.
sudo make install
Cuando los datos ya están representados como un paque-
te dentro de Pd, es posible empezar a manipularlos. La 165.6 Patch patrones
biblioteca PiDiP son objetos de video que completan la
colección de objetos de PDP. La instalación es idéntica Una buena primera toma de contacto con Pd puede ser
a la de PDP, desde el terminal ejecutamos los mismos la generación de un tono sinusoidal. Para esto utilizare-
312 CAPÍTULO 165. PURE DATA

jeto que nos permite visualizar la imagen según nuestro

sistema operativo, en Linux sería pdp_v4l (video for Li-
nux). A este objeto también le conectamos otro mensaje
donde le indicamos el canal por el que queremos enviar la
información. Finalmente le conectaremos a [pdp_v4l] un
[metro] dándole la información de la periodicidad con la
que queremos que nos muestre las imágenes que la cáma-
ra está captando. Para tener continuidad de movimien-
to le daremos un valor estándar de 100ms. A gusto del
usuario también podemos girar la imagen en sentido ho-
rizontal para que el efecto generado al ver la imagen sea
de espejo. Para conseguir esto conectaremos la salida de
[pdp_v4l] al objeto [pdp_ ip_lr]. Con esto ya tenemos,
en una ventana a parte, la imagen que la cámara está cap-
tando.

165.7 Véase también

• Miller Puckette

• Lenguaje de programación visual

165.8 Material en español

• Sistemas musicales interactivos Documentos de cur-
so de sistemas musicales interactivos por Sergi Jordà
• Taller de música electrónica Documentos del curso
de Taller de música electrónica por Sergi Jordà
Ejemplo de oscilador.
• Curso de introducción a GEM Introducción a GEM
y al live cinema por Carles Sora
mos el objeto [osc~]. En la entrada izquierda le conec-
taremos un mensaje con un número dentro que actuará
de frecuencia de oscilación. Su salida la enviaremos a un 165.9 Enlaces externos
multiplicador que nos convertirá esta frecuencia en audi-
ble y nalmente esto lo enviamos a un convertidor digital • [Link] Portal o cial sobre PureData.
analógico [dac~] para poder reproducirlo por los altavo-
ces de nuestra máquina. Una vez ya hemos creado este • puredata-es Comunidad de Puredata en Castellano
patch, podemos modi car la frecuencia clicando y man-
• IEM Institute of Electronic Music and Acoustics,
teniendo pulsado el ratón encima del mensaje del número
Graz. Muchos enlaces útiles (en inglés)
y desplazando el cursor arriba abajo, aumentando y dis-
minuyendo así el valor de la frecuencia. • Miller S. Puckette homepage con una nota biográ ca
y sus ocupaciones actuales (en inglés).

• Pure DataBase, pdb Aquí puedes buscar objetos de

pure data (en inglés)

• [Link] Sitio muy completo con prácticas abs-

tracciones (en inglés).

Abrir dispositivo externo. Cámara web. • 3 Convención Internacionale de Pd (en portugués).

Para abrir un dispositivo externo, como por ejemplo una

cámara web, deberemos escribir en un mensaje la pala-
bra “open”seguido de un espacio y la ruta de donde se
encuentra este dispositivo. Este, lo conectaremos al ob-
Capítulo 166

QuadTIN

QuadTIN es una estructura de datos en forma de árbol

ideada por Renato Pajarola, Roberto Lario y Marc Anto-
nijuan. Dicha estructura de datos se basa en la estructura
del quadtree, pero, a diferencia de éste, los hijos de un
nodo no han de ser del mismo tamaño, y ni siquiera ser
cuadrados. De esta forma, el quadTIN permite almacenar
de forma jerárquica triangulaciones irregulares.

313
Capítulo 167

Query string

Query string, en español: cadena de consulta, este tér- el valor se obtiene trás aplicar una separación de la query
mino generalmente se utiliza para hacer referencia a una string mediante el símbolo /. De ésta forma se puede tra-
interacción con una base de datos. Es la parte de una URL bajar con Friendly Urls siguiendo las recomendaciones
que contiene los datos que deben pasar a aplicaciones web de los principales motores de búsqueda, sin necesidad de
como los programas CGI. crear una estructura de directorios en el servidor. Una
gran cantidad de sitios web utilizan esta forma de inter-
En los comienzos de la web las direcciones de las páginas
contenían la estructura jerárquica de los directorios del pretación de la query string.
sitio. Por ejemplo:
[Link]/paginaprincipal/ 167.1 Véase también
paginasecundaria/[Link]
• Página web
Estos sitios eran estáticos: a menos que el administrador
modi que las páginas siempre mostrarían el mismo con- • Web 2.0
tenido a los visitantes.
• HTML dinámico
Más tarde aparecieron los sitios dinámicos. En este ca-
so, el servidor crea automáticamente la página cuando el
navegante la solicita. Para ello se vale de una serie de pa-
rámetros o datos que se incluyen en la URL. Éstos nor-
malmente están compuestos por un nombre y un valor
separados por el signo igual. Un ejemplo de dirección di-
námica sería:
[Link]/[Link]?nombredevalor1=
valor1&nombredevalor2=valor2

Otro ejemplo común de dirección dinámica consistiría en

con gurar el servidor para que asigne automáticamente a
un conjunto de variables prede nidas los valores resul-
tantes de la separación de la query string usando como
símbolo de separación de la cadena el caracter /.
[Link]/paginaprincipal/
paginasecundaria/contenido

De esta forma y mediante la con guración del servidor(ej.

mod rewrite en servidores web apache) se podría acce-
der a las tres subcadenas resultantes en nuestro ejemplo,
esto es, paginaprincipal, paginasecundaria y contenido
accediendo mediante GET a los sendos nombres de va-
riable que se de nieron en la con guración del servidor
web. Se trata de una segunda opción simpli cada de pares
variable-valor, con la peculiraridad de que los nombres de
variable se sobreentienden y prede nen en el servidor y

314
 Capítulo 168

Quest3D

Quest3D es la conjunción de un motor de videojuego con 168.1.2 Orientación a objetos

una plataforma de desarrollo. Generalmente se usa para
arquitectura, diseño de producto, videojuegos, software Quest3D ha evolucionado en su versión 4.0 y posterio-
de entrenamiento y simuladores. Los datos y animaciones res, permitiendo implementar aplicaciones siguiendo un
son importados de paquetes CAD tales como Maya, 3D paradigma de diseño orientado a objetos.
Studio Max y AutoCAD, a Quest3D donde son utilizados Haciendo uso de su nuevo editor de interfaces y clases,
para la creación de aplicaciones interactivas 3D en tiempo permite de una manera bastante intuituva el encapsula-
real. Quest3D es un producto desarrollado por Act-3D miento de subárboles de“channels”en“Objetos”, que
B.V. en Holanda. Su primera versión fue publicada en contienen métodos y propiedades. Esta característica au-
septiembre del 2001. menta la potencia del entorno, permitiendo aplicaciones
mucho más dinámicas.

168.1 Entorno de desarrollo 168.1.3 Editores

El entorno de Quest3D consiste en diferentes editores es-
Una de las características más importantantes de pecializados en la creación de la aplicación: Editor de
Quest3D es la metodología de programación. De una for- "→rbol de Channels”, modi cación de características de
ma totalmente diferente a la de los habituales lenguajes los objetos 3D (modelos 3D), animaciones, programa-
de programación, tales como el C++, el entorno de desa- ción High Level Shading Language (HLSL) y programa-
rrollo de Quest3D es casi por completo visual. Otra ca- ción LUA Script entre otros.
racterística destacable es el hecho de que el programador
puede modi car la aplicación mientras esta se ejecuta.
Esto signi ca que no existe compilación de código como 168.1.4 Publicación
en los entornos de programación habituales.
Las aplicaciones nalizadas pueden ser publicadas en di-
ferentes formatos, para permitir su visualización en dife-
rentes medios: Fichero ejecutable “standalone”(plata-
168.1.1 Lógica de las aplicaciones forma Microsoft Windows) y visor WEB basado en con-
trol ActiveX. Los navegadores soportados en la actuali-
Las aplicaciones Quest3D se desarrollan conectando dad son Internet Explorer y FireFox.
componentes funcionales (cajas negras), denominadas
“Channels”. Los“Channels”vinculados componen una
estructura de árbol, que representa la estructura del pro- 168.2 Requerimientos del sistema
grama que se implementa. El árbol de cajas negras se eje-
cuta por completo una vez (al menos) por frame, invocan-
Algunas funcionalidades del motor 3D requieren hardwa-
do a cada“channel”. Lo que se obtiene como resultado
re más especí co.
es una aplicación 3D en tiempo real.
Como no hay fase de compilación, o interpretación de un • Windows 2000, Windows XP, Windows Vista (∨4
lenguaje de scripting, ya que los “Channels”son cajas or 32 bit) y DirectX 9
con su código precompilado (implementadas en Dynamic
Link Libraries), el rendimiento de las aplicaciones es el • 2∧∨ MB RAM
mismo en fase de diseño que en ejecución, característi- • Procesador de 1Ghz
ca muy apreciada cuando se desarrollan aplicaciones en
tiempo real. • Tarjeta grá ca compatible con DirectX

31∧
31∨ CAPÍTULO 168. QUEST3D

• 32 MB de memoria grá ca

• 400MB de espacio en disco duro

168.3 Licencias
Se pueden adquirir diferentes licencias para el uso tanto
comercial como educacional.

168.4 Aplicaciones
Realidad virtual, Videojuegos, visualización arquitectó-
nica, “serious games”, simuladores, TV y cine.

168.5 Referencias
• [Link] Quest3D speci cations

• Gamasutra “Rapid gameplay iterations are crucial

to me, so I use Quest3D for everything else.”, Dylan
Fitterer in “The road to IGF”

168.6 Enlaces externos

• Quest3D website
Capítulo 169

Quine (programa)

En informática, un quine (pronunciado “kwain”) es args) { string s = “using System;{0}namespace

un programa (un tipo de Metaprogramación) que produ- quine{0}{2}{0}{1}class Program{0}
ce su código fuente como su salida única. Para diversión, {1}{2}{0}{1}{1}[STAThread]{0}{1}{1}static void
algunos hackers intentan desarrollar el quine más corto Main(string[] args){0}{1}{1}{2}{0}{1}{1}{1}
posible en cualquier lenguaje de programación. string s = {4}{∨}{4};{0}{1}{1}{1}[Link](s,
[Link], {4}{∧}t{4}, {4}{2}
Nota: simplemente abriendo el archivo fuente del progra-
ma e imprimiendo el contenido se considera hacer tram- {4}, {4}{3}{4}, {4}{∧}{4}{4}, {4}{∧}{∧}{4},
s);{0}{1}{1}{3}{0}{1}{3}{0}{3}"; [Link](s,
pa.
[Link], "\t”, "{", "}", "\"", "\\", s); } } }
Los quines se llaman así por Willard Van Orman Quine,
que hizo un estudio extensivo de autoreferencia indirecta
y sugirió un caso famoso de paradoja sin autoreferencia 169.1.3 Scheme
directa:“Da como resultado un enunciado falso si es pre-
cedido por su cita”da como resultado un enunciado falso ((lambda (x) (list x (list (quote quote) x))) (quote (lambda
si es precedido por su cita. (x) (list x (list (quote quote) x)))))

169.1 Ejemplos
169.1.4 Common Lisp
169.1.1 C (funcall (lambda (x) (append x (list (list 'quote x)))))
'(funcall (lambda (x) (append x (list (list 'quote x))))))
#include<stdio.h> char*i="\\#include<stdio.h>",n='\n',q='"',*p=
"%s%cchar*i=%c%c%s%c,n='%cn',q='%c',*p=%c%c%s%c,*m=%c%c%s%c%c;%s%c”
,*m=“int main(){return!printf(p,i+1,n,q,*i,i,q,*i,q,n,q,p,q,n,q,m,q,n,m,n);}"
169.1.5 Ocaml
;int main(){return!printf(p,i+1,n,q,*i,i,q,*i,q,n,q,p,q,n,q,m,q,n,m,n);}
(fun s -> [Link] "%s %S”s s) "(fun s -> [Link]
Otro (este debe ser una sola línea, y supone que el compi- \"%s %S\" s s)"
lador ejecuta en una máquina que usa el código ASCII):
extern printf(char*,...);main(){char*a="extern 169.1.6 Python
printf(char*,...); main(){char*a=%c%s%c;printf(a,34,a,34,10);}%c";printf(a,34,a,34,10);}
a='a=%s;print a%%`a`';print a%`a`
O aún más corto (aunque no es código C99 de ISO co-
rrecto): Otro:
main(){char*a="main(){char*a=%c%s%c;printf(a,34,a,34);}";printf(a,34,a,34);}
b='\\';g='"';p='%';s="b='%s%s';g='%s';p='%s';s=%s%s%s;print
s%s(b,b,g,p,g,s,g,p)";print s%(b,b,g,p,g,s,g,p)

169.1.2 C# Y otro que comparte los caracteres últimos con la ante-

rior (solamente para mostrar que asignaciones múltiples
Nota: Debe ser una sola línea. Los saltos de línea se agre- no salva mecanografía):
garon para hacerlo más fácil de leer. b,g,p,s='\\','"','%',"b,g,p,s='%s%s','%s','%s',%s%s%s;print
using System; namespace quine { class Pro- s%s(b,b,g,p,g,s,g,p)";print s%(b,b,g,p,g,s,g,p)
gram { [STAThread] static void Main(string[]

31∩
31∪ CAPÍTULO 169. QUINE (PROGRAMA)

169.1.7 JavaScript 169.1.11 Brainfuck

Nota: Debe ser una sola línea. Los cortes de línea se agre-
unescape(q="unescape(q=%22*%22).replace('*',q)").replace('*',q)
garon para hacerlo más fácil de leer.
->+>+++>>+>++>+>+++>>+>++>>>+>+>+>++>+>>>>+++>+>>++>+
169.1.8 Perl +>>>>+++>+>>>>++>++>>>>+>>++>+>+++>>>++>>++++++>>+>>+
>>>++>>++>>+>>++>+>+++>>>++>>+++++++++++++>>+>>++>+>+
$_=q{$_=q{Q};s/Q/$_/;print};s/Q/$_/;print ++>+>>>>+++>>+++++>>>>++>>>>+>+>++>>+++>+>>>>+++>+>>>
++>+>++>++>>>>>>++>+>+++>>>>>+++>>>++>+>+++>+>+>++>>>
+>>>+>>++>+>++++++++++++++++++>>>>+>+>>>+>>++>+>+++>>
El más corto conocido: >>+++>>++++++>>>+>++>>+++>+>+>++>+>+++>>>>>+++>>>+>+>
open+0;print<0> >>+>>++>+>>>>+++>>++++>>+>+++>>>>>>++>+>+++>>+>++>>>>
[[->>+<<]]<+]+++++[-
>+++++++++<]>.[+]>>[<<+++++++[-
Y una combinación de Perl y script de shell:
>+++++++++<]>- .------------------->-[-
perl -le '$n=q{perl -le <.<+>>]<[+]<+>>>]<<<[-[-[-[>>+<++++++[-
a$n=q{$x};($_=$n)=~s/\141/\4∩/g;s/\$x/$n/;printa};($_=$n)=~s/\141/\4∩/g;s/\$x/$n/;print'
>+++++<]]>++++ ++++++++++<]>+++<]++++++[-
>+++++++<]>+<<<-[->>>++<<<]>[->>.<<]<<]

169.1.9 BASIC 169.1.12 HQ9+

10 LIST Q

169.1.13 DOS Batch

169.1.10 Pascal
@echo o %1 %2 call %0 goto e %% call %0 goto
const a='const a=';b='begin wri- e %%3 echo.%%4 echo :f goto f :e echo.%4@echo
te(a,#39,a,#39#∧9#9∪#∨1#39,b,#39#∧9#10,b) end.'; o echo.%4%31 %32 echo.%4call %30 goto e
begin write(a,#39,a,#39#∧9#9∪#∨1#39,b,#39#∧9#10,b) %3%3 echo.%4call %30 goto e %3%33 echo.%3%34
end. echo.%4echo :f echo.%4goto f echo.%4:e :f
Comentario 1: En el caso de una implementación DOS
de Pascal, la salida de la pantalla puede parecer bastan-
te desorientadora. En ese caso, sería apropiado sustituir 169.1.14 PHP
ambas instancias de "#10”con "#13#10”e insertar un
CR antes del LF al n de la primera línea. <? $a='chr(∨0).chr(∨3).chr(10).chr(3∨).chr(9∩).chr(∨1).chr(39).$[Link](39).
$a;".chr(10).chr(∨3).chr(∨2)'; echo
Comentario 2: El programa se puede hace todavía más
chr(∨0).chr(∨3).chr(10).chr(3∨).chr(9∩).chr(∨1).chr(39).$[Link](39).chr(∧9)
corto porque ambas instancias de ") end.”se pueden sus-
$a;".chr(10).chr(∨3).chr(∨2); ?> <? $a='<? $a=2; echo
tituir con ")end.”(aunque le hace difícil de leer). Se puede
str_replace(1+1,chr(39).$[Link](39),$a); ?>'; echo
acortar más por borrar ambas instancias de "#10”y escri-
str_replace(1+1,chr(39).$[Link](39),$a); ?>
biendo el programa en una sola línea en vez de dos líneas.
Después de los cambios, el programa parecerá como si-
gue:
const a='const a=';b='begin wri- 169.1.15 PL/I
te(a,#39,a,#39#∧9#9∪#∨1#39,b,#39#∧9,b)end.';begin
write(a,#39,a,#39#∧9#9∪#∨1#39,b,#39#∧9,b)end. Nota: Este es el quine de PL/I más pequeño posible que
Otro (Borland Pascal and Free Pascal): compila usando el compilador OS PL/I V2.3.0, pero re-
quiere un margen izquierdo de 1 y la opción COMPILE
const a='const a=;begin wri- para parar una cantidad signi cativo de errores):
te(copy(a,1,∪),#39,a,#39,copy(a,9,99)) end.';begin
write(copy(a,1,∪),#39,a,#39,copy(a,9,99)) end. %dcl z%z='put edit';proc options(main;q=''''put list(m;do
i=1,2;z(q)skip;do j= 1to ∩∪c=substr(m(i),j;if c=q
Otro (Borland Pascal and Free Pascal): z(c;z(c;end;z(q',';dcl(c,q)char,m(2)char(99)init( '%dcl
const a:string='const a:string=;begin in- z%z=''put edit'';proc options(main;q=''''''''put list(m;do
sert(#39+a+#39,a,1∨);write(a) end.';begin in- i=1,2;z(q)skip;do j=', '1to ∩∪c=substr(m(i),j;if c=q
sert(#39+a+#39,a,1∨);write(a) end. z(c;z(c;end;z(q'','';dcl(c,q)char,m(2)char(99)init(',
169.2. ENLACES EXTERNOS 319

169.1.16 PostScript
(dup == {dup cvx exec} pop ∪ 12 getinterval =) dup cvx
exec

169.1.17 Visual FoxPro

CLEAR SET TALK OFF SET TEXTMERGE ON
\CLEAR \SET TALK OFF \SET TEXTMERGE ON

169.2 Enlaces externos

• La página de los quines (por Gary P. Thompson)

• Los programas quine al wiki del Portland Pattern

Repository

• Una página sobre los quines

• Unos participantes en un concurso de hacer quines
en JavaScript
• Un quine HTML con uso de CSS apegado a la nor-
ma, incluyendo resaltado de la sintaxis
• “Palíndromo quine": una página web que es lo mis-
mo que su código fuente, lo mismo de izquierda a
derecha que de derecha a izquierda, los mismo de
arriba para abajo que de abajo para arriba.
Capítulo 170

Rebanamiento estático

El rebanamiento estático es una técnica en el área de 170.3 Referencias

programación de computadoras conocida como mante-
nimiento de software. Es usada para identi car todo el • Meilir Page-Jones, "The Practical Guide to Structu-
código de programa que puede afectar de algún modo el red Systems Design", Yourdon Press,19∪0, ISBN 0-
valor de una variable dada. 91∩0∩2-1∩-0
Una descripción breve de su cálculo es el siguiente: Basa-
do en la de nición original de Mark Weiser una rebanada
estática de programa (S) consiste de todas las sentencias 170.4 Enlaces externos
en un programa P que pueden afectar el valor de la va-
riable v en algún punto p. La rebanada es de nida por un • Tufts University: Ensayo sobre Mantenimiento co-
criterio de rebanamiento C=(x,V), donde x es una senten- mo parte del Ciclo de Vida del Software (en inglés)
cia en un programa P y V es un subconjunto de variables
en P. Una rebanada estática incluye todas las sentencias
que afectan la variable v para un conjunto de todos los
posibles inputs en el punto de interés. Las rebanadas es-
táticas son computadas encontrando conjuntos consecu-
tivos de sentencias indirectamente relevantes, de acuerdo
a los datos y dependencias de control.

170.1 Ejemplo
int i; int suma = 0; int producto = 1; for(i = 0; i < N;
++i) { suma = suma + i; producto = producto * i; }
write(suma); write(producto);

El siguiente programa es un rebanamiento válido del an-

terior, respecto al criterio (write(suma),{suma}):
int i; int suma = 0; for(i = 0; i < N; ++i) { suma = suma
+ i; } write(suma);

De hecho, la mayoría de técnicas de rebanamiento está-

tico, incluida la propia técnica de Weiser, tampoco in-
cluirían la sentencia write(suma), ya que en la sentencia
write(suma), el valor de suma no es afectado por la sen-
tencia en sí.

170.2 Véase también

• Software

• CMM

320
Capítulo 171

Recolector de basura

• Compactar espacios de memoria libres y consecuti-

vos entre sí.

• Llevar cuenta de qué espacios están libres y cuáles

no.

Generalmente, el programador dispone de una biblioteca

de código que se encarga de estas tareas. No obstante, el
propio programador es responsable de utilizar adecuada-
mente esta biblioteca.
Esto tiene la ventaja de que se hace un uso e ciente de la
memoria, es decir, los espacios de memoria quedan libres
Recolección de basura informática. El espacio de memoria se va
cuando ya no son necesarios. No obstante, este mecanis-
llenando con diferentes “objetos”(representados con colores),
también pueden destruirse algunos de ellos, dejando “huecos”mo explícito de gestión de memoria es propenso a erro-
en el espacio de memoria. Cuando ya no queda espacio dispo- res. Por ejemplo, un programador puede olvidar liberar
nible, o cuando lo decide la rutina de recolección de basura, la
la memoria de manera que, tarde o temprano, no quede
memoria es“compactada”, colocando todos los“objetos”que memoria disponible, abortando la ejecución del progra-
se están usando al principio, y consolidando todos los “huecos”
ma.
de memoria al nal, quedando así una gran área de memoria
disponible para la futura creación de objetos. Como alternativa es necesaria una gestión implícita de
memoria, con lo que el programador no es consciente de
Un recolector de basura (del inglés garbage collector) es la reserva y liberación de memoria. Esto es obligado en
un mecanismo implícito de gestión de memoria imple- algunos lenguajes de programación en los que no se ma-
mentado en algunos lenguajes de programación de tipo neja el concepto de memoria. Por ejemplo, en lenguajes
interpretado o semiinterpretado. declarativos como Lisp o Prolog.

171.1 Breve reseña histórica 171.3 Cómo funciona

El concepto de recolección de basura fue inventado por Cuando un lenguaje dispone de recolección de basura, el
John McCarthy en 19∧∪ para evitar la gestión manual de programador no tiene que invocar a una subrutina para
memoria en el lenguaje Lisp. liberar memoria. La reserva de memoria también es más
o menos automática sin la intervención del programador.
Por ejemplo:
171.2 Contexto
• En los lenguajes orientados a objetos: se reserva me-
Cualquier programa informático hace uso de una cierta moria cada vez que el programador crea un objeto,
cantidad de memoria de trabajo puesta a su disposición pero éste no tiene que saber cuánta memoria se re-
por el sistema operativo. Esta memoria tiene que ser ges- serva ni cómo se hace esto.
tionada por el propio programa para:
• En los lenguajes declarativos: cada vez que se cons-
• Reservar espacios de memoria para su uso.
truye una expresión se reserva memoria (de una ma-
• Liberar espacios de memoria previamente reserva- nera inteligente), pero el programador no es cons-
dos. ciente de ello.

321
322 CAPÍTULO 171. RECOLECTOR DE BASURA

Cuando se compila el programa, automáticamente se in- 171.5 Cómo se implementa

cluye en éste una subrutina correspondiente al recolector
de basura. Esta subrutina también es invocada periódica- Existe la posibilidad de implementar la recolección de ba-
mente sin la intervención del programador. sura como una biblioteca de código más, pero por norma
El recolector de basura es informado de todas las reservas general no es así. El propio diseño de ciertos lenguajes de
de memoria que se producen en el programa. Además, el programación hace necesaria la existencia del recolector
compilador colabora para que sea posible llevar una cuen- de basura. Para poder implementar estos lenguajes se re-
ta de todas las referencias que existen a un determinado quieren dos actuaciones:
espacio de memoria reservado.
Cuando se invoca el recolector de basura, recorre la lista • Que el compilador proporcione la información ne-
de espacios reservados observando el contador de refe- cesaria para el recolector de basura (el contador de
rencias de cada espacio. Si un contador ha llegado a cero referencias).
signi ca que ese espacio de memoria ya no se usa y, por • Que el entorno de ejecución o máquina virtual im-
tanto, puede ser liberado. plemente la subrutina del recolector de basura.
Naturalmente, este proceso consume un cierto tiempo en
el que no se hace nada verdaderamente útil para el propó-
sito del programa. Por tanto, no puede ser invocado con 171.6 Ejemplos de lenguajes con
demasiada frecuencia.
recolector de basura
En consecuencia, el único inconveniente a este mecanis-
mo es determinar cuándo se tiene que ejecutar el reco-
lector de basura. Existen varios algoritmos para hacerlo, 171.7 Véase también
pero el más e ciente es el primero de ellos:
• Conteo de referencias
• Esperar a que no quede memoria libre, y entonces, • Fuga de memoria
ejecutar el recolector de basura.

• Fijar un umbral de ocupación de la memoria libre

y ejecutar el recolector de basura cuando se supere
171.8 Enlaces externos
dicho umbral.
• The Memory Management Reference (en inglés)
• Ejecutar el recolector de basura a intervalos regula- • Recolector de basura para C y C++ (en inglés)
res (no siempre es posible).

• Ejecutar el recolector de basura justo antes de cada

reserva de memoria.

• Permitir al programador que invoque explícitamente

al recolector de basura cuando quiera.

171.4 Ventajas y desventajas

Las ventajas y desventajas de este mecanismo de gestión
de memoria son las opuestas al mecanismo explícito:

• El programador no puede cometer errores y queda

liberado de la tediosa tarea de gestionar la memoria.

• La memoria permanece retenida durante más tiem-

po del estrictamente necesario.

• El recolector de basura tarda cierto tiempo en ha-

cer su tarea y produce pausas que pueden hacer la
técnica incompatible con sistemas de tiempo real.
Capítulo 172

Recursión

Imagen recursiva formada por un triángulo. Cada triángulo es-

tá compuesto de otros más pequeños, compuestos a su vez de la
misma estructura recursiva.

Para que se entienda mejor a continuación se exponen

algunos ejemplos:

• Factorial: Se desea calcular n! (el factorial de n ,

que se de ne como el producto de todos los enteros
positivos de 1 a n ). Se puede de nir el problema de
forma recurrente como n(n−1)! ; como (n−1)! es
menor que n! podemos aplicar inducción por lo que
Anuncio de cacao con una imagen recursiva. La mujer muestra disponemos del resultado. El caso base es 0! que es
un paquete idéntico al del propio anuncio, conteniendo así a otra
1 .
mujer que muestra otro paquete más pequeño, de forma recursi-
va. • Algoritmo de ordenación por fusión: Sea v un vector
de n elementos, podemos separar el vector en dos
mitades. Estas dos mitades tienen tamaño n/2 por
lo que por inducción podemos aplicar la ordenación
Recurrencia, recursión o recursividad es la forma en
en estos dos subproblemas. Una vez tenemos ambas
la cual se especi ca un proceso basado en su propia de-
mitades ordenadas simplemente debemos fusionar-
nición. Siendo un poco más precisos, y para evitar el
las. El caso base es ordenar un vector de cero o un
aparente círculo sin n en esta de nición:
elemento, que está trivialmente ordenado y no hay
Un problema que pueda ser de nido en función de su ta- que hacer nada.
maño, sea este N, pueda ser dividido en instancias más
pequeñas (< N) del mismo problema y se conozca la so- En estos ejemplos podemos observar como un problema
lución explícita a las instancias más simples, lo que se co- se divide en varias (una o más) instancias del mismo pro-
noce como casos base, se puede aplicar inducción sobre blema, pero de tamaño menor gracias a lo cual se puede
las llamadas más pequeñas y suponer que estas quedan aplicar inducción, llegando a un punto donde se conoce
resueltas. el resultado (el caso base).

323
324 CAPÍTULO 172. RECURSIÓN

Nota: aunque los términos“recursión”y“recursividad” 172.1.3 Constantes

son ampliamente empleados en el campo de la informáti-
ca, el término correcto en castellano es recurrencia * [cita La razón áurea se puede de nir como sigue: φ = 1+ φ1 =
requerida]. Sin embargo este último término es algo más 1 + 1
1 , como una fracción continua en que todos
1+
especí co. Véase relación de recurrencia. 1+ 1
1+...
los números son unos.
√
De forma similar, la identidad x = 1 + 1+ √ da lugar
x−1

172.1 Recursión en matemáticas

x
a una de nición como fracción continua de cualquier raíz
√ x−1
cuadrada:* [3] x = 1 +
172.1.1 Conjuntos de nidos de forma re- x−1
2+
currente x−1
2+
.
Un ejemplo de conjunto de nido de forma recurrente es 2 + ..
el de los números naturales, es decir, el conjunto de los
números enteros no negativos:* [1]
172.1.4 Resolución de problemas
1. 0 pertenece a ℕ.
Resolución de ecuaciones homogéneas de primer grado,
2. Si n pertenece a ℕ, entonces n + 1 pertenece a ℕ. segundo orden:
3. Si x veri ca las anteriores condiciones, entonces x a) Se pasan al primer miembro los términos an , an−1
está incluido en ℕ * [cita requerida]. , an−2 , los cuales también podrían gurar como an+2 ,
an+1 , an

172.1.2 Funciones de nidas de forma re- b) Se reemplaza an por r , an−1 por r y an−2 por 1
2

, quedando una ecuación de segundo grado con raíces

currente
reales y distintas r1 y r2 .
Aquellas funciones cuyo dominio es un conjunto a lo más c) Se plantea a = u r1 n + v r2 n
enumerable * [2] pueden ser de nidas de forma recurren- d) Debemos tener como dato los valores de los dos pri-
te. meros términos de la sucesión: A0 = k y A1 = k ′ .
Un ejemplo conocido es la de nición recurrente de la fun- Utilizando estos datos ordenamos el sistema de 2x2:
ción factorial n!:
{
{ u+v =k
si n = 0 ⇒ 1
n! = u r1 + u r2 = k ′
si n ≥ 1 ⇒ n (n − 1)!
Veamos cómo se usa esta de nición para hallar el valor La resolución de este sistema nos da como resultado los
del factorial de 3: valores u0 y v0 , que son números reales conocidos.
e) La solución general es:
3! = 3 · (3 − 1)!
= 3 · 2!
an = u0 r1 n + v0 r2 n
= 3 · 2 · (2 − 1)!
= 3 · 2 · 1!
= 3 · 2 · 1 · (1 − 1)!
172.2 Recursión en informática
= 3 · 2 · 1 · 0!
=3·2·1·1 En programación, un método usual de simpli cación de
=6 un problema complejo es la división de este en subpro-
blemas del mismo tipo. Esta técnica de programación se
Otros ejemplos de funciones y sucesiones matemáticas
conoce como divide y vencerás y es el núcleo en el di-
de nidas de forma recursiva son:
seño de numerosos algoritmos de gran importancia, así
• Sucesión de Fibonacci ̶f(0)= 1, f(1) = 1; f(n) = como también es parte fundamental de la programación
f(n−1) + f(n−2) para n ≥ 2. dinámica.
El ejemplo del cálculo recursivo del factorial de un núme-
• Números de Catalan ̶C(2n, n)/(n+1)
ro llevado al campo de la programación, en este ejemplo
• Función de Ackermann C++:
172.5. REFERENCIAS 32∧

int factorial(int x) { if (x > −1 && x < 2) return 1; // • Algoritmo recursivo

Cuando −1 < x < 2 devolvemos 1 puesto que 0! = 1 y 1!
= 1 else if (x < 0) return 0; // Error no existe factorial de • Fractal
números negativos return x * factorial(x - 1); // Si x >= 2 • Sistema-L
devolvemos el producto de x por el factorial de x - 1 }
Este ejemplo está basado en el lenguaje de programación • Torres de Hanói
Pascal: • Relación de recurrencia
Proc Factorial(x:Entero):Entero Si (x > −1 Y x < 2)
Devolver 1 ' Cuando x sea mayor que −1 y menor que 2
Devolver 1. Si (x < 0) Devolver 0 ' Cuando x sea menor 172.5 Referencias
a 0, devolver 0 Devolver x * Factorial(x - 1) ' Si x igual o
mayor que 2 devolvemos el producto de x por el factorial [1] Algunos autores consideran que los números naturales son
de x - 1 FinProc los números enteros positivos, es decir, excluyen el 0 de
este conjunto. En ese caso, basta sustituir la línea que dice
El seguimiento de la recursividad programada es casi
« 0 pertenece a ℕ» por « 1 pertenece a ℕ».
exactamente igual al ejemplo antes dado, para intentar
ayudar a que se entienda mejor se ha acompañado con [2] «Nociones de espacios normados» , Cotlar y Cignoli, Eu-
muchas explicaciones y con colores que diferencia los deba, Buenos Aires
distintos sub-procesos de la recursividad.
[3] Ben Thurston,“Estimating square roots, generalized con-
X = 3 //Queremos 3!, por lo tanto X inicial es 3 X >= 2 tinued fraction expression for every square root”, The Ben
-> return 3*factorial(2); X = 2 //Ahora estamos solici- Paul Thurston Blog
tando el factorial de 2 X >= 2 -> return 2*factorial(1);
[4] Hunter, David (2011). Essentials of Discrete Mathematics.
X = 1 // Ahora estamos solicitando el factorial de 1 X <
Jones and Bartlett. p. 494.
2 -> return 1; [En este punto tenemos el factorial de 1
por lo que volvemos marcha atrás resolviendo todos los [∧] Daniel Rodríguez Herrera (29 de julio de 2009). «←Qué es
resultados] return 2 [es decir: return 2*1 = return 2*fac- la recursividad? ←Qué es la recursividad? ←Qué es la recur-
torial(1)] return 6 [es decir: return 3*2 = return 3*fac- sividad?...». Libertad Digital. Consultado el 20 de enero
torial(2)*factorial(1)] // El resultado devuelto es ∨ de 2013.

Algoritmo implementado en el lenguaje Prolog:

fact(0,1):-!. fact(N,F):-N1 is N-1,fact(N1,F1),F is N*F1. 172.6 Enlaces externos
• Ejemplo de curvas recursivas fractales

172.3 Humor recursivo

La recursividad se emplea a menudo de forma humorísti-
ca en textos informáticos, losó cos o matemáticos. No
es raro que un libro de texto de estas disciplinas incluya
en su glosario una entrada similar a esta:

Recursividad, véase Recursividad.* [4]

En el buscador Google, al buscar «recursion», el sitio su-

giere «Quizá quisiste decir: recursion».* [∧]
Un chiste informático dice así: «Para entender la recur-
sividad, debes entender la recursividad».* [4] En la infor-
mática también es común la elección de acrónimos recur-
sivos. PHP son las iniciales de PHP Hypertext Preproces-
sor (Preprocesador de Hipertexto PHP), WINE son las
de WINE Is Not an Emulator (WINE no es un emulador)
y GNU signi ca GNU's Not Unix (GNU no es Unix).

172.4 Véase también

• Recursión (ciencias de computación)
Capítulo 173

Refactorización

La refactorización (del inglés refactoring) es una téc- nombre de una variable para que sea más signi cativo,
nica de la ingeniería de software para reestructurar un como una sola letra 't' a 'tiempo'. Una refactorización
código fuente, alterando su estructura interna sin cambiar más compleja es transformar el trozo dentro de un blo-
su comportamiento externo. que en una subrutina. Una refactorización todavía más
compleja es remplazar una sentencia condicional if por
polimor smo.
173.1 Refactorización de código Aunque la limpieza de código se lleva realizando desde
hace décadas, el factor clave de la refactorización es rea-
lizar de manera intencionada la limpieza separándola de
En ingeniería del software, el término refactorización se
la adición de funcionalidad nueva, usando un catálogo co-
usa a menudo para describir la modi cación del código
nocido de métodos útiles de refactorización, para después
fuente sin cambiar su comportamiento, lo que se conoce
comprobar el código ejecutando las pruebas unitarias, sa-
informalmente por limpiar el código. La refactorización
biendo que cualquier cambio en el comportamiento sig-
se realiza a menudo como parte del proceso de desarrollo
ni ca que se ha introducido un error.
del software: los desarrolladores alternan la inserción de
nuevas funcionalidades y casos de prueba con la refacto- La refactorización es un aspecto importante de la
rización del código para mejorar su consistencia interna programación extrema.
y su claridad. Los tests aseguran que la refactorización no El libro de Martin Fowler Refactoring es la referencia clá-
cambia el comportamiento del código. sica. Aunque la refactorización de código se ha llevado a
La refactorización es la parte del mantenimiento del có- cabo de manera informal durante años, la tesis doctoral
digo que no arregla errores ni añade funcionalidad. El ob- de William F. Opdyke (1993) es el primer trabajo co-
jetivo, por el contrario, es mejorar la facilidad de com- nocido que examina especí camente esta técnica. Todos
prensión del código o cambiar su estructura y diseño y estos recursos proporcionan un catálogo de métodos ha-
eliminar código muerto, para facilitar el mantenimiento bituales de refactorización. Un método de refactorización
en el futuro. Añadir nuevo comportamiento a un progra- tiene una descripción de cómo aplicar el método e indi-
ma puede ser difícil con la estructura dada del programa, caciones sobre cuándo debería (o no debería) aplicarse.
así que un desarrollador puede refactorizarlo primero pa- La refactorización es un concepto tan importante que ha
ra facilitar esta tarea y luego añadir el nuevo comporta- sido identi cado por David A. Wheeler como «una de
miento. las más importantes innovaciones en el campo del soft-
El término se creó como analogía con la factorización de ware».* [1]
números y polinomios. Por ejemplo, x2 −1 puede ser fac-
torizado como (x + 1)(x − 1) , revelando una estructura
interna que no era visible previamente (como las dos raí-
ces en −1 y +1). De manera similar, en la refactorización
173.2 Refactorización de otros tex-
del software, el cambio en la estructura visible puede fre- tos
cuentemente revelar la estructura interna “oculta”del
código original. El término refactorización se originó en el ámbito de la
La refactorización debe ser realizada como un paso sepa- programación de ordenadores, pero el concepto se ha
rado, para poder comprobar con mayor facilidad que no aplicado a la modi cación de cualquier texto.
se han introducido errores al llevarla a cabo. Al nal deEn los sitios Wiki, la refactorización se re ere al proceso
la refactorización, cualquier cambio en el comportamien-de reescribir y reorganizar el texto para abreviarlo preser-
to es claramente un bug y puede ser arreglado de manera vando su contenido. Se aplica en especial en las discusio-
separada a la depuración de la nueva funcionalidad. nes, que de esta manera pueden ser hechas accesibles para
Un ejemplo de una refactorización trivial es cambiar el personas que están interesadas en los argumentos ofreci-

32∨
173.5. ENLACES EXTERNOS 32∩

dos en la discusión y en la información que se obtiene de

ella, más que en la propia historia de la discusión. Puede
ser difícil refactorizar de tal manera que estén de acuerdo
todos los participantes de la discusión.

173.3 Etimología
El primer uso conocido del término refactorización en
la literatura publicada se encuentra en el artículo Re-
factoring: An Aid in Designing Application Frameworks
and Evolving Object-Oriented Systems, Proceedings of the
Symposium on Object Oriented Programming Emphasi-
zing Practical Applications (SOOPPA) September, 1990,
ACM por William F. Opdyke y Ralph E. Johnson.* [2] La
tesis doctoral de William Opdyke titulada “Refactoring
Object-Oriented Framework”(Universidad de Illinois) se
publicó en 1992.* [3] Tanto el término refactorización co-
mo la técnica que de ne se usaban ya con toda seguridad
antes.

173.4 Referencias
[1]

[2]

[3]

173.5 Enlaces externos

• Libro de Martin Fowler' sobre refactorización
Capítulo 174

Re exión (informática)

En informática, re exión (o re exión computacional) es 174.2 Ejemplos

la capacidad que tiene un programa para observar y op-
cionalmente modi car su estructura de alto nivel.
174.2.1 Python
Normalmente, la re exión es dinámica o en tiempo de
ejecución, aunque algunos lenguajes de programación # sin re exión Foo().bar() # usando re exión. ge-
permiten re exión estática o en tiempo de compilación. tattr(globals()['Foo'](), 'bar')()
Es más común en lenguajes de programación de alto nivel
ejecutándose sobre una máquina virtual, como Smalltalk
o Java, y menos común en lenguajes como C.
174.2.2 C#
En un sentido más amplio, la re exión es una actividad
computacional que razona sobre su propia computación. // Con re exión // Usando GetType para obtener
Cuando el código fuente de un programa se compila, nor- información del tipo: int i = 24; [Link] tipo
malmente se pierde la información sobre la estructura = [Link](); [Link](tipo); El
del programa conforme se genera el código de bajo nivel resultado sería: System.Int32
(normalmente lenguaje ensamblador). Si un sistema per-
mite re exión, se preserva la estructura como metadatos
en el código generado. Dependiendo de la implementa-
ción, el código con re exión tiende a ser más lento que el 174.3 Véase también
que no lo tiene.
En los lenguajes que no distinguen entre tiempo de eje- • Lenguajes de programación con tipos dinámicos
cución y tiempo de compilación (como las distintas va-
riantes de Lisp), no hay diferencia entre compilación o • Metaprogramación
interpretación de código y re exión.

174.1 Implementación
Un lenguaje con re exión proporciona un conjunto de ca-
racterísticas disponibles en tiempo de ejecución que, de
otro modo, serían muy difícilmente realizables en un len-
guaje de más bajo nivel. Algunas de estas características
son las habilidades para:

• Descubrir y modi car construcciones de código

fuente (tales como bloques de código, clases, mé-
todos, protocolos, etc.) como objetos de“categoría
superior”en tiempo de ejecución.
• Convertir una cadena que corresponde al nombre
simbólico de una clase o función en una referencia
o invocación a esa clase o función.
• Evaluar una cadena como si fuera una sentencia de
código fuente en tiempo de ejecución.

32∪
Capítulo 175

Relación de compresión (informática)

En la compresión digital, la relación de compresión

(RC) indica en qué proporción ha sido reducida la infor-
mación. Por ejemplo, un RC de 10:1 indica que por cada
10 bits del archivo informático original solamente tene-
mos 1 bit en el chero comprimido, es decir, el tamaño
del chero se habrá reducido en 10 veces.

175.0.1 Véase también

• Compresor digital

329
Capítulo 176

Resolución de problemas de programación

La resolución de un problema mediante un ordenador periencia del experto del dominio para entender el proble-
consiste en el proceso que a partir de la descripción de un ma. Al nal, si se quiere llegar a una solución satisfactoria
problema, expresado habitualmente en lenguaje natural y es necesario que:
en términos propios del dominio del problema, permite
desarrollar un programa que resuelva dicho problema.
• El problema esté bien de nido con el máximo de-
Este proceso exige los siguientes pasos: talle

• Análisis del problema. • Las especi caciones de las entradas y salidas del
problema, deben ser descritas también en deta-
• Diseño o desarrollo de un algoritmo. lle:
• Transformación del algoritmo en un programa (co- • ←Qué datos son necesarios para resolver el pro-
di cación). blema?
• Ejecución y validación del programa. • ←Qué información debe proporcionar la reso-
lución del problema?
Los dos primeros pasos son los más difíciles del proceso.
Una vez analizado el problema y obtenido un algoritmo
que lo resuelva, su transformación a un programa de or-
denador es una tarea de mera traducción al lenguaje de
176.2 Diseño del algoritmo
programación deseado.
Un algoritmo consiste en una especi cación clara y con-
cisa de los pasos necesarios para resolver un determinado
problema, pero para poder diseñar algoritmos es necesa-
176.1 Análisis del problema infor- rio disponer de una notación, que llamaremosʻnotación
mático algorítmicaʼ, que permita:

Cuando un usuario plantea a un programador un proble- • Describir las operaciones puestas en juego (accio-
ma que resolver mediante su ordenador, por lo general nes, instrucciones, comandos,...)
ese usuario tendrá conocimientos más o menos amplios
sobre el dominio del problema, pero no es habitual que • Describir los objetos manipulados por el algoritmo
tenga conocimientos de informática. Por ejemplo, un con- (datos/informaciones)
table que necesita un programa para llevar la contabilidad
de una empresa será un experto en contabilidad (domi- • Controlar la realización de las acciones descritas, in-
nio del problema), pero no tiene por qué ser experto en dicando la forma en que estas se organizan en el
programación. tiempo
Del mismo modo, el informático que va a resolver un de-
terminado problema puede ser un experto programador, Para poder describir cualquier tipo de acción de las que
pero en principio no tiene por qué conocer el dominio intervienen en un algoritmo, diversos autores proponen el
del problema; siguiendo el ejemplo anterior, el informá- uso de un conjunto de construcciones lógicas (secuencia,
tico que hace un programa no tiene por qué ser un expertodecisión e iteración) con las que es posible escribir cual-
en contabilidad. quier programa. Lo que sigue a continuación es la des-
Por ello, al abordar un problema que se quiere resolver cripción de las diferentes construcciones disponibles para
mediante un ordenador, el programador necesita de la ex- el diseño de algoritmos.

330
176.2. DISEÑO DEL ALGORITMO 331

176.2.1 Acciones elementales 176.2.5 Composición condicional múltiple

Se entiende por acciones elementales aquellas que el or- También es posible que a la hora de especi car la eje-
denador es capaz de realizar y que serán de dos tipos: cución de una acción haya que escoger ésta entre varias
dependiendo del valor de una determinada variable (o in-
dicador). Este caso se expresa del siguiente modo:
• Aritmético – lógicas: Operaciones que, a partir de
unos determinados datos, realizan un cálculo arit- Según Indicador Hacer Caso Valor 1: Acción 1; Caso
mético (suma, resta, multiplicación,...) o un cálculo Valor 2: Acción 2; ... Caso Valor n: Acción n; [De Otro
lógico (mayor que, menor que, igual que,...).Las pri- Modo: Acción X;] FinSegun
meras devuelven un valor numérico (4, −∧.∨∩,...) y En esta construcción Indicador debe tener un determi-
las segundas un valor lógico (verdadero o falso). nado valor que en caso de coincidir con alguno de los
n valores provocará la ejecución de la acción asociada a
• De entrada – salida: Acciones que permiten cap- dicho valor. Si el valor del Indicador no coincidiera con
turar datos para su posterior tratamiento (las de en- ninguno de los especi cados se ejecutará la Acción X. No
trada) y guardar los resultados de dicho tratamiento tiene por qué haber una Acción X para cuando el Indi-
(las de salida). cador' no coincida con ninguno de los n valores; en ese
caso, si el Indicador' no coincide con ningún valor no se
ejecutaría ninguna acción.
176.2.2 Secuencia de acciones elementales Al igual que en los casos anteriores, todas las acciones que
aparecen en esta estructura (Acción 1, Acción 2,..., Acción
Cuando en un algoritmo se deben ejecutar varias accio- n y Acción X) pueden referirse a una única acción o a un
nes sucesivamente, éstas se describen una detrás de otra conjunto de ellas.
según el orden en que deban ejecutarse. Si se desea se
puede emplear algún tipo de símbolo para separar dos ac-
ciones consecutivas. En el siguiente ejemplo se muestra 176.2.6 Composición iterativa o bucle
la descripción de n acciones separadas por punto y coma
(símbolo que habitualmente se emplea como separador). Cuando una acción o conjunto de acciones debe ejecu-
tarse varias veces se recurre a una estructura iterativa o
Acción 1; Acción 2; ... Acción n; bucle. En este tipo de estructuras se necesita una condi-
ción que determine cuando terminan las iteraciones. De-
pendiendo de si esa condición se evalúa al principio o al
176.2.3 Composición condicional nal de la estructura y de si la condición para que las ite-
raciones continúen debe ser verdadera o falsa, se pueden
Cuando en un algoritmo se quiere indicar que cierta ac- de nir cuatro construcciones iterativas distintas:
ción solo se debe ejecutar bajo cierta condición se indica Sobre las cuatro construcciones que se acaban de presen-
del siguiente modo: tar cabe hacer las siguientes observaciones:
Si Condición Entonces Acción; FinSi
• Si en las estructuras 1 y 2, cuando se evalúa laʻCon-
Solo si la Condición (operación lógica) es verdadera se diciónʼ, ésta toma por primera vez un valor tal que
ejecutará la Acción. En este caso, la Acción puede refe- no permita ejecutar laʻAcciónʼ(FALSO en la 1 y
rirse tanto a una acción elemental como a un conjunto de VERDADERO en la 2), ésta no se ejecutará ningu-
ellas. na vez. Es decir, puede ocurrir que la ʻAcciónʼ,
en las estructuras 1 y 2, no se ejecute nunca.
• En las estructuras 3 y 4, al estar laʻCondiciónʼde
176.2.4 Composición condicional doble
terminación al nal, laʻAcciónʼse ejecutará antes
(alternativa) de que la condición se evalúe por primera vez, por
lo que aunque laʻCondiciónʼtome un valor tal que
En ocasiones, se deben ejecutar unas acciones u otras de- no se permita realizar más iteraciones, la ʻAcciónʼ
pendiendo de la ocurrencia de una determinada condi- se ejecutará al menos una vez.
ción. Esta especi cación se realiza del siguiente modo:
• Si las ʻCondicionesʼde las estructuras 1 y 2 son
Si Condición Entonces Acción A; SiNo Acción B; FinSi complementarias, es decir, que siempre que una es
Dependiendo de si la Condición es verdadera o falsa se verdadera la otra es falsa y viceversa (ejemplo: [a
ejecutará la Acción A o la Acción B respectivamente. De > b] y [a ≤ b] son condiciones complementarias),
forma análoga a como ocurría en el caso anterior, tanto la entonces ambas estructuras son equivalentes ya que
Acción A como la Acción B pueden referirse a una acción en ambas laʻAcciónʼse ejecutará el mismo número
elemental o a un conjunto de ellas. de veces.
332 CAPÍTULO 176. RESOLUCIÓN DE PROBLEMAS DE PROGRAMACIÓN

• De forma análoga, si las ʻCondicionesʼde las es-

tructuras 3 y 4 son complementarias también ambas
estructuras serán equivalentes.

Existe una construcción especial para indicar una repeti-

ción de acciones que se suele emplear cuando se quiere
que dicha repetición se realice un número determinado
de veces:
Para i = 1 Hasta n Hacer Acción; FinPara
En este caso laʻAcciónʼse repetirá n veces eʻiʼserá una
variable que tomará todos los valores entre 1 y n (ambos
inclusive) en cada una de las sucesivas repeticiones. Esta
construcción, aunque de apariencia diferente a las ante-
riores, se podría expresar como un caso particular de la
estructura 1 del siguiente modo:
i = 1; Mientras i <= n Hacer Acción; i = i + 1; Fin-
Mientras
En este caso la condición de nalización del bucle es que
la variableʻiʼsea mayor queʻnʼy siempre, al nalizar
la ejecución de laʻAcciónʼ,ʻiʼse incrementa en una
unidad antes de volver a evaluar la ʻCondiciónʼpara el
nuevo valor de ʻiʼ.

176.3 Véase también

• Algoritmo

• Programación
• Pseudocódigo

• Diagrama de ujo
• Estructuras de control

• Bucle (programación)
• Bucle for

• Bucle while
• Bucle repetir

• Bucle in nito
• Programación estructurada

• Lenguaje de programación

• Resolución de problemas
Capítulo 177

Instancia (programación)

En el paradigma de la orientación a objetos, una instan- se (puede hacerlo para permitir ejecuciones concurren-
cia se re ere a una realización especí ca de una clase o tes de distintas versiones de una clase)* [Nota 1] entonces
prototipo determinados. las clases serán representadas utilizando un Singleton. En
En general, cuando se ejecuta un programa en un compu- Java, por ejemplo, si tenemos una clase de nida como:
tador, se dice que éste se instancia. En lenguajes que crean public class Perro {}
objetos a partir de clases, un objeto es una instancia de
una clase. Esto es, es un miembro de una clase que tiene Podremos acceder a la instancia que representa la clase
atributos en lugar de variables. En un contexto del mundo (y es una instancia de la clase [Link]<Perro>), en
real, podríamos pensar en “Perro”como una clase y en un programa principal de clase Main, del siguiente modo:
un perro conreto en una instancia de esta clase.* [1]
public class Main { public static void main(String...
args) { Class<?> perroClass = [Link]; Sys-
[Link](perroClass); } }
177.1 Programación basada en cla-
ses
En este apartado hablaremos de la programación orienta-
da a objetos basada en clases, que es la que implementa la
mayoría de lenguajes de programación orientados a ob-
jetos. En el modelo basado en prototipos, que es el de
lenguajes como JavaScript, los términos que se re eren a 177.2 Programación basada en
clases han de sustituirse por los prototipos de los objetos, prototipos
pero por lo demás, son de aplicación similar.
En este modelo, un objeto tiene una referencia a la clase a
la que pertenece y, por tanto, puede llamar a los métodos En el estilo de programación orientada a objetos basada
de instancia que hayan sido declarados como de instancia, en prototipos las instancias son los objetos creados a partir
así como a todos aquellos que hayan sido heredados por de los prototipos. En general, los prototipos también son
la jerarquía de herencia estática entre clases. objetos creados a partir de otros prototipos, con lo que
las propiedades y métodos se heredan en la profundidad
Ciertos lenguajes de programación permiten utilizar cla-
completa del árbol de herencia de prototipado.
ses mixin, que permiten además realizar asociaciones en-
tre instancias de objetos para establecer relaciones simi- En el caso particular de JavaScript, aunque no se puede
lares a la herencia en tiempo de ejecución. cambiar el prototipo de un objeto una vez instanciado, sí
se pueden cambiar las propiedades y métodos que tiene
el prototipo, afectando a todas las instancias (en profun-
177.1.1 Clases como objetos didad) de ese prototipo. En el caso particular de este len-
guaje, en el que todos los objetos son instancias de Ob-
Multitud de lenguajes de programación basados en cla- ject, modi car o añadir métodos a Object tendrá como
ses proporcionan mecanismos de re exión o introspec- consecuencia la modi cación de esos métodos u objetos
ción, esto es, permiten que el programa pueda observar en todos los demás objetos que no los hayan rede nido
(e incluso modi car) su propia estructura de alto nivel. Si posteriormente, incluyendo los ya instanciados. Este es
estos mecanismos siguen el paradigma de orientación a el mecanismo que utilizan algunas bibliotecas de JavaS-
objetos también, entonces las clases serán representadas cript* [Nota 2] para proporcionar funciones que no hayan
también como instancias de objetos. En particular, si el implementado ciertos motores a ciertos objetos del len-
lenguaje no permite dos de niciones de una misma cla- guaje.

333
334 CAPÍTULO 177. INSTANCIA (PROGRAMACIÓN)

177.3 Notas
[1] Erlang, por ejemplo, permite la ejecución concurren-
te de varias versiones de un mismo programa, véase
[[Link]#Module:code change-3 [Link]
org/doc/man/gen [Link]#Module:code change-3], y
CLOS.

[2] [Link] por ejemplo, proporciona métodos

al objeto [Link], cambiando todos los Array del
programa.

177.4 Referencias
[1] [Link] (en in-
glés)
Capítulo 178

Anexo:Scan code

Son los códigos que envía el teclado al ordenador para

indicar la tecla pulsada o soltada. Su valor no depende
de la tecla, sino de su posición, así se consigue que sea
independiente del idioma del teclado.
Para el teclado QWERTY (PS/2) y códigos ASCII los
scan codes son:

33∧
Capítulo 179

scanf

En C, la función scanf() (scan-format, analizar con for- mento con el tipo indicador al doble; o que una c siguien-
mato), en realidad representa a una familia de funciones te, s, o [el especi cador de la conversión se aplica a una
que analizan una entrada de datos con formato y cargan el argumento con el tipo indicador al wchar_t.
resultado en los argumentos que se pasan por referencia
ll (codo-codo) - Especi ca que especi cador una d, un i,
a dicha función o funciones: un o, un u, un x, de una conversión siguiente de X, o de
n se aplica a un argumento con el tipo indicador a largo
• La función scanf() lee los datos de entra- largo largo o sin rmar largo.
da en el stdin ( ujo de entrada estándar).
j - Especi ca que especi cador una d, un i, un o, un u,
• La función fscanf() ( le-scanf) lee en un un x, de una conversión siguiente de X, o de n se apli-
ujo de entrada dado, por lo general un ca a un argumento con el tipo indicador al intmax_t o al
chero ( le) abierto para lectura. uintmax_t.
• La función sscanf() (string-scanf) obtie- z - Especi ca que especi cador una d, un i, un o, un u,
ne la entrada que se va a analizar de una un x, de una conversión siguiente de X, o de n se aplica
cadena de caracteres dada (string). a un argumento con el tipo indicador al size_t o al tipo
correspondiente del entero con signo.
Todas ellas leen caracteres, los interpretan según un for- t - Especi ca que especi cador una d, un i, un o, un u, un
mato, y almacenan los resultados en sus argumentos. Ca- x, de una conversión siguiente de X, o de n se aplica a un
da uno cuenta con varios argumentos: por un lado, un for- argumento con el tipo indicador al ptrdi _t o al tipo sin
mato de la secuencia del control (se describe más abajo), rmar correspondiente.
por otro, un sistema de argumentos del indicador que se-
ñala dónde la entrada convertida debe ser almacenada. L - Especi ca que una a siguiente, A, e, E, f, F, g, o espe-
El resultado es inde nido si hay escasos argumentos pa- ci cador de la conversión de G se aplica a un argumento
ra dar formato. Si se agota el formato mientras que sigue con el tipo indicador al doble largo.
habiendo las argumentos, los argumentos sobrantes son Si un modi cante de la longitud aparece con cualquier
evaluados pero no procesados de ninguna otra manera. especi cador de la conversión con excepción de según lo
especi cado arriba, el comportamiento es inde nido.

179.0.1 Modi cantes de longitud

Los especi cadores siguientes de la conversión que
Los modi cantes de la longitud y sus signi cados son: son válidos
hh - Especí ca que especi cador una d, un i, un o, un u,
un x, de una conversión siguiente de X, o de n se aplica d - Empareja un número entero decimal opcionalmente
a un argumento con el tipo indicador al carbón rmado o con signo, que formato es igual según lo esperado para la
al carbón sin rmar. secuencia sujeta del strtol() con el valor 10 para el argu-
h - Especí ca que especi cador una d, un i, un o, un u, mento bajo. En ausencia de un modi cante del tamaño,
un x, de una conversión siguiente de X, o de n se aplica a el uso se asegurará de que el argumento correspondiente
un argumento con el tipo indicador al cortocircuito corto sea un indicador a interno.
o sin rmar. i - Empareja un entero con signo opcionalmente, que for-
l (codo) - Especí ca que especi cador una d, un i, un o, mato es igual según lo esperado para la secuencia sujeta
un u, un x, de una conversión siguiente de X, o de n se del strtol() con 0 para el argumento bajo. En ausencia de
aplica a un argumento con el tipo indicador para desear un modi cante del tamaño, el uso se asegurará de que el
o largo sin rmar; que una a siguiente, A, e, E, f, F, g, o argumento correspondiente sea un indicador a interno.
especi cador de la conversión de G se aplica a una argu- o - Empareja un número entero octal opcionalmente con

33∨
 33∩

signo, que formato es igual según lo esperado para la se- >>>Si un l (codo) cali cador está presente, la entrada es
cuencia sujeta del strtoul() con el valor ∪ para el argu- una secuencia de caracteres que comienza en el estado
mento bajo. En ausencia de un modi cante del tamaño, inicial de la cambio. Cada carácter en la secuencia será
el uso se asegurará de que el argumento correspondiente convertido a un carácter ancho como si por una llamada a
sea un indicador a sin rmar. la función del mbrtowc (), con el estado de la conversión
u - Empareja un número entero decimal opcionalmente descrito por un objeto del mbstate_t inicializado a cero
con signo, que formato es igual según lo esperado para la antes del primer carácter sea convertido. El uso se asegu-
secuencia sujeta del strtoul() con el valor 10 para el argu- rará de que el argumento correspondiente sea un indica-
dor a un arsenal de wchar_t bastante grande para aceptar
mento bajo. En ausencia de un modi cante del tamaño,
el uso se asegurará de que el argumento correspondiente la secuencia y el carácter ancho nulo que termina, que
serán agregados automáticamente.
sea un indicador a sin rmar.
x - Empareja un número entero hexadecimal opcional- >>>La especi cación de la conversión incluye todos los
mente con signo, que formato es igual según lo esperado octetos subsecuentes en la secuencia del formato hasta e
para la secuencia sujeta del strtoul() con el valor 1∨ pa- incluir el corchete derecho que empareja (“]”). Los oc-
ra el argumento bajo. En ausencia de un modi cante del tetos entre los corchetes (el scanlist) abarcan el scanset, a
tamaño, el uso se asegurará de que el argumento corres- menos que el octeto después de que el corchete izquierdo
pondiente sea un indicador a sin rmar. sea un circun ejo (“^”), en este caso el scanset contiene
todos los octetos que no aparezcan en el scanlist entre el
a, e, f, g - Empareja un número, un in nito, o un NaN circun ejo y el corchete derecho. Si la especi cación de
oating-point opcionalmente con signo, que formato es la conversión comienza con”[] “o”[^] “, el corche-
igual según lo esperado para la secuencia sujeta del strtod te derecho se incluye en el scanlist y el corchete derecho
(). En ausencia de un modi cante del tamaño, el uso se siguiente es el corchete derecho que empareja que ter-
asegurará de que el argumento correspondiente sea un in- mina la especi cación de la conversión; si no, el primer
dicador a otar. corchete derecho es el que termina la especi cación de
>>>Si la familia del fprintf() de funciones genera las re- la conversión. Si “-”es en el scanlist y no es el primer
presentaciones de la cadena de caracteres para el in ni- carácter, ni el segundo donde está un“^”, ni el carácter
to y NaN (una entidad simbólica codi cada en formato el primer carácter pasado, puesta en práctica-se de ne el
oating-point) para apoyar IEEE Std ∩∧4-19∪∧, la familia comportamiento.
del fscanf () de funciones las reconocerá como entrada. s c - Empareja una secuencia de los octetos del número es-
- Empareja una secuencia de los octetos que no son ca- peci cado por la anchura del campo (1 si no hay anchura
racteres del blanco-espacio. El uso se asegurará de que del campo presente en la especi cación de la conversión).
el argumento correspondiente sea un indicador al octeto El uso se asegurará de que el argumento correspondiente
inicial de un arsenal del carbón, del carbón rmado, o sea un indicador al octeto inicial de un arsenal del car-
del carbón sin rmar bastante grande aceptar la secuen- bón, del carbón rmado, o del carbón sin rmar bastante
cia y un código de carácter nulo que termina, que serán grande aceptar la secuencia. No se agrega ningún octe-
agregados automáticamente. to nulo. Los caracteres excesivos del blanco-espacio del
>>>Si un l (codo) cali cador está presente, la entrada es salto normal serán suprimidos en este caso.
una secuencia de caracteres que comienza en el estado >>>Si un l (codo) cali cador está presente, la entrada se-
inicial de la cambio. Cada carácter será convertido a un rá una secuencia de caracteres que comienza en el estado
carácter ancho como si por una llamada a la función del inicial de la cambio. Cada carácter en la secuencia se con-
mbrtowc (), con el estado de la conversión descrito por vierte a un carácter ancho como si por una llamada a la
un objeto del mbstate_t inicializado a cero antes del pri- función del mbrtowc (), con el estado de la conversión
mer carácter sea convertido. El uso se asegurará de que el descrito por un objeto del mbstate_t inicializado a cero
argumento correspondiente sea un indicador a un arsenal antes del primer carácter sea convertido. El uso se asegu-
de wchar_t bastante grande para aceptar la secuencia y rará de que el argumento correspondiente sea un indica-
el carácter ancho nulo que termina, que serán agregados dor a un arsenal de wchar_t bastante grande para aceptar
automáticamente. la secuencia que resulta de caracteres anchos. No se agre-
[ - Empareja una secuencia no vacía de octetos de un sis- ga ningún carácter ancho nulo.
tema de los octetos previstos (el scanset). Los caracteres s - Indica que es una cadena de caracteres (string). La en-
excesivos del blanco-espacio del salto normal serán supri- trada se termina con un espacio en blanco y un caracter
midos en este caso. El uso se asegurará de que el argu- null es guardado al nal de la cadena de caracteres. Esto
mento correspondiente sea un indicador al octeto inicial signi ca que el bu er utilizado debe ser por lo menos un
de un arsenal del carbón, del carbón rmado, o del car- caracter más grande que la longitud de entrada especi ca-
bón sin rmar bastante grande aceptar la secuencia y un da. De no ser así podría darse el caso que se sobrescriban
octeto nulo que termina, que serán agregados automáti- porciones de memorias adyacentes, generando resultados
camente. inesperados.
33∪ CAPÍTULO 179. SCANF

/*Posibles resultados no deseados al leer un solo carac- introducidos por teclado, de tipos int, oat y char //Si se
ter*/ char a; scanf("%s”,&a); /*Una forma non-sancta introduce un dato erróneo se interrumpe la lectura del
de evitarlo usando arreglos el caracter quedaría en a[0] */resto. int validos; printf(“Introduce un entero, un real, y
char a[2]; scanf("%s”,a); un caracter:"); validos=scanf("%i%f%c”,&a,&b,&c);
p - Empareja un sistema puesta en práctica-de nido de las //Entrada: ∧ 1.2 J | Salida: 3 //Lectura de una cade-
secuencias, que serán iguales que el sistema de secuencias nas de caracteres printf(“Introduce una palabra: ");
que es producido por la especi cación de la conversión scanf("%10s”,cad); // lee máximo 10 caracteres y le
de %p de las funciones correspondientes del fprintf (). El concatena el caracter cero.
uso se asegurará de que el argumento correspondiente sea
un indicador a un indicador a anular. La interpretación
del artículo de la entrada puesta en práctica-se de ne. Si
el artículo de la entrada es un valor convertido anterior 179.3 Funciones derivadas
durante la misma ejecución de programa, el indicador que
los resultados compararán el igual a ese valor; si no, el
comportamiento de la especi cación de la conversión de 179.3.1 fscanf
%p es inde nido.
La función fscanf lee datos de entrada desde un chero,
n - No se consume ninguna entrada. El uso se asegurará
en lugar de utilizar la entrada estándar.
de que el argumento correspondiente sea un indicador al
número entero en el cual será escrito el número de los oc- (C o C++)
tetos leídos en la entrada hasta ahora por esta llamada a int fscanf (FILE * le, const char *format,...);
las funciones del fscanf (). La ejecución de una especi -
cación de la conversión de %n no incrementará la cuenta (PHP)
de la asignación vuelta en la terminación de la ejecución int fscanf (resource le, const string format [, mixed
de la función. No se convertirá ningún argumento, pero args...]);
una será consumido. Si la especi cación de la conversión
incluye un carácter asignación-que suprime o una anchu- fscanf trabaja igual que la función scanf original; las en-
ra del campo, el comportamiento es inde nido. tradas una vez leídas no serán leídas otra vez hasta que el
archivo sea cerrado y abierto de nuevo.

179.1 Sintaxis 179.3.2 sscanf

valor_devuelto=scanf(tipo, &var); La función sscanf lee datos de entrada desde un bu er,
en lugar de utilizar la entrada estándar.
• valor_devuelto: representa el número datos leídos
Sus prototipos son los siguientes:
correctamente. Devuelve distinto de 0 si lee al-
guno.[Opcional] (C o C++)
int sscanf (char *bu er, const char *format,...);
• tipo: Tipo de dato a almacenar
Retorna la cantidad de datos que pudo leer.
• ampersand (&) se utiliza para indicar una dirección
de memoria de la variable donde se almacenará el Recuerda que los parámetros después de *format deben
dato. Cuando se guardan de cadenas de caracteres, ser punteros a variables donde la función dejará lo que
al tratarse de un array de tipo char, el & se omite. lee. Estas variables deben tener el espacio su ciente.

• var: variable para almacenar el dato.

179.4 Véase también
179.2 Ejemplo
• scanf_s
// Este ejemplo guarda un número en n. #include
<stdio.h> int n; printf(“Introduce un numero: "); • printf
scanf("%d”,&n); // Este ejemplo guarda en una variable
en num. char num; printf(“Introduce un caracter: "); • stdio.h
scanf("%c”,&num); // Este ejemplo guarda una cadena
de caracteres (solamente una palabra) en cad. // Notese • Lenguaje de programación C
la ausencia de & char cad[20]; printf(“Introduce una
palabra: "); scanf("%s”,cad); //Lectura de varios datos • PHP
179.5. ENLACES EXTERNOS 339

179.5 Enlaces externos

• scanf(3): conversión de la entrada con formato – Su-
brutinas en el Manual de Debian
Capítulo 180

SCons

SCons es una herramienta de código abierto para la cons-

trucción e instalación de software a través de scripts he-
chos en Python, para los sistemas operativos basados en
Unix. Su objetivo es ser una variante al método de com-
pilación tradicional de fuentes. Entre sus ventajas se en-
cuentra el análisis de dependencias.
Scons utiliza el lenguaje de programación Python de pro-
pósitos generales como fundación, para que todas las de
proyectos de con guraciones software y construcción de
procesos implementarios sean los scripts de Python.

180.1 Véase también

• Make
• Autoconf

180.2 Enlaces externos

Página o cial de SCons

340
Capítulo 181

Screen scraping

Screen scraping es el nombre en inglés de una técnica

de programación que consiste en tomar una presentación
de una información (normalmente texto, aunque puede
incluir información grá ca) para, mediante ingeniería in-
versa, extraer los datos que dieron lugar a esa presenta-
ción. Por ejemplo:

• Extraer de la página web de un diario el tiempo me-

teorológico previsto.
• Extraer los datos originales a partir de la imagen de
una grá ca elaborada.
• Hacer una consulta automática a la página de gestión
de nuestro banco para veri car si el saldo es inferior
a un umbral.

• Extraer los datos de un informe en PDF para verter-

los en una hoja de cálculo.

En general, hay que destacar que los sistemas de los que

se extrae la información no están diseñados para extraer
dicha información (en algunos casos, es al contrario, co-
mo en los sistemas de captcha).
La traducción aproximada de screen scraping es raspado
de pantalla.

181.1 Véase también

• Web scraping

341
Capítulo 182

Sección crítica

Se denomina sección crítica, en programación concu-

rrente, a la porción de código de un programa de orde-
nador en la que se accede a un recurso compartido (es-
tructura de datos o dispositivo) que no debe ser accedido
por más de un proceso o hilo en ejecución. La sección
crítica por lo general termina en un tiempo determinado
y el hilo, proceso o tarea sólo tendrá que esperar un pe-
ríodo determinado de tiempo para entrar. Se necesita un
mecanismo de sincronización en la entrada y salida de la
sección crítica para asegurar la utilización en exclusiva
del recurso, por ejemplo un semáforo.
El acceso concurrente se controla teniendo cuidado de las
variables que se modi can dentro y fuera de la sección
crítica. La sección crítica se utiliza por lo general cuando
un programa multihilo actualiza múltiples variables sin
un hilo de ejecución separado que lleve los cambios con-
ictivos a esos datos. Una situación similar, la sección
crítica puede ser utilizada para asegurarse de que un re-
curso compartido, por ejemplo, una impresora, pueda ser
accedida por un solo proceso a la vez.
La manera en cómo se implementan las secciones puede
variar dependiendo de los diversos sistemas operativos.
Sólo un proceso puede estar en una sección crítica a la
vez.
El método más común para evitar que dos procesos ac-
cedan al mismo tiempo a un recurso es el de la exclusión
mutua.

182.1 Véase también

• Cierre de exclusión mutua

342
Capítulo 183

Serialización

En ciencias de la computación, la serialización (o mars- 183.3 Enlaces externos

halling en inglés) consiste en un proceso de codi cación
de un objeto en un medio de almacenamiento (como pue- Para Java:
de ser un archivo, o un bu er de memoria) con el n de
transmitirlo a través de una conexión en red como una
• XML Data Binding
serie de bytes o en un formato humanamente más legi-
ble como XML o JSON, entre otros. La serie de bytes o • Generar el serialVersionUID de una clase
el formato pueden ser usados para crear un nuevo objeto
que es idéntico en todo al original, incluido su estado in-
Para C#:
terno (por tanto, el nuevo objeto es un clon del original).
La serialización es un mecanismo ampliamente usado
para transportar objetos a través de una red, para hacer • Serialización XML de objetos en .net con C# (en
persistente un objeto en un archivo o base de datos, o español)
para distribuir objetos idénticos a varias aplicaciones o
localizaciones.

183.1 Usos
Serialización tiene una serie de ventajas:

• Un método de persistencia de objetos que es más

conveniente que escribir sus propiedades a un archi-
vo de texto en disco.

• Un método de emisión de llamadas a procedimiento

remoto, por ejemplo, como en SOAP.

• Un método para la distribución de objetos, espe-

cialmente en los componentes software, tales como
COM, CORBA, etc.

• Un método para detectar cambios en variables en el

tiempo.

183.2 Soporte en los lenguajes de

programación
Varios lenguajes de programación orientados a objeto so-
portan la serialización de forma directa. Algunos de ellos
son Objective-C, Java, Delphi, C#, Visual Basic .NET,
ColdFusion, Ocaml, Perl, Python, PHP y Ruby

343
Capítulo 184

Sigil

En programación y sistemas de información, un sigil

(pronunciado/ˈsɪdʒəl/ o /ˈsɪɡəl/; plural sigilia o sigiles) o
sigilo es un símbolo agregado al nombre de una variable,
especi cando el tipo o alcance de la misma. Este término,
basado en la palabra inglesa para sello mágico, fue usado
por Philip Gwyn en 1999 “para designar el extraño ca-
rácter inicial en el nombre de una variable de Perl".

344
Capítulo 185

Signatura (informática)

La signatura o rma de un método o una función de ne

su entrada y su salida. Incluye por lo menos el nombre de
la función o método y el número de sus parámetros. En
algunos lenguajes de programación, puede incluir el tipo
que devuelve la función o el tipo de sus parámetros.
En el caso de un tipo de dato abstracto (TDA), se de ne
signatura como los tipos que utiliza junto con los nombres
y per les de las operaciones.
Por ejemplo, para especi car el TDA de los booleanos se
utiliza la siguiente signatura:

1. tipos bool
2. operaciones

3. verdadero : bool
4. falso : bool

∧. And : bool x bool -> bool

∨. Or : bool x bool -> bool

∩. Not : bool -> bool

34∧
Capítulo 186

Signum Framework

Signum Framework es un framework ORM Open Sour- de otros frameworks, la base de datos se genera a partir
ce creado por una empresa española en C# orientado del código y no a la inversa.
al desarrollo de aplicaciones sobre la tecnología .Net de Dada la importancia que se concede a las entidades como
Microsoft, con un visión centrada en las entidades, de ma- núcleo de las aplicaciones, Signum Framework provee un
nera que es el modelo de datos el que determina el esque- pequeño grupo de clases base y primitivas que permiten
ma de la base de datos. Como base de datos sólo está
modelar los objetos de una manera modular y reusable,
soportado MS SQL Server. evitando la redundancia y asegurando la integridad de los
Signum Framework se distribuye bajo licencia LGPL. objetos, tanto en lógica como una vez persistidos en base
de datos. Esto mismo (al tener que heredar las entidades
desde alguna de estas clases base) hace que Signum Fra-
186.1 Características mework no soporte POCO (Plain Old C# Object).

186.1.1 Elementos de Signum Framework

Signum Framework está compuesto por los siguientes en-

186.1.3 Generación del esquema
samblados:
La base de datos relacional se genera automáticamente a
partir de las entidades utilizando un mapeado 1 a 1 des-
• [Link] - Las clases base necesarias para ge-
de las entidades a las tablas, de manera que cada entidad
nerar las entidades de datos.
independiente tiene su propia tabla y cada campo de la
• [Link] - El motor ORM con un proveedor entidad su propia columna. Las entidades que son embe-
LINQ completo. bidas (EmbeddedEntity) no tienen una tabla propia, sino
que sus campos se guardan como columnas en la tabla de
• [Link] - Conjunto de utilidades y herra- la entidad a la que pertenecen. Se utilizan tablas relacio-
mientas. nales para las colecciones, lo que permite las relaciones
N a N.
• [Link] - Interfaces base del servicio WCF
Para permitir realizar modi caciones sobre los datos sin
• [Link] - Controles base para manipular tener que regenerar la base de datos cada vez, se puede
entidades realizar una sincronización entre las entidades y la base
de datos existente, en la que el motor generará un archi-
vo de script SQL con las modi caciones necesarias para
186.1.2 Entidades primero actualizar el esquema.

La losofía centrada en las entidades propicia que el es-

quema de datos se genere automáticamente a partir de los
objetos de código, evitando mapear los campos entre la 186.1.4 Herencia de entidades
base de datos y las entidades a través de archivos de con-
guración. De esta manera se trata de que se detecten las Aunque Signum Framework utiliza un sistema de“tabla
posibles incidencias en tiempo de compilación para todas por clase concreta”, en el que se crea una tabla una por
las clases (tanto de datos como de lógica). cada uno de los tipos concretos, permite implementar el
Por otro lado, esto mismo impide que Signum Framework concepto de herencia utilizando relaciones polimór cas,
se adapte bien a proyectos en los que existe una base de que cuentan con una clave externa que admite valores nu-
datos anterior que se debe preservar, ya que, a diferencia los por cada posible implementación.

34∨
186.2. HISTORIA 34∩

186.1.5 Interfaz de usuario y WCF 186.2 Historia

[Link] ofrece controles WPF básicos que • 2004 - Primera versión de un motor ORM basado
aprovechan la homogeneidad de las entidades para im- en los principios de reutilización y centrado en enti-
plementar un comportamiento automático. Estos contro- dades.
les simpli can el desarrollo de las vistas de las entidades
de una aplicación. • 200∩ - Segunda versión del motor ORM, incluyendo
el Gestor de Operaciones y Procesos.
Para la comunicación entre los clientes y el servidor se
utilizan contratos WCF que permiten la compartición de • 200∪ - Signum Framework 1.0 Beta 1, incluyendo
tipos. Esto facilita reutilizar las reglas de validación de las las funcionalidades de ORM, WPF y LINQ.
entidades en el cliente, eliminando la redundancia.
• 2009 - Release de Signum Framework 1.0 en Code-
La utilización de objetos Lazy permite trabajar con“hue- plex.
llas”de una entidad, conociendo su ToString y su identi-
cador, pero sin recuperar la entidad completa hasta que • 2010 - Signum Framework 2.0 Beta 1, con soporte
sea necesario, minimizando así la carga de trabajo y la para .Net Framework 4 y [Link] MVC 2.0 (ver-
transferencia de datos, aumentando considerablemente el sión interna).
rendimiento de las aplicaciones.
• 2011 - Signum Framework 2.0 Beta 2, con soporte
para [Link] MVC 3.0 (versión interna).
186.1.6 LINQ
• 2011 - Release de Signum Framework 2.0, inclu-
Signum Framework tiene un proveedor LINQ comple- yendo soporte para .Net Framework 4 y [Link]
to, de manera que todas las operaciones se ejecutan en MVC 3.0
LINQ, e internamente el motor las traduce a SQL. Algu-
nas de las características del proveedor de LINQ son las
siguientes: 186.3 Enlaces externos
• Soporta joins. • Página o cial de Signum Framework.

• Soporta valores booleanos en cualquier parte de la • Código fuente de Signum Framework.

consulta.
• Canal de Youtube con tutoriales sobre Signum Fra-
• Soporta GroupJoin y DefaultIfEmpty. mework.

• Soporta Group By en C# y [Link] con agregados • Sitio web de Signum Software.

múltiples.
• Soporta el uso de let en las consultas.
• Maneja la construcción de objetos en memoria den-
tro de consultas, así como llamadas a métodos en
memoria.
• Soporta tipos nulables y conversiones implícitas.
• Ofrece emulación nativa de funciones SQL.
• Soporta operaciones de tipo SelectMany.

Debido a algunas de las funcionalidades que soporta

(en concreto las funciones CROSS APPLY / OUTER
APPLY), actualmente las bases de datos soportadas por
Signum Framework se limitan a SQL Server 200∧ y SQL
Server 200∪ (tanto en las versiones Express como en las
versiones de pago).
La principal diferencia entre el proveedor de LINQ de
Signum Framework y otros proveedores es que no de-
pende de un contexto explícito que depende del esquema
actual de la base de datos, lo que permite escribir lógica
de negocio reutilizable.
Capítulo 187

Simple Network Library

Simple Network Library (SNL) es una biblioteca in- 187.2 Desarrollo

formática desarrollada con el lenguaje C que proporciona
funciones para realizar operaciones de comunicación en El sistema de control de versiones usado en el desarrollo
red. La primera versión de esta biblioteca fue acabada el de SNL es Darcs por ser distribuido y no depender sus
∧ de abril de 2009. repositorios de un servidor. El repositorio o cial es acce-
Proporciona herramientas para el desarrollo de sible desde internet y los parches son enviados al mante-
videojuegos y cualquier otra aplicación que necesi- nedor por correo electrónico para ser aplicados al reposi-
te comunicación a través de una red informática. Una torio o cial. Todo aquel que quiere colaborar en el desa-
de sus grandes virtudes es el tratarse de una biblioteca rrollo de SNL únicamente tiene que obtener una copia de
multiplataforma, soportando o cialmente los sistemas trabajo desde el repositorio o cial y realizar los cambios
GNU/Linux y OpenSolaris, además de otras arquitectu- que desee, enviando después los parches resultantes para
ras/sistemas como windows, MacOS, etc. Las siglas le que puedan ser aplicados al repositorio o cial.
vienen de Simple Network Library que se traduce como En la página web o cial de SNL se indica la localización
biblioteca de red simple. Desarrollada inicialmente por del repositorio o cial así como documentación que pue-
Jesús Hernández Gormaz. den consultar todos aquellos que quieran participar en el
Soporta los protocolos de IP tanto de IPv4 como de IPv∨ hacking de SNL y no conozcan el uso de Darcs.
además de los protocolos de comunicación TCP y UDP.
La biblioteca se distribuye bajo la licencia GPL.
187.3 Véase también
• Simple DirectMedia Layer

187.4 Referencias
187.1 Origen del nombre
187.5 Bibliografía
El origen del nombre, Simple Network Library, puede 187.5.1 Documentación de SNL
considerarse como un guiño a la biblioteca Simple Di-
rectMedia Layer, SDL, ya que como se puede observar • Jesús Hernández Gormaz (2009). Documentacion de
las siglas solo varían de una D, SDL, a una N, SNL. Esto SNL (1). p. 2.
es debido a que al igual que SDL es ampliamente usada
para el desarrollo de videojuegos, especialmente de vi-
deojuegos que sean software libre, SNL se creó con la
intención de facilitar el desarrollo y programación de vi-
187.6 Enlaces externos
deojuegos multijugador en red aún más de lo que pueda
facilitarlo otras bibliotecas como SDL Net, de forma que • [Link] - Página o cial de SNL (en esperanto,
el trabajo de el programador con los sockets y la labor español e ingles).
de conseguir Multiplexación, para que un servidor pue-
da atender a varios clientes de forma no bloqueante, sea
lo su cientemente sencillo para que el programador no
pierda tiempo en la comunicación que podría invertir en
el juego en si.

34∪
Capítulo 188

Smarty

Smarty es un motor de plantillas para PHP, es decir, se- medida van surgiendo sistemas de separación en capas
para el código PHP, como lógica de negocios, del código que intentan disciplinar un poco las metodologías de pro-
HTML, como lógica de presentación, y genera conteni- gramación envueltas en el desarrollo con PHP, pero que
dos web mediante la colocación de etiquetas Smarty en un no hacen otra cosa que acercarse más y más a otras herra-
documento. Se encuentra bajo la Licencia Pública Gene- mientas ya existentes en otros entornos de desarrollo más
ral Reducida de GNU. complejos y pensados desde sus orígenes para proyectos
más grandes, como pueden ser J2EE (Java), .NET (C#)
Es común que en grandes proyectos el rol de diseñador
grá co y el de programador sean cubiertos por personas o Django (Python).
distintas, sin embargo la programación en PHP tiene la
tendencia de combinar estas dos labores en una persona
y dentro del mismo código, lo que trae consigo grandes 188.3 Ejemplo
di cultades a la hora de cambiar alguna parte del diseño
de la página, pues se tiene que escarbar entre los scripts [Link]
para modi car la presentación del contenido, Smarty tie-
ne como objetivo solucionar este problema. require_once(“smarty/[Link]”); // Instanciar
la clase de Smarty $smarty = new Smarty(); // Con -
gurar Smarty $smarty->template_dir = "./templates/";
188.1 Características $smarty->compile_dir = "./templates_c/"; $smarty-
>con g_dir = "./con gs/"; $smarty->cache_dir =
"./cache/"; // Establecer variables que se usarán en la
• Expresiones regulares
plantilla $smarty->assign(“nombre”, “José Manuel
• Bucles foreach, while Pardo Pérez”); $smarty->assign(“direccion”, “C/
Alpes, 992”); // Mostrar la plantilla $smarty->display(
• Sentencias condicionales if, elseif, else “[Link]”);
• Modi cadores de variables (por ejemplo: {$varia-
ble|nl2br})
[Link]
• Funciones creadas por el usuario
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML
• Evaluación de expresiones matemáticas en la plan- 4.01//EN”"[Link]
tilla <html lang="es"> <head> <title>Información del
Usuario</title> </head> <body> <p>Información del
Usuario:</p> <p> Nombre: {$nombre}<br /> Direc-
188.2 Críticas ción: {$direccion} </p> </body> </html>

Existen más sistemas de plantillas para PHP, pero éste

Salida HTML generada
parece ser el más avanzado y con más frecuencia de desa-
rrollo. También hay detractores de estas técnicas que ale-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML
gan que las mismas hacen en cierta medida un grado más 4.01//EN”"[Link]
complejo el desarrollo web, por la necesidad de aprender <html lang="es"> <head> <title>Información del
un (pseudo) lenguaje más. Usuario</title> </head> <body> <p>Información del
Los detractores de esta idea se basan en el hecho de que, Usuario:</p> <p> Nombre: José Manuel Pardo Pérez<br
precisamente, el lenguaje PHP nació como un lenguaje /> Dirección: C/ Alpes, 992 </p> </body> </html>
rápido para hacer desarrollos web a pequeña escala. A

349
3∧0 CAPÍTULO 188. SMARTY

188.4 Referencias

188.5 Enlaces externos

• Sitio web o cial
• Documentación en español

• Problemas con Smarty

Capítulo 189

Snippet

Snippet es un término del idioma inglés utilizado en pro-

gramación para referirse a pequeñas partes reusables de
código fuente, código binario o texto. Comúnmente son
de nidas como unidades o métodos funcionales que se
pueden integrar fácilmente en módulos mucho más gran-
des, aportando funcionalidad. También se utiliza la pa-
labra para referirse a la práctica de minimizar el uso de
código repetido que es común en muchas funciones, por
medio del uso de un solo método que pueda ser reutiliza-
do. (No te repitas).

189.1 Rich snippets

Los rich snippets son etiquetas de código HTML utiliza-
dos por los programadores web para facilitar mayor in-
formación acerca del contenido de una web a los busca-
dores. La relación de etiquetas existentes en la actualidad,
se puede encontrar en [Link].

189.2 Enlaces externos

• Listado de tags o etiquetas enriquecidas o Rich Snip-
pets

3∧1
Capítulo 190

Stack Over ow

Stack Over ow es un sitio web desarrollado por Je Att- 190.3 Moderación

wood, este sitio web es utilizado por una comunidad de
desarrolladores informáticos, en la cual otros desarrolla- Hasta enero del 2012, Stack Over ow tenía un registro de
dores pueden encontrar soluciones a problemas de pro- ∩∩1.000 usuarios registrados, y 12 moderadores, en pro-
gramación en diferentes lenguajes.* [2] medio, cada moderador tenía gestionar ∨42∧0 usuarios y
sus actividades.
El sistema de moderación está basado en la reputación.
190.1 Funcionamiento de Stack Los 12 moderadores iniciales son los moderadores gene-
Over ow rales del sitio web, pero todos los usuarios pueden alcan-
zar cierto poder de moderación en función de su repu-
1. El usuario se suscribe al sitio web. tación. Cuantos más puntos tenga el usuario, más cosas
puede hacer. De esa manera se divide el coste de la mo-
2. El usuario hace pública su pregunta. deración entre toda la comunidad: si cada uno modera un
3. El usuario recibe las respuestas. poco, entre todos moderan todo; pero siempre basado en
la habilidad individual que permite ese privilegio.
Las respuestas son publicadas por los miembros de una
comunidad determinada o por otros usuarios con las mis-
mas experiencias que encontraron solución al problema 190.4 Estadísticas
planteado.
Todos los usuarios pueden votar por las preguntas y por Un estudio en 2013 encontró que el ∩∩% de los usuarios
sus respuestas, cuando se vota por una pregunta, el usua- sólo hacen una pregunta, el ∨∧% solamente responden a
rio puede cali carlas como más relevante o menos re- una pregunta, y sólo el ∪% de los usuarios responden a
levante; por otra parte, cuando se vota por las respuestas, más de ∧ preguntas.* [3] A partir de 2011, el 92% de las
éstas pueden ser más acertadas o menos acertadas. preguntas fueron contestadas en un tiempo medio de 11
minutos.* [4] Desde 2013, el software de red Stack Ex-
change elimina automáticamente las preguntas que cum-
plen con ciertos criterios, entre ellos el no tener respuestas
190.2 Reputación en una cierta cantidad de tiempo.* [∧]
A partir de agosto de 2012, 443.000 de los 1,3 millones
Stack Over ow posee un aspecto interesante, la repu-
de usuarios registrados habían respondido al menos una
tación, este término es destacado de acuerdo a la canti-
pregunta, y de ellos, unos ∨.000 (0,4∨% del número to-
dad de votos que poseen las preguntas y las respuestas,
tal de usuarios) se había ganado una puntuación de repu-
a mayor cantidad de votos relevantes o aciertos, mayor
tación superior a ∧000.* [∨]La Reputación se puede ganar
es la reputación en el sitio web. De hecho, el número de
más rápido contestando a preguntas relacionadas con las
votos es un indicador para muchos aspectos, entre estos
etiquetas con menor densidad de conocimientos, el hacer-
tenemos:
lo con prontitud (en particular, siendo la primera persona
en contestar una pregunta), estar activo durante las horas
1. Con anza de los usuarios.
de menor uso, y contribuyendo a diversas áreas.* [∩]
2. Habilidades de comunicación.
[1] «Stack Over ow ranking [Link]».
3. Calidad y relevancia en preguntas y Respuestas.
[2] «Stack Over ow información sobre la compañía».
4. Manejo de los temas.
[3] “An Empirical Study on Developer Interactions in Stac-
∧. Nivel de experiencia y participación. kOver ow”

3∧2
190.4. ESTADÍSTICAS 3∧3

[4] Mamykina, Lena; Bella Manoim; Manas Mittal; George

Hripcsak; Bjfirn Hartmann (2011).“Design lessons from
the fastest q&a site in the west”

[∧] “Turbocharging the Roomba: solutions for premature de-

letion”. [Link].

[∨] Bosu, Amiangshu; Christopher S. Corley; Dustin Heaton;

Debarshi Chatterji; Je rey C. Carver; Nicholas A. Kraft
(2013).“Building Reputation in StackOver ow: An Em-
pirical Investigation”

[∩] What posts get deleted, and why?". [Link] ow.

10 June 201∧.
Capítulo 191

StarBasic

StarO ce Basic, también conocido como StarBasic, es

un dialecto de Basic que Soporta Unicode, incluido en las
Suites de O cina OpenO [Link] y StarO ce.

191.1 Primer virus para OpenO -

ce
El 30 de mayo de 200∨ fue detectado el primer virus con-
ceptual para OpenO ce. Fue desarrollado con el sólo
objetivo de demostrar que es posible crear este tipo de
software usando el lenguaje de macros de esta suite de
aplicaciones libre. Escrito en StarBasic, el virus es capaz
de infectar las versiones de OpenO ce y StarO ce en
cualquier plataforma.

191.2 Enlaces externos

• Más información

3∧4
Capítulo 192

Stub

Un stub es, en el contexto del testeo del software, un tro- • Stub/mock frameworks for Java Review and com-
zo de código usado como sustituto de alguna otra fun- parison of stub & mock frameworks for Java
cionalidad. Un stub puede simular el comportamiento de
código existente (tal como un procedimiento en una má-
quina remota) o ser el sustituto temporal para un código
aún no desarrollado. Los stubs son, por tanto, muy úti-
les para porting, computación distribuida así como en el
desarrollo y pruebas de software en general.
Un ejemplo de stub en pseudocódigo podría ser como és-
te:
INICIO Temperatura = LeerTermometro(Afuera) SI
Temperatura > 40 ENTONCES ESCRIBIR “Hace ca-
lor!" FIN SI FIN INICIO LeerTermometro(Fuente aden-
troOafuera) RETORNAR 2∪ FIN LeerTermometro
El pseudocódigo de arriba utiliza la función LeerTermo-
metro, que devuelve la temperatura. Aunque se preten-
de que LeerTermometro obtenga la temperatura de al-
gún dispositivo, la función en este momento no contie-
ne el código necesario. LeerTermometro, en esencia, no
simula ningún proceso aunque devuelve un valor legal,
permitiendo así probar aunque sea en parte el programa
principal. Hay que notar también que aunque acepta un
parámetro de tipo Fuente para determinar si se va a leer
la temperatura externa o interna, éste no se usa.
Un stub* [1] es una rutina que realmente no hace otra cosa
que declararse a sí misma y a los parámetros que acepta
y que devuelve un valor habitual dentro de los 'escena-
rios felices' del que llama al stub. Los stubs se usan habi-
tualmente como sustitutos de la implementación aún no
nalizada de una interfaz ya de nida. El stub contendría
sólo el código necesario para que compile y enlace con el
resto del programa.

192.1 Referencias
[1] [Link]

192.2 Enlaces externos

• A Stub Generation System For C++ (PDF)

3∧∧
Capítulo 193

Subalgoritmo

Se llama subalgoritmo a cada una de las partes de un nes en su funcionamiento. Este paso de argumentos se
algoritmo más general que resuelve cada una de las ta- puede hacer por valor o por referencia.
reas particulares necesarias para que dicho algoritmo ge- Ver Paso de argumentos en Argumento (Ciencias de la
neral alcance el objetivo para el que fue diseñado, es de- computación)'
cir resolver un problema. Este concepto está vinculado al
diseño estructurado de algoritmos, en el cual un problema
se divide en partes que posteriormente son resueltas por
un módulo. Cada módulo coincidirá con un subalgoritmo. 193.4 Véase también
• Programación estructurada
193.1 Tipos de subalgoritmos • Programación modular

• Funciones: devuelven un valor. • Subrutina

• Procedimientos: cambian un valor. • Encapsulamiento (programación orientada a obje-

tos)

• Abstracción (programación orientada a objetos)

193.2 Ámbito de las variables
• Recursión y Algoritmo recursivo
Desde el punto de un subalgoritmo las variables pueden
ser locales o globales:

• Las variables locales se declaran dentro de un mó-

dulo o subalgoritmo y sólo tienen utilidad dentro de
ese módulo, no se podrá acceder a ellas desde otros
módulos. Pueden existir variables locales con el mis-
mo nombre siempre que estén en módulos diferen-
tes.

• Las variables globales son declaradas de forma que

puedan ser utilizadas (consultada y/o modi cada)
desde cualquiera de los módulos que forman el pro-
grama. En este caso, no puede haber dos variables
globales con el mismo nombre, ya que esto produ-
ciría una ambigüedad que el compilador no podría
resolver. En el diseño estructurado de algoritmos se
desaconseja el uso de variables globales ya que este
produciría acoplamiento común.

193.3 Paso de argumentos

Cuando se hace una llamada a un subalgoritmo, se le pue-
den pasar argumentos para determinar ciertas condicio-

3∧∨
Capítulo 194

Tabla de saltos

En programación, se denomina tabla de saltos a un mé- funciones por su número (el índice en la tabla) pueden
todo e ciente de transferencia de control de programas ser útiles en ciertos programas.
saltando a otra parte del código mediante una tabla de
instrucciones de salto. Este sistema es utilizado normal-
mente en la programación en ensamblador aunque estas 194.1 Ejemplo
tablas también pueden ser generadas por un compilador.
Una tabla de saltos consiste en una lista de instrucciones Un ejemplo simple del uso de tablas de saltos en ensam-
de salto incondicional que se ejecutan utilizando un o set blador del microcontrolador PIC de ∪ bits es:
creado mediante la multiplicación de un índice secuencial
por la longitud de la instrucción (los bytes que ocupa en movf INDEX, W ; mover el valor de índice al registro
memoria cada instrucción). Se basa en el hecho de que W (registro de trabajo) desde la dirección de memoria
las instrucciones de salto en código máquina tienen una INDEX addwf PCL, F ; sumarlo al registro de contador
longitud ja y pueden ser ejecutadas de forma extrema- de programa (PCL). Cada instrucción PIC ocupa 1 byte
damente e ciente por la mayoría del hardware, además ; de modo que no es necesario realizar ninguna multipli-
de ser más útil cuando se trabaja con datos sin formato cación. La mayoría de las arquitecturas transformarían ;
fácilmente convertibles a valores secuenciales de índice. el índice de alguna manera antes de sumarlo al contador
Dados estos datos, una tabla de saltos suele ser bastante de programa table ; esta etiqueta marca el comienzo de
e ciente, siguiendo normalmente estos pasos: validación la tabla de salto goto index_zero ; cada una de estas ins-
opcional de los datos de entrada, transformación de los trucciones goto es un salto incondicional a diferentes sec-
mismos en un o set dentro de la tabla de saltos (esto sue- ciones goto index_one ; del código goto index_two goto
le necesitar multiplicarlos o desplazarlos para su longitud index_three index_zero ; en esta parte se añadiría el códi-
coincida con las instrucciones de salto) y salto a una di- go necesario para realizar cualquier acción que requiera
rección obtenida a partir de la base de la tabla y el o set que el valor de INDEX sea igual a cero return index_one
generado (esta operación suele incluir la suma del o set ...
al registro del contador de programa).
Otro método de implementación de las tablas de saltos
consiste en un array de direcciones desde las cuales es
194.2 Historia
capturada la dirección necesaria para saltar. Este método
suele implicar un menor tamaño del código y evita los El uso de las tablas de saltos y de la representación de
saltos indirectos. Normalmente el método empleado para los datos sin formato mediante índices era común en los
construir la tabla de saltos suele venir determinada por la inicios de la informática cuando las memorias eran caras
arquitectura del procesador en el cual va a ser ejecutado y los procesadores lentos, siendo la representación com-
el código. pacta de los datos y la elección e ciente de las alternativas
de almacenamiento dos factores importantes. También se
Las tablas de saltos suelen usarse en el desarrollo de ven con frecuencia en los sistemas empotrados modernos,
sistemas operativos. Tanto las llamadas al sistema como donde suele hacer falta que el código quepa en espacios
las funciones de biblioteca pueden ser referenciadas me- realmente mínimos y que a la vez opere de manera e -
diante un índice entero de una tabla de saltos. Con esto se ciente. La principal ventaja de tal conversión es que una
consigue una mejora de la compatibilidad con las versio- vez que un valor ha sido convertido a un índice, puede
nes siguientes: si el código de una función y la dirección ser utilizado para saltar o para recuperar algún dato de
de su destino de salto son modi cados, solamente hará una tabla de búsqueda de forma e ciente y en cualquier
falta reajustar la instrucción de salto en la tabla, de este momento sin necesidad de ser convertido de nuevo. Por
modo todas las aplicaciones compiladas utilizando códi- ejemplo, se podría decir que, relativamente, hay pocos
go de la biblioteca y/o sistema operativo en cuestión no países en el mundo; de forma que éstos podrían ser repre-
necesitan modi cación alguna. Además, las llamadas a sentados de manera sencilla mediante un código de país

3∧∩
3∧∪ CAPÍTULO 194. TABLA DE SALTOS

en lugar de por una cadena de texto. Esto evita almace-

namientos masivos de datos y por consiguientes grandes
tiempos de procesado. Las comparaciones numéricas son
signi cativamente más rápidas que las de cadenas de tex-
to, y las búsquedas indexadas son también notablemente
más rápidas que las de cadenas. Sin embargo, entre las
desventajas se incluye la aparición de un nivel más de
indirección. Esto es de poca importancia para los orde-
nadores, pero supone mayor complejidad de código y de
datos para el programador. Además, tal y como se pu-
do ver en el Efecto 2000, esta aproximación al problema
puede llevar posteriormente a problemas si los requisitos
de espacio para el índice o la representación superan a los
reservados para la tarea.

194.3 Enlaces externos

• HOWTO sobre la implementación de tablas de sal-
tos en C
Capítulo 195

Tabla de verdad

Una tabla de verdad, o tabla de valores de verdad, Negación La negación es un operador que se ejecu-
es una tabla que muestra el valor de verdad de una ta, sobre un único valor de verdad, devolviendo el valor
proposición compuesta, para cada combinación de ver- contradictorio de la proposición considerada.
dad que se pueda asignar.* [1]
Fue desarrollada por Charles Sanders Peirce por los A ∼A
años 1∪∪0, pero el formato más popular es el que in- V F
trodujo Ludwig Wittgenstein en su Tractatus logico- F V
philosophicus, publicado en 1921.

Conjunción La conjunción es un operador que actúa

195.1 De niciones en el cálculo ló- sobre dos valores de verdad, típicamente los valores de
verdad de dos proposiciones, devolviendo el valor de ver-
gico dad verdadero cuando ambas proposiciones son verdade-
ras, y falso en cualquier otro caso. Es decir es verdadera
Para establecer un Sistema formal se establecen las de - cuando ambas son verdaderas
niciones de los operadores. Las de niciones se harán en La tabla de verdad de la conjunción es la siguiente:
función del n que se pretenda al construir el sistema que
haga posible la formalización de argumentos:
A B A∧B
• Como razonamientos deductivos lógico-lingüísticos V V V
V F F
• Como construcción de un sistema matemático puro F V F
F F F
• Como una aplicación lógica en un Circuito de con-
mutación. Que se corresponde con la columna ∪ del algoritmo fun-
damental.
en simbologia "^" hace referencia a el conector “y”
Verdadero El valor verdadero se representa con la le-
tra V; si se emplea notación numérica se expresa con un
uno: 1; en un circuito eléctrico, el circuito está cerrado. Disyunción La disyunción es un operador que actúa
sobre dos valores de verdad, típicamente los valores de
verdad de dos proposiciones, devolviendo el valor de ver-
Falso El valor falso se representa con la letra F; si se dad verdadero cuando una de las proposiciones es verda-
emplea notación numérica se expresa con un cero: 0; en dera, o cuando ambas lo son, y falso cuando ambas son
un circuito eléctrico, el circuito está abierto. falsas.
La tabla de verdad de la disyunción es la siguiente:

Variable Para una variable lógica A, B, C, ... que pue-

A B A∨B
den ser verdaderas V, o falsas F, los operadores funda-
mentales se de nen así: V V V
V F V
F V V
F F F
A A
V V Que se corresponde con la columna 2 del algoritmo fun-
F F damental.

3∧9
3∨0 CAPÍTULO 195. TABLA DE VERDAD

Implicación o Condicional El condicional material es

un operador que actúa sobre dos valores de verdad, típi-
n Nc
camente los valores de verdad de dos proposiciones, de-
0 1
volviendo el valor de falso sólo cuando la primera pro-
1 2
posición es verdadera y la segunda falsa, y verdadero en
2 4
cualquier otro caso.
3 8
La tabla de verdad del condicional material es la siguiente: 4 16
5 32
... ...
A B A⇒B n 2n
V V V Si consideramos que un sistema combinacional de n va-
V F F riables binarias, puede presentar un resultado verdadero:
F V V V, o falso: F, para cada una de las posibles combinaciones
F F V de entrada tenemos que se pueden construir Cp circuitos
posibles con n variables de entrada, donde:
Que se corresponde con la columna ∧ del algoritmo fun-
damental.
Cp = 22
n

Que da como resultado la siguiente tabla:

Equivalencia, doble implicación o Bicondicional El
bicondicional o doble implicación es un operador que
funciona sobre dos valores de verdad, típicamente los va-
n Cp
lores de verdad de dos proposiciones, devolviendo el valor
0 2
de verdad verdadero cuando ambas proposiciones tienen
1 4
el mismo valor de verdad, y falso cuando sus valores de
2 16
verdad son diferentes.
3 256
La tabla de verdad del bicondicional es la siguiente: 4 65. 536
5 4. 294.967.296
... ...
22
n

A B A⇔B n
V V V Para componer una tabla de verdad, pondremos las n va-
V F F riables en una línea horizontal, debajo de estas variables
F V F desarrollamos las distintas combinaciones que se pueden
F F V formar con V y F, dando lugar a la distintas Nc, núme-
ro de combinaciones. Normalmente solo se representa la
Que se corresponde con la columna ∩ del algoritmo fun- función para la que se confecciona la tabla de verdad, y en
damental. todo caso funciones parciales que ayuden en su cálculo,
en la gura, se pueden ver todas las combinaciones po-
sibles Cp, que pueden darse para el número de variables
dado.
195.2 Número de combinaciones
n C
Partiendo de un número n de variables, cada una de las
cuales puede tomar el valor verdadero: V, o falso: F,
por Combinatoria, podemos saber que el número total de A B 1 2 3 4 5 6 7
combinaciones: Nc, que se pueden presentar es:

V V V V V V V V V
N c = 2n
V F V V V V F F F
el número de combinaciones que se pueden dar con n va-
Nc
riable, cada una de las cuales puede tomar uno entre dos
F V V V F F V V F
valores lógicos es de dos elevado a n, esto es, el núme-
ro de combinaciones: Nc, tiene crecimiento exponencial
F F V F V F V F V
respecto al número de variable n:
195.3. TABLAS DE VERDAD 3∨1

Así podemos ver que para dos variables binarias: A y B, Considérese además a "·" como una operación o función
n= 2 , que pueden tomar los valores V y F, se pueden lógica que realiza una función de verdad al tomar los va-
desarrollar cuatro combinaciones: Nc= 4, con estos valo- lores de verdad de A y de B, y devolver un único valor de
res se pueden de nir dieciséis resultados distintos, Cp= verdad. Entonces, existen 1∨ funciones distintas posibles,
1∨, cada una de las cuales seria una función de dos va- y es fácil construir una tabla que muestre qué devuelve ca-
riables binarias. Para otro número de variables se obten- da función frente a las distintas combinaciones de valores
drán los resultados correspondientes, dado el crecimien- de verdad de A y de B.
to exponencial de Nc, cuando n toma valores mayores
de cuatro o cinco, la representación en un cuadro resul-
ta compleja, y si se quiere representar las combinaciones
posibles Cp, resulta ya complejo para n= 3.
Las dos primeras columnas de la tabla muestran las cuatro
combinaciones posibles de valores de verdad de A y de
195.2.1 Para cero variables B. Hay por lo tanto 4 líneas, y las 1∨ columnas despliegan
todos los posibles valores que puede devolver una función
Un circuito sin variables, puede presentar una combina- "·".
ción posible: Nc=1, con dos circuitos posibles: Cp=2. De esta forma podemos conocer mecánicamente, me-
Que serían el circuito cerrado permanentemente, y el cir- diante algoritmo, los posibles valores de verdad de cual-
cuito abierto permanentemente. quier conexión lógica interpretada como función, siempre
y cuando de namos los valores que devuelva la función.
Se hace necesario, pues, de nir las funciones que se uti-
lizan en la confección de un sistema lógico.
En este caso se puede ver que no interviene ninguna va-
De especial relevancia se consideran las de niciones para
riable.
el Cálculo de deducción natural y las puertas lógicas
Cada uno de estos circuitos admite una única posición y en los circuitos electrónicos.
hay dos circuitos posibles.

195.2.2 Para una variable

195.3 Tablas de verdad

El caso de una variable binaria, que puede presentar dos Las tablas nos mani estan los posibles valores de verdad
combinaciones posibles: Nc=2, con 4 circuitos posibles: de cualquier proposición molecular, así como el análisis
Cp=4. de la misma en función de las proposicíones que la inte-
gran, encontrándonos con los siguientes casos:

195.3.1 Verdad Indeterminada o Contin-

Los casos 1 y 4 coinciden con los de cero variables, el gencia
caso 2 la salida es la de la variable y el caso 3 la negación
de la variable. Se entiende por verdad contingente, o verdad de hecho,
aquella proposición que puede ser verdadera o falsa, se-
gún los valores de las proposiciones que la integran. Sea
195.2.3 Para dos variables el caso: A ∧ (B ∨ C) .
Considérese dos variables proposicionales A y B.* [2] Ca- Su tabla de verdad se construye de la siguiente manera:
da una puede tomar uno de dos valores de verdad: o V Ocho las que responden a los casos posibles que pueden
(verdadero), o F (falso). Por lo tanto, los valores de ver- darse según el valor V o F de cada una de las proposicio-
dad de A y de B pueden combinarse de cuatro maneras nes A, B, C. (Columnas 1, 2, 3)
distintas: o ambas son verdaderas; o A es verdadera y B
falsa, o A es falsa y B verdadera, o ambas son falsas. Esto Una columna (Columna 4) en la que se establecen los va-
puede expresarse con una tabla simple: lores de B ∨ C aplicando la de nición del disyuntor a los
valores de B y de C en cada una de las las.(Columnas 2,3
4)
A B Una columna (columna ∧) en la que se establecen los va-
V V lores resultantes de aplicar la de nición de la conjunción
V F entre los valores de A (columna 1) y valores de la columna
F V B ∨ C , (columna 4) que representarán los valores de la
F F proposición completa A ∧ (B ∨ C) , cuyo valor de ver-
3∨2 CAPÍTULO 195. TABLA DE VERDAD

dad es V o F según la la de los valores de A, B, y C que No obstante la sencillez del algoritmo, aparecen dos di -
consideremos. (Columnas 1,4 ∧) cultades.
Donde podemos comprobar cuándo y por qué la propo-
sición A ∧ (B ∨ C) es V y cuándo es F. • La gran cantidad de operaciones que hay que hacer
para una proposición con más de 4 variables.

Esta di cultad ha sido magní camente superada por la

rapidez de los ordenadores, y no presenta di cultad algu-
195.3.2 Contradicción na.

Se entiende por proposición contradictoria, o contradic- • Que únicamente será aplicable a un esquema de in-
ción, aquella proposición que en todos los casos posibles ferencia, o argumento cuando la proposición condi-
de su tabla de verdad su valor siempre es F. Dicho de otra cionada, como conclusión, sea previamente conoci-
forma, su valor F no depende de los valores de verdad de da, al menos como hipótesis, hasta comprobar que
las proposiciones que la forman, sino de la forma en que su tabla de verdad mani esta una tautología.
están establecidas las relaciones sintácticas de unas con
otras. Sea el caso: Por ello se construye un cálculo mediante cadenas deduc-
tivas:

A∧ ∼ A Las proposiciones que constituyen el antecedente del es-

quema de inferencia, se toman como premisas de un ar-
Procederemos de manera similar al caso anterior. Par- gumento.
tiendo de la variable A y su contradicción, la conjunción Se establecen como reglas de cálculo algunas tautologías
de ambos siempre es falso, dado que si A es verdad su como tales leyes lógicas, (pues garantizan, por su carácter
contradicción es falsa, y si A es falsa su contradicción es tautológico, el valor V).
verdad, la conjunción de ambas da falso en todos los ca-
sos. Se permite la aplicación de dichas reglas como reglas de
sustitución de fórmulas bien formadas en las relaciones
que puedan establecerse entre dichas premisas.
195.3.3 Tautologías Deduciendo mediante su aplicación, como teoremas, to-
das las conclusiones posibles que haya contenidas en las
Se entiende por proposición tautológica, o tautología, premisas.
aquella proposición que en todos los casos posibles de su
tabla de verdad su valor siempre es V. Dicho de otra for- Cuando en un cálculo se establecen algunas leyes como
ma, su valor V no depende de los valores de verdad de principios o axiomas, el cálculo se dice que es axiomático.
las proposiciones que la forman, sino de la forma en que El cálculo lógico así puede utilizarse como demostración
están establecidas las relaciones sintácticas de unas con argumentativa.
otras. Sea el caso:

195.5 Aplicaciones
A∨ ∼ A

Siguiendo la mecánica algorítmica de la tabla anterior 195.5.1 Cálculo lógico

construiremos su tabla de verdad, tenemos la variable A
en disyunción con su contradicción, si A es verdad, su ne- La aplicación fundamental se hace cuando se construye
gación es falsa y si A es falsa su negación es verdad, en un sistema lógico que modeliza el lenguaje natural some-
cualquier caso una de las dos alternativas es cierta, y su tiéndolo a unas reglas de formalización del lenguaje. Su
disyunción es cierta en todos los casos. aplicación puede verse en el cálculo lógico.

195.4 Tablas de verdad, proposi- 195.5.2 Lógica de circuitos

ciones lógicas y argumentos Una aplicación importante de las tablas de verdad proce-
de del hecho de que, interpretando los valores lógicos de
deductivos verdad como 1 y 0 (lógica positiva) en el sentido que

En realidad toda la lógica está contenida en las tablas de • valor “1”permite el paso de corriente eléctrica; y
verdad, en ellas se nos manifesta todo lo que implican las
relaciones sintácticas entre las diversas proposiciones. • valor “0”corta el paso de dicha corriente.
195.5. APLICACIONES 3∨3

El primer caso en una función lógica que para todas las

posibles combinaciones de A y B, el resultado siempre es
verdadero, es un caso de tautología, su implementación
en un circuito es una conexión ja.

• Caso 2

En este segundo caso el resultado solo es falso si A y B son

falsos, si una de las dos variables es verdad el resultado es
Puertas lógicas para circuitos eléctricos
verdad.
La función seria:
Los valores de entrada o no entrada de corriente a tra-
vés de un diodo pueden producir una salida 0 ó 1 según
las condiciones de nidas como función según las tablas A ∨ B
mostradas anteriormente.
• Caso 3
Así se establecen las algunas funciones básicas: AND,
NAND, OR, NOR, XOR, XNOR (o NXOR), que se co-
En el tercer caso es verdad si A es verdad y cuando A y
rresponden con las funciones de nidas en las columnas ∪,
B son falsos el resultado también es verdad.
9, 2, 1∧, 10 y ∩ respectivamente, y la función NOT.
Su función seria:
En lugar de variables proposicionales, considerando las
posibles entradas como EA y EB, podemos armar una
tabla análoga de 1∨ funciones como la presentada arriba,
con sus equivalentes en lógica de circuitos. A∨ ∼ B
Esta aplicación hace posible la construcción de aparatos • Caso 4
capaces de realizar estas computaciones a alta velocidad,
y la construcción de circuitos que utilizan este tipo de En el cuarto caso la función es cierta si A es cierta, los
análisis se hace por medio de puertas lógicas. posibles valores de B no in uyen en el resultado.
La Tabla de la verdad es una herramienta imprescindible La función solo depende de A:
en la recuperación de datos en las bases de datos como
Internet con los motores de búsqueda o en una biblioteca
con sus cheros informatizados. Así mismo se utilizan
para programar simulaciones lógicas de inteligencia arti- A
cial con lenguajes propios. También en modelos mate-
máticos predictores: meteorología, marketing y otros mu- • Caso ∧
chos.
En el quinto caso si A es falso el resultado es verdadero,
y si A y B son verdaderos el resultado también es ver-
dadero, puede verse que este caso es idéntico al tercero
195.5.3 Desarrollo del algoritmo funda- permutando A por B.
mental en lógica de circuitos Y si función es:

La de nición de la tabla de verdad corresponde a funcio-

nes concretas, en cada caso, así como a implementacio- ∼A∨B =A⇒B
nes en cada una de las tecnologías que pueden representar
funciones lógicas en binario, como las puertas lógicas o • Caso ∨
los circuitos de conmutación. Se entenderá como verdad
la conexión que da paso a la corriente; en caso contrario En el sexto caso la función es cierta si B es cierta, los
se entenderá como falso. Veamos la presentación de los valores de A no in uyen en el resultado.
dieciséis casos que se presentan con dos variables binarias
A y B: La función solo depende de B:

• Caso 1 B
3∨4 CAPÍTULO 195. TABLA DE VERDAD

• Caso ∩ • Caso 13

El séptimo caso corresponde a la relación bicondicional En el caso decimotercero podemos ver que el resultado
entre A y B, el resultado solo es verdad si A y B son ambos es el opuesto de A, independientemente del valor de B:
verdad o si A y B son ambos falsos.

∼A
(A ∧ B) ∨ (∼ A∧ ∼ B) = A ⇔ B
• Caso 14
• Caso ∪

En el octavo caso el resultado es verdad si A y B son ver- Caso decimocuarto, el resultado de la función solo es ver-
dad, en el resto de los valores de A y B el resultado es dad si A es falso y B verdadero, luego es equivalente a un
falso, corresponde a la conjunción de A y B, equivalente circuito en serie de A en conexión inversa y de B en co-
a un circuito en serie. nexión directa.

A∧B ∼A∧B

• Caso 9 • Caso 1∧

En el noveno caso el resultado solo es falso si A y B son En el caso decimoquinto, el resultado solo es verdad si A
verdad, en el resto de los valores de A y B el resultado es y B son falsos, Luego es necesario que tanto A como B
verdadero, corresponde a la disyunción de la negación A y sean falsos para que el resultado sea verdadero.
de B, equivalente a un circuito en paralelo de conexiones
inversas.
∼ A∧ ∼ B

∼ A∨ ∼ B • Caso 1∨
• Caso 10
Por último en el caso decimosexto, tenemos que el resul-
tado siempre es falso independientemente de los valores
Podemos ver que el décimo caso es lo opuesto a la bi-
de A o de B.
condicional, solo es verdad si A y B discrepan, si A y B
son diferentes el valor es verdad, si A y B son iguales el
resultado es falso.
F

(A∧ ∼ B) ∨ (∼ A ∧ B)
195.6 Véase también
• Caso 11
• Operador lógico
En este caso podemos ver que cuando B es verdad el re-
sultado es falso y que cuando B es falso el resultado es • Anexo:Tabla de símbolos matemáticos
verdadero, independientemente del valor de A, luego la
función solo depende de B, en sentido inverso. • Lenguaje formalizado

• →lgebra de Boole
∼B • Cálculo lógico

• Caso 12 • Lógica binaria

En el caso doce, vemos que solo hay un combinación de • Lógica proposicional

A y B con resultado verdadero, que es A y la negación de
B. • Puerta lógica

• Función lógica

A∧ ∼ B • Función de verdad
195.8. ENLACES EXTERNOS 3∨∧

195.7 Notas y referencias

[1] «truth table» (en inglés), The Concise Oxford Dic-
tionary of Mathematics, Oxford University Press,
[Link]
subview=Main&entry=t∪2.e2∪9∧, consultado el ∪ de
octubre de 2009

[2] Las letras A y B son metavariables, es decir pertenecen

a un metalenguaje respecto a un lenguaje-objeto; por ello
simbolizan cualquier proposición, atómica o no, del len-
guaje de la lógica proposicional.

195.8 Enlaces externos

• TABLAS DE VERDAD
• Tablas De Verdad

• Tablas de Verdad
• Lógica matemática
Capítulo 196

Thunk

Thunk es un término usado en la jerga del desarrollo de public ref class CManagedClass { private: System::Int32
software que designa la llamada o invocación a un código m_i; public: void SetValue( int i ) { m_i = i; // Implemen-
que pertenece a otra plataforma o a otro Framework. En tación del tipo de datos } };
el paso de 1∨ a 32 bit por ejemplo, los sistemas operativos
Las clases nativas C++ en un proyecto C++/CLI. Aquí se
(OS/2, Windows NT etc.) podían resolver código de 1∨ puede ver que también el camino inverso es posible, es
bit a través de la transformación de los parámetros de lla-
decir, instanciar el código gestionado dentro de una clase
madas y direcciones, de modo tal que fue posible seguir no gestionada. La condición es, sin embargo, que se trate
utilizando los programas de 1∨ bit. de un proyecto C++/CLI, de modo tal que el compilador
En el desarrollo de software moderno, un thunk es la lla- comprenda la correspondiente sintaxis. El thunk ya apa-
mada del código nativo desde el código gestionado y vi- rece en la instrucción «gcnew», ya que aquí se invoca al
ceversa (véase por ejemplo Java Native Access o .NET constructor de la clase gestionada:
P/Invoke). Es decir, se trata de una plataforma de tran- public class CNativeClass { public: void Foo() { int i =
sición, en la que las convenciones y/o parámetros de in- 42; CManagedClass^ pManagedClass = gcnew CMana-
vocación tienen que transformarse correspondientemente gedClass(); pManagedClass->SetValue( i ); } };
(Marshalling). El lenguaje de programación C++/CLI del
.NET-Framework de Microsoft fue concebido especial-
mente para posibilitar tales thunks en ambas direcciones:
196.3 Bibliografía
• Marcus Heege: Expert C++/CLI. Apress Verlag,
196.1 Invocación por «gestionada» Berkeley 200∩, ISBN 9∩∪-1-∧90∧9-∩∧∨-9, Capítulo
a «no gestionada» 9, p. 203 y siguientes.

Sea dada una clase nativa en C++, por ejemplo un proyec-

to C++ o como parte integrante de un proyecto C++/CLI,
que se utilizará más abajo en código gestionado:
public class CNativeClass { private: int m_i; public: void
SetValue( int i ) { m_i = i; } };
La clase gestionada C++/CLI (que en esta forma puede
ser directamente instanciada, por ejemplo, en C#), la cual
utiliza la clase nativa mostrada anteriormente:
public ref class CManagedClass { public: CManaged-
Class() { System::Int32 i = 42; CNativeClass* pNative-
Class = new CNativeClass(); pNativeClass->SetValue( i
); // Implementación del tipo de datos delete pNative-
Class; } };

196.2 Invocación por «no gestiona-

da» a «gestionada»
La clase gestionada C++/CLI :

3∨∨
Capítulo 197

Tipo de dato elemental

Se llama tipo primitivo o tipo elemental a los tipos de

datos originales de un lenguaje de programación, esto es,
aquellos que nos proporciona el lenguaje y con los que
podemos (en ocasiones) construir tipos de datos abstrac-
tos y estructuras de datos.
Generalmente ejemplos de tipos primitivos son:

• Char (Carácter)
• Int (Entero)

• Float (Real - Coma otante)

Otros tipos de datos que pueden ser considerados primi-

tivos ya que la mayoría de lenguajes de programación así
los proporcionan (aunque no todos) son:

• Booleano (Lógico: Verdadero, Falso)

• String (Cadena de caracteres)

• Puntero (Dirección de memoria - Int)

3∨∩
Capítulo 198

Triángulo de Floyd

El Triángulo de Floyd, llamado así en honor a Robert 198.3 Referencias

Floyd, es un triángulo rectángulo formado con números
naturales. Para crear un triángulo de Floyd, se comien- [1] Keller, Arthur M. (19∪2), A rst course in computer pro-
za con un 1 en la esquina superior izquierda, y se conti- gramming using PASCAL, McGraw-Hill, p. 39.
núa escribiendo la secuencia de los números naturales de
[2] Peters, James F. (19∪∨), Pascal with program design, Holt,
manera que cada línea contenga un número más que la
Rinehart and Winston, pp. 13∩, 1∧4.
anterior:
Una de los ejercicios más comunes en los cursos de in-
troducción a la programación de ordenadores consiste en
escribir un pequeño programa que produzca este triángu-
lo.* [1]* [2] El triángulo de Floyd tiene varias propiedades
matemáticas interesantes. Los números del cateto de la
parte izquierda forman la secuencia de los números poli-
gonales centrales, mientras que los de la hipotenusa nos
dan el conjunto de los números triangulares. La suma de
los números de la línea n equivale a n(n2 + 1)/2 (sucesión
A00∨003 en OEIS).

198.1 Algoritmo computacional

En PSeInt es:
De nir TAMANIO Como Entero; TAMANIO <- 10;
De nir i, j, t Como Enteros; t <- 1; Escribir “Triángulo
Floyd"; Para i <- 1 Hasta TAMANIO Con Paso 1 Hacer
Para j <- t Hasta t + i - 1 Con Paso 1 Hacer Escribir
j, " " Sin Bajar; FinPara Escribir ""; t <- t + i; FinPara
FinProceso

En Java es:
public class TrianguloFloyd { public static void
main(String[] args) { nal int TAMANO = 10; int t = 1;
[Link]("\nTriángulo Floyd\n”); for (int i =
1; i <= TAMANO; ++i) { for (int j = t; j <= t + i - 1; ++j)
{ [Link](j + "\t”); } [Link]("\n”
); t += i; } } }

198.2 Véase también

• Triángulo de Pascal

3∨∪
Capítulo 199

Tubería (informática)

La comunicación por medio de tuberías se basa en la in-

teracción productor/consumidor, los procesos produc-

|¦
tores (aquellos que envían datos) se comunican con los
procesos consumidores (que reciben datos) siguiendo un
orden FIFO. Una vez que el proceso consumidor recibe
un dato, éste se elimina de la tubería.
Las tuberías (pipes) están implementadas en forma muy
e ciente en los sistemas operativos multitarea, iniciando
todos los procesos al mismo tiempo, y atendiendo auto-
máticamente los requerimientos de lectura de datos para
cada proceso cuando los datos son escritos por el proce-
so anterior. De esta manera el plani cador de corto plazo
va a dar el uso de la CPU a cada proceso a medida que
pueda ejecutarse minimizando los tiempos muertos.
Para mejorar el rendimiento, la mayoría de los sistemas
operativos implementan las tuberías usando bu ers, lo
que permite al proceso proveedor generar más datos que
lo que el proceso consumidor puede atender inmediata-
mente.
Podemos distinguir dos tipos de tuberías:

Tubería sin nombre Las tuberías sin nombre tienen

asociado un chero en memoria principal, por lo
tanto, son temporales y se eliminan cuando no están
siendo usados ni por productores ni por consumido-
res. Permiten la comunicación entre el proceso que
crea un cauce y procesos hijos tras la creación de la
tubería.

Tubería con nombre Su diferencia respecto a las tube-

rías sin nombre radica en que el cauce se crea en el
sistema de archivos, y por lo tanto no tienen carácter
temporal. Se manejan mediante llamadas al sistema
(open, close, read y write) como el resto de cheros
del sistema. Permiten la comunicación entre los pro-
Tubería y barra partida. cesos que usen dicha tubería, aunque no exista una
conexión jerárquica entre ellos.

En informática, una tubería (pipe, cauce o '|') consiste

en una cadena de procesos conectados de forma tal que 199.1 Véase también
la salida de cada elemento de la cadena es la entrada del
próximo. Permiten la comunicación y sincronización en- • Arquitectura en pipeline (informática)
tre procesos. Es común el uso de bu er de datos entre
elementos consecutivos. • Tubería (Unix)

3∨9
3∩0 CAPÍTULO 199. TUBERÍA (INFORMÁTICA)

• Pleca

• Wikcionario tiene de niciones y otra informa-

ción sobre tubería (informática).Wikcionario
Capítulo 200

Violación de acceso

Se de ne como violación de acceso (violación del seg-

mento o access violation y segmentation fault en Inglés)
al intento fallido de acceso a información o a programas
a los que no se tiene autorización para ver o modi car.
Este mensaje puede ser causado por la con guración de
software, por los programadores o por falla de hardware,
siendo los más comunes los 2 primeros.
Con los sistemas operativos actuales, cada proceso tiene
uno o más segmentos de la memoria del sistema donde
puede almacenar y recuperar la información. Cada proce-
so puede solicitar más o menos memoria (según lo nece-
sitado), y la petición será reconocida por el sistema ope-
rativo y comparada con la sección de memoria concedida
para el proceso. Generalmente, el proceso que solicitó la
memoria es el único que puede leerla o modi carla.
Una violación de acceso ocurre cuando un proceso trata
de acceder a una parte de la memoria asignada a otra apli-
cación, o a una área no usada de la memoria, no tenien-
do los permisos para hacerlo. Normalmente se produce
como resultado de un error de programación, por ejem-
plo, un puntero descarriado. Otra forma en que podría
producirse un“segmentation fault”es con una memoria
dañada físicamente, puesto que algún programa escribirá
en la memoria, luego intentará acceder a esos datos, pe-
ro al tener una falla la memoria, es posible que los datos
se hayan borrado, por ende el programa considerará esa
dirección de memoria como vacía, o sea no usada, con lo
que arrojará el error.

200.1 Véase también

• Error de software.
• Agujero de seguridad.

3∩1
Capítulo 201

Waf

Waf es una herramienta que ayuda a con gurar automá- • Información en pantalla colorida y barra de progre-
ticamente la compilación y la instalación de otros progra- so.
mas o bibliotecas (build).
• Los scripts son módulos de Python.

201.1 Funciones • Esquema modular de con guración con análisis per-

sonalizable en línea de comandos.
General
• Modo demonio para el historial de recompilación.
• Es portable a sistemas Unix y no-Unix.
• Busca archivos fuente de forma inteligente para fa-
• Es ligero. cilitar el mantenimiento del script .

• Ofrece un lenguaje de programación real (similar a • Soporta caché de objetos global para evitar compi-
SCons). laciones innecesarias.
• Soporta objetivos estándar: con gurar, compilar,
limpiar, instalar y desinstalar. • Soporta la ejecución de pruebas(test) en los progra-
mas al nal de la compilación.
Requerimientos

• No requiere instalación: el script WAF (menos de 201.2 Historia

100KB) puede ser distribuido y utilizado directa-
mente. Era alrededor del año 200∧, el proyecto KDE usó duran-
te mucho tiempo el Autotools como su principal sistema
• Sólo necesita a Python como dependencia externa.
de construcción. Autotools tiene una arquitectura que es
• No requiere sh (a diferencia de GNU Autotools). difícil de comprender, y ha sido apodado“auto-in erno”
.,* [1] en KDE estaban considerando la posibilidad de pa-
• No requiere de conocimientos acerca de M4 (a di- sar de Autotools a SCons.
ferencia de GNU Autotools).
Thomas Nagy había creado una herramienta de construc-
ción automatizada llamada BKsys que fue diseñada para
Soporte de lenguajes: colocarse encima de SCons, proporcionando mayor nivel
de funcionalidad similar a la de autotools. Cuando Tho-
• Preprocesador de dependencias C/C++. mas Nagy decide que los problemas fundamentales de
SCons (sobre todo la mala escalabilidad) eran demasia-
• Soporte para programas híbridos en OCaml, en pro- do complejos y requerían mucho tiempo para arreglarse,
gramas de GNOME. comienza una reescritura completa llamada “Waf”.
• Soporte para el lenguaje de programación D (tanto Waf fue objeto de un poco de atención cuando el proyec-
GDC y dmd son compatibles). to en KDE decidieron utilizar BKsys (y más tarde WAF)
como su principal sistema de construcción, aunque más
• Proyectos escritos en vala son soportados ( como tarde, esa decisión fue revocada en favor de CMake por-
Val(a)IDE ). que BKsys no pudo resolver los problemas de SCons, y
Waf todavía estaba en una fase muy temprana de desa-
Otros: rrollo (pre-alfa) en ese momento.* [1]

3∩2
201.6. ENLACES EXTERNOS 3∩3

201.3 Ejemplo Waf archivo

A continuación se muestra una wscript muy simple, que
incluirá una fuente llamada “hola-mundo.c”usando el
compilador C por defecto.
top = '.' out = 'build' def set_options(opt):
opt.tool_options('compiler_cc') def con gure(conf):
conf.check_tool('compiler_cc') def build(bld):
bld(source = 'hello-world.c', target = 'hello-world',
features = 'cc cprogram')

El proyecto se construye con el siguiente comando:

waf con gure build

201.4 Véase también

• CMake

• GNU build system

• SCons

201.5 Referencias
[1] ←Por qué el proyecto KDE cambió a CMake(ingles)

201.6 Enlaces externos

• Waf página de inicio

• GNOME, usado WAF?

• Proyectos de Uso Waf
Capítulo 202

Win32 Thread Information Block

En computación, el Win32 Thread Information Block Ejemplos en C inlined-assembly para x∪∨ de 32 bits:
(TIB) es una estructura de datos en los sistemas Win32, // gcc (AT&T-style inline assembly). void *getTIB() {
especí camente en la arquitectura x∪∨, que almacena in-
void *pTib; __asm__(“movl %%fs:0x1∪, %0”: "=r”
formación acerca del hilo que se está ejecutando. Tam- (pTib) : : ); return pTib; }
bién es conocido como el Thread Environment Block
// Microsoft C void *getTib() { void *pTib; __asm {
(TEB).* [1] mov EAX, FS:[1∪h] mov [pTib], EAX } return pTib; }
El TIB no está documentado o cialmente para Windows // Usando intrinsics de Microsoft en vez de inline
9x. El DDK de la familia Windows NT incluye una es- assembly void *getTib() { void *pTib = ( void * )
tructura NT_TIB en winnt.h que documenta la parte in- __readfsdword( 0x1∪ ); return pTib; }
dependiente de subsistema. El emulador Wine incluye de-
claraciones para el TIB extendido (una parte especi ca
del subsistema). Todavía muchos programas de Win32
usan estos campos no documentados que son en efecto 202.3 Enlaces externos
una parte de la API. El primer campo, en particular, está
directamente referenciado por el código producido por el
• Under The Hood - MSJ, May 199∨
propio compilador de Microsoft.* [1]
El TIB puede ser usado para obtener una buena canti- • Wine HQ
dad de información sobre el proceso sin tener que llamar
a ninguna API de Win32 (por ejemplo, emulaciones de [1]
GetLastError() , GetVersion() ). A través del puntero al
PEB se puede obtener acceso a las tablas de importación
(IAT), los argumentos de inicio pasados al proceso, nom-
bre de la imagen, etc.

202.1 Contenido del TIB

FS conduce a un TIB que está incorporado en un bloque
de datos conocido como el TDB (Thread Data Base). El
TIB contiene la cadena de manejo de excepciones especí-
co a cada hilo y punteros al TLS (Thread Local Storage).
El TLS no es lo mismo que el C local storage.

202.2 Acceso al TIB

El TIB se puede acceder como un desplazamiento del seg-
mento de registro FS.
No es común acceder a campos del TIB por medio de un
desplazamiento desde FS:[0], sino que primero se obtiene
un puntero de auto-referencia lineal a éste, almacenado en
FS:[0x1∪]. Este puntero se puede usar con aritmética de
punteros o se puede transformar a un puntero struct.

3∩4
Capítulo 203

Wrapper

GNU y la Licencia Creative Commons Atribución-

• Wikcionario tiene de niciones y otra informa-
CompartirIgual 3.0 Unported.
ción sobre [Link]

Wrapper (en castellano empaquetador), es un término • Esta obra deriva de la traducción parcial de Wrapper
inglés que generalmente se re ere a un tipo de embalaje, de Wikipedia en portugués, publicada por sus edi-
tal como una hoja plana de papel, celofán o plástico para tores bajo la Licencia de documentación libre de
envolver un objeto. GNU y la Licencia Creative Commons Atribución-
CompartirIgual 3.0 Unported.

203.1 Computación
• Función wrapper, una función cuyo principal propó-
sito es llamar a otra función.
• Biblioteca wrapper
• Driver wrapper, software que funciona como
un adaptador entre un sistema operativo y un
driver.
• Patrón Wrapper, donde algunos códigos de
programación permiten que ciertas clases tra-
bajen juntas, lo que no sería posible de otra
forma.
• Clase wrapper, término de computación que se re-
ere a una clase Java en programación orientada a
objetos.
• TCP Wrapper, software usado para ltrar el acceso
a la red.
• Wrapper (Minería de datos), técnica usada en la mi-
nería de datos.

203.2 Véase también

• Framework

203.3 Referencias
• Esta obra deriva de la traducción parcial de Wrapper
de Wikipedia en inglés, concretamente de esta ver-
sión del 1∧ de mayo de 2014, publicada por sus edi-
tores bajo la Licencia de documentación libre de

3∩∧
Capítulo 204

XAML

XAML (acrónimo pronunciado xammel del inglés como un recurso en un ensamblado de Framework .NET.
eXtensible Application Markup Language, Lenguaje Ex- En el momento de ejecución, el motor del Framework ex-
tensible de Formato para Aplicaciones en español) es el trae el archivo .baml de los recursos del ensamblado, se
lenguaje de formato para la interfaz de usuario para la analiza sintácticamente, y crea el correspondiente árbol
Base de Presentación de Windows (WPF por sus siglas en visual WPF o Work ow.
inglés) y Silverlight(wpf/e), el cual es uno de los“pilares”
Cuando se use en Windows Presentation Foundation,
de la interfaz de programación de aplicaciones .NET en XAML es usado para describir interfaces visuales para
su versión 3.0 (conocida con anterioridad con el nombre usuarios. WPF permite la de nición de objetos en 2D y
clave WinFX). 3D, rotaciones, animaciones y otra variedad de caracte-
XAML es un lenguaje declarativo basado en XML, opti- rísticas y efectos.
mizado para describir grá camente interfaces de usuarios
Cuando es usado en el contexto de Windows Work ow
visuales ricas desde el punto de vista grá co, tales co- Foundation, XAML es usado para describir lógica de-
mo las creadas por medio de Adobe Flash. XUL y UIML clarativa potencialmente larga (potentially long-running
son otros ejemplos de lenguajes de interfaz basados en declarative logic), como aquellos creados en el proceso
XML. SVG es un estándar de la organización W3C, el de sistemas de modelado y herramientas. El formato de
cual soporta grá cos, animaciones, audio y video inte- serialización para WorkFlows había sido llamado previa-
grados, eventos y comportamiento descrito por medio de mente XOML, para diferenciarlo de su uso en IU de los
escritura y puede ser utilizado como lenguaje de interfaz XAML, pero esa diferenciación ya no existe. Sin embar-
basado en XML. go las extensiones de los archivos que contienen marcado
En su uso típico, los archivos tipo XAML serían pro- de work ow es todavía XOML. [4][∧]
ducidos por una herramienta de diseño visual, como
Microsoft Visual Studio o Microsoft Blend. El XML re-
sultante es interpretado en forma instantánea por un sub-
sistema de despliegue de Windows que reemplaza al GDI
204.2 Ejemplos
de las versiones anteriores de Windows. Los elementos de
XAML se interconectan con objetos del Entorno Común Este ejemplo en XAML muestra un texto“Hola Mundo!"
de Ejecución para Lenguajes. Los atributos se conectan dentro de un contenedor del tipo Canvas.
con propiedades o eventos de esos objetos. <Canvas xmlns="[Link]
XAML fue diseñado para soportar las clases y métodos //[Link]/client/200∩" xmlns:x=\_
de la plataforma de desarrollo .NET que tienen relación _xunadd_text_character:nN{\textquotedbl}{"}{}http:
con la interacción con el usuario, en especial el despliegue //[Link]/web/[Link]
en pantalla. El acrónimo XAML originalmente signi ca- com/winfx/200∨/xaml"> <TextBlock>Hola Mun-
ba Extensible Avalon Markup Language, Lenguaje do!</TextBlock> </Canvas>
Extensible de Formato de Avalon; habiendo sido Ava-
lon el nombre clave original de la Base de Presentación
de Windows, nombre que engloba a este grupo de clases
de .NET. 204.3 Véase también
• Microsoft Expression Blend (Herramienta de Mi-
204.1 Tecnología crosoft que utiliza XAML)

• Adobe Flex
Un archivo XAML puede ser compilado para obtener un
archivo binario XAML .baml, el cual puede ser insertado • JavaFX

3∩∨
204.5. ENLACES EXTERNOS 3∩∩

• OpenLaszlo

• XUL
• ZUL

204.4 Referencias

204.5 Enlaces externos

• Microsoft Expression
• Blog del Equipo de Silverlight (español)

• Blog del Equipo de Expression(español)

• Información general sobre XAML

• United XAML Initiative - Alternativas a XAML de

código libre.

• Editor XAML gratuito - Aurora

Capítulo 205

Zenphp

205.1 ¿Qué es zenphp?

zenphp es un completo framework con código fuente,
comentarios y documentación en español. Hace las ta-
reas de creación de aplicaciones, no sólo para la web,
más sencillas gracias al patrón MVC modi cado, y una
jerarquía que conecta los componentes de forma que ca-
da parte es accesible mediante variables "$padre”. Está
desarrollado en PHP 4 y ∧, de forma que es compatible
con la mayor parte de los servidores web. Ha sido proba-
do en numerosos proyectos reales. Es posible usarlo para
conectar con sistemas gestores de bases de datos como
MySQL, PostgreSQL, Oracle o Microsoft SQL Server.
Se puede ejecutar por tanto en plataformas *nix (Unix,
Linux, etc.) como en plataformas Windows. Hace uso
de varios lenguajes de programación:HTML, XHTML,
CSS, JavaScript, PERL(CGI), AJAX, PHP, Gtk y XML
Se llama zen PHP porque no sólo “simpli ca”mucho
el código sino que es llevado con la máxima concentra-
ción y poco a poco, cada vez más lejos, en cada ver-
sión,automáticamente, instantáneamente se van generan-
do nuevas líneas de trabajo...

205.2 ¿Qué ventajas ofrece

zenphp?
• Separación de las capas de información en 3 fases
bien distinguidas: diseño de la aplicación, comuni-
cación con el sistema y resultados visibles.

• Sencillez y“luminosidad”del código, comprensible

de un vistazo y simple.

• Realización de tareas complejas,pretratamiento de

datos de entrada/salida,etc.

• Posibilidad de automatización para AJAX

• Generadores de código, formularios, plantillas, con-
sultas,etc.

3∩∪
205.3. ORIGEN DEL TEXTO Y LAS IMÁGENES, COLABORADORES Y LICENCIAS 3∩9

205.3 Origen del texto y las imágenes, colaboradores y licencias

205.3.1 Texto
• Programación Fuente: [Link] Colaboradores: Youssefsan, EL Willy, So-
niautn, Sabbut, Moriel, Josmanbernal, Sauron, ManuelGR, Sanbec, Javier Carro, Dodo, Ejmeza, Fortran~eswiki, Ascánder, Rsg, Tostadora,
Tano4∧9∧, Fernandomirandamuro, Jecanre, Pablomdo, Cinabrium, Porao, Elsenyor, Renabot, Richy, FAR, Mejiad, Mendocino, Digigalos,
Sicarul, Airunp, Edub, Emijrp, Magister Mathematicae, Viko~eswiki, Guanxito, Murven, Unf, Mikel Gómez, Dromero, Yrbot, Vitamine,
BOTijo, Ivancp, GermanX, Jyon, Gaijin, Quiron, The Photographer, Lucascr, Jesuja, Tigerfenix, Eduardo Lima, Gfitz, Morza, Ciencia Al
Poder, Cheveri, Chlewbot, Tomatejc, Zanaqo, Rbonvall, Electrican MV, Jstitch, BOTpolicia, Qwertyytrewqqwerty, CEM-bot, Jorgelrm,
Krli2s, Laura Fiorucci, Chabacano, [Link], Retama, Rosarinagazo, Antur, Dorieo, Thijs!bot, Esoya, Alvaro qc, Jonpagecr, RoyFocker,
Isha, Rrmsjp, JAnDbot, Jugones∧∧, Cmontero, Kved, Pmisiones, Mansoncc, Bboccioz, NaBUru3∪, Humberto, Netito∩∩∩, Xsm34, Marvels-
hine, Nioger, Chabbot, Pólux, Biasoli, AchedDamiman, Snakeyes, Technopat, Matdrodes, Autonomia, Fernando Estel, Elabra sanchez, Lic.
Armando, BlackBeast, Shooke, Lucien leGrey, Sdfk, Dinopmi, Gerakibot, SieBot, Ctrl Z, Cousteau, Ortellado, Manwë, Correogsk, 3xxx,
Mafores, Yonseca, Tirithel, Jarisleif, Javierito92, Amorde2, Eduardosalg, Leonpolanco, Botito∩∩∩, Petruss, Aliuk, Moucaisius, JMDC,
UA31, SergioN, AVBOT, David0∪11, Diegusjaimes, IATG, Jj orescueto, CarsracBot, HerculeBot, Arjuno3, Andreasmperu, Luckas-bot,
Jaromero, Cata11, Roinpa, Bifus, Jotterbot, Vitucho300∧, ArthurBot, SuperBraulio13, Xqbot, Jkbw, NeoTommy, Serolillo, Pedrovicen-
terosero, Voetius, Chester2∨9, Albertochoa, Torrente, Botarel, BenzolBot, Stu y, MauritsBot, TigreVMMM, MAfotBOT, Gusbelluwiki,
Linux∨∧, RedBot, KamikazeBot, Slashcsc, Dinamik-bot, Angelito∩, Ripchip Bot, Tarawa1943, GrouchoBot, EmausBot, Savh, HRoestBot,
Sergio Andres Segovia, Fabian Rod, Rubpe19, Jcaraballo, ChuispastonBot, Merryt, Waka Waka, WikitanvirBot, Upc, RobotEducativo,
Renly, Communities, AvicBot, Sebrev, Travelour, Acratta, Brainup, LlamaAl, EnzaiBot, Helmy oved, DavidUlquiorra, MaKiNeoH, Ova-
llesoft, [Link], Ivanretro, Addbot, Balles2∨01, Advarg, Tenganmemiedo, Qwerty asdfg zxcvb, Eliazibh Bojorquez, MrCharro,
Jarould, Eurodyne, Sapristi1000, [Link] y Anónimos: 43∩
• Portal:Programación Fuente: [Link] Colaboradores: Emijrp,
Jesuja, Bienchido, AchedDamiman, VolkovBot, Shooke, PaintBot, KLBot2, MetroBot, Addbot y Anónimos: 1
• & Fuente: [Link] Colaboradores: Josemoya, Rosarino, Cookie, Tano4∧9∧, Rodrigouf,
M3c4n0, Edupedro, Jo-Con-El, Taichi, Emijrp, LP, Kenedhor, Orgullobot~eswiki, RobotQuistnix, Platonides, Caiserbot, Amadís, BOT-
Superzerocool, YurikBot, Martingala, Armin∩∨, KnightRider, Kazahana, No sé qué nick poner, Ephraim33, DivByZ, Faelomx, Futbole-
ro, Cerato, SaulPerdomo, Qwertyytrewqqwerty, Nethac DIU, CEM-bot, Jorgelrm, Al2, Corbu, Araltor, Penquista, Rastrojo, Antur, D.o,
Thijs!bot, Zigurat, JAnDbot, Mansoncc, TXiKiBoT, Aalvarez12, Humberto, Guillermo D.~eswiki, Rei-bot, Chabbot, Pólux, Bucephala,
Aibot, Vicdesan, Technopat, Lahi, DRMProd, Matdrodes, RandomJambo, Muro Bot, Edmenb, SieBot, Bigsus-bot, BOTarate, Ceat ∩00,
Greek, Tirithel, Farisori, Eduardosalg, TronaBot, Petruss, Osado, Purbo T, Abajo estaba el pez, AVBOT, LucienBOT, Marifernan, Lam-
psako, Luckas-bot, ∨∩wkii, Almabot, Jkbw, Cally Berry, TobeBot, Alph Bot, GrouchoBot, AVIADOR, WikitanvirBot, Serlack, KLBot2,
Biblio lotranstornado, Stramin, Ralgisbot, Thegastiinthedark, Jarould, ~Expresses life y Anónimos: ∨∪
• Acoplamiento secuencial Fuente: [Link] Colaboradores: Kavanagh,
Héctor Guido Calvo, Invadibot, Dalbela y Addbot
• Adobe Director Fuente: [Link] Colaboradores: BOT-Superzerocool, BOTijo,
FedericoMP, Sinopsis, Boja, Faelomx, BOTpolicia, Mampato, CEM-bot, Laura Fiorucci, Muro de Aguas, JoseA, Rei-bot, Pólux, Vol-
kovBot, Muro Bot, SieBot, Pedro Felipe, Ivgarci, Mit3d, [Link], Alexbot, Orgullo Illustrator, Spider pig, BotSottile, AVBOT, Die-
gusjaimes, MelancholieBot, Luckas-bot, Wikisilki, Dangelin∧, Ortisa, AstaBOTh1∧, EmausBot, Grillitus, Ru os, MerlIwBot, KLBot2,
Elvisor, Helmy oved, Ralgisbot, Digmin3 y Anónimos: 19
• Anidamiento (informática) Fuente: [Link] Colaboradores:
Muro Bot, Poco a poco, Dangelin∧, MaxBech19∩∧, Pata sik, EmausBot, KLBot2, Ginés90, Harpagornis y Anónimos: 3
• Antipatrón de diseño Fuente: [Link] Colaboradores: Pa-
coqueen, Vanbasten 23, Rosarino, Fortran~eswiki, Ascánder, Tostadora, Porao, Benjavalero, Renabot, RobotQuistnix, YurikBot, Ger-
manX, KnightRider, Dmlambea~eswiki, Cad, Zoid, CEM-bot, Davius, Thijs!bot, Yeza, Kavanagh, [Link], Pvent, Kijote, PJTraill,
VolkovBot, [Link], Technopat, Lauramcastro, SieBot, Ozewi, Pablo323, BetoCG, Zeliq, BotSottile, Diegusjaimes, Amirobot, Ptbot-
gourou, Vic Fede, Xqbot, Silvioq, AstaBOTh1∧, Enrique Cordero, ArwinJ, Xiidarkevil, EmausBot, ZéroBot, WikitanvirBot, MovGP0,
KLBot2, MetroBot, Addbot y Anónimos: 44
• Archivo de cabecera Fuente: [Link] Colaboradores: Sabbut, Basquetteur,
CEM-bot, BlackSalamander, Cratón, Isha, JAnDbot, TXiKiBoT, Phirosiberia, Muro Bot, MaSt, Poco a poco, Kroji, MastiBot, Angel GN,
DumZiBoT, Luckas-bot, Marioxcc, SuperBraulio13, Xqbot, Jkbw, Panderine!, KamikazeBot, [Link], Sergio Andres Segovia, Grillitus,
Hoo man, MerlIwBot, Elvisor, Addbot y Anónimos: 1∧
• Aserción (informática) Fuente: [Link] Colaboradores:
Robbot, BOT-Superzerocool, GermanX, Escarbot, Fabeirojorge, Carmin, Poco a poco, MystBot, Alph Bot, Waeswaes, EmausBot, ZéroBot,
KLBot2, Biblio lotranstornado, Elvisor y Anónimos: ∧
• Automatización de tareas Fuente: [Link] Colaboradores:
CF, Walking Mind, Technopat, BlackBeast, PaintBot, M S, Farisori, Diegusjaimes, DiegoFb, Victor carmonag, Jkbw, Khavas, RodolfoLay
y Anónimos: ∧
• Base de código Fuente: [Link] Colaboradores: GermanX, CEM-bot y
KLBot2
• Bean Fuente: [Link] Colaboradores: Pilaf, Sunsinron, Robotico, Soulreaper, Taichi, FlaBot,
Rosarinagazo, Desert∨9, Kved, VolkovBot, Carmin, Umondri, PatruBOT, Canyq, Goica, Dark Bane, HRoestBot, ChuispastonBot, Addbot
y Anónimos: 2∨
• Beta tester Fuente: [Link] Colaboradores: SimónK, Digigalos, FlaBot, Varano, Vita-
mine, GermanX, Smrolando, Nethac DIU, CEM-bot, Marianov, Madoks, JAnDbot, TXiKiBoT, Krun00, Mstreet linux, Muro Bot, Fadesga,
UA31, AVBOT, MastiBot, Ezarate, Arjuno3, Hoenheim, SuperBraulio13, Jkbw, Ignasi Gorina, Irak Gaitán, Addbot, BOTito y Anónimos:
10
3∪0 CAPÍTULO 205. ZENPHP

• Bifurcación (sistema operativo) Fuente: [Link] Cola-

boradores: Yearofthedragon, Niqueco, Chobot, FlaBot, Qwertyytrewqqwerty, TXiKiBoT, VolkovBot, Shooke, PaintBot, Diegusjaimes,
Ptbotgourou, DiegoFb, Kizar, ZéroBot, ChessBOT, MerlIwBot, KLBot2, Martin Ariel Ramirez, Porrasporrasporras y Anónimos: 11
• Binding Fuente: [Link] Colaboradores: Robbot, Loco0∪∧, Airunp, Genba, Yrbot, Beto29,
CEM-bot, Thijs!bot, Gusgus, Segedano, Aika~eswiki, Synthebot, Muro Bot, Farisori, Jerowiki, Diamondland, MerlIwBot, KLBot2, Elvisor,
Addbot, Hipocamp1∧ y Anónimos: ∪
• Bloqueo mutuo Fuente: [Link] Colaboradores: Sabbut, Moriel, Sauron, Vanbas-
ten 23, Dodo, Sms, Niqueco, Hari Seldon, Rembiapo pohyiete (bot), RobotQuistnix, Francosrodriguez, Superzerocool, Caiserbot, Yu-
con, Yrbot, BOT-Superzerocool, Martincarr, YurikBot, GermanX, Gothmog, Tigerfenix, Eskimbot, CEM-bot, Isha, Dogor, JAnDbot,
TXiKiBoT, Rei-bot, NaSz, VolkovBot, Matdrodes, Estirabot, Leonpolanco, Alexbot, BotSottile, AVBOT, Luckas-bot, Amirobot, Jkbw,
AstaBOTh1∧, D'ohBot, PatruBOT, Waeswaes, EmausBot, ZéroBot, Elvisor, Legobot, Ideator 2.0 y Anónimos: 21
• Bodyshopping Fuente: [Link] Colaboradores: SimónK, Yrbot, Varano, Olea,
CEM-bot, Tortillovsky, Isha, Phirosiberia, Rolloqui, Muro Bot, Diegusjaimes, Marcomogollon, Caritdf, Grillitus, Johnbot, Elvisor y Anó-
nimos: 12
• BrookGPU Fuente: [Link] Colaboradores: Boticario, CEM-bot, Montgomery, Fili-
prino, VolkovBot, Alexbot, Krysthyan, AVBOT, Bethan 1∪2, In aBOT, MerlIwBot, KLBot2, Elvisor, EduLeo y Anónimos: 3
• Caja blanca (sistemas) Fuente: [Link] Colaboradores: Carutsu, Xexito,
Cinevoro, Robertorp, Espilas, Nicop, Farisori, VkN, UA31, AVBOT, Angel GN, KLBot, MerlIwBot, KLBot2, YeltFlor y Anónimos: 11
• Caja negra (sistemas) Fuente: [Link] Colaboradores: Oblongo, Jesuja,
Davius, Tortillovsky, Amire∪0, JAnDbot, VolkovBot, Synthebot, Muro Bot, Feministo, Loveless, [Link], XalD, Cyborg ar, Alejandro
Lodes, UA31, AVBOT, Diegusjaimes, CarsracBot, Luckas-bot, Ptbotgourou, DiegoFb, Botarel, MondalorBot, PatruBOT, Dinamik-bot,
Angelito∩, Foundling, Wikiléptico, EmausBot, HRoestBot, WikitanvirBot, MerlIwBot, KLBot2, TeleMania, Elvisor, MahdiBot, AS-W,
BOTito, Jarould, Crystallizedcarbon y Anónimos: 33
• CamelCase Fuente: [Link] Colaboradores: Robbot, Miuler, Ascánder, Fernandomi-
randamuro, Fleam, Emijrp, Rembiapo pohyiete (bot), Aadrover, RobotQuistnix, Maquiavelo, Yrbot, Bai to, BOT-Superzerocool, FlaBot,
BOTijo, Eskimbot, Floppy3, Rei-bot, Biasoli, VolkovBot, Technopat, Chechurisk, Muro Bot, SieBot, Loveless, Mrfoxtalbot, Jaontiveros,
Alexbot, MastiBot, Luckas-bot, MystBot, Marioxcc, Vivaelcelta, Invelg, Yago AB, EmausBot, David camelo, Grillitus, Albertojuanse,
WikitanvirBot, KLBot2, Allan Aguilar, Makecat-bot, Addbot y Anónimos: 2∪
• Caml Fuente: [Link] Colaboradores: UAwiki y Brivadeneira
• Cierre de exclusión mutua Fuente: [Link] Colaboradores:
Periku, Boticario, Yrbot, Martincarr, YurikBot, GermanX, CEM-bot, Thijs!bot, Dogor, CommonsDelinker, VolkovBot, Muro Bot, Racso,
STBot~eswiki, Luckas-bot, Amirobot, Diogeneselcinico42, EmausBot, WikitanvirBot, Dexbot, Legobot y Anónimos: 3
• Clase utilidad Fuente: [Link] Colaboradores: Matiasmoreno, Muro Bot, Gizbot y
Anónimos: 1
• [Link] Fuente: [Link] Colaboradores: Eloy, CEM-bot, Beaire1 y Anónimos: 1
• CMake Fuente: [Link] Colaboradores: Emijrp, Anonimato1990, El Pantera, Menthalo,
UA31, Billinghurst, [Link], Paroga, KLBot2, Conopo, Silentter y Anónimos: ∪
• Codecademy Fuente: [Link] Colaboradores: Eloy, CEM-bot, CommonsDelinker,
Fremen, TheDarkFear, EmausBot, Grillitus, Invadibot, Flashlack, Harry Canyon, Quethzel, Jaod9∪ y Anónimos: 4
• Código cerrado Fuente: [Link] Colaboradores: Pino, Joseaperez, Dodo,
Ejrrjs, Ascánder, Sms, Yakoo, JCCO, Digigalos, Hari Seldon, RobotQuistnix, FlaBot, Usrwp, AtilaElHuno, Gabriel Acquistapace, Thijs!bot,
JAnDbot, TXiKiBoT, Rei-bot, AlnoktaBOT, Shooke, Muro Bot, SieBot, PaintBot, Javierito92, Marcecoro, UA31, X-DNA-X, DiegoFb,
MerlIwBot, Addbot, Balles2∨01 y Anónimos: 12
• Código compilado Fuente: [Link] Colaboradores: CEM-bot, Neti-
to∩∩∩, AchedDamiman, Muro Bot, PaintBot, Farisori, DiegoFb, Jarould, Ivan santillo y Anónimos: 1
• Código mutante Fuente: [Link] Colaboradores: Hari Seldon, Tomatejc,
Sirpuppet, AchedDamiman, VolkovBot, Muro Bot, PaintBot, BOTarate, Farisori, DiegoFb, Jorge c2010, Addbot y Anónimos: 2
• Código objeto Fuente: [Link] Colaboradores: Oblongo, Moriel, Ma-
nuelGR, Sms, Rsg, Rembiapo pohyiete (bot), RobotQuistnix, Yrbot, Bai to, Icvav, GermanX, Jesuja, Aleator, Chabacano, Escarlati,
Thijs!bot, TXiKiBoT, Gacq, Rei-bot, Biasoli, Shooke, AlleborgoBot, Muro Bot, Loveless, BOTarate, Marodok, AVBOT, Arjuno3, Luckas-
bot, Kender00, RedBot, PatruBOT, KamikazeBot, GrouchoBot, EmausBot, Grillitus, ChuispastonBot, Legobot, DarkBlueZV, Jarould y
Anónimos: 21
• Ofuscación Fuente: [Link] Colaboradores: JMPerez, Nuen, Thijs!bot, Mat-
drodes, Alejandroadan, BenzolBot, Gusbelluwiki, Acastiello, Elvisor, Addbot, Comnetgt y Anónimos: 14
• ColdFusion Fuente: [Link] Colaboradores: Pino, Tostadora, Benjavalero, Boticario,
Yrithinnd, Taichi, RobotQuistnix, Yrbot, FlaBot, GermanX, The Photographer, Aladiah, FedericoMP, Kekkyojin, Mrpollo, Faelomx,
CEM-bot, Thijs!bot, Ernesto r., JAnDbot, C4rlitoz, Tuliopa, Spa karmona, TXiKiBoT, AlnoktaBOT, Shinji14, AlleborgoBot, Muro Bot,
Bucho, Rrrafa, BotMultichill, SieBot, Loveless, Abrenoite, WikiBotas, Alexbot, LucienBOT, Emiliot11, HerculeBot, Nallimbot, Cristian-
park, Ptbotgourou, Xqbot, TiriBOT, Alph Bot, EmausBot, KLBot2, LlamaAl, Elvisor, Legobot y Anónimos: 23
• Coloreado de sintaxis Fuente: [Link] Colaboradores: Oblongo, Murphy
era un optimista, Barcex, Ictlogist, RobotQuistnix, Icvav, Eloy, Antur, Diosa, Isha, JAnDbot, Humberto, Biasoli, Dusan, VolkovBot, Alle-
borgoBot, Muro Bot, SieBot, Pan con queso, MenoBot, Heallo, AVBOT, MastiBot, Luckas-bot, WikiDreamer Bot, Xqbot, Josemiguel93,
Adryitan, EmausBot, Guarddon, Grillitus, Diego Moya, Gcosta∪∩, Draug, Legobot y Anónimos: 1∨
205.3. ORIGEN DEL TEXTO Y LAS IMÁGENES, COLABORADORES Y LICENCIAS 3∪1

• Comentario (informática) Fuente: [Link] Colaboradores:

Joseaperez, Corso, Jachguate, Emijrp, Adrruiz, Gfitz, Faelomx, CEM-bot, Isha, Gaius iulius caesar, Xosema, Netito∩∩∩, VolkovBot, Mat-
drodes, Drinibot, BOTarate, Eduardosalg, Poco a poco, Ucevista, LucienBOT, MastiBot, TheDarkFear, Diegusjaimes, MelancholieBot,
Luckas-bot, Gperaltascura, SuperBraulio13, Jkbw, Kyng, Rubinbot, Desiben, Waeswaes, Edslov, EmausBot, Adri12∪, Grillitus, Wikitan-
virBot, Metrónomo, KLBot2, Invadibot, Elvisor, DarkBlueZV y Anónimos: 1∧
• Compatibilidad (informática) Fuente: [Link] Colabora-
dores: Elwikipedista, Emijrp, Yrbot, BOTijo, Gejotape, Dmitri Lytov, Isha, Pólux, AchedDamiman, Technopat, Elabra sanchez, Shooke,
Muro Bot, Fadesga, Farisori, Botito∩∩∩, Jcaraballo, MerlIwBot, Elvisor, Addbot y Anónimos: 12
• Competición Internacional Universitaria ACM de Programación Fuente: [Link]
Internacional_Universitaria_ACM_de_Programaci%C3%B3n?oldid=∪∩4∨2212 Colaboradores: Sabbut, Sanbec, Boticario, BOT-
Superzerocool, Jgaray, Banderas, CEM-bot, Ingenioso Hidalgo, Xxim, Xavigivax, Pólux, Atomic 00∩, AlleborgoBot, Loblesa, BOTarate,
Botito∩∩∩, MastiBot, Diegusjaimes, Luckas-bot, MystBot, Xqbot, TobeBot, ZéroBot, Elvisor, ShersonLazaro, Legobot, Cbretana,
LucasMCG y Anónimos: 31
• Computación parasitaria Fuente: [Link] Colaboradores: Ae-
veraal, CEM-bot, Argaldo, Muro Bot, KLBot2 y Anónimos: 1
• Conectiva lógica Fuente: [Link] Colaboradores: Niceforo, Dodo, As-
cánder, Julian Colina, Xenoforme, Superzerocool, Caiserbot, Memiux, Yrbot, GermanX, JAGT, Jesuja, Er Komandante, Rdds, Ivan ro-
mero, CEM-bot, Damifb, Davius, Julian Mendez, Zufs, TXiKiBoT, MONIMINO, Snakeyes, Matdrodes, Elabra sanchez, Mary dream,
Edmenb, SieBot, Francisco Mochis, Drinibot, Jarisleif, Dnu∩2, Alejandrocaro3∧, AVBOT, Cegik, Diegusjaimes, Davidgutierrezalvarez,
Arjuno3, Dangelin∧, Equiman, Luis Felipe Schenone, ArthurBot, SuperBraulio13, Xqbot, Jkbw, GNM, Danke∩, Igna, Foundling, Grillitus,
Gusama Romero, Acratta, Addbot, Anderper, Jarould, TheGamerSexy y Anónimos: ∨4
• Con guración regional Fuente: [Link] Colaboradores: Fae-
lomx, Thijs!bot, Biasoli, Fadesga, Nallimbot, ArthurBot, Xqbot, Born2bgratis, Dinamik-bot, EmausBot, Grillitus, JackieBot, Wikitan-
virBot, Makecat-bot y Addbot
• Conteo de referencias Fuente: [Link] Colaboradores: Niqueco, Pi-
nar~eswiki, Thijs!bot, Muro Bot, SieBot, Luckas-bot, DiegoFb, Hoenheim, D'ohBot, Hprmedina, Dinamik-bot, EmausBot y KLBot2
• Convención de Nombres (Programación) Fuente: [Link]
B3n)?oldid=∪∩413∩49 Colaboradores: BOT-Superzerocool, Bngs, FrescoBot, Grillitus, KLBot2, MetroBot, Elvisor, Omixam, JSuarezB,
BenjaBot y Anónimos: 4
• Cracking (software) Fuente: [Link] Colaboradores: Robbot, Alakasam,
JAnDbot, ARNT, TXiKiBoT, ColdWind, Xvazquez, Biasoli, Poco a poco, MystBot, Jotterbot, Xqbot, Kizar, Sermed, Alph Bot, ChessBOT,
Grillitus, WikitanvirBot, KLBot2 y Damianiencowiki
• Cuaderno de carga Fuente: [Link] Colaboradores: Tomatejc, Boja, CEM-
bot, Montgomery, Resped, Muro Bot, HUB y Anónimos: 3
• Curri cación Fuente: [Link] Colaboradores: Rbonvall, Rosarinagazo, SI-
TOMON, Nolaiz, VolkovBot, Loveless, BOTarate, Poco a poco, OMFGROFLMAO, Angelito∩, ChuispastonBot, Elvisor, Addbot y Anó-
nimos: 1
• Código enhebrado Fuente: [Link] Colaboradores: GermanX, Cine-
voro, Shooke, Muro Bot, ZéroBot, Elvisor, Addbot y Anónimos: 1
• Código inalcanzable Fuente: [Link] Colaboradores: CEM-bot, Ci-
nevoro, Waeswaes, Grillitus, Invadibot, Rotlink y Addbot
• Código muerto Fuente: [Link] Colaboradores: Sabbut, GermanX, CEM-
bot, Angelito∩, Waeswaes, Invadibot, Addbot y Anónimos: 1
• Código redundante Fuente: [Link] Colaboradores: CEM-bot,
Waeswaes, Grillitus, Invadibot y Addbot
• Dato Fuente: [Link] Colaboradores: PACO, Moriel, Sauron, JorgeGG, Pilaf, Angus, Wi-
ki Wikardo~eswiki, Bigsus, Interwiki, Cookie, Tano4∧9∧, Robotito, Dianai, Jpodjarny, Porao, Alphabravotango, Digigalos, Soulreaper,
Hispa, Airunp, Taichi, Emijrp, RobotQuistnix, Alhen, Chobot, Yrbot, Bai to, Vitamine, .Sergio, YurikBot, Icvav, KnightRider, The Pho-
tographer, Jesuja, Maldoror, Er Komandante, Filipo, Siabef, Alexquendi, Locutus Borg, BOTpolicia, Klondike, Damifb, Laura Fiorucci,
-jem-, Davius, Antur, Montgomery, Escarbot, CED, RoyFocker, IrwinSantos, Isha, Egaida, Dogor, Gusgus, JAnDbot, Ana wiki, TXi-
KiBoT, Humberto, Idioma-bot, Pólux, Biasoli, AchedDamiman, Cinevoro, VolkovBot, Technopat, Mr. Benq, Matdrodes, Lucien leGrey,
Edmenb, Racso, Dodecaedro, SieBot, Manwë, Correogsk, Aleposta, Tirithel, Jarisleif, Javierito92, Marcecoro, HUB, Nicop, Farisori,
Eduardosalg, Leonpolanco, Alejandrocaro3∧, Furti, Açipni-Lovrij, UA31, AVBOT, David0∪11, Alejandro bera, MastiBot, MarcoAure-
lio, NjardarBot, Diegusjaimes, CarsracBot, HerculeBot, Arjuno3, Andreasmperu, Luckas-bot, SuperBraulio13, Jkbw, Igna, Botarel, SUL,
MondalorBot, TobeBot, Vubo, Leugim19∩2, PatruBOT, Dinamik-bot, Duuk-Tsarith, Tarawa1943, Foundling, Edslov, EmausBot, Savh,
AVIADOR, MercurioMT, Jcaraballo, Waka Waka, WikitanvirBot, Richardedu, Rezabot, MerlIwBot, JABO, Laencilclopedialibre, Deivis,
Travelour, Vichock, Gusama Romero, Hcurti, Acratta, Mega-buses, Érico, Santga, Helmy oved, Syum90, Faustinogay, Addbot, Balles2∨01,
Chivogay, Edergay, Rancho gudy, JacobRodrigues, CamiloBer04, Joyaso123, Jarould, Matiia, Raelth, Fearinghealer, Gaby Medina Murillo,
JuanCalamidad, Ariel034∧, Losperritos, Fernando2∪12l y Anónimos: 2∪∨
• Depuración de programas Fuente: [Link] Colaboradores:
Kristobal, Ejrrjs, Sms, Rsg, Felipealvarez, Renabot, Rembiapo pohyiete (bot), Wastingmytime, OMenda, Orgullobot~eswiki, Chobot,
Yrbot, Bai to, YurikBot, GermanX, KnightRider, CEM-bot, ARHEKI, Thijs!bot, JAnDbot, Gsrdzl, Guirrohl, Biasoli, Gmarinp, Muro
Bot, [Link], SieBot, PaintBot, Djblack!, Facucario, Alejandrocaro3∧, Pedromanchon, Diegusjaimes, Luckas-bot, Amirobot, Xqbot,
Jkbw, Rocafort∪, BOTirithel, Kizar, Waeswaes, EmausBot, HRoestBot, Grillitus, WikitanvirBot, Lexinerus, MerlIwBot, Erick Capslock,
Legobot, Addbot, Jarould, Gregory serrata y Anónimos: 23
3∪2 CAPÍTULO 205. ZENPHP

• Desarrollador de software Fuente: [Link] Colaboradores: SimónK,

Herenvardo, Vitamine, BOTijo, CEM-bot, Thijs!bot, JAnDbot, Antipatico, TXiKiBoT, Rei-bot, VolkovBot, Shooke, Lucien leGrey, Bot-
Multichill, Loveless, Marcecoro, DragonBot, BetoCG, Nallimbot, DiegoFb, ArthurBot, Xqbot, AnselmiJuan, PatruBOT, EmausBot, Co-
cuBot, MerlIwBot, KLBot2, Wrotetool, Legobot, Hazel.rojas9∨, Jarould y Anónimos: 11
• Desarrollo en cascada Fuente: [Link] Colaboradores: Ejmeza, Ejrrjs,
Richy, FAR, Edub, Yrithinnd, Orgullobot~eswiki, Penyaskito, Unf, Alhen, Superzerocool, Yrbot, Vitamine, Icvav, GermanX, JRGL, Ke-
pler Oort, Axxgreazz, CEM-bot, Osepu, Fsd141, Thijs!bot, Jonpagecr, Mahadeva, Isha, Ppedrodom, Infovoro, TXiKiBoT, Humberto,
Decorrea, Pólux, VolkovBot, WarddrBOT, Technopat, Jose gueredo, Matdrodes, DJ Nietzsche, SieBot, Irtusb, Greek, Jossue1309∪∩,
Marcecoro, Feperozpo, Nicop, UA31, AVBOT, SpBot, Diegusjaimes, Bethan 1∪2, MelancholieBot, Luckas Blade, Tremal Naik, Arjuno3,
Luckas-bot, Nallimbot, Roinpa, Markoszarrate, Barteik, Gacpro, ArthurBot, SuperBraulio13, Jkbw, Torrente, Jesua300∧, PatruBOT, Ta-
rawa1943, GrouchoBot, EmausBot, Africanus, Grillitus, Almogo, Alexandermark, WikitanvirBot, Lcsrns, MerlIwBot, Ayaita, Renciw,
Adribeex, Harpagornis, Elvisor, Asqueladd, Bolivarista, Rotlink, Legobot, Melgar22, Bordierrez, Jedijor14, Julianromera, IsaacReal, Jon-
xa22, Ikeri122 y Anónimos: 20∨
• Desarrollo en espiral Fuente: [Link] Colaboradores: PACO, Vanbasten 23,
Sanbec, Dodo, Rikaaii, Cookie, Murphy era un optimista, Msxgopr, Cinabrium, Balderai, Kordas, Taragui, Pezezin~eswiki, Airunp, Rem-
biapo pohyiete (bot), Orgullobot~eswiki, RobotQuistnix, LarA, Caiserbot, Yrbot, Oscar ., BOTijo, Martingala, GermanX, The Photograp-
her, Galle, Siabef, Tamorlan, CEM-bot, Meltryth, Ignacio Icke, Rafa sanz, GuiXu, Retama, Osepu, EcLiB, Thijs!bot, Escarbot, RoyFocker,
Isha, Kved, Yamaneko, Infovoro, Muro de Aguas, Netito∩∩∩, Xsm34, Pólux, Javierxar, VolkovBot, Technopat, Jose gueredo, Matdrodes,
Shooke, Muro Bot, Bucho, Jmvgpartner, SieBot, PaintBot, Gospelepsog, Cumanacr, Leonpolanco, Caucas, SergioN, AVBOT, Adelpine,
Diegusjaimes, Arjuno3, Kmilovc, Xqbot, Jkbw, Botarel, Ereguero, ErikvanB, Jorge c2010, Savh, Grillitus, Bpk, MerlIwBot, Thehelpfulbot,
Ginés90, Adribeex, Johnbot, MarioCar∪∪, Legobot, Nito1∪, Thawk101, Jarould y Anónimos: 142
• Desarrollo iterativo y creciente Fuente: [Link] Colaboradores:
Vanbasten 23, Yrbot, Varano, Martingala, CEM-bot, Osepu, Isha, Corvocativo, LeinaD natipaC, Redjhawk, Technopat, Jose gueredo,
BlackBeast, Muro Bot, Botito∩∩∩, UA31, Diegusjaimes, Bloomy, DixonDBot, Foundling, Grillitus, Davidarturo21, MerlIwBot, AvicBot,
Addbot, Farnhey, Nathy2∪93, Dominic1∧93, LinkYanela, Elnico2∩∪∩, Gustavosanais y Anónimos: 2∪
• Detección dinámica de invariantes Fuente: [Link]
∧00∨031∩ Colaboradores: El Pantera
• Diagrama de colaboración Fuente: [Link] Colaboradores:
Tano4∧9∧, Santiperez, Er Komandante, Dhidalgo, PaintBot, Tirithel, Mutari, Javierito92, Kikobot, Alejandro Lodes, AVBOT, Ialad, Die-
goFb, Wikante, Hoenheim, Botarel, Allforrous, EduLeo y Anónimos: 3∪
• Diagrama de ujo Fuente: [Link] Colaboradores: JIPumarino, JorgeGG, We-
sisnay, Angus, Comae, Rosarino, Dodo, SimónK, Rsg, Cookie, Tostadora, Julian Colina, Barcex, DanielCardaci, Gengiskanhg, Porao,
Schummy, Fmariluis, Chewie, FAR, Digigalos, Boticario, Soulreaper, Petronas, Hispa, Airunp, JMPerez, Edub, Taichi, LeCire, Magister
Mathematicae, Dem, Murven, RobotQuistnix, Unf, Alhen, Akhram, Ryavara, Jomra, Caiserbot, Yrbot, Amadís, BOT-Superzerocool, Vi-
tamine, BOTijo, .Sergio, Mortadelo200∧, Beto29, Armin∩∨, Quiron, The Photographer, Jesuja, Santiperez, Ban eld, Jmencisom, Morza,
Er Komandante, Tomatejc, Filipo, The worst user, Rbonvall, Faelomx, Kn, Aleator, BOTpolicia, CEM-bot, Jorgelrm, Cantero, Laura Fio-
rucci, Ignacio Icke, Xexito, Baiji, Rastrojo, Antur, Dorieo, Montgomery, Resped, Thijs!bot, Alvaro qc, Tortillovsky, Hygiliak, Carlos t,
Diosa, Olaf Emmanuel Vargas Ramírez, RoyFocker, Gabrielmt, IrwinSantos, Ninovolador, Cratón, Isha, Gusgus, Góngora, Mpeinadopa,
Niko guti200∨, Jurgens~eswiki, JAnDbot, Ncespedes, Maria angelica, Mansoncc, Muro de Aguas, Zufs, Gsrdzl, Hidoy kukyo, Elisardojm,
Humberto, Netito∩∩∩, Jvlivs, Pólux, Rovnet, Manuel Trujillo Berges, Bucephala, AlnoktaBOT, Cipión, Cinevoro, Aibot, VolkovBot, Tech-
nopat, Jose gueredo, Galandil, Queninosta, Er l, Matdrodes, Fernando Estel, Synthebot, BlackBeast, Lucien leGrey, Luis19∩0, Vatelys,
Muro Bot, [Link], Numbo3, Comu nacho, YonaBot, Sealight, Jmvgpartner, SieBot, Mushii, Carmin, Dars∨∨∨, Cyberkender, Gur-
gut, OboeCrack, Manwë, Greek, BuenaGente, Belb, Mafores, PipepBot, Ivanics, Xqno, Tirithel, XalD, HUB, Antón Francho, Nicop,
Farisori, Eduardosalg, Leonpolanco, Pan con queso, Alejandrocaro3∧, TronaBot, Petruss, Víctor Barbero, BetoCG, PetrohsW, Toolserver,
Açipni-Lovrij, Osado, Camilo, UA31, CRISPIS, AVBOT, Elliniká, JAQG, David0∪11, Yoprideone, LucienBOT, [Link], MastiBot,
Angel GN, MarcoAurelio, Speedplus, Ezarate, Diegusjaimes, Davidgutierrezalvarez, DumZiBoT, Arjuno3, Lampsako, Luckas-bot, Spirit-
Black-Wikipedista, M41104∧, Vic Fede, Dangelin∧, Kevinprado, Nixón, MaBy2∧, ArthurBot, SuperBraulio13, Xqbot, Jkbw, Rubinbot,
Dreitmen, Plasmoid, AssassinR1∧, Annabrinn, NONYTO P∪a, FrescoBot, Ricardogpn, Janiyi, Xalox~eswiki, Igna, Botarel, Hprmedi-
na, Guillermo Axel, TobeBot, Halfdrag, RedBot, Alonsosm, Abece, Leugim19∩2, Elchelemanda, PatruBOT, KamikazeBot, Angelito∩,
Zpu,portaynach, Tarawa1943, Foundling, Miss Manzana, Axvolution, Edslov, EmausBot, Savh, AVIADOR, Edgarga, ZéroBot, HRoest-
Bot, Allforrous, Sergio Andres Segovia, Africanus, J. A. Gélvez, SAMTODOPODEROSO, Rubpe19, Emiduronte, MadriCR, Fjmejor,
Waka Waka, Banck, Movses-bot, Wednom, Antonorsi, MerlIwBot, KLBot2, TeleMania, Firewalldefender, Vagobot, AvocatoBot, Trave-
lour, Ginés90, Jhóselings, Carliitaeliza, Vetranio, LlamaAl, Érico, Elvisor, DanielithoMoya, AGEchacky, Jlurbe, Flashlack, Armonizador,
Juanitorreslp, 2rombos, Lfe-2, Leitoxx, [Link]∩, Lautaro 9∩, Tushu∪9, Richard Lyon, Sanperni, Jean∩0000, Addbot, Balles2∨01,
Kamarori, Zamaconas, Omelgarejo, Luiggypozo∩, Henrikhwolf, Jarould, Matiia, Egis∧∩, Crystallizedcarbon, Berruguin, Rodsg, Sfr∧∩0,
Fernando2∪12l, Axel froylan, Pikamas y Anónimos: 993
• Diagrama Nassi-Shneiderman Fuente: [Link] Colaboradores:
Magister Mathematicae, Jesuja, Folkvanger, VolkovBot, Urdangaray, DJ Nietzsche, Muro Bot, Anoryat, Ezarate, Arjuno3, Luckas-bot,
Ortisa, Xqbot, Jkbw, D'ohBot, MAfotBOT, PatruBOT, EmausBot, ZéroBot, Iwèr, KLBot2, Rotlink, Addbot, Marcelita torres y Anóni-
mos: 14
• Di Fuente: [Link] Colaboradores: Ascánder, FlaBot, The Photographer, Camima, Jarke,
CEM-bot, Penquista, Rastrojo, TXiKiBoT, Mercenario9∩, Muro Bot, PaintBot, Brayan Habid, Bigsus-bot, BOTarate, Desmond, Botellín,
AVBOT, David0∪11, LucienBOT, Luckas-bot, Xqbot, EmausBot, ZéroBot, Hiperfelix, Kasirbot, MetroBot, Invadibot, Ninrouter, Dexbot,
Zerabat, Addbot, Jarould y Anónimos: ∨
• Dirección de retorno Fuente: [Link] Colaboradores: GermanX,
Resped, AchedDamiman, Farisori, DiegoFb y Addbot
• Diseño estructurado Fuente: [Link] Colaboradores: GermanX, Je-
suja, CEM-bot, Jorgelrm, Developer, Jkarretero, [Link], Farisori, AVBOT, Andreasmperu, SuperBraulio13, Jarould y Anónimos: 24
205.3. ORIGEN DEL TEXTO Y LAS IMÁGENES, COLABORADORES Y LICENCIAS 3∪3

• Distancia de Damerau-Levenshtein Fuente: [Link] Cola-

boradores: Sabbut, RobotQuistnix, Pinar~eswiki, Muro de Aguas, Rapid2k1, VolkovBot, Cibi3d, CiaPan, Luckas-bot, Ptbotgourou, Die-
goFb, Addbot, Fivestarts y Anónimos: 2
• Distancia de Levenshtein Fuente: [Link] Colaboradores: Sabbut, Do-
do, Chewie, LeonardoRob0t, Orgullobot~eswiki, RobotQuistnix, Yrbot, FlaBot, YurikBot, Gaeddal, KnightRider, Tamorlan, Pinar~eswiki,
Davius, RoyFocker, Rei-bot, Dante Alighieri 19∩∧, AlleborgoBot, Luigli, Oncina, DragonBot, Amsantosr, Botito∩∩∩, DumZiBoT, Luckas-
bot, ArthurBot, Sharop, Halfdrag, Tomasdev, Sigifredo∪9, MerlIwBot, Elvisor, Addbot, Juankmx y Anónimos: 44
• DLO Fuente: [Link] Colaboradores: BOTijo, Gusgus, Anna Montull~eswiki, Elvisor y Add-
bot
• Driver Chain Manager Fuente: [Link] Colaboradores: BOT-
Superzerocool, CEM-bot, Shooke, LucienBOT, Abece y Siwel
• Dublin Core Fuente: [Link] Colaboradores: RGLago, JosebaAbaitua, Ecemaml, Ni-
queco, Wikier~eswiki, RobotQuistnix, Chobot, Yrbot, FlaBot, BOTijo, Fariel, CEM-bot, Laura Fiorucci, Rosarinagazo, Thijs!bot, Esena-
bre, Gusgus, Humberto, Rei-bot, Amisadai, Anna Montull~eswiki, Zesar∪∪, SieBot, Francisco Mochis, Wekeland, DragonBot, Alejandro-
caro3∧, Webposible, Luckas-bot, Gallega∨1, Abece, Jorge c2010, Kasirbot, Senator2029, MetroBot, Legobot, Ramonjeria y Anónimos:
21
• EAthena Fuente: [Link] Colaboradores: Joseaperez, Taichi, Lord cradet, Rastrojo, Ka-
men~eswiki, Muro Bot, PaintBot, BOTarate, Manwë, Revealer, Lockalbot, Remember the dot, DumZiBoT, Streiker~eswiki, Diego Plaza,
0scar0nOjeda, MetroBot, Elvisor, Addbot y Anónimos: 10
• Efecto Hover Fuente: [Link] Colaboradores: Akhram, Muro Bot, FBaena, Botellín,
Fidelbotquegua, DiegoFb, Marsal20, Elvisor y Anónimos: 2
• Emtp Fuente: [Link] Colaboradores: Akhram, FlaBot, CEM-bot, Ernesto Genis, Muro Bot,
Bigsus-bot, DoN vErDuGo, DiegoFb, Addbot y Anónimos: 3
• Enlace dinámico Fuente: [Link] Colaboradores: Ecemaml, Digigalos,
Genba, GermanX, Lobillo, CEM-bot, Shooke, Muro Bot, PaintBot y Anónimos: 3
• Enlace estático Fuente: [Link] Colaboradores: Digigalos, Yrbot, Ger-
manX, Jesuja, CEM-bot, Technopat, Shooke, Muro Bot, PaintBot, Omegakent y Anónimos: 3
• Enlazado Fuente: [Link] Colaboradores: Zuirdj, Digigalos, Zeioth, Platonides, Caiser-
bot, ¡EL WIKIPEDIA ES COMUNISMO!, Yrbot, GermanX, Lobillo, [Link], Muro Bot, PaintBot, Leonpolanco, AVBOT, PatruBOT
y Anónimos: 2
• Entrada chapuza Fuente: [Link] Colaboradores: Kavanagh, Waeswaes, Dalbela,
Addbot y Anónimos: 1
• Error de software Fuente: [Link] Colaboradores: 4lex, Neodraco, Moriel,
Sauron, Wiki Wikardo~eswiki, Comae, Stoni, Sms, Robotito, Sonett∩2~eswiki, Carnendil, Edub, Rembiapo pohyiete (bot), OMenda, Or-
gullobot~eswiki, RobotQuistnix, Adept~eswiki, Superzerocool, Yrbot, Bai to, Vitamine, YurikBot, GermanX, Quiron, Eskimbot, Kuanto,
Sking, Linus~eswiki, CEM-bot, CF, Thijs!bot, Bark~eswiki, Escarbot, Hanjin, JAnDbot, Jugones∧∧, Cuate∩∩, Zyder, AchedDamiman,
Aibot, Technopat, Matdrodes, ElVaka, DJ Nietzsche, BlackBeast, Gmarinp, Muro Bot, Gerakibot, SieBot, Wilfreddehelm, Bigsus-bot,
Xqno, Helenio, Poco a poco, UA31, AVBOT, MastiBot, Joaferna200∪, Diegusjaimes, DumZiBoT, Eldelgas, Arjuno3, Luckas-bot, Na-
llimbot, Markoszarrate, Yuri Grille Orce, Feedehh, Obersachsebot, Xqbot, Jkbw, Rubinbot, Josemiguel93, ChenzwBot, Igna, BenzolBot,
Alfre204, TobeBot, RedBot, PatruBOT, Alph Bot, Waeswaes, EmausBot, ZéroBot, JackieBot, ChuispastonBot, Albertojuanse, HarrySanti,
VR0, MetroBot, Invadibot, Lfgg2∨0∪, LSonico2012, Biblio lotranstornado, Minsbot, Salvador∪∧, Elvisor, Rotlink, Legobot, Addbot, Ro-
ger de Lauria, JacobRodrigues, DarkBlueZV, Das MiMaMi, Pololo gibby, Eschweiler-19∨4, Jarould, GTX-TTT, GanksLocos y Anónimos:
∩∨
• Estilo de programación Fuente: [Link] Colaboradores: Grs-
tain~eswiki, GermanX, CEM-bot, Thijs!bot, Alvaro qc, JAnDbot, TXiKiBoT, Barri, SieBot, Jpereza, AVBOT, Luckas-bot, ArthurBot,
Jkbw, EmausBot, ChuispastonBot, WikitanvirBot, Biblio lotranstornado, Elvisor, Addbot y Anónimos: 14
• Eventos del ratón Fuente: [Link] Colaboradores: Pino, Pertile, Ger-
manX, Manolo4∧∨, No sé qué nick poner, Guialven, Dani2∨, Filipo, CEM-bot, NickelSpider, Educhip, Satin, Muro de Aguas, Gustronico,
PaintBot, Marcecoro, Machucho200∩, AVBOT, DiegoFb, Elvisor, Jarould, Aramiza y Anónimos: ∩
• Exclusión mutua (informática) Fuente: [Link]
∩29∪09∧∩ Colaboradores: PACO, Pantulis, Ascánder, Robotito, Niqueco, Emijrp, RobotQuistnix, Yrbot, Martincarr, GermanX,
KnightRider, Chlewbot, Xibranc, CEM-bot, AugustoIturri, Thijs!bot, Dogor, JAnDbot, Pólux, VolkovBot, Muro Bot, SieBot, Mcapdevila,
Almabot, Rubinbot, EmausBot, ChuispastonBot, WikitanvirBot, BendelacBOT, Addbot y Anónimos: 9
• Expresión regular Fuente: [Link] Colaboradores: Moriel, JorgeGG,
Pilaf, SpeedyGonzalez, ManuelGR, Diegojc, Bigsus, Dodo, Crescent Moon, Triku, Ascánder, Sms, Tano4∧9∧, SantiagoGala, Periku,
Toto~eswiki, Digigalos, Boticario, Hari Seldon, Silvestre, Korg, Viko~eswiki, Murven, RobotQuistnix, Caiserbot, Yrbot, GermanX,
M4r10c3∧4r, George McFinnigan, Maldoror, Er Komandante, Chlewbot, UberKaeL, CEM-bot, 333, Rbrena, Damifb, Laura Fiorucci,
Alexav∪, Exos, Lcmarzulli, Resped, Cfvergara, TXiKi, JoaquinFerrero, Botones, JAnDbot, Muro de Aguas, Erwin, TXiKiBoT, Luis jun-
co, ColdWind, Humberto, Luisgulo, Rlizarralde, Vector Mike Bravo Sierra, NaSz, Fixertool, Nioger, Mcanto, Feandir, Technopat, Alvlin,
Matdrodes, Muro Bot, SieBot, Loveless, BOTarate, Macarse, Cristhiangr, Arafael, MetsBot~eswiki, Borja Sánchez, Eduardosalg, Leonpo-
lanco, [Link], Hernaldo, SilvonenBot, AVBOT, Antolingarcia, Dermot, LucienBOT, Vituzzu, Diegusjaimes, CarsracBot, Andreasmpe-
ru, Luckas-bot, QuBote, Nixón, ArthurBot, Eññe, 0x ~eswiki, Xqbot, Igna, Botarel, Joaquin medina, Jomabeal, Foundling, GrouchoBot,
Savh, ChuispastonBot, Albertojuanse, Waka Waka, Hiperfelix, KLBot2, Angelgonzg, John plaut, Óscar Becerril, Biblio lotranstornado,
Elvisor, Legobot, Francisco22∪9, Addbot, Paconaranjo, Jarould, Matiia, Egis∧∩, Enxaneta y Anónimos: 14∩
• Flag Fuente: [Link] Colaboradores: Sabbut, BOT-Superzerocool, GermanX, VolkovBot, Ale-
posta, Ptbotgourou, Rubinbot, Puck2099, ZéroBot, Grillitus, KLBot2, Addbot, JacobRodrigues, Giliofelix y Anónimos: 3
3∪4 CAPÍTULO 205. ZENPHP

• Front-end y back-end Fuente: [Link] Colaboradores: Sabbut, Robbot,

Dodo, Sms, Julgon, Elwikipedista, Armonth, Periku, MatiasBellone, Morgul~eswiki, Soulreaper, Edub, Emijrp, AlexGalisteo, Robot-
Quistnix, Caiserbot, Sotomayor, Yrbot, Bai to, FlaBot, BOTijo, YurikBot, LoquBot, C-3POrao, Gfitz, CEM-bot, Damifb, Thijs!bot,
VARGUX, Crates, ColdWind, Carlesius~eswiki, VolkovBot, Technopat, BlackBeast, Shooke, SieBot, Pablo323, LordT, Yorulito ∪9, Hoen-
heim, Bot0∪11, Hprmedina, Born2bgratis, PatruBOT, Waeswaes, Grillitus, Ser malvado, MerlIwBot, Invadibot, MadonnaFan, Legobot,
Deimagjas, Addbot, Lagoset, BenjaBot y Anónimos: 3∧
• Fuga de memoria Fuente: [Link] Colaboradores: Pino, Moriel, Sauron, Ma-
nuelGR, Triku, Niqueco, Rembiapo pohyiete (bot), Further (bot), RobotQuistnix, Chobot, Bai to, FlaBot, YurikBot, GermanX, CEM-bot,
Tute, Ignacio Icke, Thijs!bot, Botones, JAnDbot, ColdWind, Galaxy4, AlnoktaBOT, Gmarinp, Muro Bot, YonaBot, BotMultichill, Alexbot,
Luckas-bot, Amirobot, Wikante, Hprmedina, Ripchip Bot, Waeswaes, EmausBot, Grillitus, WikitanvirBot, MetroBot, Elvisor, Legobot y
Anónimos: ∩
• Generación de código Fuente: [Link] Colaboradores:
Edub, Superzerocool, GermanX, Equi, Lobillo, [Link], Eduardo Lima, CEM-bot, Joseanquiles, VolkovBot, PaintBot, Loveless, Leon-
polanco, Luckas-bot, DiegoFb, Xqbot, GrouchoBot, Legobot y Anónimos: 4
• Generador de números aleatorios Fuente: [Link]
Colaboradores: Pino, Joseaperez, Th3j0ker, Julian Colina, Anv, Pati, Airunp, Orgullobot~eswiki, LuchoX, GermanX, JRGL, Emi-
[Link], Siabef, Qwertyytrewqqwerty, CEM-bot, Thanos, Alexav∪, Pevica, FrancoGG, TXiKiBoT, Aibot, Muro Bot, Pacomegia,
Pascow, Kalverseihn, LordT, Juan Mayordomo, Raulshc, MystBot, Billinghurst, ArthurBot, Xqbot, Jkbw, Hprmedina, Ganímedes, Emaus-
Bot, ZéroBot, Esaintpierre, ChuispastonBot, Ricardo IV, Biblio lotranstornado, JYBot, Legobot, Wilson Pinto Romero, Ncomputersorg y
Anónimos: 20
• Gledplay Fuente: [Link] Colaboradores: Superzerocool, BOT-Superzerocool, Gaeddal,
JorSol, CEM-bot, Sergio. erens~eswiki, Mahadeva, [Link], Pólux, Zyder, Botellín, LucienBOT, KLBot2, Elvisor y Anónimos: ∧
• GPGPU Fuente: [Link] Colaboradores: Riviera, Rondador, Yrithinnd, RobotQuistnix,
Yrbot, GermanX, CEM-bot, Thijs!bot, CommonsDelinker, TXiKiBoT, Filiprino, VolkovBot, PolarBot, Alexaltea, DragonBot, Alexbot,
LucienBOT, Cibi3d, Luckas-bot, MKDrDre, Xqbot, SassoBot, Mctpyt, ZéroBot, Alecm∪∪, KLBot2, Elvisor, Legobot, ScotXW y Anóni-
mos: 10
• Hackathon Fuente: [Link] Colaboradores: Luisrull, Itnas19, Graciela Caldeiro, El Pan-
tera, Luckas-bot, MystBot, MartinDM, Xqbot, EmausBot, ZéroBot, HRoestBot, Sergio Andres Segovia, Grillitus, WikitanvirBot, KLBot2,
ShakMR, Cleibenzon y Anónimos: 10
• Hacker Fuente: [Link] Colaboradores: Sabbut, Lourdes Cardenal, Gmagno, SimónK, Pe-
tronas, [Link], Superzerocool, Vitamine, Olea, Baronti, The Photographer, Er Komandante, Fercufer, CEM-bot, Laura Fiorucci,
IvanStepaniuk, Montgomery, Resped, PabloCastellano, RoyFocker, JoaquinFerrero, Alakasam, Isha, JAnDbot, Mansoncc, Tucto, Cristia-
nuz12, L0biz0n, Gustronico, Humberto, Nioger, Biasoli, Technopat, BlackBeast, Muro Bot, El Pantera, Loveless, Bigsus-bot, Marcelo,
Pascow, McOil, Tirithel, Javierito92, Leonpolanco, Pan con queso, PetrohsW, Rαge, Frei sein, Osado, UA31, AVBOT, DayL∨, TheDark-
Fear, Diegusjaimes, Davidgutierrezalvarez, Malacitano, Arjuno3, Gacpro, Bloomy, Nixón, Jkbw, Rubinbot, Cybermaniac, FrescoBot, Sur-
faz, Igna, BenzolBot, AstaBOTh1∧, RubiksMaster110, Panderine!, Jakeukalane, Halfdrag, Omerta-ve, AnselmiJuan, Lustar, PatruBOT,
Ganímedes, ArwinJ, Hack txus, Isi viki, Tarawa1943, Nachosan, Foundling, Edslov, EmausBot, Savh, AVIADOR, ChessBOT, Internetsi-
nacoso, Mescaicedo, Grillitus, FL0per, Waka Waka, Warairarepano&Guaicaipuro, EdgarFabiano, Metrónomo, MerlIwBot, KLBot2, Te-
leMania, Luisllamas, UAwiki, Damianiencowiki, Frank sin Otra, Allan Aguilar, Nernix1, LlamaAl, Elvisor, Santga, ElGatoSaez, Syum90,
Leitoxx, Alberto Elvira, NeftaliYagua, Chmarkine, Balles2∨01, Romuant, Paolaricaurte, Saectar, 19Tarrestnom∨∧, Henrikhwolf, Laberin-
to1∨, Juancastellar1, [Link], Majlis99, Shernandezrg, ComaHermosa, PabloYglesias, Joeldavid rodriguez hernandez, Jarould,
Otup, FedeNab PB, SAHIBORFIRE001, Lioemiliorodriguez, MoonLeech, Hacker1234∧∨∩∪90123, Randomediterhahatroll, Hola ke azse,
Rulax Nada, [Link], Condoruser, Daniel Justiniani, Cristiantamara1999, Vladernn, Nada Nada01, YerayJackson, Juliana colorado,
Hackersjorge, Alquimista Kvothe, Ana Lucia-es genial y Anónimos: 219
• Heisenbug Fuente: [Link] Colaboradores: JKD, Yeza, Invadibot, BenjaBot y Cecetaca
• Hoja de estilo Fuente: [Link] Colaboradores: Pilaf, Daniel G., JosebaAbaitua,
Kokoo, Tomatejc, Alexquendi, Gizmo II, Especiales, Locovich, Gaius iulius caesar, Osado, Linfocito B, Jkbw, PatruBOT, Semensoy,
Diamondland, Johnbot, Elvisor, Addbot, Jarould y Anónimos: 1∧
• Hola mundo Fuente: [Link] Colaboradores: Sabbut, Pilaf, Angus, Zwobot, Comae,
Janus~eswiki, Dodo, Sms, Rsg, Opinador, Robotito, Jag2k4, Xenoforme, Jecanre, Hildergarn, Porao, [Link], Steve-o, Robotico,
Adrianbs, Kordas, Niqueco, FAR, Lmsilva, Digigalos, Quemasda~eswiki, Soulreaper, RobotJcb, JMPerez, Edub, Yrithinnd, Emijrp, Rem-
biapo pohyiete (bot), Johnbojaen, Ppfk~eswiki, Orgullobot~eswiki, RobotQuistnix, Platonides, Unf, Superzerocool, BillGatos, Chobot,
Warmize, Yrbot, Amadís, BOT-Superzerocool, Oscar ., Davidsevilla, Vitamine, Laban~eswiki, Gaeddal, Museo∪bits, Icvav, Martingala,
Zelkova~eswiki, Unaiaia, KnightRider, Acalpixca, Ban eld, Kenshin ∪∧, Aenima~eswiki, Gfitz, Skirmish~eswiki, Er Komandante, Leo-
nardocaballero, Touareg, Spc, Tomatejc, EOZyo, Siabef, Bernethe, BOTpolicia, CEM-bot, Guzman∨22, Voragine, Efegé, Xexito, Davius,
Antur, Yuanga, Programador, Thijs!bot, Nabrozidhs, Alvaro qc, RoyFocker, JoaquinFerrero, Locovich, Ninovolador, Egaida, Gusgus,
JAnDbot, Mansoncc, Muro de Aguas, Iulius19∩3, TXiKiBoT, Humberto, Infjms00, Sirpuppet, Pólux, Snakefang, Developer, Swicher, Wu-
tores, Garaizar, VolkovBot, Technopat, Zurtitto, Mstreet linux, Matdrodes, Elabra sanchez, Synthebot, ElVaka, BlackBeast, Lucien leGrey,
[Link], Muro Bot, Srbanana, BotMultichill, Zydeco, Gmol, Gerakibot, SieBot, Tucapl, Nachet∩0, Cousteau, Jjcc, Manwë, Dmontero∩,
Joelperez, Tomyleeswf, PipepBot, Tirithel, Javierito92, [Link], Socram∪∪∪∪, Minterior, Nicop, PixelBot, Leonpolanco, Sunopen,
TuEresTu, Gxlalesca, LordT, Alexbot, Manco Capac, Darkicebot, Miguelusque, Osado, Jofegibo, Mr freeze3∨0, SilvonenBot, Camilo, AV-
BOT, Louperibot, NicolasAlejandro, [Link], Diegusjaimes, Fguillen, Amirobot, Nallimbot, Diádoco, Ptbotgourou, Jotterbot, LyingB,
Cplusplus~eswiki, Byrito, Barteik, Yonidebot, Edutecno, Hytac, Ezarate∩3, DSisyphBot, Clablues, SuperBraulio13, Xqbot, Jkbw, Es carva,
Dreitmen, Helloworldextremadura, Ferbrunnen, Adryitan, Botarel, TiriBOT, Hprmedina, Halfdrag, Edgardo C, PatruBOT, KamikazeBot,
TheOrlSan, EmausBot, Sergio Andres Segovia, Bazookao, ChuispastonBot, Jereees, Antonorsi, MerlIwBot, KLBot2, AvocatoBot, Metro-
Bot, [Link], Fontedoso, Lautaro 9∩, Coins, Jarould, Pedrov∪∧∩ y Anónimos: 39∧
• Homebrew Fuente: [Link] Colaboradores: Aloriel, FlaBot, Eloy, Elrond 3, CEM-bot,
Laura Fiorucci, Twisen, Mapep, Bernard, JAnDbot, Rtalaman, TXiKiBoT, Wikiangeld, Biasoli, Technopat, AlleborgoBot, SieBot, PaintBot,
Ensada, Bigsus-bot, El bot de la dieta, Javierito92, Eduardosalg, Sidcc, Alexbot, AVBOT, SpBot, Vic Fede, DSisyphBot, Xqbot, Irbian,
205.3. ORIGEN DEL TEXTO Y LAS IMÁGENES, COLABORADORES Y LICENCIAS 3∪∧

Doble, BOTirithel, Kizar, Ravmn, PatruBOT, Sergi∩0, Nanopulga, Gerda Arendt, ASTUR2000, EmausBot, Yayolas, KLBot2, Gusama
Romero, Elvisor, Daltreck, BenjaBot y Anónimos: ∨2
• ICONIX Fuente: [Link] Colaboradores: BOT-Superzerocool, CEM-bot, CommonsDe-
linker, Technopat, Rwheimle, Ortisa, Marsal20, PatruBOT, Angelito∩, KLBot2, Invadibot, Arvelo∧92, Jarould y Anónimos: 12
• Anexo:Implementaciones de Smalltalk Fuente: [Link]
∩0∩∩∧90∩ Colaboradores: Sabbut, Tano4∧9∧, Dusan, Stickel, Shooke, Muro Bot, Carmin, MiguelAngelCaballero, Alelapenya, Lividiniski,
Elvisor y Anónimos: 1
• Anexo:Implementaciones para algoritmo de rut Fuente: [Link]
de_rut?oldid=∪∩1∨∨∨∪3 Colaboradores: Josemoya, Isha, Terinchu y Anónimos: 1
• Inanición (informática) Fuente: [Link] Colaborado-
res: Sabbut, GermanX, Thijs!bot, Mcapdevila, Angelito∩, Ripchip Bot, EmausBot, KLBot2, Nejnadusho, Angeldefuego22 y Anónimos:
2
• Indirección Fuente: [Link] Colaboradores: DMG, Glia, Muro de Aguas, Bia-
soli, Elabra sanchez, Xqbot, KLBot2, Lizbeth Melissa Appleton Tavarez y Sociologiaipa
• Infraestructura de lenguaje común Fuente: [Link]
∩004∩1∨∩ Colaboradores: Pino, Wikier~eswiki, Yrbot, BOTijo, Dangertn, Biasoli, Muro Bot, [Link], XalD, Leonpolanco,
Luckas-bot, SuperBraulio13, Canyq, Waeswaes, EmausBot, Javiermarinros, MerlIwBot, KLBot2, Dexbot y Anónimos: ∨
• Ingeniería de software Fuente: [Link] Colaboradores: Zeno
Gantner, 4lex, Caligari~eswiki, Soniautn, Sabbut, Moriel, Sauron, JorgeGG, Lourdes Cardenal, ManuelGR, Head, Lsanabria, Rosarino,
Dodo, Jonik, Jynus, Ascánder, Sms, Rsg, Cookie, Tano4∧9∧, Robotito, JavierCantero, Amana, Ograma, Rodrigouf, Cinabrium, Porao, Lo-
co0∪∧, Jabernal, Renabot, Richy, Robotkarel, Chlewey, Soulreaper, Petronas, Airunp, JMPerez, Edub, Taichi, Emijrp, Rembiapo pohyiete
(bot), Magister Mathematicae, RobotQuistnix, Platonides, Chobot, Afpineda, Yrbot, Bai to, BOT-Superzerocool, Adrruiz, Mortadelo200∧,
Martingala, GermanX, The Photographer, Tigerfenix, Ppja, Maldoror, Covi, BOTpolicia, CEM-bot, Jorgelrm, Laura Fiorucci, Eneaslabra,
Ignacio Icke, Osepu, Dou19∪∧, Davius, Govelamo, Antur, [Link], Julian Mendez, Gafotas, Genaro Rafael, Fsd141, Jonpagecr, Dio-
sa, Bot que revierte, Eidansoft, Ninovolador, Botones, Isha, Arcibel, Migp~eswiki, JAnDbot, Jugones∧∧, Antipatico, Xavigivax, Gsrdzl,
Fugarte, Humberto, Netito∩∩∩, Fixertool, Nioger, Pólux, Developer, Manuel Trujillo Berges, Biasoli, Bucephala, VolkovBot, Drever, Tech-
nopat, Jose gueredo, Galandil, Queninosta, Raystorm, MasterNoX, Belgrano, Matdrodes, Autonomia, Gmarinp, Muro Bot, Jmvgpartner,
SieBot, Ctrl Z, Carmin, Hompis, Bigsus-bot, Alben9∧∪∨, Switcher∨∩4∨, Navarroaxel, Greek, BuenaGente, Mafores, Fadesga, Arnombela,
Tirithel, Javierito92, Marcecoro, Antón Francho, Nicop, Brayan Jaimes, Eduardosalg, Qwertymith, Graimito, Leonpolanco, Pan con queso,
Alejandrocaro3∧, LordT, Furti, Poco a poco, Rαge, Camilo, UA31, SergioN, Climens, Andres romeroc, AVBOT, Flakinho, Diegusjaimes,
Davidgutierrezalvarez, CarsracBot, Arjuno3, Saloca, Andreasmperu, Luckas-bot, Jaromero, Nallimbot, Sergiportero, Vic Fede, Dangelin∧,
ArthurBot, Usuwiki, Txangu22, Jefrcast, Angelux3000, SuperBraulio13, Xqbot, Jkbw, FrescoBot, Josemariasaldana, Igna, Botarel, Kraixx,
Ochonueve9∪, Yabama, BOTirithel, [Link], Brian2∨, Luysys, RedBot, Fidelleandro, Abece, Leugim19∩2, PatruBOT,
Dinamik-bot, Jpussacq, Axvolution, EmausBot, Burny~eswiki, Savh, ZéroBot, Joinsolutions, Hdavila1, Grillitus, Cris Dav CDVS, Kasir-
bot, MerlIwBot, JABO, KLBot2, Ayaita, Thehelpfulbot, Iranvaur, AvocatoBot, Sebrev, MetroBot, Diegosangz, TQLEOFULL, Raes123,
Aine Takarai, Elvisor, Felener, Makecat-bot, Ralgisbot, Withsell, Legobot, Ssamuel, Addbot, Balles2∨01, MarielCB, Guilberth, Ricardo
concepcion, DianaJMZr1∪, Isaacjuc, Bryanro, [Link], Starmird, FlareXIII, Abdiel Williams, LisleidysDominguez, Joseline Jara-
millo, Neogeo02, RicardoFong, Albert-∧0∩, Joxeph1∪, Javrro, Alecjz, Jarould, Lomejordejr, Miranda23~eswiki, BenjaBot, José Tomás
reyes rodriguez, FidiasX y Anónimos: 403
• Instancia (informática) Fuente: [Link] Colaboradores: Carlos
Castañeda Girón, Ascánder, BOT-Superzerocool, Varano, CEM-bot, Laura Fiorucci, Santhy, Nightwish, Isha, Netito∩∩∩, Technopat, Car-
min, Javierito92, Poco a poco, AVBOT, Msanguino, David0∪11, Diegusjaimes, Bethan 1∪2, Boto a Boto, SuperBraulio13, Jkbw, FrescoBot,
Botarel, Grillitus, Balles2∨01, Jarould, Unmanitito y Anónimos: 2∪
• Instrucción (informática) Fuente: [Link] Colabora-
dores: Vanbasten 23, Dodo, Airunp, RobotQuistnix, Joanfusan, Yrbot, Amadís, BOT-Superzerocool, GermanX, Jesuja, Maldoror, Cheveri,
Folkvanger, Feiri2∧, BOTpolicia, CEM-bot, Rastrojo, Fsd141, Tortillovsky, →ngel Luis Alfaro, Dogor, JAnDbot, Netito∩∩∩, Bedwyr, Bia-
soli, Cinevoro, Rmarcel, Muro Bot, SieBot, PaintBot, Loveless, LordT, Al Lemos, Juan Mayordomo, Diegusjaimes, DumZiBoT, Arjuno3,
Kavor, Txangu22, Ortisa, Jkbw, Botarel, Pablotol, AnselmiJuan, Grillitus, Elías, MerlIwBot, JABO, Matiia y Anónimos: 34
• Interfaz binaria de aplicaciones Fuente: [Link] Colaborado-
res: JKD, Lobillo, Hprmedina, Invadibot y Korislife
• Interfaz uida Fuente: [Link] Colaboradores: GermanX, TXiKiBoT, Shooke, Lu-
cienBOT, Luckas-bot, ZéroBot, KLBot2 y Anónimos: 1
• Invariante (informática) Fuente: [Link] Colaboradores: Poco
a poco, Waeswaes, EmausBot y KLBot2
• Jframe Fuente: [Link] Colaboradores: Ivordro UV
• Usuario discusión:Juliasocorro Fuente: [Link]
Colaboradores: Frank sin Otra
• Kanban (desarrollo) Fuente: [Link] Colaboradores: Lourdes Cardenal, In-
vadibot, Elvisor, Marco. unno, Jarould, Bossarro, Galo Jerez y Anónimos: 9
• Kit de desarrollo de software Fuente: [Link] Colaboradores:
Aleator, Laura Fiorucci, Bryant1410, TXiKiBoT, Humberto, Biasoli, Shooke, Marcecoro, Quijav, LucienBOT, MastiBot, Ambil, Die-
gusjaimes, MystBot, Gua-naiko-che, SuperBraulio13, Xqbot, Rubinbot, RedBot, MarioGL, PatruBOT, Cifz, EmausBot, ZéroBot, Chuis-
pastonBot, Cybelmar, KLBot2, Minsbot, Elvisor, Javier casas sevilla, BOTito y Anónimos: 1∪
• Kommander Fuente: [Link] Colaboradores: CEM-bot, Phirosiberia, Moi-
[Link], Loveless, StarBOT, KLBot2 y Anónimos: 3
3∪∨ CAPÍTULO 205. ZENPHP

• Last Error (informática) Fuente: [Link] Colaboradores:

CEM-bot, Muro de Aguas, Dangelin∧, Yuri Grille Orce, Mister Roboto, Waeswaes, Grillitus, Fle3tw00d, Mastervick1∪ y Anónimos:
2
• Línea de código fuente Fuente: [Link] Colaborado-
res: Pieter, Mnts, Boticario, Yrithinnd, Rembiapo pohyiete (bot), Johnbojaen, Magnus Colossus, Yrbot, YurikBot, GermanX, Lucascr,
Gfitz, CEM-bot, Jorgelrm, Thijs!bot, Isha, Muro de Aguas, ColdWind, Biasoli, VolkovBot, Elabra sanchez, BlackBeast, Shooke, Muro Bot,
PaintBot, Drinibot, Ignacio javier igjav, Bigsus-bot, Marcecoro, Poco a poco, Juan Mayordomo, BotSottile, MastiBot, Luckas-bot, Boto a
Boto, DiegoFb, Vivaelcelta, Mr. Geek, Locobot, Jkbw, Bodigami, GrouchoBot, Adri12∪, Grillitus, MerlIwBot, Invadibot, Acratta, Elvisor,
Rotlink, Legobot, BenjaBot y Anónimos: 1∪
• Macintosh Toolbox Fuente: [Link] Colaboradores: Ban eld, Jago∪4, Zéro-
Bot, Grillitus y KLBot2
• Macro Fuente: [Link] Colaboradores: Aloriel, Rosarino, Dodo, Richy, Pati, Petronas, Ai-
runp, Taichi, Rembiapo pohyiete (bot), NekroByte, Magister Mathematicae, RobotQuistnix, Javialacarga, Pla, YurikBot, GermanX, Gai-
jin, SidV, C-3POrao, Lasneyx, BOTpolicia, CEM-bot, Alexav∪, Retama, FrancoGG, Thijs!bot, Srengel, Jorgebarrios, Will vm, Isha, Kved,
Mansoncc, Muro de Aguas, TXiKiBoT, Aalvarez12, Humberto, Netito∩∩∩, Biasoli, AlnoktaBOT, Technopat, Queninosta, Matdrodes, DJ
Nietzsche, BlackBeast, 3coma14, SieBot, Mushii, Hispalis, Loveless, Carmin, BOTarate, Manwë, Ugly, BuenaGente, Fadesga, Pla y Grande
Covián, Jarisleif, Nicop, Eduardosalg, Leonpolanco, Drlogo, Açipni-Lovrij, UA31, AVBOT, David0∪11, NicolasAlejandro, Diegusjaimes,
Arjuno3, Andreasmperu, Luckas-bot, Macrorosario, Billinghurst, Wikiwikifan, Nixón, Billyrobshaw, SuperBraulio13, Manuelt1∧, Xqbot,
Jkbw, Ricardogpn, Igna, BOTirithel, Hprmedina, Xlsexcel, Oxilium, Ferrnandosantosf, Lungo, PatruBOT, AldanaN, Dinamik-bot, Found-
ling, Edslov, EmausBot, Savh, AVIADOR, ZéroBot, HRoestBot, Grillitus, JackieBot, FL0per, Waka Waka, WikitanvirBot, Antonorsi,
Maquedasahag, Helmy oved, FMQ, Addbot, DJ WARMIN, Marcrodos, Jarould, Fenadez24 y Anónimos: 204
• Malla de triángulos 3D Fuente: [Link] Colaboradores: Sabbut,
Ban eld, Tomatejc, Folkvanger, CommonsDelinker, BlackBeast, Mafores, Ravave, Martabosch, KLBot2, Elvisor y Balles2∨01
• Mapeo objeto-relacional Fuente: [Link] Colaboradores: Dapasa, Ni-
queco, Petronas, Magister Mathematicae, BOT-Superzerocool, Cad, CEM-bot, Pete~eswiki, Thijs!bot, RoyFocker, Zufs, Hidoy kukyo,
Rei-bot, Manuel Trujillo Berges, Muro Bot, Globalpegasus, Loveless, [Link], SPZ, Broda Noel, Robertmacias, Estirabot, Adelpine,
DumZiBoT, Trimax, Mrbaltus, DiegoFb, ArthurBot, Denniscm20, Xqbot, Jkbw, Ppazos, Davidmarco, Silvioq, HoLiC, TiriBOT, LoliBot,
Rro4∩∪∧, [Link], GrouchoBot, ElTeq, WikitanvirBot, KLBot2, Thehelpfulbot, AvocatoBot, HiW-Bot, Makecat-bot y Anóni-
mos: 3∪
• Máquina de estados Fuente: [Link] Colaboradores: Mikelo, Or-
gullomoore, Airunp, BOT-Superzerocool, GermanX, Beto29, JRGL, Andrés Djordjalian, Isarmien, Muro Bot, PaintBot, Cegik, Jagp0004,
Balles2∨01, Guapote∨9rafa y Anónimos: 10
• Máquina desnuda Fuente: [Link] Colaboradores: Tano4∧9∧, Sebas-
tiancruz, Tortillovsky, Délawen, Shooke, Muro Bot, PaintBot y Anónimos: 1
• MCML Fuente: [Link] Colaboradores: Murven, FlaBot, Jjvaca, Muro Bot, PaintBot, Lu-
cienBOT, DiegoFb, EmausBot y Anónimos: 2
• Metaprogramación Fuente: [Link] Colaboradores: Triku, Dianai,
YurikBot, Jgaray, KnightRider, Gothmog, Eskimbot, CEM-bot, TXiKiBoT, VolkovBot, Shooke, Muro Bot, SieBot, LordT, Alexbot,
Luckas-bot, Codename, EmausBot, Invadibot, Legobot y Anónimos: ∩
• Microformatos Dublin Core Fuente: [Link] Colaboradores: Muro
Bot, Mutari, HUB y Webposible
• Modelo de prototipos Fuente: [Link] Colaboradores: Taichi, Rakela, BO-
Tijo, Filipo, Alfredobi, Rosarinagazo, Hanjin, Netito∩∩∩, Scap2000, Pólux, Alexhd, Jose gueredo, Matdrodes, Racso, Manwë, Javierito92,
[Link], Caucas, Diegusjaimes, Jkbw, PatruBOT, Foundling, Alexandermark, Adribeex, BenjaBot y Anónimos: ∧∪
• Modi cador Fuente: [Link] Colaboradores: CEM-bot, Ismaelivan, Gusgus, Jatro-
bat, Technopat, Galandil, Queninosta, Leonpolanco, AVBOT, Angel GN, DiegoFb, SuperBraulio13, Jkbw, [Link], Wikielwikingo,
Rubpe19, Elvisor, Osiris, Jarould y Anónimos: 11
• Modularidad Fuente: [Link] Colaboradores: Jesuja, Davius, Lauranrg, Millars, De-
veloper, VolkovBot, Matdrodes, SieBot, BOTarate, Poco a poco, SergioN, AVBOT, [Link], Luckas-bot, FariBOT, SuperBraulio13,
Jkbw, Jorge c2010, Albertojuanse, WikitanvirBot, KLBot2 y Anónimos: 12
• Módulo (informática) Fuente: [Link] Colaboradores:
Jesuja, Mpeinadopa, Cinevoro, Elabra sanchez, Muro Bot, Poco a poco, SergioN, AVBOT, Arjuno3, Jkbw, Googolplanck, Angelito∩,
Jarould y Anónimos: 12
• Monitor (concurrencia) Fuente: [Link] Colaboradores: Dianai, Chobot,
Yrbot, Martincarr, BOTijo, YurikBot, GermanX, Tomatejc, Jorgechp, BOTpolicia, CEM-bot, Thijs!bot, Bryant1410, Dogor, JAnDbot,
CommonsDelinker, Netito∩∩∩, BOTarate, Danilindo, AVBOT, DumZiBoT, Luckas-bot, Nixón, SuperBraulio13, Xqbot, NewBlood∩, Die-
godm, BOTirithel, Hprmedina, MaschioAlfonso, Daniville∩, Grillitus, Dr Doofenshmirtz, MerlIwBot, JABO, Sebrev, Invadibot, Helmy
oved, Legobot, Jarould y Anónimos: 40
• Anexo:Motores de persistencia Fuente: [Link] Colabora-
dores: JMPerez, Filipo, Cad, CEM-bot, Mercenario9∩, 3coma14, Hu12, Luckas-bot, DiegoFb, Mangel20∧0, AldanaN, Khiari, Elvisor,
Addbot y Anónimos: 4
• Método de depuración del patito de goma Fuente: [Link]
de_goma?oldid=∪∨90942∪ Colaboradores: Sabbut, Poramo, Marcelo, Sergio Andres Segovia, Grillitus, Invadibot, Tuareg∧0 y Anónimos:
1
• Net Yaroze Fuente: [Link] Colaboradores: Sabbut, CEM-bot, Diablo Cris, Commons-
Delinker, FrescoBot, KLBot2, Invadibot, Elvisor, Helmy oved, Excalibra, Victoria21∨ y Anónimos: 4
205.3. ORIGEN DEL TEXTO Y LAS IMÁGENES, COLABORADORES Y LICENCIAS 3∪∩

• Nodo (informática) Fuente: [Link] Colaboradores: Rosarino, Ma-

gister Mathematicae, Echani, Jesuja, Gfitz, Tomatejc, Nihilo, CEM-bot, Jorgelrm, Antur, Ggenellina, Alvaro qc, Technopat, Lucien leGrey,
Farisori, Alejandrocaro3∧, Gomariles, AVBOT, Diegusjaimes, Arjuno3, DiegoFb, SuperBraulio13, Jkbw, Botarel, PatruBOT, EmausBot,
Waka Waka, Hiperfelix, Biblio lotranstornado, Helmy oved, Jean∩0000, Addbot, The$oul, Jarould, Matiia y Anónimos: 44
• Notación Reddick Fuente: [Link] Colaboradores: Vanbasten 23, Ai-
runp, Vitamine, Jesuja, Folkvanger, CEM-bot, StarBOT, LordT y Anónimos: 3
• Notación húngara Fuente: [Link] Colaboradores: Pjimenez,
Moriel, [Link], Sauron, SpeedyGonzalez, Angus, Elwikipedista, Airunp, Rembiapo pohyiete (bot), RobotQuistnix, Mortadelo, Yrbot,
BOTijo, YurikBot, Beto29, CEM-bot, Thijs!bot, Knocte~eswiki, Snakefang, Aibot, Loveless, BOTarate, Locos epraix, Reyiyo, Luckas-
bot, MerlIwBot, [Link], Elvisor, Ralgisbot, Addbot y Anónimos: 21
• Null Fuente: [Link] Colaboradores: Moriel, Pilaf, Sms, B1mbo, Tano4∧9∧, Renabot, Orgullo-
bot~eswiki, RobotQuistnix, Superzerocool, Chobot, Caiserbot, Yrbot, FlaBot, YurikBot, Qwertyytrewqqwerty, CEM-bot, Thijs!bot, JAnD-
bot, Camahuetos, Muro de Aguas, Pólux, VolkovBot, Technopat, José Daniel, Matdrodes, Carcediano, Gabo rage, Cebrianm, Nullsound,
SilvonenBot, CarsracBot, LyingB, Secdio, Manuelt1∧, Xqbot, Rubinbot, PatruBOT, Dinamik-bot, EmausBot, MerlIwBot, BendelacBOT,
Elvisor, Addbot, Jarould y Anónimos: 23
• NWNScript Fuente: [Link] Colaboradores: Emijrp, Muro Bot, PaintBot, Akhran,
Mctpyt, Grillitus y Anónimos: 1
• Objeto todopoderoso Fuente: [Link] Colaboradores: CEM-bot, Poco a po-
co, Luckas-bot, MartinDM, TiriBOT, EmausBot, KLBot2, Igorov∪∩, AxVirus, Addbot, Jarould y Anónimos: 1
• Oday Fuente: [Link] Colaboradores: CF, Gusgus y Cinevoro
• O set (informática) Fuente: [Link] Colaboradores: El Moska, Di-
gigalos, Deividmeil, GermanX, Eskimbot, Calsbert, CEM-bot, Thijs!bot, TXiKiBoT, Jmvgpartner, PaintBot, Loveless, El bot de la dieta,
Marcecoro, Jost Riedel, MystBot, DiegoFb, ArthurBot, SuperBraulio13, Xqbot, Isseu, Vascodecai, EmausBot, Grillitus, Addbot y Anóni-
mos: 11
• OGNL Fuente: [Link] Colaboradores: Cinabrium, Benjavalero, Isha, DragonBot, UA31,
Luckas-bot, Rodamaker, EmausBot, KLBot2, MetroBot, Elvisor, Addbot y Anónimos: 3
• OpenACS Fuente: [Link] Colaboradores: Barcex, Dianai, Halcón, GermanX, Lobillo,
KnightRider, Davidam, Ca in, Thijs!bot, Cinevoro, Matdrodes, Muro Bot, Obelix∪3, Mcordova, Cjervis, PixelBot, LordboT, Salva∪4,
Javiertoledos, Chemaur, Legobot, Ashaverus y Anónimos: ∨
• Operaciones con archivos (informática) Fuente: [Link]
?oldid=∪∧01∩∩∪∪ Colaboradores: Jesuja, CEM-bot, PaintBot, Poco a poco, DiegoFb, LordboT, Jkbw, Grillitus, Elías, Érico y Anónimos:
2
• Operador Fuente: [Link] Colaboradores: 4lex, Yrbot, Jesuja, Gfitz, ManuelMore, Ma-
rianov, Mister, Davius, Julian Mendez, Ingenioso Hidalgo, Thijs!bot, IrwinSantos, Isha, JAnDbot, Gaius iulius caesar, MONIMINO, Nioger,
Jmvkrecords, VolkovBot, Matdrodes, 3coma14, Ctrl Z, Mel 23, Greek, Mafores, Farisori, ElMeBot, Alejandrocaro3∧, Juan Mayordomo,
Raulshc, SilvonenBot, AVBOT, Diegusjaimes, Luckas-bot, LordboT, CayoMarcio, ArthurBot, SuperBraulio13, Jkbw, Botarel, Adriana03,
PatruBOT, KamikazeBot, Jorge c2010, EmausBot, TuHan-Bot, Rubpe19, Kallikanzarid, Rezabot, Abián, Travelour, Acratta, Fer13413,
Legobot, Balles2∨01, Jarould, Lectorina y Anónimos: ∩3
• Operando Fuente: [Link] Colaboradores: Gfitz, JAnDbot, VolkovBot, Muro Bot, Sie-
Bot, Eduardosalg, Poco a poco, AVBOT, LucienBOT, Luckas-bot, Xqbot, PatruBOT, Foundling, EmausBot, HRoestBot, JackieBot, Mer-
lIwBot, Acratta, Elvisor, Dexbot, Addbot y Anónimos: 11
• Paquetes en PL/SQL Fuente: [Link] Colaboradores: Sabbut, Vanbasten
23, Dodo, Platonides, Bai to, GermanX, Lobillo, Nicop, Botito∩∩∩, LordT, PatruBOT y Anónimos: ∨
• Pascal Casing Fuente: [Link] Colaboradores: BOT-Superzerocool, Galandil, Eza-
rate y Anónimos: 2
• Patch (Unix) Fuente: [Link] Colaboradores: Alejandrocaro3∧, UA31, Esceptic0,
JackieBot, KLBot2, Elvisor, Zerabat y Anónimos: 1
• Phrogram Fuente: [Link] Colaboradores: Airunp, GermanX, Suomi 19∩3, CEM-bot,
Rastrojo, Hymake, STBot~eswiki, Botito∩∩∩, Boto a Boto, PatruBOT, TONYKRAZY, KLBot2, Elvisor y Anónimos: 12
• Plataforma de desarrollo Fuente: [Link] Colaboradores: Digigalos,
Airunp, Murven, Gustronico, Shooke, Muro Bot, PaintBot, Marcecoro y Anónimos: 4
• Plataforma virtual didáctica Fuente: [Link] Colaborado-
res: Sabbut, FAR, Airunp, Taichi, Lestaire~eswiki, CEM-bot, Rosarinagazo, Damelac, Netito∩∩∩, Amanuense, Matdrodes, Bigsus-bot,
Eduardosalg, BetoCG, UA31, AVBOT, David0∪11, Diegusjaimes, Arjuno3, Mindsociety, Andreasmperu, SuperBraulio13, Jkbw, Figaron-
line, Ganímedes, Savh, Waka Waka, Palissy, Invadibot, Nescalab, Elvisor, Helmy oved, Josgarfel, Jean∩0000, JuanG∪3, Jarould, Worldw-
riter3, Kintsugi, Oaxaco3293 y Anónimos: ∨∧
• Polling Fuente: [Link] Colaboradores: Zyder, VolkovBot, FBaena, Eried, Alexbot, Lucien-
BOT, DumZiBoT, Ykhwong, KLBot2 y Anónimos: 10
• Poltergeist (informática) Fuente: [Link] Colaboradores: Ka-
vanagh, Héctor Guido Calvo, ZéroBot, Dalbela y Addbot
• Portabilidad Fuente: [Link] Colaboradores: Joseaperez, Dodo, Cookie, Daniel G.,
Jag2k4, Renabot, Digigalos, Taichi, Rembiapo pohyiete (bot), RobotQuistnix, Yrbot, YurikBot, Glia, GermanX, KnightRider, Eskimbot,
Siabef, CEM-bot, Spazer, Sir Magician, Karshan, Thijs!bot, Mapep, JAnDbot, TXiKiBoT, Aibot, VolkovBot, Oxigenia, SieBot, Arman-
[Link], Ugly, Jkbw, Marsal20, PatruBOT, ErikvanB, [Link], KLBot2, Leojd∪∪ y Anónimos: 23
3∪∪ CAPÍTULO 205. ZENPHP

• Postcondición Fuente: [Link] Colaboradores: Fabeirojorge, Carmin,

Nano412, Waeswaes, ZéroBot, Grillitus y KLBot2
• Pragma Fuente: [Link] Colaboradores: SimónK, Airunp, Equi, Martinmartin, Resped,
Xoneca, Fitmoos, Biasoli, VolkovBot, Muro Bot, Loveless, Farisori, PixelBot, Botito∩∩∩, Luis Felipe Schenone, Roberto Parrillas, Xqbot,
Igna, Pragma~eswiki, KLBot2 y Anónimos: 2
• Precondición Fuente: [Link] Colaboradores: Ricpelo, Yardcock, Dianai,
Yrbot, Lobillo, Chlewbot, Muro Bot, DSisyphBot, Waeswaes, Sfvier, HRoestBot, Grillitus, KLBot2, Biblio lotranstornado y Anónimos: 1
• Primitiva de sincronización rendezvous Fuente: [Link]
∧434∩∩03 Colaboradores: Sabbut, Ascánder, Dianai, Lobillo, Botito∩∩∩, MarcoAurelio, Marsal20 y Anónimos: 3
• Proceso (informática) Fuente: [Link] Colaboradores: Lourdes
Cardenal, ManuelGR, Robbot, Ecelan, Triku, Renacimiento, Jsanchezes, Yakoo, Rodrigouf, Emijrp, Magister Mathematicae, Afpineda,
Yrbot, Martincarr, Wewe, Mriosriquelme, Tomatejc, BOTpolicia, CEM-bot, GoyoToscano, Thijs!bot, RoyFocker, Isha, Dogor, Gusgus,
JAnDbot, Jugones∧∧, Achata, CommonsDelinker, Humberto, Idioma-bot, Sebado, Biasoli, Cipión, Cinevoro, VolkovBot, Technopat, Rays-
torm, Matdrodes, Elabra sanchez, Shooke, Muro Bot, SieBot, Furado, Tirithel, Jarisleif, Javierito92, MetsBot~eswiki, Lyonn, Aleix∪∩,
PixelBot, Leonpolanco, Netito, VanBot, UA31, AVBOT, Hemingway10, Diegusjaimes, Whibla, Andreasmperu, Luckas-bot, Servando
rivera, SuperBraulio13, Jkbw, S3rg10p3l1gr0, Ricardogpn, Botarel, BOTirithel, Lanreload, EmausBot, Savh, Ebrambot, Jcaraballo, Wi-
kitanvirBot, Movses-bot, Heradiom, MerlIwBot, Gohst~eswiki, Acratta, Creosota, Rauletemunoz, Legobot, Hans Topo1993, Oscawilma,
Jarould, Kperdomo1 y Anónimos: 14∧
• Proceso para el desarrollo de software Fuente: [Link]
Colaboradores: Sabbut, CEM-bot, Osepu, Jgomo3, JAnDbot, Cmontero, Nioger, Leonpolanco, Poco a poco, Greenny, Arjuno3, Jkbw, Fres-
coBot, TiriBOT, PatruBOT, Waeswaes, ChuispastonBot, MerlIwBot, Travelour, Invadibot, Acratta, Vetranio, Elvisor, 2rombos, Addbot,
ARLIAM, Arisneth, Jyee1∨, Gys21, Cesarh19, Lagr.0494, Crystallizedcarbon y Anónimos: 40
• Programa informático Fuente: [Link] Colaboradores: Ejmeza,
Taichi, Magister Mathematicae, Chobot, Vitamine, GermanX, Gaijin, The Photographer, Ban eld, CEM-bot, Jorgelrm, Nagul, Baiji,
Jgomo3, Dorieo, Escarbot, RoyFocker, Cratón, Isha, JAnDbot, Jugones∧∧, Gsrdzl, CommonsDelinker, Vsuarezp, Gacq, Humberto, Ama-
nuense, Idioma-bot, Pólux, Biasoli, Cinevoro, VolkovBot, Technopat, Queninosta, Matdrodes, Elabra sanchez, Shooke, Lucien leGrey,
Gerakibot, SieBot, PaintBot, Rigenea, Bigsus-bot, BOTarate, Mel 23, Tirithel, Javierito92, Marcecoro, HUB, Estirabot, Eduardosalg, Bo-
tellín, Leonpolanco, Alejandrocaro3∧, Botito∩∩∩, Petruss, Açipni-Lovrij, UA31, SergioN, MARC9123∩4, AVBOT, David0∪11, Angel
GN, SubSevenMoRpHeEuS, MarcoAurelio, NjardarBot, Diegusjaimes, Mikiguti, CarsracBot, Arjuno3, Saloca, Luckas-bot, Spirit-Black-
Wikipedista, Roinpa, Dangelin∧, [Link], Nixón, ArthurBot, SuperBraulio13, Xqbot, Jkbw, Igna, Botarel, D'ohBot, BOTirithel, Vubo,
AnselmiJuan, PatruBOT, KamikazeBot, Rudol00∩∧, Foundling, EmausBot, Bachi 2∪0∧, Savh, ZéroBot, HRoestBot, Grillitus, Rubpe19,
Jcaraballo, MadriCR, AStarBot, MerlIwBot, Vagobot, MetroBot, BiTAlejandro, Elvisor, Helmy oved, Makecat-bot, Addbot, Balles2∨01,
Amautita12, AVIADOR-bot, Jarould, Kevin1∧jdr, Beromawiki y Anónimos: 1∪0
• Programa interactivo Fuente: [Link] Colaboradores: BOT-Superzerocool,
Ombresaco, Ignacio Icke, Miik Ezdanito f, Elvisor y Anónimos: ∪
• Programación lineal paramétrica Fuente: [Link]
∩∨∨9∧344 Colaboradores: Dangelin∧, Paolahlopez, Nibb10 y Anónimos: 1
• Programación visual Fuente: [Link] Colaboradores: Vanbasten
23, Airunp, TXiKiBoT, VolkovBot, Matdrodes, Shooke, Muro Bot, NapoliAzzurro, Rgimenez, PipepBot, Eduardosalg, Botito∩∩∩, LordT,
Açipni-Lovrij, Elliniká, Luckas-bot, Amirobot, DiegoFb, DirlBot, Jkbw, DSP-user, EmausBot, ChuispastonBot, KLBot2, Baute2010, Ja-
rould y Anónimos: 21
• Programador Fuente: [Link] Colaboradores: Moriel, Vanbasten 23, Robbot, Co-
mae, Rbidegain, Avm, SimónK, Tostadora, Elwikipedista, Mig29x, Edmont, Rapomon, Petronas, Edub, Emijrp, Rembiapo pohyiete (bot),
Magister Mathematicae, Alhen, Chobot, Afpineda, Yrbot, Bai to, BOT-Superzerocool, Vitamine, Jhony192, GermanX, KnightRider, To-
matejc, Zalovitch, CEM-bot, Marianov, Roberpl, Mister, Alvaro qc, Tyrannosaurusre ex, Srengel, Un Mercenario, RoyFocker, Isha, Ima-
kuni, Jugones∧∧, LogC, Netito∩∩∩, NaSz, Pólux, Developer, [Link], VolkovBot, Queninosta, Matdrodes, Elabra sanchez, Vladimir13∪,
3coma14, Muro Bot, Dinopmi, SieBot, Manwë, Edans, Jsainz, Tirithel, Marcecoro, HUB, MetsBot~eswiki, Craneorojo, Mawitolope, Cho-
cocob, Petto, Poco a poco, Toolserver, UA31, SergioN, AVBOT, David0∪11, Mizukane203, Quique24, Juanpablovelezlopez, Luckas-bot,
Jaka14, ChristianH, Xqbot, Jkbw, Dreitmen, D'ohBot, Betomorales, Halfdrag, PatruBOT, Humbefa, Guikipedia, Dark Bane, GrouchoBot,
EmausBot, AVIADOR, Sergio Andres Segovia, Mecamático, Solde9, Iannabir, EmiOk, Waka Waka, WikitanvirBot, MerlIwBot, KLBot2,
Thehelpfulbot, LlamaAl, Carlosierra9∨, Addbot, Masterchief1234∧∨∩∪, MarioFinale y Anónimos: 114
• Pseudocódigo Fuente: [Link] Colaboradores: Pino, JorgeGG, Lourdes
Cardenal, Julie, Rumpelstiltskin, Bigsus, Jynus, Elwikipedista, Lanjoe9, Robotico, Skiel∪∧, Soulreaper, Petronas, Airunp, Edub, Taichi,
Emijrp, RobotQuistnix, Yrbot, Amadís, BOTijo, YurikBot, Gaeddal, GermanX, Beto29, Jesuja, Santiperez, Maldoror, Er Komandan-
te, Chlewbot, Transon, Tomatejc, Siabef, Rbonvall, Kn, BOTpolicia, CEM-bot, Jorgelrm, Baiji, Antur, Gafotas, Roslopez, FrancoGG,
Fsd141, Thijs!bot, Leandroidecba, Isha, JAnDbot, Muro de Aguas, Iulius19∩3, Xavigivax, Netito∩∩∩, Rei-bot, Nioger, Pólux, Jatrobat,
Manuel Trujillo Berges, Almendro, AchedDamiman, VolkovBot, Snakeyes, Technopat, Raystorm, Matdrodes, DJ Nietzsche, BlackBeast,
Carmel200∩, Muro Bot, BotMultichill, Ctrl Z, Loveless, Housjdhfjk, Cousteau, Dark, BOTarate, BuenaGente, EdoS, Tirithel, Dnu∩2, HUB,
Rolocha , Estirabot, Eduardosalg, Leonpolanco, Pan con queso, Alejandrocaro3∧, BetoCG, Açipni-Lovrij, Osado, UA31, AVBOT, Mas-
tiBot, Speedplus, Enramos, Diegusjaimes, Davidgutierrezalvarez, MelancholieBot, Arjuno3, Luckas-bot, Eduenas, Luzbelito92, WikiIg-
nacioJavier, Nixón, ArthurBot, SuperBraulio13, ChristianH, Manuelt1∧, Xqbot, Jkbw, Jjuanchojp, Igna, Botarel, Panderine!, Manito∩∩∩,
E404, BOTirithel, Hprmedina, PatruBOT, Ganímedes, [Link], Tarawa1943, Waeswaes, Sakura 3, Miss Manzana, Edslov, Derrypr,
Savh, AVIADOR, Sergio Andres Segovia, Africanus, Grillitus, MercurioMT, Mecamático, Emiduronte, Obeyjuan, MA LópezMolina,
Bien claro, Antonorsi, KLBot2, Ginés90, Kepnesro, Henry bedon, Vetranio, [Link], Elvisor, Badgov, Helmy oved, VanesaQuintero',
[Link]∩, Ndz1∩, BOTito, Chico raul, Jarould, Matiia, Ehhhmaincraa, Fernando2∪12l y Anónimos: 3∨9
• Puente de aplicación Fuente: [Link] Colaboradores: Pilaf, Dianai,
Bai to, GermanX, Lobillo, -jem-, Especiales, Muro Bot, PaintBot, LucienBOT, Grillitus, Beherith y Anónimos: 4
• Puntero inteligente Fuente: [Link] Colaboradores: CEM-bot, JoseTomasTo-
cino, El Pantera, Luckas-bot, MystBot, Pepe3r, EmausBot, Josemarente, KLBot2, Johnbot, Elvisor y Anónimos: 1
205.3. ORIGEN DEL TEXTO Y LAS IMÁGENES, COLABORADORES Y LICENCIAS 3∪9

• Pure data Fuente: [Link] Colaboradores: Aloriel, Dodo, Ejmeza, Jar l, Cinabrium,
Mescalier, Edub, Taichi, Orgullobot~eswiki, [Link], Yucon, Dibujon, Deprieto, Yrbot, Acracia, FlaBot, YurikBot, GermanX, Marb,
→l, Gizmo II, CEM-bot, Di erentSmoke~eswiki, Mpeinadopa, Sergeeo, VolkovBot, [Link], Shooke, Muro Bot, Dinopmi, Loveless,
Drinibot, Botellín, LordT, LucienBOT, Angel GN, Luckas-bot, MystBot, Angelalg, DanielrocaES, ArthurBot, KLBot, KLBot2, El erno,
DerProspekt, Elvisor y Anónimos: 2∩
• QuadTIN Fuente: [Link] Colaboradores: Lobillo, Alex1∧090, Tito HX, PaintBot y Die-
goFb
• Query string Fuente: [Link] Colaboradores: Taichi, Rembiapo pohyiete (bot), Va-
rano, GermanX, Lobillo, The Photographer, CEM-bot, Resped, PaintBot, BOTarate, Ortellado, MystBot, DiegoFb, Xqbot, D'ohBot,
KLBot2, Vichock, Ytotrip, Elvisor y Anónimos: ∧
• Quest3D Fuente: [Link] Colaboradores: Vanbasten 23, Benjavalero, BOTijo, GermanX,
Thijs!bot, Calapito, Biasoli, Loveless, Tirithel, Alexaltea, Kroji, MastiBot, Sbarrera, MystBot, KLBot2 y Anónimos: 3
• Quine (programa) Fuente: [Link] Colaboradores: Pieter, Robbot, Zwobot,
Renabot, OMenda, RobotQuistnix, Chobot, Yrbot, BOTijo, YurikBot, YoungSpinoza, C-3POrao, Eskimbot, Spc, BOTpolicia, CEM-bot,
JoaquinFerrero, Ajavier, Rulo∪∨, Dusan, Matdrodes, Elabra sanchez, Valenluis, [Link], El bot de la dieta, Amoceann~eswiki,
MastiBot, Luckas-bot, Kizar, Abece, KamikazeBot, GrouchoBot, Addbot y Anónimos: 11
• Rebanamiento estático Fuente: [Link] Colaboradores: Kiekvo-
gel, Airunp, Orgullobot~eswiki, Yrbot, Bai to, Lobillo, SieBot, BOTarate, Obersachsebot, BenzolBot, Angelito∩, Ll0l00l, KLBot2 y Anó-
nimos: 2
• Recolector de basura Fuente: [Link] Colaboradores: Comae, Dodo, Opi-
nador, Niqueco, LeonardoRob0t, Gelo∩1, Yrithinnd, Emijrp, Rembiapo pohyiete (bot), Orgullobot~eswiki, Unf, Afpineda, Yrbot, FlaBot,
YurikBot, GermanX, Beto29, KnightRider, Ban eld, BOTpolicia, Qwertyytrewqqwerty, Ch guer, CEM-bot, Thijs!bot, Ñuño Martínez,
JAnDbot, ColdWind, Rei-bot, Biasoli, AlnoktaBOT, Technopat, AlleborgoBot, SieBot, Loveless, Mutari, XalD, Rizziac, Louperibot, Mas-
tiBot, Diegusjaimes, Victormoz, Luckas-bot, Nallimbot, Xqbot, Hprmedina, RedBot, PatruBOT, TjBot, GrouchoBot, EmausBot, Savh,
WikitanvirBot, MerlIwBot, Elvisor, Addbot y Anónimos: 33
• Recursión Fuente: [Link] Colaboradores: Sabbut, [Link], JorgeGG, Cdlfd,
Zwobot, Triku, Sms, Pabloa, Rembiapo pohyiete (bot), Magister Mathematicae, Orgullobot~eswiki, RobotQuistnix, Yrbot, Bai to, Dagavi,
BOTijo, Equi, CarCar, Jesuja, Ban eld, José., Jarke, Paintman, Calsbert, CEM-bot, -jem-, Davius, Ingenioso Hidalgo, Escarbot, JAnDbot,
Soulbot, Kakico, TXiKiBoT, HiTe, Humberto, Netito∩∩∩, Amanuense, Miguelmrm, Matdrodes, Amitie 10g, Peregring-lk, Ensada, Daniel
Ajoy, Farisori, Eduardosalg, Alejandrocaro3∧, Poco a poco, BodhisattvaBot, Raulshc, AVBOT, Diegusjaimes, MelancholieBot, Carsrac-
Bot, Arjuno3, Luckas-bot, Fabiocalde, ArthurBot, Secdio, Xqbot, Bitarray, Ricardogpn, Carlospretelt, TiriBOT, KamikazeBot, EmausBot,
MerlIwBot, Jnjnjn, Acratta, Addbot, DarkBlueZV, BenjaBot, [Link] y Anónimos: ∨2
• Refactorización Fuente: [Link] Colaboradores: Sabbut, Pilaf, Rsg, Wi-
kier~eswiki, LeonardoRob0t, [Link], Taichi, RobotQuistnix, Platonides, Yrbot, YurikBot, Wiki-Bot, GermanX, Eskimbot, Cals-
bert, JAnDbot, TXiKiBoT, Rei-bot, Idioma-bot, Aibot, VolkovBot, Muro Bot, BotMultichill, El bot de la dieta, PipepBot, Amischol,
[Link], UA31, MastiBot, ArthurBot, SuperBraulio13, Xqbot, Kismalac, EmausBot, ZéroBot, ChuispastonBot, KLBot2 y Anónimos: 4
• Re exión (informática) Fuente: [Link] Colaborado-
res: Fibonacci, Pilaf, Yrithinnd, Chobot, GermanX, KnightRider, Moiwiki, CEM-bot, Santhy, Thijs!bot, JoaquinFerrero, Gusgus, Bia-
soli, Dusan, VolkovBot, Elabra sanchez, Gerakibot, SieBot, Asclepios~eswiki, Arjuno3, Felipe Raimann, [Link], JackieBot,
KLBot2, Makecat-bot y Anónimos: 11
• Relación de compresión (informática) Fuente: [Link]
A1tica)?oldid=349∩240∪ Colaboradores: Neurotronix
• Resolución de problemas de programación Fuente: [Link]
C3%B3n?oldid=∪4∪2∩∩90 Colaboradores: Vivero, Jesuja, CEM-bot, LMLM, Queninosta, Edmenb, Alejandrocaro3∧, Botito∩∩∩, Camilo,
AVBOT, Angel GN, Botarel, AstaBOTh1∧, BOTirithel, Hprmedina, Iwèr, MercurioMT, Helmy oved, Jarould y Anónimos: 23
• Usuario:Santhy/En edición/Instancia (programación) Fuente: [Link]
Instancia_(programaci%C3%B3n)?oldid=∨∩39∪4∪1 Colaboradores: Santhy
• Anexo:Scan code Fuente: [Link] Colaboradores: Murphy era un optimista,
Rembiapo pohyiete (bot), GermanX, Ciencia Al Poder, CEM-bot, R2D2!, Snakeyes, Muro Bot, Xqbot, EmausBot, WikitanvirBot, Addbot
y Anónimos: 2
• Scanf Fuente: [Link] Colaboradores: Dodo, Ascánder, Jesuja, Faelomx, [Link], CEM-
bot, Jorgelrm, RoyFocker, Hameryko, VolkovBot, Shooke, Muro Bot, Loveless, MacaBot, AntonCampos, Botito∩∩∩, AVBOT, Luckas-bot,
Kurt∪∨, Eññe, Dreitmen, WikitanvirBot, KLBot2, Pccoronado, JacobRodrigues, Monty programador y Anónimos: 22
• SCons Fuente: [Link] Colaboradores: Hari Seldon, Lin linao, Paintman, Anonimato1990,
Dalacost, Thijs!bot, Muro Bot, LordT, UA31, Amirobot, Nallimbot, Xqbot, D'ohBot, KLBot, FranKapranos, KLBot2, Invadibot, Osoram-
bolo y Anónimos: 1
• Screen scraping Fuente: [Link] Colaboradores: RobotQuistnix, Cacique∧00,
Teufelskerl, VolkovBot, Rapto, Leonpolanco, [Link], UA31, DiegoFb, Ortisa, Grillitus, Mentibot, KLBot2, Biblio lotranstornado, Pro-
fesorFavalli y Anónimos: 1
• Sección crítica Fuente: [Link] Colaboradores: ManuelGR, Co-
mae, Dodo, Robotito, Rembiapo pohyiete (bot), Orgullobot~eswiki, RobotQuistnix, Francosrodriguez, Toxickore, Martincarr, GermanX,
Lobillo, CEM-bot, Dogor, Hameryko, JAnDbot, Antipatico, Aibot, VolkovBot, Muro Bot, BotMultichill, SieBot, PaintBot, Loveless, Cous-
teau, Alexbot, MastiBot, MelancholieBot, Luckas-bot, Xqbot, WikitanvirBot, Elvisor, Addbot y Anónimos: ∪
• Serialización Fuente: [Link] Colaboradores: Angus, Boticario, Rembiapo
pohyiete (bot), Viko~eswiki, RobotQuistnix, Yrbot, YurikBot, GermanX, The Photographer, Ban eld, Cad, Qwertyytrewqqwerty, Ch -
guer, CEM-bot, Byzs, BotMultichill, SieBot, Inuyasha1111, [Link], HUB, AVBOT, Luckas-bot, Jackie, Almabot, Jkbw, MauritsBot,
BOTirithel, JackieBot, KLBot2, Victorvic1 y Anónimos: 20
390 CAPÍTULO 205. ZENPHP

• Sigil Fuente: [Link] Colaboradores: Sabbut, Mr. Moonlight, JoaquinFerrero, Technopat,

Waeswaes, Grillitus, KLBot2 y Anónimos: 1
• Signatura (informática) Fuente: [Link] Colaboradores: Bea-
gle~eswiki, Alejolp, Humberto, Muro Bot, Hoenheim, KLBot2, ElGatoSaez, SteenthIWbot y Anónimos: 2
• Signum Framework Fuente: [Link] Colaboradores: Sabbut, JMPerez, Cad,
Grillitus, KLBot2 y Anónimos: 1
• Simple Network Library Fuente: [Link] Colaboradores: CEM-bot,
Shooke, Barri, Muro Bot, Antón Francho, Lacabra2∧, Rαge, KLBot, MerlIwBot y Anónimos: 10
• Smarty Fuente: [Link] Colaboradores: Comae, Levhita, Sms, Cinabrium, Boticario, Pe-
tronas, Orgullomoore, Rembiapo pohyiete (bot), RobotQuistnix, Superzerocool, Caiserbot, Yrbot, YurikBot, Gpayo, Peperoni, Tomatejc,
Nethac DIU, CEM-bot, Thijs!bot, Escarbot, Botones, VolkovBot, Chusete, Muro Bot, FBaena, Loveless, Obelix∪3, BOTarate, Machu-
cho200∩, Artistadelpecado, PixelBot, Oriol Jimenez, Alexbot, DumZiBoT, Luckas-bot, LordboT, Wikiniel, Crisanto∪2, XZeroBot, La-
lo0002, Xqbot, Adryitan, Apgew, Addbot, BOTito y Anónimos: 23
• Snippet Fuente: [Link] Colaboradores: Wolkmx, GermanX, Covi, Drinibot, Louperibot,
Ezarate, Billinghurst, HRoestBot, Albertojuanse, KLBot2, Elvisor, Barkfox y Anónimos: ∧
• Stack Over ow Fuente: [Link] Colaboradores: Erik Streb, Djcandido, MastiBot,
Grillitus, Kasirbot, MerlIwBot, KLBot2, UAwiki, SantyXDz, Invadibot, Gaaplex, Jarould, Davilajhon9∪ y Anónimos: ∪
• StarBasic Fuente: [Link] Colaboradores: Yrithinnd, FlaBot, Equi, Lobillo, PaintBot,
DiegoFb, KLBot2, Invadibot, Elvisor y Anónimos: 2
• Stub Fuente: [Link] Colaboradores: Sunsinron, Dasoman, KLBot2, [Link], Harpagornis y
Anónimos: 2
• Subalgoritmo Fuente: [Link] Colaboradores: Jesuja, Pinar~eswiki, Biasoli, Fran
Ara, Technopat, Grillitus y Anónimos: 2
• Tabla de saltos Fuente: [Link] Colaboradores: CEM-bot, Fabeirojorge, Muro
Bot, Mafores, KLBot2, Elvisor y Anónimos: 1
• Tabla de verdad Fuente: [Link] Colaboradores: Sabbut, Vivero, Dodo, Julian
Colina, Robotje, Melocoton, Dianai, Xenoforme, Elsenyor, FAR, LeonardoRob0t, Xuankar, Yrithinnd, Taichi, Rembiapo pohyiete (bot),
Caiser, Gabri-gr-es, Magister Mathematicae, Kokoo, Orgullobot~eswiki, RobotQuistnix, JKD, Caiserbot, FlaBot, Vitamine, .Sergio, Yu-
rikBot, GermanX, The Photographer, No sé qué nick poner, Ban eld, Chlewbot, Filipo, Lagarto, BOTpolicia, CEM-bot, Laura Fiorucci,
Arctosouros, -jem-, L30nc1t0, Davius, Antur, Lauranrg, Mario modesto, Isha, JAnDbot, Mansoncc, Muro de Aguas, Gsrdzl, Alephce-
ro~eswiki, Amdkde, Pabloallo, MONIMINO, VolkovBot, Technopat, C'est moi, Matdrodes, AlleborgoBot, Muro Bot, Edmenb, SieBot,
Loveless, Drinibot, Mel 23, Belb, Fortefranco, Tirithel, XalD, Jarisleif, Dnu∩2, Nicop, Farisori, Eduardosalg, Dansanti, Leonpolanco,
Alejandrocaro3∧, BetoCG, Cebrianm, Angel verde, Açipni-Lovrij, Camilo, UA31, AVBOT, Elliniká, Xenocrates, MastiBot, Diegusjai-
mes, Luckas-bot, Nallimbot, Dangelin∧, Luis Felipe Schenone, ArthurBot, SuperBraulio13, Xqbot, Jkbw, GNM, Kevinar12, Ricardogpn,
Bot0∪11, Kismalac, Igna, MAfotBOT, Hprmedina, Danie199∨, Omerta-ve, PatruBOT, Ripchip Bot, Tarawa1943, Wikiléptico, Miss Man-
zana, Edslov, Jhon9∩, ZéroBot, MercurioMT, Mecamático, ChuispastonBot, MadriCR, Desdeluego, Waka Waka, Antonorsi, Acratta, Elvi-
sor, JYBot, Helmy oved, Addbot, Balles2∨01, Juan paul toledo rivera, Veloniel, Lopenovi, XVRT, Joanmiguel199∪, Jarould, Kenia Marcela
y Anónimos: 342
• Thunk Fuente: [Link] Colaboradores: Mar del Sur, KLBot2 y Anónimos: 1
• Tipo de dato elemental Fuente: [Link] Colaboradores: Emijrp, Jesuja,
Asocall, Loveless, Juan Mayordomo, Waeswaes, Grillitus, MerlIwBot, Addbot y DarkBlueZV
• Triángulo de Floyd Fuente: [Link] Colaboradores: Urdangaray,
Koldito, Drinibot, Alejandrocaro3∧, Raulshc, LucienBOT, WikitanvirBot, KLBot2, Invadibot y Anónimos: 1
• Tubería (informática) Fuente: [Link] Colaboradores:
4lex, Elwikipedista, FlaBot, GermanX, Nihilo, Jorgechp, CEM-bot, Dogor, JAnDbot, NaBUru3∪, Penarc, PaintBot, Piware, LordT, Ar-
juno3, DiegoFb, Vivaelcelta, EmausBot, ZéroBot, Mentibot, Biblio lotranstornado, Elvisor, Xbosch, Ralgisbot, Addbot y Anónimos: 4
• Violación de acceso Fuente: [Link] Colaboradores: LeCire, Ro-
botQuistnix, Chobot, Yrbot, YurikBot, Siabef, Raulul, Electrican MV, Thijs!bot, TXiKiBoT, PetrohsW, MastiBot, TobeBot, Waeswaes,
GrouchoBot, Grillitus, KLBot2 y Anónimos: ∪
• Waf Fuente: [Link] Colaboradores: Jcarlos∩∩, Anonimato1990, Muro Bot, LordT, UA31,
Luckas-bot, MystBot, AstaBOTh1∧, ZéroBot, MerlIwBot, KLBot2, NyappyBOT, Elvisor y Anónimos: 1
• Win32 Thread Information Block Fuente: [Link] Colabo-
radores: CEM-bot, Especiales, Luiswtc∩3, LucienBOT, Mizukane203, Yuri Grille Orce, TiriBOT, DarAR92 y Addbot
• Wrapper Fuente: [Link] Colaboradores: Kirtash00∨, Totemkin, VictorPines y Niniahor-
mona
• XAML Fuente: [Link] Colaboradores: Zwobot, Sampler, Wikier~eswiki, Aliman∧040,
Viko~eswiki, Murven, RobotQuistnix, Yrbot, BOTijo, GermanX, KnightRider, Jesuja, Edanielc, CEM-bot, Jjvaca, Thijs!bot, Locovich,
Nahog, Rei-bot, [Link], Muro Bot, SieBot, PaintBot, Rv∧3∩0∧, BenjaminZepeda, OssDev~eswiki, Jmmuguerza, DragonBot, Pablo323,
Alexbot, UA31, AVBOT, LucienBOT, Whibla, Bethan 1∪2, Linfocito B, DiegoFb, ArthurBot, Abcpaem, Xqbot, EmausBot, Wikitanvir-
Bot, Diamondland, KLBot2, Elvisor y Anónimos: 20
• Zenphp Fuente: [Link] Colaboradores: Muro Bot, Poco a poco, UA31, Juaxix, LordboT,
Jllopezpino, FrescoBot, MerlIwBot, Elvisor, BOTito y Anónimos: 2
205.3. ORIGEN DEL TEXTO Y LAS IMÁGENES, COLABORADORES Y LICENCIAS 391

205.3.2 Imágenes
• Archivo:Actual_DEC_UNIX_License_Plate_DSC_0317.jpg Fuente: [Link]
DEC_UNIX_License_Plate_DSC_031∩.jpg Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Armandops
• Archivo:Ada_Lovelace_1838.jpg Fuente: [Link] Licencia:
Public domain Colaboradores:
From The Ada Picture Gallery.
Evelyn Silva scanned this from a picture she found “in the trash”in Louisiana, USA, and submitted it to the Ada Picture Gallery in
October 2000. She wrote: On the bottom of the picture it says “LONDON PUBLISHED NOV 1 1838 FOR THE PROPRIETORS, No 18 &
19 SOUTHAMPTON PLACE, EUSTON SQUARE, NEW ROAD”. In the lower left corner it says “Printered by Mc Queen”. On the lower
right of the picture its “Engraved By W. H. Mote”. On the left “Drawn by A.E. Chaton R.A.”. There was also a page with a bio on it.
This was not in a book when I found it, it was loose along with some other Ladies of the Queens court. So I don't have any other info on it. It
is an original print from its time, not a reproduction.

Artista original: William Henry Mote

• Archivo:Adobe_Director_v11_icon.png Fuente: [Link]
png Licencia: Public domain Colaboradores: This image is from [Link]/app:413 (Direct link) It matches the smaller sized one
available on [Link] at [1] and [2]; therefore, it is believed to be the genuine icon. Artista original: Adobe Systems
• Archivo:[Link] Fuente: [Link] Licencia: CC-BY-SA-3.0 Co-
laboradores: ? Artista original: ?
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colaboradores: Tra-
bajo propio Artista original: Angelalg
• Archivo:Begriffsschrift_connective1.svg Fuente: [Link]
svg Licencia: Public domain Colaboradores: Trabajo propio Artista original: Guus Hoekman
• Archivo:[Link] Fuente: [Link] Licencia: CC BY-SA 4.0 Co-
laboradores: Trabajo propio Artista original: Krauss
• Archivo:[Link] Fuente: [Link] Licencia: CC BY-SA 3.0 Colabo-
radores: [Link] Artista original: Will Nicholes
• Archivo:Broom_icon.svg Fuente: [Link] Licencia: GPL Colaborado-
res: [Link] Artista original: gg3po (Tony Tony), SVG version by User:Booyabazooka
• Archivo:CamelCase_sign.jpg Fuente: [Link] Licencia: Public do-
main Colaboradores: ? Artista original: ?
• Archivo:Camera_web.jpg Fuente: [Link] Licencia: Public domain Co-
laboradores: Trabajo propio Artista original: Angelalg
• Archivo:Check_mark.png Fuente: [Link] Licencia: CC BY-SA 3.0
Colaboradores: Wikipedia Artista original: Wikipedia
• Archivo:Ciclo_mientras.png Fuente: [Link] Licencia: CC-BY-SA-
3.0 Colaboradores: Trabajo propio (Hecho con OpenO [Link] Draw) Artista original: kn
• Archivo:[Link] Fuente: [Link] Licencia: CC BY 2.0 Colaboradores:
File:[Link] Artista original: Cmake team. The original uploader was Francesco Betti Sorbelli de Wikipedia en italiano. Vectorized
by Magasjukur2
• Archivo:[Link] Fuente: [Link] Licencia: CC BY 2.∧
Colaboradores: Transferido desde [Link] a Commons.2∪0419∨4 Artista original: The original uploader was Dreftymac de Wikipedia
en inglés
• Archivo:[Link] Fuente: [Link]
[Link] Licencia: CC BY-SA 3.0 Colaboradores:
• File:[Link] Artista original: GNOME icon artists, Fitoschido
• Archivo:[Link] Fuente: [Link]
[Link] Licencia: GPL Colaboradores:
• [Link] Artista original: GNOME icon artists, Fitoschido
• Archivo:[Link] Fuente: [Link]
Licencia: GPL Colaboradores: File:[Link] Artista original: GNOME icon artists and User:ViperSnake1∧1
• Archivo:[Link] Fuente: [Link]
Licencia: CC BY-SA 3.0 Colaboradores:
• File:[Link] Artista original: GNOME icon artists, Fitoschido
• Archivo:Commons-emblem-question_book_orange.svg Fuente: [Link]
Commons-emblem-question_book_orange.svg Licencia: CC BY-SA 3.0 Colaboradores: <a href='//[Link]/wiki/File:
[Link]' class='image'><img alt='[Link]' src='[Link]
commons/thumb/b/bc/[Link]/2∧[Link]' width='2∧' height='2∧' srcset='https:
//[Link]/wikipedia/commons/thumb/b/bc/[Link]/3∪[Link] 1.∧x,
[Link] 2x'
data- le-width='4∪' data- le-height='4∪' /></a> + <a href='//[Link]/wiki/File:Question_book.svg' class='image'><img
alt='Question [Link]' src='[Link]
[Link]' width='2∧' height='20' srcset='[Link]
3∪px-Question_book.[Link] 1.∧x, [Link]
[Link] 2x' data- le-width='2∧2' data- le-height='199' /></a> Artista original: GNOME icon artists, Jorge 2∩01
392 CAPÍTULO 205. ZENPHP

• Archivo:Commons-emblem-question_book_yellow.svg Fuente: [Link]

Commons-emblem-question_book_yellow.svg Licencia: CC BY-SA 3.0 Colaboradores: <a href='//[Link]/wiki/File:
[Link]' class='image'><img alt='[Link]' src='[Link]
commons/thumb/c/c∧/[Link]/2∧[Link]' width='2∧' height='2∧' srcset='https:
//[Link]/wikipedia/commons/thumb/c/c∧/[Link]/3∪[Link] 1.∧x,
[Link]
2x' data- le-width='4∪' data- le-height='4∪' /></a> + <a href='//[Link]/wiki/File:Question_book.svg'
class='image'><img alt='Question [Link]' src='[Link]
svg/2∧px-Question_book.[Link]' width='2∧' height='20' srcset='[Link]
Question_book.svg/3∪px-Question_book.[Link] 1.∧x, [Link]
svg/∧0px-Question_book.[Link] 2x' data- le-width='2∧2' data- le-height='199' /></a> Artista original: GNOME icon artists, Linfocito
B
• Archivo:[Link] Fuente: [Link] Licencia: Public do-
main Colaboradores: This version created by Pumbaa, using a proper partial circle and SVG geometry features. (Former versions used
to be slightly warped.) Artista original: SVG version was created by User:Grunt and cleaned up by 324∩, based on the earlier PNG version,
created by Reidab.
• Archivo:Computer-aj_aj_ashton_01.svg Fuente: [Link]
-_Yellow_theme.svg Licencia: CC0 Colaboradores: [Link] Artista original: AJ
from [Link]
• Archivo:[Link] Fuente: [Link] Licencia: CC-BY-SA-3.0
Colaboradores: Trabajo propio (Hecho con OpenO [Link] Draw) Artista original: kn
• Archivo:[Link] Fuente: [Link] Licencia: CC-BY-SA-3.0
Colaboradores: Trabajo propio Artista original: Jesuja
• Archivo:Crystal_Clear_action_edit_add.png Fuente: [Link]
edit_add.png Licencia: LGPL Colaboradores: All Crystal Clear icons were posted by the author as LGPL on kde-look; Artista original:
Everaldo Coelho and YellowIcon;
• Archivo:Crystal_Clear_app_kcoloredit.png Fuente: [Link]
[Link] Licencia: LGPL Colaboradores: All Crystal Clear icons were posted by the author as LGPL on kde-look; Artista original:
Everaldo Coelho and YellowIcon;
• Archivo:[Link] Fuente: [Link] Licencia: LGPL Colabo-
radores: Wikipedia until June, 200∨ Artista original: Wikimedia users ClockworkSoul, CyberSkull, Optimager, White Cat, Erina, AzaToth,
Pbroks13.
• Archivo:Cuadro_de_ventajas_y_desventajas_del_uso_del_Paradigma_tradicional.JPG Fuente: [Link]
wikipedia/commons/2/21/Cuadro_de_ventajas_y_desventajas_del_uso_del_Paradigma_tradicional.JPG Licencia: CC BY-SA 3.0
Colaboradores: Trabajo propio Artista original: Arisneth Chanapi
• Archivo:[Link] Fuente: [Link] Licencia: CC0 Cola-
boradores: Trabajo propio Artista original: Niqueco
• Archivo:[Link] Fuente: [Link] Licencia: Copyrighted free use Co-
laboradores: Photograph taken by Qu1j0t3. Artista original: User Qu1j0t3 on [Link]
• Archivo:[Link] Fuente: [Link]
Licencia: CC-BY-SA-3.0 Colaboradores: versión en español de w:Image:[Link] Artista original: svg en español por Jipumarino

• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabora-

dores: Trabajo propio Artista original: Angelalg
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colaboradores:
[4] [∧] Artista original: Jan (Johannes) Misset?
• Archivo:Ejemplo_de_JFrame.png Fuente: [Link] Licencia:
CC BY-SA 4.0 Colaboradores: Trabajo propio Artista original: Ivordro UV
• Archivo:El_modelo_de_desarrollo_en_cascada.svg Fuente: [Link]
desarrollo_en_cascada.svg Licencia: CC BY 3.0 Colaboradores: [Link] Artista
original: Paulsmith99
• Archivo:Esoteric_Taijitu.svg Fuente: [Link] Licencia: Public do-
main Colaboradores: Trabajo propio Artista original: Kenny Shen
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Cola-
boradores: ? Artista original: ?
• Archivo:[Link] Fuente: [Link] Licencia: CC
BY-SA 2.∧ Colaboradores: No machine-readable source provided. Own work assumed (based on copyright claims). Artista original: No
machine-readable author provided. Faxe assumed (based on copyright claims).
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colaboradores:
? Artista original: ?
• Archivo:Garbage_collection.gif Fuente: [Link] Licencia: Pu-
blic domain Colaboradores: Trabajo propio Artista original: German
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colaboradores:
Hacker Emblem Artista original: Eric S. Raymond
205.3. ORIGEN DEL TEXTO Y LAS IMÁGENES, COLABORADORES Y LICENCIAS 393

• Archivo:[Link] Fuente: [Link] Licencia: LGPL Colabo-

radores: [Link] Artista original: David
Vignoni
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colaboradores: Tra-
bajo propio Artista original: Angelalg
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabora-
dores: U.S. Naval Historical Center Online Library Photograph NH 9∨∧∨∨-KN Artista original: Courtesy of the Naval Surface Warfare
Center, Dahlgren, VA., 19∪∪.
• Archivo:[Link] Fuente: [Link] Li-
cencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Omerta-ve
• Archivo:Heckert_GNU_white.svg Fuente: [Link] Licencia:
CC BY-SA 2.0 Colaboradores: [Link] Artista original: Aurelio A. Heckert <aurium@[Link]>
• Archivo:Historical_ampersand_evolution.svg Fuente: [Link]
[Link] Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Alatius
• Archivo:[Link] Fuente: [Link] Licencia: CC BY-SA 3.0 Colaborado-
res: [Link] Artista original: ~DarKobra at Deviantart
• Archivo:Hola_Mundo_AppleScript.png Fuente: [Link]
png Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Jaimemf
• Archivo:[Link] Fuente: [Link] Licencia: Pu-
blic domain Colaboradores: ? Artista original: ?
• Archivo:Icon_tools.svg Fuente: [Link] Licencia: CC BY 2.∧ Colabora-
dores: File:Icon [Link]: [Link] Artista original: David Vignoni, STyx
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Cola-
boradores: No machine-readable source provided. Own work assumed (based on copyright claims). Artista original: No machine-readable
author provided. Glioma assumed (based on copyright claims).
• Archivo:Linux_API_and_Linux_ABI.svg Fuente: [Link]
[Link] Licencia: CC BY-SA 4.0 Colaboradores: Trabajo propio Artista original: ScotXW
• Archivo:Linux_kernel_interfaces.svg Fuente: [Link] Li-
cencia: CC BY-SA 3.0 Colaboradores: Esta imagen incluye elementos que han sido tomados o adaptados de esta: <a
href='//[Link]/wiki/File:[Link]' class='image'><img alt='[Link]' src='[Link]
wikipedia/commons/thumb/0/0a/[Link]/1∩[Link]' width='1∩' height='20' srcset='[Link]
org/wikipedia/commons/thumb/0/0a/[Link]/2∧[Link] 1.∧x, [Link]
thumb/0/0a/[Link]/[Link] 2x' data- le-width='249' data- le-height='29∩' /></a> [Link]. Artista ori-
ginal: ScotXW
• Archivo:Logical_connectives_Hasse_diagram.svg Fuente: [Link]
connectives_Hasse_diagram.svg Licencia: Public domain Colaboradores: Trabajo propio Artista original: Watchduck (a.k.a. Tilman
Piesk)
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Cola-
boradores: ? Artista original: ?
• Archivo:Metro_pd.jpg Fuente: [Link] Licencia: Public domain Colabo-
radores: Trabajo propio Artista original: Angelalg
• Archivo:[Link] Fuente: [Link] Licencia: Public domain
Colaboradores: ? Artista original: Chabacano
• Archivo:Multiple_Branching.jpg Fuente: [Link] Licencia: Pu-
blic domain Colaboradores: Trabajo propio Artista original: Ben Honan
• Archivo:[Link] Fuente: [Link] Licencia: Attribution Colaboradores:
Based on original image by Larry Ewing, created using Sodipodi Artista original: gg3po ([Link] source)
• Archivo:Nuvola_apps_edu_science.svg Fuente: [Link]
Licencia: LGPL Colaboradores: [Link]
Artista original: David Vignoni / ICON KING
• Archivo:Nuvola_apps_konsole.png Fuente: [Link] Licen-
cia: LGPL Colaboradores: [Link] Artista original: David Vignoni / ICON KING
• Archivo:Nuvola_devices_cdrom_unmount.png Fuente: [Link]
cdrom_unmount.png Licencia: LGPL Colaboradores: [Link] Artista original: David Vignoni / ICON KING
• Archivo:Nuvola_mimetypes_template_source.png Fuente: [Link]
mimetypes_template_source.png Licencia: LGPL Colaboradores: [Link] Artista original: David Vignoni / ICON
KING
• Archivo:[Link] Fuente: [Link]
wikipedia/commons/3/3∩/[Link] Licencia: CC BY-SA 3.0
Colaboradores: Taking a screenshot, then editing using [Link] Artista original: Carrot Lord
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colaborado-
res: Trabajo propio Artista original: Angelalg
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colaboradores: Traba-
jo propio Artista original: Angelalg
394 CAPÍTULO 205. ZENPHP

• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabo-

radores: Trabajo propio Artista original: Angelalg
• Archivo:Overview_of_the_Common_Language_Infrastructure.svg Fuente: [Link]
Overview_of_the_Common_Language_Infrastructure.svg Licencia: Public domain Colaboradores: Trabajo propio Artista original: Jarkko
Piiroinen
• Archivo:Phonebloks_open.jpg Fuente: [Link] Licencia: CC BY-
SA 3.0 Colaboradores: Provided by email Artista original: Dave Hakkens
• Archivo:Pipe_and_broken_bar.svg Fuente: [Link] Licen-
cia: Public domain Colaboradores: Trabajo propio Artista original: GJo
• Archivo:[Link] Fuente: [Link] Li-
cencia: Public domain Colaboradores: Trabajo propio Artista original: Theodoric Stier
• Archivo:[Link] Fuente: [Link] Licencia:
Public domain Colaboradores:
• [Link] Artista original: [Link]: Moriel
• Archivo:Puertas_lógicas_de_circuitos.jpg Fuente: [Link]
de_circuitos.jpg Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: MONIMINO
• Archivo:Pure_data_screen_capture.png Fuente: [Link]
png Licencia: CC-BY-SA-3.0 Colaboradores: ? Artista original: ?
• Archivo:Rubber_duck_assisting_with_debugging.jpg Fuente: [Link]
assisting_with_debugging.jpg Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Tom Morris
• Archivo:SNL_Logo.png Fuente: [Link] Licencia: CC BY-SA 3.0 Cola-
boradores: Trabajo propio Artista original: Lacabra2∧
• Archivo:SO_Home_Page.jpg Fuente: [Link] Licencia: Public do-
main Colaboradores: Trabajo propio Artista original: George Edison
• Archivo:Sciences_humaines.svg Fuente: [Link] Licencia:
LGPL Colaboradores: eriollsdesigns - Lanthys Icon Set (for KDE) Artista original: Adrien Facélina
• Archivo:Select-object_Pure_Data.svg Fuente: [Link] Li-
cencia: BSD Colaboradores: SVG converted from the PostScript output of the software Artista original: Miller-Puckette
• Archivo:[Link] Fuente: [Link] Licencia: Public
domain Colaboradores: Trabajo propio Artista original: PiAndWhippedCream
• Archivo:Spanish_Language_Wiki.svg Fuente: [Link]
Licencia: CC BY-SA 3.0 Colaboradores: Derived from Wiki [Link] by user:Kimbar Artista original: [Link]
• Archivo:Spanish_Wikiquote.SVG Fuente: [Link] Licencia:
CC BY-SA 3.0 Colaboradores: derived from [Link] Artista original: [Link]
• Archivo:Sports_icon.png Fuente: [Link] Licencia: Public domain Co-
laboradores: made by myself Artista original: Pepetps
• Archivo:Start_pd.jpg Fuente: [Link] Licencia: Public domain Colaborado-
res: Trabajo propio Artista original: Angelalg
• Archivo:Steven_Levy_(1).jpg Fuente: [Link] Licencia:
CC BY 2.0 Colaboradores: [Link] Artista original: Joi
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabora-
dores: Trabajo propio Artista original: Angelalg
• Archivo:TE_Conex_00.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Conex_05.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Conex_09.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Conex_10.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Conex_12.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Conex_14.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Interu_05.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Interu_06.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Interu_07.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Interu_08.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
205.3. ORIGEN DEL TEXTO Y LAS IMÁGENES, COLABORADORES Y LICENCIAS 39∧

• Archivo:TE_Interu_1A.svg Fuente: [Link] Licencia: GFDL Colabo-

radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Interu_1B.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Interu_1C.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Interu_2A.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Interu_2B.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Interu_3A.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Interu_3B.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:TE_Interu_4B.svg Fuente: [Link] Licencia: GFDL Colabo-
radores: Trabajo propio Artista original: Dnu∩2
• Archivo:Tabla_de_verdad.svg Fuente: [Link] Licencia: CC BY-
SA 3.0 Colaboradores: Trabajo propio Artista original: Dnu∩2
• Archivo:[Link] Fuente: [Link] Licencia: CC BY-SA 2.∧
Colaboradores: <a href='//[Link]/wiki/File:[Link]' class='image'><img alt='[Link]' src='[Link]
[Link]/wikipedia/commons/thumb/∧/∧∩/[Link]/[Link]' width='32' height='32' srcset='[Link]
[Link]/wikipedia/commons/thumb/∧/∧∩/[Link]/4∪[Link] 1.∧x, [Link]
commons/thumb/∧/∧∩/[Link]/∨[Link] 2x' data- le-width='4∪' data- le-height='4∪' /></a> The Tango! Desktop
Project. Artista original: The people from the Tango! project.
• Archivo:Test_pd.png Fuente: [Link] Licencia: Public domain Colaborado-
res: Trabajo propio Artista original: Angelalg
• Archivo:Translation_arrow.svg Fuente: [Link] Licencia: CC-
BY-SA-3.0 Colaboradores: grá co vectorial con Inkscape.
Artista original: Jesse Burgheimer
• Archivo:Two_red_dice_01.svg Fuente: [Link] Licencia: CC0
Colaboradores: Open Clip Art Library Artista original: Stephen Silver
• Archivo:USB_flash_drive.JPG Fuente: [Link] Licencia: CC-
BY-SA-3.0 Colaboradores: ? Artista original: ?
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colaborado-
res: Trabajo propio Artista original: Lipedia
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabo-
radores: ? Artista original: ?
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabo-
radores: ? Artista original: ?
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colaborado-
res: Trabajo propio Artista original: Lipedia
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabo-
radores: ? Artista original: ?
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabo-
radores: ? Artista original: ?
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabo-
radores: ? Artista original: ?
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colaborado-
res: Trabajo propio Artista original: Watchduck (a.k.a. Tilman Piesk)
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabo-
radores: ? Artista original: ?
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabo-
radores: ? Artista original: ?
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabo-
radores: ? Artista original: ?
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colaboradores:
Trabajo propio Artista original: Lipedia
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabo-
radores: ? Artista original: ?
• Archivo:[Link] Fuente: [Link] Licencia: Public domain Colabo-
radores: ? Artista original: ?
39∨ CAPÍTULO 205. ZENPHP

• Archivo:Waterfall_model.png Fuente: [Link] Licencia: CC BY-

SA 2.∧ Colaboradores: Transferido desde [Link] a Commons. Artista original: The original uploader was PaulHoadley de Wikipedia
en inglés
• Archivo:[Link] Fuente: [Link] Licencia: CC BY-SA
3.0 Colaboradores: Trabajo propio Artista original: User:Bastique, User:Ramac et al.
• Archivo:[Link] Fuente: [Link] Licencia: CC BY-SA
3.0 Colaboradores: This is a cropped version of Image:[Link]. Artista original: Vectorized by Simon 01:0∧, 2 August
200∨ (UTC) Updated by Time3000 1∩ April 200∩ to use o cial Wikinews colours and appear correctly on dark backgrounds. Originally
uploaded by Simon.
• Archivo:[Link] Fuente: [Link] Licen-
cia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Snorky
• Archivo:[Link] Fuente: [Link] Licencia: CC
BY-SA 3.0 Colaboradores: originally uploaded there by author, self-made by author Artista original: es:Usuario:Pybalo

205.3.3 Licencia del contenido

• Creative Commons Attribution-Share Alike 3.0