Programacin.

ndice general
1

Programacin

1.1

Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Lxico y programacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3

Programas y algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4

Compilacin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5

Programacin e ingeniera del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6

Referencias histricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.7

Objetivos de la programacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.8

Ciclo de vida del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.9

Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.10 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.11 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Portal:Programacin

&

3.1

Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3

Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Acoplamiento secuencial

4.1

Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Adobe Director

5.1

Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2

Timeline

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3

Director y Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

5.4

Shockwave / Shockwave 3D

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

5.5

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

5.6

Enlaces externos

10

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Anidamiento (informtica)

12

6.1

12

En las planillas de clculo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

i

ii

NDICE GENERAL
6.2

En programacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

6.3

Vase tambin

12

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Antipatrn de diseo

13

7.1

Algunos antipatrones de desarrollo de software . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

7.1.1

Antipatrones de gestin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

7.1.2

Antipatrones de gestin de proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

7.1.3

Antipatrones generales de diseo de software

. . . . . . . . . . . . . . . . . . . . . . . .

14

7.1.4

Antipatrones de programacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

7.1.5

Antipatrones metodolgicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

7.1.6

Antipatrones de gestin de la conguracin

. . . . . . . . . . . . . . . . . . . . . . . . .

16

7.2

Algunos antipatrones organizacionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

7.3

Relacin alfabtica de otros antipatrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

7.4

Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

7.5

Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

Archivo de cabecera

21

8.1

Motivacin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

8.2

Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

8.3

Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

8.4

Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

Asercin (informtica)

24

9.1

Uso de las aserciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

9.1.1

Aserciones en el diseo por contrato . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

9.1.2

Aserciones en tiempo de ejecucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

9.1.3

Aserciones durante el ciclo de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

9.1.4

Aserciones estticas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

9.2

Desactivacin de las aserciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

9.3

Comparacin con los manejadores de errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

9.4

Enlaces externos

26

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 Automatizacin de tareas

27

11 Base de cdigo

28

11.1 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12 Bean

28
29

12.1 Bean en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

12.2 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

13 Beta tester

30

13.1 Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

13.2 Alfa tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

NDICE GENERAL

iii

13.3 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

13.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

14 Bifurcacin (sistema operativo)

31

14.1 UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

14.2 Vase tambin

31

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15 Binding

32

15.1 Psicologa y educacin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

15.2 Informtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

15.3 Derecho mercantil

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

15.4 Enlaces externos

16 Bloqueo mutuo

33

16.1 Representacin de Bloqueos Mutuos usando grafos . . . . . . . . . . . . . . . . . . . . . . . . . .

33

16.2 Condiciones necesarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

16.3 Evitando bloqueos mutuos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

16.5 Livelock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

16.4 Prevencin

17 Bodyshopping

35

17.1 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

18 BrookGPU

36

19 Caja blanca (sistemas)

37

19.1 Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20 Caja negra (sistemas)

37
38

20.1 Justicacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

20.2 Caja negra y programacin modular

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

20.3 Pruebas de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

20.4 Caja negra vs 'Cajanegrizar' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

20.5 Vase tambin

38

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 CamelCase

40

21.1 Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

21.2 Enlaces externos

40

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22 Caml
22.1 Ejemplos

41
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22.1.1 Hola Mundo

41

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

22.1.2 Funcin factorial (recursividad y programacin puramente funcional) . . . . . . . . . . . .

41

22.1.3 Derivacin numrica (funciones de alto orden) . . . . . . . . . . . . . . . . . . . . . . . .

41

22.1.4 Transformada Wavelet discreta (concordancia de patrones) . . . . . . . . . . . . . . . . .

42

iv

NDICE GENERAL
22.2 Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

22.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

22.4 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

22.4.1 Libros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

23 Cierre de exclusin 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

26.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

26.2 Documentacin y tutoriales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

26.3 Principales funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

26.4 CTest, CPack, CDash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

26.5 Aplicaciones que utilizan CMake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

26.6 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

26.7 Enlaces externos

27 Codecademy

48

27.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

27.2 Code Year

48

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27.3 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

27.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

27.5 Enlaces externos

49

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28 Cdigo cerrado
28.1 Vase tambin

50
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

29 Cdigo compilado

51

30 Cdigo mutante

52

31 Cdigo objeto

53

31.1 Cdigo objeto en lenguajes de programacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

31.2 Errores comunes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

31.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

31.4 Enlaces externos

53

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32 Ofuscacin
32.1 Informtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54
54

NDICE GENERAL

32.1.1 Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

32.2 Otros objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

32.3 Enlaces externos

55

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33 ColdFusion

56

33.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

33.2 Versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

33.3 Ejemplos de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

33.4 Enlaces externos

57

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34 Coloreado de sintaxis

58

34.1 Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

34.2 Programas con coloreado de sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

34.3 Vase tambin

58

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35 Comentario (informtica)

59

35.1 Informacin general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

35.2 Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

35.2.1 Planeacin / Revisin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

35.2.2 Descripcin de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

35.2.3 Descripcin algortmica

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

35.2.4 Inclusin de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

35.2.5 Depuracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

35.2.6 Generacin de documentacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

35.3 Estilos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

35.3.1 Etiquetas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

35.4 Curiosidades

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.5.1 Ensamblador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.5.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.5.3 C/C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.5.4 Delphi

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.5.5 Lua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.5.6 Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.5.7 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.5.8 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.5.9 Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.5.10 cdigo HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.5.11 SQL

62

35.5 Ejemplos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35.5.12 Visual Basic

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.5.13 Pauscal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.5.14 PHP

62

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vi

NDICE GENERAL
35.5.15 Cobol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.6 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

35.7 Enlaces externos

63

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36 Compatibilidad (informtica)

64

36.1 Problemas de compatibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

36.2 Emulacin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

36.3 OpenSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

36.4 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

36.5 Enlaces externos

37 Competicin Internacional Universitaria ACM de Programacin

66

37.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

37.2 Reglas de la competicin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

37.3 Competiciones locales, regionales y nal mundial

. . . . . . . . . . . . . . . . . . . . . . . . . .

67

37.4 Lista de competiciones regionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

37.5 Ganadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

37.6 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

37.7 Enlaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

37.7.1 Jueces en Lnea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

38 Computacin parasitaria

69

38.1 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

38.2 Enlaces externos

69

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39 Conectiva lgica

70

39.1 Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

39.1.1 Lenguaje natural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

39.1.2 Lenguajes formales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

39.2 Lista de conectivos lgicos comunes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

39.2.1 Lista de conectivos lgicos comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

39.2.2 Historia de las notaciones

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

39.4 Propiedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

39.5 Ciencias de la computacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

39.6 Conectivas por el nmero de argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

39.6.1 Sin argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

39.6.2 Con un argumento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

39.6.3 Con dos argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

39.3 Redundancia

39.7 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

39.8 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

39.9 Enlaces externos

73

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

NDICE GENERAL

vii

40 Conguracin regional

74

40.1 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

40.2 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

40.3 Enlaces externos

74

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41 Conteo de referencias
41.1 Vase tambin

75
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42 Convencin de Nombres (Programacin)

75
76

42.1 Benecios potenciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

42.2 Desafos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

42.3 El valor del negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

42.4 Elementos comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

42.4.1 Longitud de identicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

42.4.2 Maysculas, minsculas y nmeros

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

42.4.3 Identicadores de varias palabras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

42.5 Metadatos y convenciones hbridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

42.5.1 Notacin hngara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

42.5.2 Notacin posicional

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

42.5.3 Esquema de palabra compuesta (del lenguaje) . . . . . . . . . . . . . . . . . . . . . . . .

78

42.6 Convenciones especcas del lenguaje

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

42.6.2 Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

42.6.3 C y C++

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

42.6.4 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

42.6.5 JavaScript

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

42.6.6 Lisp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

42.6.7 .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

42.6.8 Objective-C

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

42.6.9 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

42.6.10 Python y Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

42.6.1 ActionScript

42.7 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

42.8 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

42.9 Enlaces externos

80

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43 Cracking (software)
43.1 Vase tambin

81
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

44 Cuaderno de carga

82

45 Curricacin

83

45.1 Nomenclatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

45.2 Denicin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

viii

NDICE GENERAL
45.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

45.4 Enlaces externos

83

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46 Cdigo enhebrado

84

46.1 Historia que llev al cdigo enhebrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

46.2 Desarrollo del cdigo enhebrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

46.3 Modelos de enhebrado

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

46.3.1 Enhebrado directo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

46.3.2 Enhebrado indirecto

86

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46.3.3 Enhebrado de subrutina

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

46.3.5 Enhebrado de Human . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

46.3.6 Enhebrados menos usados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

46.4 Bifurcaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

46.5 Amenidades comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

46.6 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

46.7 Lectura adicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

46.8 Vase tambin

88

46.3.4 Enhebrado de token

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47 Cdigo inalcanzable
47.1 Causas

89

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89

47.2 Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89

47.3 Anlisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

47.3.1 Proling

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

47.5 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

47.6 Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

47.7 Enlaces externos

90

47.4 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48 Cdigo muerto

91

48.1 Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

48.2 Anlisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

48.3 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

48.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

48.5 Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

48.6 Enlaces externos

91

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49 Cdigo redundante
49.1 Ejemplos

93

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

49.2 Eliminacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

49.3 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

49.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

NDICE GENERAL

ix

50 Dato

94

50.1 Vase tambin

50.2 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

94

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

94

51 Depuracin de programas

95

51.1 Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

95

51.2 Aplicacin

95

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51.3 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52 Desarrollador de software
52.1 Vase tambin

95
96

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53 Desarrollo en cascada

96
97

53.1 Fases del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97

53.1.1 Anlisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97

53.1.2 Diseo del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97

53.1.3 Diseo del Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

53.1.4 Codicacin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

53.1.5 Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

53.1.6 Vericacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

53.1.7 Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

53.2 Variantes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

53.3 Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

53.4 Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

53.5 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

53.6 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

99

53.7 Enlaces externos

99

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54 Desarrollo en espiral
54.1 Introduccin

100

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

54.2 Ciclos o Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

54.2.1 Tareas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

54.3 Mecanismos de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

54.4 Variaciones del Modelo En Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
54.5 Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
54.6 Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
54.7 Inconvenientes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

54.8 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

54.9 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

54.10Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

55 Desarrollo iterativo y creciente

55.1 Concepto de desarrollo iterativo y creciente

103
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

NDICE GENERAL
55.2 Ciclo de vida

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

55.2.1 Consideraciones sobre el momento de aplicacin

. . . . . . . . . . . . . . . . . . . . . . 103

55.2.2 Etapa de inicializacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

55.2.3 Etapa de iteracin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

55.3 Caso prctico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

55.4 Caractersticas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

55.5 Ventajas del desarrollo incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

55.6 Ventajas del desarrollo iterativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
55.7 Debilidades de este modelo de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
55.8 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

55.9 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

56 Deteccin dinmica de invariantes

107

56.1 Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

57 Diagrama de colaboracin

108

57.1 Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

57.2 Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
57.3 Mensajes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

57.4 Flujos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

57.5 Cambios en versiones recientes de UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
58 Diagrama de ujo

110

58.1 Normas de trabajo

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

58.2 Descripcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

58.3 Tipos de diagramas de ujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
58.4 Simbologa y signicado

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

58.5 Cursograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

58.5.1 Simbologa y normas del cursograma

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

58.6 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

58.7 Ventajas de los diagramas de ujo

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

58.8 Software para diseo de diagramas de ujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

58.9 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

58.10Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
58.11Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

59 Diagrama Nassi-Shneiderman

114

59.1 Descripcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

59.2 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
59.3 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

59.3.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

60 di

115

NDICE GENERAL

xi

60.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

60.2 Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
60.3 Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
60.4 Variantes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

60.4.1 Edit script

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

60.5 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

60.6 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

60.7 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

61 Direccin de retorno

118

62 Diseo estructurado

119

62.1 Etapas del Diseo estructurado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

62.1.1 Descomposicin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

62.1.2 Jerarqua de mdulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

62.1.3 Independencia

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

62.2 Evaluando el diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

62.2.1 Acoplamiento

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

62.2.2 Cohesin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

62.2.3 Fan-In y Fan-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
62.3 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

63 Distancia de Damerau-Levenshtein

122

63.1 Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

63.2 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

63.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

64 Distancia de Levenshtein

123

64.1 El algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

64.2 Implementacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
64.2.1 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
64.2.2 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
64.2.3 C#

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

64.2.4 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

64.2.5 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
64.2.6 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
64.2.7 Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
64.2.8 PHP
64.2.9 Delphi

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

64.2.10 [Link] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

64.2.11 ActionScript 3.0

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

64.2.12 ColdFusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

64.2.13 JavaScript (NodeJS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

xii

NDICE GENERAL
64.3 Aplicaciones

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

64.4 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

64.5 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

65 DLO

126

65.1 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

66 Driver Chain Manager

127

66.1 Qu hace? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

66.1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
66.1.2 Capacidades de DCM

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

66.1.3 Cuestiones fuera del alcance de DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

66.2 Sotrware que utiliza DCM

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

66.2.1 Aplicaciones que utilizan DCM

66.2.2 Empresas desarrolladoras

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

66.2.3 Sistemas operativos que soportan DCM . . . . . . . . . . . . . . . . . . . . . . . . . . 128

66.3 Funcionamiento de la cadena de drivers
66.3.1 El problema

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

66.3.2 Forma de solucionarlo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

66.4 Otras aplicaciones que utilizan DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
66.5 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

66.6 Fuentes y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

67 Dublin Core

129

67.1 Descripcin general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

67.2 Clasicacin y elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
67.3 Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
67.4 Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
67.5 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
68 eAthena
68.1 Enlaces externos

132
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

69 Efecto Hover

133

69.1 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

69.2 Enlaces de inters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
70 Emtp

134

70.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

70.2 ATP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
70.3 Mtodo de solucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
70.4 Distribucin de EMTP-ATP
70.5 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

70.6 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

NDICE GENERAL

xiii

71 Enlace dinmico

135

72 Enlace esttico

136

73 Enlazado

137

74 Entrada chapuza

138

74.1 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

74.2 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

75 Error de software

139

75.1 Orgenes del trmino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

75.2 Defectos de diseo de programas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
75.3 Errores de programacin comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
75.4 Defectos de instalacin o programacin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

75.5 Cdigos de errores de lenguajes de programacin

75.6 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . 140

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

75.7 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

75.8 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

76 Estilo de programacin

142

76.1 Caractersticas del estilo

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

76.1.1 Nombres de variable apropiadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

76.1.2 Estilo de indentacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
76.1.3 Valores booleanos en estructuras de decisin . . . . . . . . . . . . . . . . . . . . . . . . . 142
76.1.4 Bucles y estructuras de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
76.1.5 Espaciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
76.2 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

76.3 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

76.3.1 Convenciones de cdigo en castellano . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

76.3.2 Convenciones de cdigo en ingls

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

76.3.3 Convenciones de cdigo de proyectos

77 Eventos del ratn
77.1 Vase tambin

144
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

78 Exclusin mutua (informtica)

78.1 Vase tambin
79 Expresin regular

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

145

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
146

79.1 Construccin de expresiones regulares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

79.2 Aplicaciones

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

79.3 Las expresiones regulares en programacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

79.4 Descripcin de las expresiones regulares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

xiv

NDICE GENERAL
79.4.1 El punto ". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
79.4.2 La admiracin "!"

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

79.4.3 La barra inversa o antibarra "\" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

79.4.4 Los corchetes "[ ]" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
79.4.5 La barra "|" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
79.4.6 El signo de dlar "$" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
79.4.7 El acento circunejo "^" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
79.4.8 Los parntesis "()" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
79.4.9 El signo de interrogacin "?" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
79.4.10 Las llaves "{}" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
79.4.11 El asterisco "*" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
79.4.12 El signo de suma "+" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
79.4.13 Grupos annimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
79.5 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

80 Flag

153

80.1 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

81 Front-end y back-end

154

81.1 Informtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

81.2 Tecnologa

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

81.3 Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

81.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
82 Fuga de memoria
82.1 RAII

156

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

82.2 Fugas de memoria en lenguajes con recolector de basura . . . . . . . . . . . . . . . . . . . . . . . 156

82.3 Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
83 Generacin de cdigo

158

83.1 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

84 Generador de nmeros aleatorios

84.1 Algoritmos

159

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

84.2 Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

84.3 Enlaces externos
85 Gledplay

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
161

85.1 Dispositivos Soportados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

85.2 GledDraw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
85.3 GledVideo

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

85.4 GledSave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

85.5 GledApplication

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

85.6 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

NDICE GENERAL

xv

86 GPGPU

163

86.1 Modelo de programacin GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

86.2 Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
86.3 Crticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
86.4 Otros

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

86.5 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

86.6 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

87 Hackathon

165

87.1 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

87.2 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

88 Hacker

166

88.1 Otros signicados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

88.2 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
88.2.1 ARPANET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
88.2.2 UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
88.2.3 GNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
88.2.4 LINUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
88.3 tica hacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
88.4 Controversia

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

88.4.1 Ambigedad y debate

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

88.5 Activismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

88.6 Terminologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
88.6.1 OverHat

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

88.6.2 White hat y black hat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

88.6.3 Samuri

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

88.6.4 Phreaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

88.6.5 Lamer o script-kiddie

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

88.6.6 Newbie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

88.7 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

88.8 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

88.9 Descripcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
88.10Enlaces externos
89 Heisenbug

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
172

89.1 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

89.2 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
90 Hoja de estilo
90.1 Vase tambin
90.2 Enlaces externos

173
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

90.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

xvi

NDICE GENERAL

91 Hola mundo
91.1 Vase tambin

174
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

91.2 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

91.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

92 Homebrew

175

92.1 Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

92.2 Homebrew en diferentes consolas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
92.2.1 Sega Dreamcast

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

92.2.2 Nintendo Entertainment System (NES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

92.2.3 Super Nintendo Entertainment System (SNES) . . . . . . . . . . . . . . . . . . . . . . . . 176
92.2.4 Nintendo DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
92.2.5 Sony PSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
92.2.6 Microsoft Xbox

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

92.2.7 Microsoft Xbox 360 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

92.2.8 Nintendo Wii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
92.2.9 PlayStation 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
92.3 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

92.4 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

93 ICONIX
93.1 Ventajas de Iconix

179
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

93.2 Tareas de la metodologa Iconix

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

93.2.1 Fase 1: Anlisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

93.2.2 Fase 2: Anlisis y diseo preliminar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
93.2.3 Fase 3: Diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
93.2.4 Fase 4: Implementacin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

93.3 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

93.4 Conceptos Relacionados
93.5 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

93.5.1 Fase 2: Anlisis y diseo preliminar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

93.5.2 Fase 3: Diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
93.5.3 Fase 4: Implementacin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

93.6 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

93.7 Conceptos Relacionados
93.8 Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

94 Anexo:Implementaciones de Smalltalk

181

95 Anexo:Implementaciones para algoritmo de rut

182

95.1 Objective-C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

95.2 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
95.3 Visual Basic MS Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

NDICE GENERAL

xvii

95.4 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
95.5 Perl 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
95.6 Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
95.7 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
95.8 Transact-SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
95.9 MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
95.10PSeInt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
95.11Python
95.12Ruby

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

95.13Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
95.14Pl/pgsql de PostgreSql

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

96 Inanicin (informtica)

185

97 Indireccin

186

98 Infraestructura de lenguaje comn

187

98.1 Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

99 Ingeniera de software

189

99.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

99.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
99.3 Recursos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

99.3.1 Recurso humano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

99.3.2 Recursos de software reutilizables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
99.3.3 Recursos de entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
99.4 Implicaciones socioeconmicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
99.4.1 Econmicamente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
99.4.2 Socialmente
99.5 Notaciones

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

99.5.1 LUM (lenguaje unicado de modelado) o UML . . . . . . . . . . . . . . . . . . . . . . . 191

99.5.2 BPMN (notacin para el modelado de procesos de negocios)

. . . . . . . . . . . . . . . . 191

99.5.3 Diagrama de ujo de datos (DFD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

99.6 Herramienta CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
99.7 Metodologa

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

99.7.1 Etapas del proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

99.7.2 Ventajas* [22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
99.8 Modelos y Ciclos de Vida del Desarrollo de Software

. . . . . . . . . . . . . . . . . . . . . . . . 195

99.8.1 Modelo en cascada o clsico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

99.8.2 Modelo de prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
99.8.3 Modelo en espiral

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

99.8.4 Modelo de desarrollo por etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

99.8.5 Modelo Incremental o Iterativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

xviii

NDICE GENERAL
99.8.6 Modelo RAD (rapid application development) . . . . . . . . . . . . . . . . . . . . . . . . 197
99.8.7 Modelo de desarrollo concurrente

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

99.8.8 Proceso unicado del desarrollo de software . . . . . . . . . . . . . . . . . . . . . . . . . 197

99.9 Producto

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

99.10Naturaleza de la Ingeniera de Software

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

99.11Participantes y papeles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

99.11.1 Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
99.11.2 Desarrolladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
99.11.3 Gestores

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

99.11.4 Usuarios nales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

99.11.5 Cdigo tico de un ingeniero de software

. . . . . . . . . . . . . . . . . . . . . . . . . . 199

99.12Educacin tica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

99.12.1 Organizaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
99.13Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

99.14Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
99.15Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
99.16Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

100Instancia (informtica)
100.1Etimologa

202

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

100.2Programacin basada en clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

100.2.1 Clases como objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
100.3Programacin basada en prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
100.4Notas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
100.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
101Instruccin (informtica)

204

101.1Campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
101.2Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
101.3Repertorio

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

101.4Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

102Interfaz binaria de aplicaciones

206

102.1Descripcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
102.2EABI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
102.3Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

102.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
102.5Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
103Interfaz uida

208

103.1Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
103.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

NDICE GENERAL

xix

104Invariante (informtica)

210

104.1Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

105Jframe
105.1Herencia

211
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

105.2Constructores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
105.3Mtodos propios de la clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
105.4Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

106Usuario discusin:Juliasocorro

213

107Kanban (desarrollo)

215

107.1El mtodo Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

107.2Los principios del mtodo Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
107.3Cinco prcticas centrales del mtodo Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
107.4Comportamiento emergente con Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
107.5La implementacin del mtodo Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
107.6Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
107.7Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

108Kit de desarrollo de software

218

108.1Incompatibilidad de licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

108.2SDK para aadidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
108.3Trminos ms especcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
108.4Ejemplos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

108.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
108.6Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

108.7Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

109Kommander

220

109.1El editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

109.2El ejecutor

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

109.3Direcciones de Kommander
110Last Error (informtica)
110.1Errores personalizados

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
221

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

110.2En DELPHI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

110.3Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

111Lnea de cdigo fuente

111.1El uso de medidas de LCF

222
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

111.2Programas para contar lneas de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.3Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

111.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
111.5Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

112Macintosh Toolbox

225

113Macro

226

113.1Macros de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

113.2Macros en programacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
113.3Macros ocultas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

113.4Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

114Malla de tringulos 3D

227

114.1Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
114.2Obtencin de las mallas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
114.3Compresin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
115Mapeo objeto-relacional

229

115.1El problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

115.2Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
115.3Bases de datos distintas a SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
115.4Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

115.5Enlaces relacionados

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

116Mquina de estados

231

117Mquina desnuda

232

118MCML

233

118.1Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

119Metaprogramacin

234

119.1Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

120Microformatos Dublin Core

235

121Modelo de prototipos

236

121.1Etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
121.2Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
121.3Inconvenientes
121.4Conclusiones
121.5Vase tambin
122Modicador

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
238

NDICE GENERAL

xxi

122.1Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

123Modularidad

239

123.1Modularidad en Ciencias de la Computacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

123.2Modularidad en Biologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
123.3Modularidad en Economa y en la Empresa

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

123.4Modularidad en el diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

123.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
123.6Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

124Mdulo (informtica)

241

124.1Caractersticas de un mdulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

124.2Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

125Monitor (concurrencia)

242

125.1Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
125.2Exclusin mutua en un monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
125.3Tipos de monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
125.3.1 Tipo Hoare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
125.3.2 Tipo Mesa

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

125.4Vericacin de monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

125.4.1 Inicializacin de las variables del monitor

. . . . . . . . . . . . . . . . . . . . . . . . . . 244

125.4.2 Monitores tipo Hoare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

125.4.3 Monitores tipo Mesa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
125.5Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

125.6Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
126Anexo:Motores de persistencia

245

126.0.1 ColdFusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

126.0.2 Common Lisp

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

126.0.3 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

126.0.4 JavaScript

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

126.0.5 .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

126.0.6 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
126.0.7 PHP

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

126.0.8 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

126.0.9 Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
126.0.10Smalltalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
126.0.11C++

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

127Mtodo de depuracin del patito de goma

127.1Vase tambin

248

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

127.2Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

xxii

NDICE GENERAL

127.3Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

128Net Yaroze

249

128.1Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

128.2Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

128.3Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
129Nodo (informtica)

251

129.1Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
129.2Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

130Notacin Reddick

252

130.1Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
130.2Notacin para objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
130.3Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

131Notacin hngara
131.1Ejemplos

253

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

131.2Situacin actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

131.2.1 Ejemplo notaciones de 1 carcter
131.3Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

132Null

254

133NWNScript

255

133.1Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

134Objeto todopoderoso

256

134.1Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
134.2Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
134.3Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

135Oday

257

136Oset (informtica)

258

136.1Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

136.2Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
137OGNL

259

137.1Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
137.2Cadenas (chains) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
137.3Proyectos que usan OGNL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
137.4Enlaces externos
138OpenACS
138.1Arquitectura

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
260

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

NDICE GENERAL

xxiii

138.2Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
138.3Vase tambin
138.4Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

139Operaciones con archivos (informtica)

139.1Vase tambin

261

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

140Operador

262

140.1Operadores en un espacio vectorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

140.2Operadores bilineales o bivariantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
140.3Tipos generales de operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
140.3.1 Operadores de condicin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
140.3.2 Operadores de orden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
140.3.3 Operadores lgicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
140.3.4 Operaciones aritmticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
140.4Otros operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
140.5Temas relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
140.6Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
141Operando

265

141.1En informtica

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

141.2Conexiones externas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

141.2.1 Matemtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

141.2.2 Informtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
142Paquetes en PL/SQL

266

142.1Especicacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
142.2Cuerpo

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

143Pascal Casing

268

143.1Enlaces externos
144Patch (Unix)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
269

144.1Contexto de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

144.2Enlaces externos
145Phrogram

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
270

145.1Detalles tcnicos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

145.2Hola, Mundo! en KPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

145.3Filosofa

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

145.4Otra informacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

145.5The Phrogram Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
145.6Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

xxiv

NDICE GENERAL

146Plataforma de desarrollo
146.1Vase tambin

272

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

147Plataforma virtual didctica

273

147.1Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
147.2Herramientas que las componen

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

147.3Para que sirven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

147.4Autores y contribuyentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
147.5Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
147.6Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
147.7Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
147.8Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

148Polling

275

148.1Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
148.2Polling del registro de Windows

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

148.3Soluciones para el polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

148.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
148.5Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

149Poltergeist (informtica)
149.1Consecuencias

277

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

149.2Solucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
149.3Vase tambin
149.4Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

150Portabilidad
150.1Vase tambin

278
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

150.2Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
151Postcondicin

279

151.1Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

152Pragma

280

152.1Programacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
152.2Vase tambin
152.3Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

153Precondicin

281

153.1Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

154Primitiva de sincronizacin rendezvous

282

154.1Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
154.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

NDICE GENERAL

xxv

155Proceso (informtica)

283

155.1Creacin de un proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

155.2Terminacin de un proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
155.3Estados de un proceso

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

155.4Tipos de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

155.5Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

155.6Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
155.7Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
156Proceso para el desarrollo de software

286

156.1Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
156.2Actividades del desarrollo de software

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

156.2.1 Planicacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

156.2.2 Implementacin, pruebas y documentacin

. . . . . . . . . . . . . . . . . . . . . . . . . 286

156.2.3 Despliegue y mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

156.3Modelos de Desarrollo de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
156.3.1 Modelo de cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
156.3.2 Modelo de espiral

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

156.3.3 Desarrollo iterativo e incremental

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

156.3.4 Desarrollo gil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

156.3.5 Codicacin y correccin
156.3.6 Orientado a la Reutilizacin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

156.4Modelos de mejora de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

156.5Mtodos formales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
156.6Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

156.7Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
156.8Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

157Programa informtico

291

157.1Programacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
157.1.1 Paradigmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
157.1.2 Compilado o interpretando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
157.1.3 Programas que se auto-modican

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

157.2Ejecucin y almacenamiento de los programas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

157.2.1 Programas empotrados en hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
157.2.2 Programas cargados manualmente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
157.2.3 Programas generados automticamente

. . . . . . . . . . . . . . . . . . . . . . . . . . . 293

157.2.4 Ejecucin simultnea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

157.3Categoras funcionales
157.4Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

157.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
157.6Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

xxvi

NDICE GENERAL

157.7Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

158Programa interactivo

296

158.1Frente a Procesamiento por lotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

158.1.1 Ventajas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

158.1.2 Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

158.2Ejemplos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

158.2.1 Cajero automtico

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

158.2.2 Compresor de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

159Programacin lineal paramtrica

297

159.1Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
160Programacin visual

298

160.1Programacin orientada a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

160.2Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

161Programador

299

161.1Resea histrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

161.2Funciones del programador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
161.3Especialidades

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

161.4Notas y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

161.5Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

162Pseudocdigo
162.1Aplicaciones

301
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

162.2Sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
162.3Denicin de datos del pseudocdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
162.4Funciones y operaciones

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

162.5Estructuras de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

162.5.1 Estructuras secuenciales

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

162.5.2 Estructuras selectivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

162.5.3 Estructuras iterativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
162.5.4 El anidamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
162.6Desarrollo de algoritmos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

162.7Funciones y procedimientos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

162.8Ventajas del pseudocdigo sobre los diagramas de ujo

162.9Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . 304

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

162.10Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
162.11Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
162.12Vase tambin
163Puente de aplicacin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
305

NDICE GENERAL

xxvii

164Puntero inteligente

306

164.1Punteros inteligentes en Boost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

164.1.1 Scoped pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
164.1.2 Shared pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
164.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
165Pure data

308

165.1Tipos de objetos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

165.2Objetos ms importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

165.3Instalacin en GNU posibles problemas y soluciones . . . . . . . . . . . . . . . . . . . . . . . . . 310
165.4Introduccin rpida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
165.5Bibliotecas pdp, pidip y opencv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
165.6Patch patrones

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

165.7Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

165.8Material en espaol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

165.9Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

166QuadTIN

313

167Query string

314

167.1Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

168Quest3D

315

168.1Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

168.1.1 Lgica de las aplicaciones

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

168.1.2 Orientacin a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

168.1.3 Editores

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

168.1.4 Publicacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

168.2Requerimientos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
168.3Licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
168.4Aplicaciones

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

168.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
168.6Enlaces externos
169Quine (programa)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
317

169.1Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
169.1.1 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
169.1.2 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
169.1.3 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
169.1.4 Common Lisp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
169.1.5 Ocaml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
169.1.6 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
169.1.7 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

xxviii

NDICE GENERAL
169.1.8 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
169.1.9 BASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
169.1.10Pascal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
169.1.11Brainfuck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
169.1.12HQ9+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
169.1.13DOS Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
169.1.14PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
169.1.15PL/I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
169.1.16PostScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
169.1.17Visual FoxPro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

169.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

170Rebanamiento esttico

320

170.1Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
170.2Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

170.3Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
170.4Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
171Recolector de basura

321

171.1Breve resea histrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

171.2Contexto

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

171.3Cmo funciona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

171.4Ventajas y desventajas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

171.5Cmo se implementa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

171.6Ejemplos de lenguajes con recolector de basura
171.7Vase tambin
171.8Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . 322

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

172Recursin

323

172.1Recursin en matemticas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

172.1.1 Conjuntos denidos de forma recurrente . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

172.1.2 Funciones denidas de forma recurrente . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
172.1.3 Constantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
172.1.4 Resolucin de problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
172.2Recursin en informtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
172.3Humor recursivo
172.4Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

172.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
172.6Enlaces externos
173Refactorizacin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
326

173.1Refactorizacin de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

173.2Refactorizacin de otros textos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

NDICE GENERAL
173.3Etimologa

xxix
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

173.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
173.5Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

174Reexin (informtica)

328

174.1Implementacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
174.2Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
174.2.1 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
174.2.2 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
174.3Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

175Relacin de compresin (informtica)

329

175.0.1 Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

176Resolucin de problemas de programacin

330

176.1Anlisis del problema informtico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

176.2Diseo del algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
176.2.1 Acciones elementales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
176.2.2 Secuencia de acciones elementales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
176.2.3 Composicin condicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
176.2.4 Composicin condicional doble (alternativa) . . . . . . . . . . . . . . . . . . . . . . . . . 331
176.2.5 Composicin condicional mltiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
176.2.6 Composicin iterativa o bucle
176.3Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

177Instancia (programacin)

333

177.1Programacin basada en clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

177.1.1 Clases como objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
177.2Programacin basada en prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
177.3Notas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
177.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
178Anexo:Scan code

335

179scanf

336
179.0.1 Modicantes de longitud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

179.1Sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
179.2Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
179.3Funciones derivadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
179.3.1 fscanf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
179.3.2 sscanf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
179.4Vase tambin
179.5Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

xxx

NDICE GENERAL

180SCons
180.1Vase tambin

340
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

180.2Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

181Screen scraping
181.1Vase tambin

341
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

182Seccin crtica
182.1Vase tambin

342
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

183Serializacin

343

183.1Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
183.2Soporte en los lenguajes de programacin
183.3Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

184Sigil

344

185Signatura (informtica)

345

186Signum Framework

346

186.1Caractersticas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

186.1.1 Elementos de Signum Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

186.1.2 Entidades primero

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

186.1.3 Generacin del esquema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

186.1.4 Herencia de entidades

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

186.1.5 Interfaz de usuario y WCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

186.1.6 LINQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
186.2Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
186.3Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

187Simple Network Library

187.1Origen del nombre

348
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

187.2Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
187.3Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

187.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
187.5Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
187.5.1 Documentacin de SNL
187.6Enlaces externos
188Smarty
188.1Caractersticas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
349
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

188.2Crticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
188.3Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
188.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

NDICE GENERAL

xxxi

188.5Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

189Snippet

351

189.1Rich snippets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

189.2Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
190Stack Overow

352

190.1Funcionamiento de Stack Overow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

190.2Reputacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
190.3Moderacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
190.4Estadsticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
191StarBasic

354

191.1Primer virus para OpenOce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

191.2Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

192Stub

355

192.1Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
192.2Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

193Subalgoritmo

356

193.1Tipos de subalgoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

193.2mbito de las variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
193.3Paso de argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
193.4Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

194Tabla de saltos

357

194.1Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
194.2Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
194.3Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

195Tabla de verdad

359

195.1Deniciones en el clculo lgico

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

195.2Nmero de combinaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

195.2.1 Para cero variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
195.2.2 Para una variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
195.2.3 Para dos variables
195.3Tablas de verdad

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

195.3.1 Verdad Indeterminada o Contingencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

195.3.2 Contradiccin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

195.3.3 Tautologas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

195.4Tablas de verdad, proposiciones lgicas y argumentos deductivos
195.5Aplicaciones

. . . . . . . . . . . . . . . . . . 362

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

195.5.1 Clculo lgico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

xxxii

NDICE GENERAL
195.5.2 Lgica de circuitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
195.5.3 Desarrollo del algoritmo fundamental en lgica de circuitos . . . . . . . . . . . . . . . . . 363

195.6Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

195.7Notas y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

195.8Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

196Thunk

366

196.1Invocacin por gestionada a no gestionada

. . . . . . . . . . . . . . . . . . . . . . . . . . . 366

196.2Invocacin por no gestionada a gestionada

. . . . . . . . . . . . . . . . . . . . . . . . . . . 366

196.3Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
197Tipo de dato elemental

367

198Tringulo de Floyd

368

198.1Algoritmo computacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368

198.2Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368

198.3Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
199Tubera (informtica)

369

199.1Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

200Violacin de acceso

371

200.1Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

201Waf

372

201.1Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
201.2Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
201.3Ejemplo Waf archivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
201.4Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

201.5Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
201.6Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

202Win32 Thread Information Block

202.1Contenido del TIB

374

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

202.2Acceso al TIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

202.3Enlaces externos
203Wrapper

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
375

203.1Computacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
203.2Vase tambin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

203.3Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
204XAML
204.1Tecnologa
204.2Ejemplos

376
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

NDICE GENERAL
204.3Vase tambin

xxxiii
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

204.4Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
204.5Enlaces externos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

205Zenphp
205.1Qu es zenphp?

378
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

205.2Qu ventajas ofrece zenphp?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

205.3Origen del texto y las imgenes, colaboradores y licencias . . . . . . . . . . . . . . . . . . . . . . 379

205.3.1 Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
205.3.2 Imgenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
205.3.3 Licencia del contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

Captulo 1

Programacin
La programacin informtica, acortada como programacin, es el proceso de disear, codicar, depurar y
mantener el cdigo fuente de programas computacionales. El cdigo fuente es escrito en un lenguaje de programacin. El propsito de la programacin es crear programas que exhiban un comportamiento deseado. El proceso
de escribir cdigo requiere frecuentemente conocimientos en varias reas distintas, adems del dominio del lenguaje a utilizar, algoritmos especializados y lgica formal. Programar no involucra necesariamente otras tareas
tales como el anlisis y diseo de la aplicacin (pero s el
diseo del cdigo), aunque s suelen estar fusionadas en
el desarrollo de pequeas aplicaciones.

trivial como multiplicar dos nmeros puede necesitar un

conjunto de instrucciones en lenguaje ensamblador, en
un lenguaje de alto nivel bastar con solo una. Una vez
que se termina de escribir un programa, sea en ensamblador o en algunos lenguajes de alto nivel, es necesario compilarlo, es decir, traducirlo completo a lenguaje
mquina.* [1] Eventualmente ser necesaria otra fase denominada comnmente link o enlace, durante la cual se
anexan al cdigo, generado durante la compilacin, los
recursos necesarios de alguna biblioteca. En algunos lenguajes de programacin, puede no ser requerido el proceso de compilacin y enlace, ya que pueden trabajar en
modo intrprete. Esta modalidad de trabajo es equivalente
pero se realiza instruccin por instruccin, a medida
Del proceso de programacin surge lo que comnmente
que
es ejecutado el programa.
se conoce como software (conjunto de programas), aunque estrictamente este ltimo abarca mucho ms que solo
la programacin.

1.2 Lxico y programacin

1.1 Historia

La programacin se rige por reglas y un conjunto ms o

menos reducido de rdenes, expresiones, instrucciones y
comandos que tienden a asemejarse a una lengua natural
acotada (en ingls); y que adems tienen la particularidad
de una reducida ambigedad. Cuanto menos ambiguo es
un lenguaje de programacin, se dice, es ms potente. Bajo esta premisa, y en el extremo, el lenguaje ms potente
existente es el binario, con ambigedad nula (lo cual lleva
a pensar as del lenguaje ensamblador).

Para crear un programa, y que la computadora lo interprete y ejecute las instrucciones escritas en l, debe escribirse en un lenguaje de programacin. En sus inicios
las computadoras interpretaban solo instrucciones en un
lenguaje especco, del ms bajo nivel, conocido como
cdigo mquina, siendo ste excesivamente complicado
para programar. De hecho solo consiste en cadenas de
nmeros 1 y 0 (sistema binario). Para facilitar el trabajo
de programacin, los primeros cientcos, que trabajaban en el rea, decidieron reemplazar las instrucciones,
secuencias de unos y ceros, por palabras o abreviaturas
provenientes del ingls; las codicaron y crearon as un
lenguaje de mayor nivel, que se conoce como Asembly
o lenguaje ensamblador. Por ejemplo, para sumar se podra usar la letra A de la palabra inglesa add (sumar).
En realidad escribir en lenguaje ensamblador es bsicamente lo mismo que hacerlo en lenguaje mquina, pero
las letras y palabras son bastante ms fciles de recordar
y entender que secuencias de nmeros binarios. A medida que la complejidad de las tareas que realizaban las
computadoras aumentaba, se hizo necesario disponer de
un mtodo sencillo para programar. Entonces, se crearon los lenguajes de alto nivel. Mientras que una tarea tan

En los lenguajes de programacin de alto nivel se distinguen diversos elementos entre los que se incluyen el lxico propio del lenguaje y las reglas semnticas y sintcticas.

1.3 Programas y algoritmos

Un algoritmo es una secuencia no ambigua, nita y ordenada de instrucciones que han de seguirse para resolver un problema. Un programa normalmente implementa
(traduce a un lenguaje de programacin concreto) uno o
ms algoritmos. Un algoritmo puede expresarse de distintas maneras: en forma grca, como un diagrama de
ujo, en forma de cdigo como en pseudocdigo o un
1

CAPTULO 1. PROGRAMACIN

lenguaje de programacin, en forma explicativa, etc.

Los programas suelen subdividirse en partes menores, llamadas mdulos, de modo que la complejidad algortmica
de cada una de las partes sea menor que la del programa
completo, lo cual ayuda al desarrollo del programa. Esta
es una prctica muy utilizada y se conoce como reno
progresivo.
Segn Niklaus Wirth, un programa est formado por los
algoritmos y la estructura de datos.

puede almacenarse solo de forma temporal. Un programa

podra tener partes escritas en varios lenguajes, por ejemplo, Java, C, C++ y ensamblador, que se podran compilar
de forma independiente y luego enlazar juntas para formar un nico mdulo ejecutable.

1.5 Programacin e ingeniera del

software

Se han propuesto diversas tcnicas de programacin cuyo objetivo es mejorar tanto el proceso de creacin de Existe una tendencia a identicar el proceso de creacin
software como su mantenimiento. Entre ellas, se pueden de un programa informtico con la programacin, que es
mencionar las siguientes:
cierta cuando se trata de programas pequeos para uso
personal, y que dista de la realidad cuando se trata de
grandes proyectos.
Programacin declarativa
Programacin estructurada
Programacin modular
Programacin orientada a objetos

1.4 Compilacin
El programa escrito en un lenguaje de programacin de
alto nivel (fcilmente comprensible por el programador)
es llamado programa fuente y no se puede ejecutar directamente en una computadora. La opcin ms comn
es compilar el programa obteniendo un mdulo objeto,
aunque tambin puede ejecutarse en forma ms directa a
travs de un intrprete informtico.
El cdigo fuente del programa se debe someter a un
proceso de traduccin para convertirlo a lenguaje mquina o bien a un cdigo intermedio, generando as un mdulo denominado objeto. A este proceso se le llama
compilacin.

El proceso de creacin de software, desde el punto de vista de la ingeniera, incluye mnimamente los siguientes
pasos:
1. Reconocer la necesidad de un programa para solucionar un problema o identicar la posibilidad de
automatizacin de una tarea.
2. Recoger los requisitos del programa. Debe quedar
claro qu es lo que debe hacer el programa y para
qu se necesita.
3. Realizar el anlisis de los requisitos del programa.
Debe quedar claro qu tareas debe realizar el programa. Las pruebas que comprueben la validez del
programa se pueden especicar en esta fase.
4. Disear la arquitectura del programa. Se debe descomponer el programa en partes de complejidad
abordable.

5. Implementar el programa. Consiste en realizar un

Habitualmente la creacin de un programa ejecutable (un
diseo detallado, especicando completamente [Link] para Microsoft Windows o DOS) conlleva dos
do el funcionamiento del programa, tras lo cual la
pasos. El primer paso se llama compilacin (propiamente
codicacin (programacin propiamente dicha) dedicho) y traduce el cdigo fuente escrito en un lenguaje
bera resultar inmediata.
de programacin almacenado en un archivo de texto a
6. Probar el programa. Comprobar que pasan pruebas
cdigo en bajo nivel (normalmente en cdigo objeto, no
que se han denido en el anlisis de requisitos
directamente a lenguaje mquina). El segundo paso se
llama enlazado en el cual se enlaza el cdigo de bajo ni7. Implantar (instalar) el programa. Consiste en poner
vel generado de todos los cheros y subprogramas que se
el programa en funcionamiento junto con los comhan mandado compilar y se aade el cdigo de las funcioponentes que pueda necesitar (bases de datos, redes
nes que hay en las bibliotecas del compilador para que el
de comunicaciones, etc.).
ejecutable pueda comunicarse directamente con el sistema operativo, traduciendo as nalmente el cdigo objeto
a cdigo mquina, y generando un mdulo ejecutable.
La ingeniera del software se centra en los pasos de plaEstos dos pasos se pueden hacer por separado, almace- nicacin y diseo del programa, mientras que antiguanando el resultado de la fase de compilacin en archivos mente (programacin artesanal) la realizacin de un proobjetos (un tpico .o para Unix, .obj para MS-Windows, grama consista casi nicamente en escribir el cdigo, baDOS); para enlazarlos en fases posteriores, o crear direc- jo solo el conocimiento de los requisitos y con una motamente el ejecutable; con lo que la fase de compilacin desta fase de anlisis y diseo.

1.8. CICLO DE VIDA DEL SOFTWARE

1.6 Referencias histricas

El trabajo de Ada Lovelace, hija de Anabella Milbanke Byron y Lord Byron, realiz para la mquina de
Babbage le hizo ganarse el ttulo de primera programadora de computadoras del mundo, aunque Babbage nunca complet la construccin de la mquina. El nombre del
lenguaje de programacin Ada fue escogido como homenaje a esta programadora.

1.7 Objetivos de la programacin

3
Portabilidad. Un programa es portable cuando tiene
la capacidad de poder ejecutarse en una plataforma,
ya sea hardware o software, diferente a aqulla en la
que se desarroll. La portabilidad es una caracterstica muy deseable para un programa, ya que permite, por ejemplo, a un programa que se ha elaborado
para el sistema GNU/Linux ejecutarse tambin en la
familia de sistemas operativos Windows. Esto permite que el programa pueda llegar a ms usuarios
ms fcilmente.

1.8 Ciclo de vida del software

La programacin debe perseguir la obtencin de programas de calidad. Para ello se establece una serie de factores El trmino ciclo de vida del software describe el desaque determinan la calidad de un programa. Algunos de los rrollo de software, desde la fase inicial hasta la fase nal,
incluyendo su estado funcional. El propsito es denir las
factores de calidad ms importantes son los siguientes:
distintas fases intermedias que se requieren para validar
Correctitud. Un programa es correcto si hace lo que el desarrollo de la aplicacin, es decir, para garantizar que
debe hacer tal y como se estableci en las fases pre- el software cumpla los requisitos para la aplicacin y vevias a su desarrollo. Para determinar si un progra- ricacin de los procedimientos de desarrollo: se asegura
ma hace lo que debe, es muy importante especi- que los mtodos utilizados son apropiados. Estos mtodos
car claramente qu debe hacer el programa antes de se originan en el hecho de que es muy costoso recticar
su desarrollo y, una vez acabado, compararlo con lo los errores que se detectan tarde dentro de la fase de implementacin (programacin propiamente dicha), o peor
que realmente hace.
aun, durante la fase funcional. El modelo de ciclo de vida
Claridad. Es muy importante que el programa sea permite que los errores se detecten lo antes posible y por
lo ms 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 implementacin y
borar un programa se debe intentar que su estructu- en los costos asociados. El ciclo de vida bsico de un softra sea sencilla y coherente, as como cuidar el es- ware consta de, al menos, los siguientes procedimientos:
tilo de programacin. De esta forma se ve facilita Denicin de objetivos: denir el resultado del prodo el trabajo del programador, tanto en la fase de
yecto y su papel en la estrategia global.
creacin como en las fases posteriores de correccin
de errores, ampliaciones, modicaciones, etc. Fases
Anlisis de los requisitos y su viabilidad: recopilar,
que pueden ser realizadas incluso por otro prograexaminar y formular los requisitos del cliente y examador, con lo cual la claridad es an ms necesaria
minar cualquier restriccin que se pueda aplicar.
para que otros puedan continuar el trabajo fcilmente. Algunos programadores llegan incluso a utilizar
Diseo general: requisitos generales de la arquitecArte ASCII para delimitar secciones de cdigo; una
tura de la aplicacin.
prctica comn es realizar aclaraciones en el cdigo
Diseo en detalle: denicin precisa de cada subfuente utilizando lneas de comentarios. Contrariaconjunto de la aplicacin.
mente, algunos por diversin o para impedirle un
anlisis cmodo a otros programadores, recurren al
Programacin (programacin e implementacin): es
uso de cdigo ofuscado.
la implementacin en un lenguaje de programacin
para crear las funciones denidas durante la etapa de
Eciencia. Se trata de que el programa, adems de
diseo.
realizar aquello para lo que fue creado (es decir, que
Prueba de unidad: prueba individual de cada subsea correcto), lo haga gestionando de la mejor forconjunto de la aplicacin para garantizar que se imma posible los recursos que utiliza. Normalmente,
plementaron de acuerdo con las especicaciones.
al hablar de eciencia de un programa, se suele hacer referencia al tiempo que tarda en realizar la ta Integracin: para garantizar que los diferentes
rea para la que ha sido creado y a la cantidad de
mdulos y subprogramas se integren con la aplicamemoria que necesita, pero hay otros recursos que
cin. ste es el propsito de la prueba de integracin
tambin pueden ser de consideracin para mejorar
que debe estar cuidadosamente documentada.
la eciencia de un programa, dependiendo de su na Prueba beta (o validacin), para garantizar que el
turaleza (espacio en disco que utiliza, trco en la
software cumple con las especicaciones originales.
red que genera, etc.).

CAPTULO 1. PROGRAMACIN
Documentacin: se documenta con toda la informacin necesaria, sea funcional nal para los usuarios
del software (manual del usuario), y de desarrollo
para futuras adaptaciones, ampliaciones y correcciones.
Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento
continuo).

1.11 Enlaces externos

Wikimedia Commons alberga contenido multimedia sobre Programacin. Commons

Wikcionario tiene deniciones y otra informacin sobre [Link]

Wikiquote alberga frases clebres de o sobre

El orden y la presencia de cada uno de estos procedimienProgramacin. Wikiquote
tos en el ciclo de vida de una aplicacin dependen del tipo
de modelo de ciclo de vida acordado entre el cliente y el Wikilibros
equipo de desarrolladores.

1.9 Vase tambin

Portal:Programacin. Contenido relacionado

con Programacin.

Wikiproyecto:Informtica/Programacin
error de software
losofas del desarrollo de software
historia de la ingeniera del software
ingeniera en computacin
Desarrollo De Software
ingeniera en informtica
lnea de cdigo fuente
lenguaje de programacin
programacin automtica
programacin dirigida por eventos
programacin estructurada
programacin extrema
programacin en pareja
programacin dinmica
programacin orientada a objetos
pruebas de software
software

1.10 Referencias
[1] Laboda, Xavier; Josep Galimany, Rosa Mara Pena, Antoni Gual (1985). Software. Biblioteca prctica de la
computacin. Barcelona: Ediciones Ocano-xito, S.A.

Wikilibros alberga un libro o manual sobre

Fundamentos de programacin.

Captulo 2

Portal:Programacin

Captulo 3

&
El signo en s es una ligadura combinacin de diseo de
dos letras en un nico grafema, usado primero para aumentar la velocidad de la escritura manualdesarrollada
por Marco Tulio Tirn, secretario del gran orador romano
Cicern. Para poder registrar los discursos y la correspondencia dictada por este ltimo, Tiro, que era un esclavo liberto, invent varias formas de acelerar la escritura, siendo por ello considerado el padre de la taquigrafa. En la
Edad Media o en los primeros tiempos de la imprenta el
uso de ligaduras era muy comn, en este caso por la economa de espacio, cuando la materia prima pergamino
o papelaada mucho al precio de los libros.

Et redirige aqu. Para otras acepciones, vase

E. T.

Evolucin de la ligadura &:

1-3, cursivas romanas de los siglos ii-iv
4-5, minsculas medievales de los siglos vi-vii
6, minscula carolingia, s. ix.

Tambin se le conoce como signo tironiano.

El signo &, cuyo nombre en espaol es et,* [1] es una alternativa grca de la conjuncin copulativa latina et, que
signica y de la que deriva la espaola y.

3.1 Historia

Es conocido tambin por su nombre en ingls ampersand,

proveniente a su vez de la expresin and per se and, es decir, y por s mismo, y, antiguamente usada como parte
de la retahla para la memorizacin del alfabeto.
Deriva del latn de donde el signo pas a diversos idiomas,
incluido el espaol. Su uso en nuestra lengua es superuo,
pues no resulta econmico (a diferencia de otros idiomas)
ya que la conjuncin copulativa y tiene una grafa ms
breve y sencilla. En textos espaoles antiguos es frecuente
encontrarlo empleado en la expresin latina adoptada et
El et latino a la izquierda se encuentra estilizado, pero la forma
cetera, en las formas &c. o &cetera.
itlica a la derecha revela sus orgenes de la palabra del latn et.

Un uso extendido es el que persiste en la bibliografa acadmica en ingls, en la enumeracin de los autores, in- El smbolo fue usado en el antiguo Imperio romano, y su
cluidas la expresin como & al. (del latn et alii, plural uso data del primer siglo d.C. Se adjudica su invencin a
masculino, o et alia, plural neutro) que se traduce como Marco Tulio Tirn.* [2]
y otros.
Para el siglo viii, la caligrafa occidental estaba bien desarrollada, particularmente en la forma uncial, escritura insular y minscula carolingia. Los calgrafos hicieron un
extensivo uso del et, ya que la condensacin de una palabra en una sola letra haca su trabajo ms fcil. Durante
aquel tiempo, se desarroll una versin mucho ms comprimida del et. Normalmente se le llama ampersandRoEn la tipografa de la derecha es evidente el origen de la ligadura mana.
et.

En HTML se usa al comienzo de los cdigos de entidad

Como se observa en la lista de letras de Byrhtfer (ao con que se designan los caracteres especiales: los ejem1011), este signo & fue considerado a menudo como plos ms tpicos son &gt; &lt;, y &amp; (>, < y &,
una letra ms al nal del alfabeto latino.
respectivamente).
6

3.3. ENLACES EXTERNOS

En Internet y direcciones web, & simboliza la separacin
de variables pasadas mediante GET.
En Excel, se usa para concatenar celdas.
En la lnea 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 Espaola (2001). Apndice 4: Lista de
smbolos o signos no alfabetizables. Diccionario de la
lengua espaola. Consultado el 25 de septiembre de 2012.
[2] The History of Court Reporting. National Court Reporters Association.

3.3 Enlaces externos

Wikimedia Commons alberga contenido multimedia sobre &Commons.

Wikcionario tiene deniciones y otra informacin sobre &.Wikcionario

Wikcionario tiene deniciones y otra informacin sobre [Link]

Apndice 4: Lista de smbolos o signos no alfabetizables en la pgina de la Real Academia Espaola.

Captulo 4

Acoplamiento secuencial
En Programacin orientada a objetos el antipatrn de diseo acoplamiento secuencial se reere a una clase que
requiere que sus mtodos sean llamados en un orden secuencial particular.
Los mtodos 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 analoga, si el
usuario sigue los pasos de acelerar sin antes arrancar el
motor, el coche no se mueve y enva una Excepcin.
Las excepciones son aceptables en algunas ocasiones porque los programas (en particular los grandes) necesitan la
informacin para determinar por qu en un objeto no se
est realizando el comportamiento esperado cuando uno
de sus mtodos es llamado. La inicializacin de objetos
no siempre es posible en el constructor y puede ser necesario retrasarla a un momento posterior.
El acoplamiento secuencial puede ser reprogramado con
el Template Method (patrn de diseo)* [1] para superar
los problemas planteados por el uso de este antipatrn.

4.1 Vase tambin

Antipatrn de diseo
Patrn de diseo

4.2 Referencias
[1] Andriy, Buday. Refactor: Acoplamiento secuencial =>
Template Method. The Code Project. Consultado el 23
de abril de 2011.

Captulo 5

Adobe Director
Adobe Director Es una aplicacin de Desarrollo de
Software (o Autora de Software) Multimedia (que inspir a Adobe Flash ) destinado para la produccin de
programas ejecutables ricos en contenido multimedia. Es
considerada una de las herramientas ms poderosas de
integracin y programacin de medios digitales, debido a
su versatilidad de poder incorporar imgenes, audio, vdeo digital, pelculas ash, y un engine 3D, en una sola
aplicacin, y manipularlas a travs de un lenguaje de programacin (Lingo; Javascript).

Con el lanzamiento de Director 11 y su evolucin a la

versin 11.5, de la mano de Adobe, se incorpor soporte para DirectX y se extendieron las capacidades en 3D
basadas en el engine PhysX de NVIDIA, importacin de
3D desde Google SketchUp, as como tambin ltros de
bitmaps, canales de audio 5.1, vdeo en alta denicin,
soporte para H.264, e integracin de Adobe Flash CS3
y Shockwave Player 11. Director 12, lanzado en febrero de 2013, incorpor la posibilidad de publicacin para
dispositivos iOS, adems de otras utilidades como esteDesarrollado a nes de los aos 80 por la empresa reoscopa, nuevos efectos, y nuevas potencialidades del
Macromedia, es distribuido desde el ao 2008 por Adobe engine 3D.
Systems Incorporated.
Adobe Director, permite crear y publicar juegos interactivos, prototipos, simulaciones y cursos eLearning para la
Web, dispositivos iOS, sistemas de escritorio Windows
y Mac, DVDs y CDs. Con Director tambin es posible
programar una amplia gama de aplicaciones basadas en
redes, lo que ha permitido crear innumerables sistemas y
juegos multiusuario online.

5.1

Interfaz

A lo largo de todas sus versiones, la interfaz de Director ha sido el a su concepcin inicial, y a su nombre:
entregarle al desarrollador un escenario (Stage), para el
armado de su Aplicacin. Cada uno de los mltiples medios que pueden ser utilizados en Director son consideradosactores(casts), cuyas caractersticas pueden ser
manipuladas a travs de guiones (o Scripts) escritos en
lenguaje Lingo o Javascript. En sntesis, el desarrollador
es el director de su propia pelcula, controlando todos sus
aspectos.

Director tambin permite la manipulacin de modelos en

3D, gracias a Shockwave 3D. Es as como diversos programas de modelamiento, como 3D Studio MAX (de la
empresa Autodesk), permiten exportar sus modelos (incluyendo las animaciones) en formato Shockwave 3D, el
que puede ser importado a Director, y manipulado a travs de instrucciones. A travs de variados Xtras (como
Havok), Director tambin puede manipular propiedades
fsicas de modelos 3D (como por ejemplo, gravedad, coecientes de roce, restitucin, etc) que permiten lograr simulaciones ms realistas, tanto para software de ingeniera avanzada, como para juegos.

5.2 Timeline
1985: VideoWorks (Disponible para Apple Macintosh)
1988: Director 1.0

Adems del potente lenguaje incorporado (Lingo), una

de sus principales ventajas radica en el uso de los llamados xtras. Se trata de pequeos programas(plugins)
desarrollados en lenguaje C++ por otros usuarios o terceras empresas, que proporcionan al usuario innidad de
utilidades.

1993: Macromind Director se convierte en Macromedia Director (v 3.1.3)

1994: Macromedia Director 4 (Plataformas Windows y Powermac)

Se pueden generar varios tipos de archivos, sin embargo lo ms normal es crear un archivo ejecutable para
Windows (.exe) o Macintosh (.app). De esta forma puede verse la presentacin en cualquier ordenador, sin tener
instalado Adobe Director.

1996: Macromedia Director 5 (Aparicin de Shockwave)

1997: Macromedia Director 6 (Implementacin de
Behaviors & y soporte mp3)
9

10
1997: Macromedia Director 6.5 (integracin de
Xtras)

CAPTULO 5. ADOBE DIRECTOR

5.4 Shockwave / Shockwave 3D

Desde la aparicin de Director 5, Shockwave es el for 1998: Macromedia Director 7 (Se re-escribi el en- mato exclusivo de publicacin para web de Director. El
gine)
plugin de shockwave permite ejecutar aplicaciones realizadas en Director (archivos DCR), a travs de Internet,
2000: Macromedia Director 8
sin que estas pierdan su calidad ni caractersticas, adems
de aprovechar al mximo las potencialidades de aquellas
2001: Macromedia Director 8.5 (Aparicin de que poseen engine multiusuario. Con la aparicin de Director 8.5, Shockwave tuvo un nuevo impulso, al incorShockwave3D)
porar capacidades de manipulacin de elementos en 3D
2002: Macromedia Director MX (Tambin conoci- (Shockwave 3D). Esto abri las puertas a los desarrolladores de Director a un nuevo mundo, a partir del cual fue
do como Director 9)
posible crear ambientes modelados en 3D (generados en
2004: Macromedia Director MX 2004 (Tambin Director, o importados como archivos W3D desde aplicaciones externas) y utilizar toda la riqueza del cdigo linconocido como Director 10)
go / javascript, para manipular dichos modelos en tiempo
real.
2008: Adobe Director 11
El motor 3D de Shockwave es todava el lder indiscutible en su mercado, y hace que este plugin sea muy popular
entre un gran nmero de desarrolladores de juegos en lnea y de jugadores. Los archivos Flash (swf) pueden ser
2010: Adobe Director 11.5.8
incorporados a Director y ser ejecutados en Shockwave,
2013: Adobe Director 12. (Publicacin a dispositi- pero no a la inversa.
vos iOS, estereoscopa, mejora de Engine 3D)
Otras caractersticas no incorporadas por Flash incluyen un motor de render mucho ms rpido, junto con
aceleracin 3D por medio de hardware, acceso directo
al pxel en imgenes bitmap, diferentes modos de ltrado
5.3 Director y Flash
para composiciones en capas de los grcos y compatibilidad con diversos protocolos de red, incluido Internet
Histricamente, la comunidad ms cercana a Flash y Relay Chat. Adems, a travs de los Xtras, los desarrodesconocedora de Director, tiende a preguntarse sobre lladores pueden ampliar la funcionalidad de Shockwave
las comparaciones entre ambos programas. Literalmen- con aplicaciones hechas a medida.
te, Director y Flash no son competidores. Flash naci en
1996, orientado al desarrollo de aplicaciones multimedia
Macromedia Shockwave Player, instalado en un
en Web, y en poco tiempo evolucion poderosamente de
50% de los navegadores. Ficheros con extensin
la mano del lenguaje ActionScript. Director naci varios
".dcrdesarrollados con Adobe Director
aos antes (1985), y evolucion como una poderosa herramienta de integracin de medios digitales de alta cali Macromedia Flash Player, instalado en un 98%
dad para plataformas de escritorio, y que tambin gener
de los navegadores. Utiliza cheros con extensin
una arista para su incorporacin a Web (Shockwave).
".swfdesarrollados con Macromedia Flash, Macro 2009: Adobe Director 11.5

La evolucin de la popularidad de Flash sobre Shockwave tiene varias explicaciones; no solo el plugin de Shockwave fue histricamente ms pesado y menos amigable
de instalar que Flash, sino tambin la autora de Director siempre ha requerido la mano de un desarrollador de
software, con conocimientos en programacin; en cambio
Flash se posicion rpidamente en el universo de diseadores Web (sin necesidad de poseer conocimientos de
programacin), y de hecho ha incentivado con los aos el
aprendizaje de programacin ActionScript a varios no
programadores, generando una importante sinergia en
el mundo del diseo y la programacin -antes estrictamente lejanos-. Por otro lado, Macromedia logr acuerdos con empresas como DELL y Apple, para que Flash
sea preinstalado en sus sistemas, evitando que los usuarios
deban instalar software adicional.

media FreeHand, Generator y otras aplicaciones.

5.5 Referencias
5.6 Enlaces externos
Sitio ocial de Adobe Director
Adobe Director Forum
[Link] Foro temtico sobre el programa (en ingls).
Foro de usuarios de Adobe Director (en ingls).

5.6. ENLACES EXTERNOS

Dean's Director Tutorials, sitio web con tutoriales
del programa (en ingls).
IEEE History Center: John Thompson, inventor of
Lingo Programming Language Biografa de John
Thompson, inventor del lenguaje de programacin
Lingo(en ingls).

11

Captulo 6

Anidamiento (informtica)
El anidamiento (llamado nesting en ingls) es la
prctica de incorporar llamadas (calls) a funciones o
procedimientos (unas) dentro de otras, mediante la inclusin de diversos niveles de parntesis.

linea, ruta as string dim valor_a_devolver as integer

ruta="C:\[Link] FileExists(ruta) then open
C:\[Link] input as #1 do while not EOF(1)
line input #1, linea if left(linea, 3)=cod then 'Realizar
Debido a que la potencial acumulacin de stos ltimos una accin o varias acciones End if loop close #1
suele hacer que la edicin y la deteccin de errores se BuscarCodigo=valor_a_devolver end function
vuelva un proceso engorroso, los entornos de programacin modernos -as como los programas de planilla de En este simple ejemplo, la estructura condicional if...
clculo- resaltan en negrita el par correspondiente a la po- then... end if (si... entonces... n si) est anidada
sicin que est editando el programador o usuario en cada dentro de otra que la contiene, el ciclo do while... loop
momento. El control (automtico) del balance o equili- (repetir... mientras, literalmente hacer mientras...
brio entre los parntesis de apertura y de cierre se suele bucle).
conocer como brace match checking en ingls.
Naturalmente, para la resolucin matemtica de estas
complejas formulas encadenadas, las expresiones deben
ser evaluadas desde adentro hacia afuera, ya que los resultados de las ms internas sirven, temporalmente, de
datos de entrada de las exteriores.

6.3 Vase tambin

Bucle (programacin)
Estructuras de control
Funcin (programacin)

6.1 En las planillas de clculo

Procedimiento (programacin)

En las hojas de clculo, se suelen anidar o agrupar funciones unas dentro de otras, derivando en frmulas relativamente complejas. El programa [Link] Calc
permite, mediante su asistente de funciones (function wizard), navegar a travs de los varios o mltiples niveles
de anidamiento, permitiendo editar (y eventualmente corregir) cada una de ellas por separado. Tal vez de manera
sorprendente, su rival Microsoft Excel no posee esa caracterstica, eventualmente deseable cuando se trabaja en
algunas grandes planillas.

6.2 En programacin
En los lenguajes de programacin estructurada, el anidamiento est relacionado a la inclusin de estructuras de
control dentro de otras, usualmente indicado mediante la
inclusin de distintos niveles de sangra (llamada indentation en ingls) dentro del cdigo fuente, como se muestra
en el sencillo cdigo BASIC siguiente:
function BuscarCodigo(cod as string) as integer dim
12

Programacin estructurada
Pseudocdigo

Captulo 7

Antipatrn de diseo
Un antipatrn de diseo es un patrn de diseo que invariablemente conduce a una mala solucin para un problema.
Al documentarse los antipatrones, adems de los patrones de diseo, se dan argumentos a los diseadores de
sistemas para no escoger malos caminos, partiendo de
documentacin disponible en lugar de simplemente la
intuicin.
El trmino se origina inspirado en el libro Design Patterns,
escrito por un grupo de autores conocido como Gang of
Four, y que aglutina un conjunto de buenas soluciones
de programacin. Los autores bautizaron dichas soluciones con el nombre de patrones de diseopor analoga con el mismo trmino, usado en arquitectura. El libro
Anti-Patterns (de William Brown, Raphael Malveau, Skip
McCormick y Tom Mowbray, junto con la ms reciente
incorporacin de Scott Thomas) describe los antipatrones
como la contrapartida natural al estudio de los patrones
de diseo. El estudio formal de errores que se repiten permite reconocer y reconducir los elementos involucrados
hacia una mejor solucin. Los antipatrones no se mencionan en el libro original de Design Patterns, puesto que
ste es anterior.
Los antipatrones se consideran una parte importante de
una buena prctica de programacin. Es decir, un buen
programador procurar evitar los antipatrones siempre
que sea posible, lo que requiere su reconocimiento e identicacin tan pronto como sea posible, dentro del ciclo de
vida del software.
El concepto de antipatrn se puede aplicar a la ingeniera
en general, e incluso a cualquier tarea realizada por el
hombre. Aunque no se escucha con frecuencia fuera del
campo ingenieril, la nocin est ampliamente extendida.

7.1 Algunos
antipatrones
desarrollo de software
7.1.1

de

Antipatrones de gestin

Productividad a toda costa: La empresa busca la productividad a costa de la calidad del software y de la
13

calidad de vida de sus empleados, intenta homogeneizar los puestos de trabajo quitando en la medida
de lo posible los permisos a los programadores para
que no daen los sistemas operativos, monitoriza a
los equipos de trabajo y acta cortando la visibilidad de ciertas pginas o las reuniones de programadores, al nal se consigue que se vaya la gente de
la empresa cuando la situacin es insostenible, esto
suele ocurrir en ciclos de uno o dos aos.
Responsable ausente (absentee manager): Situacin
en la que el principal responsable o coordinador se
ausenta o permanece en paradero desconocido o no
localizable durante importantes perodos de tiempo.
Todo lo que tienes es un martillo (all you have is a
hammer): Gestin gris y plana, incapaz de tratar a
los subordinados de manera personalizada y acorde
con sus necesidades particulares.
Negociador de jaula de acero (cage match negotiator): Se aplica cuando un coordinador, gestor o responsable aplica una losofa de "xito a cualquier
precio.
Dos caras (doppelganger): Coordinador o compaero que en un determinado momento puede ser agradable y de trato fcil, pero igualmente puede volverse irracional y despiadado de modo inesperado.
Rodeos improductivos (fruitless hoops): Gestor o
coordinador que solicita grandes cantidades de datos (en ocasiones sin relevancia alguna) antes de tomar una decisin.
Niito de oro (golden child): Situacin en la que
ciertas responsabilidades, oportunidades, reconocimientos o recompensas van a parar a un determinado miembro del equipo como consecuencia de una
relacin personal o en clara contradiccin con su
rendimiento real.
Pollo sin cabeza (headless chicken): Se aplica al gestor, coordinador o responsable que vive en una permanente situacin de pnico y medidas desesperadas.

14

CAPTULO 7. ANTIPATRN DE DISEO

Lder pero no gestor (leader not manager): Un buen

lder no tiene por qu ser necesariamente un buen
gestor, coordinador o responsable.

Mala gestin (bad management): Gestionar un proyecto sin tener sucientes conocimientos sobre la
materia.

Gestin clonada (managerial cloning): Situacin en

la que los coordinadores o gestores son contratados
e instruidos para actuar y trabajar todos del mismo
modo, a imagen y semejanza de sus propios jefes.

Software inado (software bloat): Permitir que las

sucesivas versiones de un sistema exijan cada vez
ms recursos.

Gestor pero no lder (manager not leader): Un coor- 7.1.3 Antipatrones generales de diseo de
dinador brillante en sus deberes administrativos y de
software
gestin, pero que carece de habilidades de liderazgo.
Base de datos como comunicador de procesos (data Abuso de la mtrica (metric abuse): Utilizacin mabase as an IPC): Usar una base de datos para comunipuladora o incompetente de las medidas y las mnicar procesos en uno o varios ordenadores, cuando
tricas.
la comunicacin entre procesos directa es ms adecuada.
Sr. Amigo de todos (Mr. Nice Guy): Se aplica al gestor que pretende convertirse en amigo de todos.
Blob: Vase Objeto todopoderoso.
Hroe del proletariado (proletariat hero): El empleado para todoque siempre es puesto como ejemplo ante sus compaeros, pero que realmente es la
excusa perfecta para demandas crecientes y constantes incrementos de expectativas.
Estrellas nacientes (rising upstart): Se aplica a quienes, teniendo potencial, no son capaces de respetar la progresin profesional establecida, y pretenden sortear los plazos y requisitos de aprendizaje y
madurez.
Ejecutivo sin carcter (spineless executive): Gestor,
coordinador o responsable que no tiene el coraje de
enfrentarse a las situaciones, asumir las responsabilidades de los errores, o dar la cara por sus subordinados.

BOMQ (Batch Over MQ): Abuso en el empleo de integracin basada en mensajes en tiempo real para
transferencias espordicas de gran tamao en segundo plano.
Clase Gorda: Dotar a una clase con demasiados atributos y/o mtodos, hacindola responsable de la mayora de la lgica de negocio.
Botn mgico (magic pushbutton): Tender, desarrollando interfaces, a programar la lgica de negocio
en los mtodos de interaccin, implementando los
resultados de las acciones del usuario en trminos
no sucientemente abstractos.
Carrera de obstculos (race hazard): Incapacidad de
prever las consecuencias de diferentes sucesiones de
eventos.

Caballero de tres cabezas (three-headed knight):

Gestor indeciso, poco rme, dubitativo.

Entrada chapuza (input kludge): No especicar e implementar el manejo de entradas invlidas.

Arma denitiva (ultimate weapon): Individuos altamente competentes en los que la organizacin o sus
compaeros confan tanto que se convierten en el
canal por el que todo pasa.

Fbrica de combustible (gas factory): Disear de

manera innecesariamente compleja.

Recin llegado (warm body): Trabajador que apenas

cubre las expectativas mnimas y por tanto circula de
proyecto en proyecto o de equipo en equipo.
Arquitecto a obrero (super builder): Creencia por la
que se asigna a un buen diseador de software al
desarrollo de cdigo pensando en que tardara mucho menos en teclearlo.

7.1.2

Antipatrones de gestin de proyectos

Humo y espejos (smoke and mirrors): Mostrar cmo

ser una funcionalidad antes de que est implementada.

Gran bola de lodo (big ball of mud): Construir un

sistema sin estructura denida.
Interfaz inada (interface bloat): Pretender que una
interfaz sea tan potente que resulta extremadamente
difcil de implementar.
Inversin de abstraccin (abstraction inversion): No
exponer las funcionalidades implementadas que los
usuarios necesitan, forzando a que se reimplementen
a ms alto nivel.
Punto de vista ambiguo (ambiguous viewpoint): Presentar un modelo sin concretar ciertos aspectos, postergando as decisiones conictivas.
Re-dependencia (re-coupling): Introducir dependencias innecesarias entre objetos.

7.1. ALGUNOS ANTIPATRONES DE DESARROLLO DE SOFTWARE

15

Sistema de caeras de calefaccin (stovepipe sys- 7.1.4 Antipatrones de programacin

tem): Construir un sistema difcilmente mantenible,
Nomenclatura heroica (heroic naming): Identicar
ensamblando componentes poco relacionados.
los miembros de un programa (interfaces, clases,
propiedades, mtodos...) con nombres que provocan
que el conjunto aparente estandarizacin con la inAntipatrones de diseo orientado a objetos
geniera del software pero que en realidad oculta una
implementacin anrquica.
Acoplamiento secuencial (sequential coupling):
Construir una clase que necesita que sus mtodos
se invoquen en un orden determinado.
BaseBean: Heredar funcionalidad de una clase utilidad en lugar de delegar en ella.
Fallo de clase vaca (empty subclass failure): Crear
una clase que no supera el test de la subclase vaca, es
decir, que se comporta de manera diferente cuando
se invoca desde una subclase que no aade modicacin alguna.
Llamar a super (callsuper): Obligar a las subclases
a llamar a un mtodo de la superclase que ha sido
sobrescrito.
Modelo de dominio anmico (anemic domain model): Usar un modelo del dominio sin ninguna lgica
de negocio. Esto no es un enfoque orientado a objetos porque cada objeto debera tener tanto propiedades como comportamiento asociado.
Objeto sumidero (object cesspool): Reutilizar objetos
no adecuados realmente para el n que se persigue.
Objeto todopoderoso (god object): Concentrar demasiada funcionalidad en una nica parte del diseo
(clase).
Poltergeist (informtica): Emplear objetos cuyo nico propsito es pasar la informacin a terceros objetos.
Problema del crculo-elipse (circle-ellipse problem):
Crear variables de tipo pensando en los valores de
posibles subtipos.
Problema del yoy (yo-yo problem): Construir estructuras (por ejemplo, de herencia) que son difciles de comprender debido a su excesiva fragmentacin.
Singletonitis: Abuso de la utilizacin del patrn
singleton.
YAFL (yet another fucking layer, y otra maldita capa ms) o 'Cdigo Lasagna': Aadir capas innecesarias a un programa, biblioteca o framework. Esta
tendencia se extendi bastante despus de que se publicase el primer libro sobre patrones.

Accin a distancia (action at a distance): Provocar

la interaccin no prevista de componentes muy distantes de un sistema.
Acumular y disparar (accumulate and re): Establecer una coleccin de variables globales para ser usadas por un conjunto de subrutinas.
Ancla del barco (boat anchor): Retener partes del
sistema que ya no tienen utilidad.
Bucle activo (busy spin): Utilizar espera activa cuando existen alternativas.
Cdigo duro (hard code): Hacer supuestos sobre
el entorno del sistema en demasiados lugares de la
implementacin.
Complejidad no indispensable (accidental complexity): Dotar de complejidad innecesaria a una solucin.
Cdigo espagueti (spaghetti code): Construir sistemas cuya estructura es difcilmente comprensible, especialmente debido a la escasa utilizacin de
estructuras de programacin.
Cdigo ravioli (ravioli code): Construir sistemas con
multitud de objetos muy dbilmente conectados.
Comprobacin de tipos en lugar de interfaz (checking type instead of interface): Comprobar que un
objeto es de un tipo concreto cuando lo nico que
se necesita es vericar si cumple un contrato determinado.
Conanza ciega (blind faith): Descuidar la comprobacin de los resultados que produce una subrutina,
o bien de la efectividad de un parche o solucin a un
problema.
Doble comprobacin de bloqueo (double-checked
locking): Comprobar, antes de modicar un objeto,
si es necesario hacer esa modicacin, pero sin bloquear para comprobarlo, de manera que dicha comprobacin puede fallar.
Fallo de cach (caching failure): Olvidar restablecer
una marca de error cuando ste ya ha sido tratado.
Lava seca (lava ow): Cdigo muerto e informacin
de diseo olvidada permanecen congelados en un diseo cambiante. Esto es anlogo a un ujo de lava
en el que se van endureciendo pedazos de roca. La

16

CAPTULO 7. ANTIPATRN DE DISEO

solucin incluye un proceso de gestin de la conguracin que elimina el cdigo muerto y permite
evolucionar o rehacer el diseo para acrecentar la
calidad.

Lgica super-booleana (superboolean logic): Emplear comparaciones o abstracciones de la lgica

booleana innecesarias.
Manejo de excepciones (exception handling): Emplear el mecanismo de manejo de excepciones del
lenguaje para implementar la lgica general del programa.
Manejo de excepciones intil (useless exception
handling): Introducir condiciones para evitar que se
produzcan excepciones en tiempo de ejecucin, pero
lanzar manualmente una excepcin si dicha condicin falla.
Momento del cdigo (code momentum) : Establecer
demasiadas restricciones sobre una parte del sistema
debido a la asuncin de muchas de sus propiedades
desde otros lugares del propio sistema.
Nmeros mgicos (magic numbers): Incluir en los
algoritmos nmeros concretos sin explicacin aparente.

Desfactorizacin (de-factoring): Eliminar funcionalidad y reemplazarla con documentacin.

Factor de improbabilidad (improbability factor):
Asumir que es improbable que un error conocido
cause verdaderos problemas.
Martillo de oro (golden hammer): Asumir que nuestra solucin favorita es universalmente aplicable, haciendo bueno el refrn a un martillo, todo son clavos.
Optimizacin prematura (premature optimization):
Realizar optimizaciones sin disponer de la informacin suciente para hacerlo con garantas, sacricando decisiones de diseo.
Programacin de copiar y pegar (copy and paste programming): Programar copiando y modicando cdigo existente en lugar de crear soluciones genricas.
Programacin por permutacin (programming by
permutation): Tratar de aproximarse a una solucin
modicando el cdigo una y otra vez para ver si acaba por funcionar.

Ocultacin de errores (error hiding): Capturar un

error antes de que se muestre al usuario, y reemplazarlo por un mensaje sin importancia o ningn
mensaje en absoluto.

Reinventar la rueda (reinventing the wheel): Enfrentarse a las situaciones buscando soluciones desde cero, sin tener en cuenta otras que puedan existir ya
para afrontar los mismos problemas.

Packratting: Consumir memoria en exceso debido

a no liberar objetos reservados dinmicamente una
vez ya han dejado de ser necesarios.

Reinventar la rueda cuadrada (reinventing the square

wheel): Crear una solucin pobre cuando ya existe
una buena.

Programacin por excepcin (coding by exception):

Aadir trozos de cdigo para tratar casos especiales
7.1.6
a medida que se identican.
Secuencia de bucle por casos (Loop-switch sequence): Programar un conjunto de pasos secuenciales
usando un bucle en combinacin con una estructura
de control por casos.
Cadenas mgicas (magic strings): Incluir cadenas de
caracteres determinadas en el cdigo fuente para hacer comparaciones, como tipos de eventos, etc.

7.1.5

Antipatrones metodolgicos

Antipatrones de gestin de la conguracin

Conicto de extensiones (extension conict): Problemas con diferentes extensiones que tratan de gestionar las mismas partes del sistema (especco de Mac
OS).
Inerno de dependencias (dependency hell): Escenario de problemas producidos por las versiones de
otros productos que se necesitan para hacer funcionar un tercero.

Bala de plata (silver bullet): Asumir que nuestra solucin tcnica favorita puede resolver un problema
mucho mayor.

Inerno DLL (DLL hell): Problemas con las

versiones, disponibilidad o proliferacin de
DLLs (especco de Microsoft Windows)

Desarrollo conducido por quien prueba (tester driven development): Permitir que un proyecto software avance a base de extraer sus nuevos requisitos de
los informes de errores.

Inerno JAR (JAR hell): Problemas con diferentes versiones o ubicaciones de cheros JAR
(Java), tpicamente causados por la falta de
comprensin del modelo de carga de clases.

7.3. RELACIN ALFABTICA DE OTROS ANTIPATRONES

7.2 Algunos antipatrones organizacionales

Alcance incremental (scope creep): Permitir que el
alcance de un proyecto crezca sin el control adecuado.
Dependencia de proveedor (vendor lock-in): Construir un sistema que dependa en exceso de un componente proporcionado por un tercero.
Diseo en comit (design by committee): Contar con
muchas opiniones sobre un diseo, pero adolecer de
falta de una visin unicada.
Escalada de compromiso (escalation of commitment): No ser capaz de revocar una decisin a la
vista de que no ha sido acertada.
Funcionalitis creciente (creeping featuritis): Aadir
nuevas funcionalidades al sistema en detrimento de
su calidad.
Gestin basada en nmeros (management by numbers): Prestar demasiada atencin a criterios de gestin cuantitativos, cuando no son esenciales o difciles de cumplir.
Gestin de championes (mushroom management):
Tratar a los empleados sin miramientos, sin informarles de las decisiones que les afectan (mantenindolos cubiertos y en la oscuridad, como los championes).
Gestin porque lo digo yo (management by perkele):
Aplicar una gestin autoritaria con tolerancia nula
ante las disensiones.
Migracin de costes (cost migration): Trasladar los
gastos de un proyecto a un departamento o socio de
negocio vulnerable.
Obsolescencia continua (continuous obsolescence):
Destinar desproporcionados esfuerzos a adaptar un
sistema a nuevos entornos.
Organizacin de cuerda de violn (violin string organization): Mantener una organizacin anada y en
buen estado, pero sin ninguna exibilidad.
Parlisis por anlisis (analysis paralysis): Dedicar
esfuerzos desproporcionados a la fase de anlisis
de un proyecto, eternizando el proceso de diseo
iterando sobre la bsqueda de mejores soluciones o
variantes.
Peligro moral (moral hazard): Aislar a quien ha tomado una decisin a raz de las consecuencias de la
misma.

17
Sistema de caeras (stovepipe): Tener una organizacin estructurada de manera que favorece el ujo
de informacin vertical, pero inhibe la comunicacin horizontal.
Te lo dije (I told you so): Permitir que la atencin se
centre en que la desoda advertencia de un experto
se ha demostrado justicada.
Gallina de los huevos de oro (cash cow): Pecar de autocomplacencia frente a nuevos productos por disponer de un producto legacy muy lucrativo.

7.3 Relacin alfabtica de otros antipatrones

Arrojar al otro lado del muro (thrown over the wall):
Cuando un proyecto involucra a varios grupos de
trabajo y va pasando secuencialmente de uno a otro,
con escasa o nula comunicacin entre ellos.
Billete lobo (wolf ticket): Declarar compatibilidad
con un estndar cuando sta no existe, o bien cuando
el estndar solo incluye recomendaciones no obligatorias que, de hecho, no se siguen.
Fiesta de los bocazas (Blowhard Jamboree): Cuando
se intenta que las decisiones tcnicas del proyecto
sean las basadas en opiniones de expertos publicadas
en prensa.
Cadena sin longitud (string without length).
Cajas de dilogos en cascada (cascading dialog boxes).
Callejn sin salida (dead end): Encontrar un problema que impide continuar trabajando, pero la direccin no permite corregir el problema. El equipo queda estancado.
Caminar por un campo de minas (walking through
a mine eld): Trabajar con un componente pobremente probado (usualmente inestable), y por tanto
poco conable.
Chivo expiatorio (scape goat): Ante circunstancias
de crisis en un proyecto se toma la decisin de dirigir las culpas a una persona o a un conjunto de
personas concretas sin analizar si verdaderamente la
naturaleza del problema se encuentra en las mismas.
Codicacin brutal: Presionar a los programadores
a trabajar sobre una arquitectura sin disear y sin
requisitos evidentes.
Comit designado (appointed team): Crear un comit o grupo de trabajo para resolver un problema y no
ocuparse de lograr que el grupo funcione.

18

CAPTULO 7. ANTIPATRN DE DISEO

Compensacin equitativa (egalitarian compensation): Compensar al personal por el trabajo individual hecho.

El correo electrnico es peligroso (email is dangerous): Peligro de olvidar que detrs de los emails recibidos hay personas de carne y hueso.

Contenedor mgico (magic container): La implementacin de mtodos que intentan ser tan exibles
como para adaptar su comportamiento a multitud de
circunstancias, sobrepasando el umbral de una mantenibilidad adecuada del mismo.

El gestor controla el proceso (manager controls process).

Cuerpos tibios (warm bodies).

Culto al carguero (cargo cult): Consiste en copiar
ciertas prcticas que podran ser consideradas (no
siempre) buenas prcticas sin saber muy bien los
benecios o ventajas que proporcionan, provocando
esfuerzo innecesario en el proyecto para incorporarlas o problemas.
Cultura del miedo (fear culture)): Ambiente en el
que cada empleado tiene miedo de mostrar el resultado de su trabajo por miedo a ser despedido por
tener errores.
Cultura del hroe (hero culture): Se produce cuando
una o pocas personas toman la responsabilidad del
xito de todo el equipo o proyecto, a menudo trabajando sobretiempo.
Decisin aritmtica (decision by arithmetic): En lugar de intentar tomar una decisin con los datos disponibles y basado en el conocimiento y experiencia
de nuestros colaboradores y el nuestro, se trata de
justicar la misma sobre la base de unos factores
presuntamente objetivos.
Desarrollo distribuido geogrcamente (geographically distributed development).
Desarrollo marcado por las herramientas (autogenerated stovepipe): Preferir una solucin generada automticamente sobre la mejor solucin.
Descomposicin funcional (functional decomposition): Traducir un programa de un lenguaje estructurado a uno OO usando una sola clase y muchos
mtodos privados.
Disear por disear (design for the sake of design):
Realizar un diseo excesivamente complejo sin necesidad real.
Diseo con arquitectura impuesta (architecture as
requirement): Imponer que el diseo considere, obligatoriamente, el uso de herramientas o mtodos no
necesariamente idneos.
Diseo de fregadero (kitchen sink design).
Diseadores empricos (architects don't code): Incapacidad del grupo de diseo para evaluar la complejidad del objeto diseado.

El traje nuevo del emperador (emperor's new clothes): Temor a sealar los defectos de un producto o
proceso que un gerente o manager cree que funciona
bien.
El viejo gran duque de York (the grand old Duke of
York): Cuando los arquitectos o analistas no intervienen (uno o los dos), dejando a los programadores
(especialistas en la implementacin) prcticamente
todas las decisiones a nivel e ejecucin de las especicaciones del usuario.
Ellos me entendieron (they understood me): Explicar a programadores o diseadores junior lo que se
espera de ellos muy brevemente, y asumir que entendieron lo que se les pidi.
Embudo de excepciones (exception funnel): Atrapar
una excepcin e ignorarla, sin reportarlo.
Entrenar al entrenador (train the trainer): Contratar
una formacin sin haber precisado con cierta exactitud la materia sobre la que se desea la misma. Esto puede provocar que la formacin no se enfoque
de manera adecuada, tratando aspectos que no son
necesarios en el proyecto o dejando fuera aspectos
fundamentales. Contratar una formacin sin tener
referencias del formador, ya que lo mismo su nivel
de conocimiento no es el adecuado a la naturaleza
de la formacin a impartir.
Es un problema de operadores (it is an operator problem).
Esconder las armas (cover your assets).
Falsa economa (false economy): Permitir que los
recortes de presupuesto afecten la eciencia de los
trabajadores (las prdidas terminan siendo mayores
que lo ahorrado).
Falso punto nal subrogado (false surrogate endpoint).
Fechas en punto otante (oating point times).
Haz tu propia base de datos (roll your own database): Ante la necesidad de persistencia de datos se
utiliza una solucin que no se basa en un estndar.
Ingenieros compatibles e intercambiables (plug
compatible interchangeable engineers).
Introduccin de dicultad por analoga (analogy
breakdown): Disear por analoga con problemas
resueltos, posiblemente introduciendo dicultades
no inherentes al problema, o descuidando dicultades propias del nuevo caso que se maneja.

7.3. RELACIN ALFABTICA DE OTROS ANTIPATRONES

Invocar a constructores con nulos (passing nulls to
constructors).

19
contingencias del proceso de desarrollo, o cuando no
se es exible ante una planicacin inicial, conservndose a lo largo del proyecto pese a que se pueda
apreciar que resulta absolutamente irreal.

La disputa familiar (the feud): Cuando existiendo un

conicto entre gestores de proyectos no se le busca
una solucin denitiva al mismo.

Nacionalismo (national ism).

La experiencia mata el diseo (architecture by implication): Descuidar el diseo por conar excesivamente en la experiencia previa.

Navaja suiza (swiss army knife): Intentar crear un

producto que solucione varios problemas poco relacionados entre s.

Los clientes son tontos (customers are idiots): Pensar

que uno sabe ms que el cliente, y por tanto no es
necesaria una investigacin con el cliente.

No es mi trabajo (Not my job): No solucionar algn

problema evidente argumentando que es problema o
fallo de otro.

Manaco del control (control freak): El deseo de

control lleva a la microgestin y sta a su vez a una
prdida importante de la capacidad de autogestin
del equipo, ya que todos los pasos se miden milimtricamente.

No especicar (specify nothing).

Mquina de Rube Goldberg (Rube Goldberg machine): Realizar implementaciones muy complejas para
tareas sencillas.

Otra reunin ms lo resolver (yet another meeting

will solve it): Ante un problema en la planicacin
del proyecto, se convocan reuniones para intentar
dar una solucin al problema. En stas reuniones
participan los miembros del equipo de proyecto que
tendrn que dejar su trabajo habitual, producindose nuevos retrasos.

Matar al mensajero (shoot the messenger).

Matar dos pjaros de un tiro (kill two birds with one
stone).
Matrimonio sumarsimo (sumo marriage): Suele
ocurrir en cualquier situacin en la que exista una
dependencia de un elemento o de una serie de factores que dicultan el mantenimiento o evolucin del
sistema.
Mazorca de maz (corn cob): Mantener personas en
el proyecto que resultan difciles, conictivas o que
funcionan de manera absolutamente al margen de lo
que es cualquier trabajo en equipo o de un comportamiento solidario y que rompen con la armona del
grupo.
Mecanismos de recompensa discordantes (discordant reward mechanisms): Un equipo recibe reconocimiento por ser el que ms trabajo ejecuta sobre
la base de criterios objetivos que no son vlidos para
medir el nivel de productividad o calidad.
Mezclador de software (software merger).

No inventado aqu (not invented here): Cuando la organizacin o uno se niega a utilizar soluciones, metodologas, prcticas, herramientas, etc. externas slo porque no se nos ocurri previamente.

Otro programador ms (yet another programmer).

Presunto heredero (heir apparent): Cuando vemos
que los posibles huecos que podran quedar para seguir progresando en nuestra organizacin tienen ya
nombres y apellidos (cuando adems sus mritos son
ms que discutibles), provocar la salida de la organizacin en busca de otras alternativas o se producir una prdida de motivacin que impactar directamente en la productividad.
Proceso a prueba de idiotas (idiot proof process).
Programador discordante (net negative producing
programmer): Hay proyectos donde el rendimiento
de uno o ms miembros del equipo es muy inferior
al esperado, hasta el punto de ser su productividad
neta en el proyecto negativa (el proyecto mejorara
con el simple hecho de prescindir de estas personas,
sin necesidad de sustituirlas por otra)

Miedo al xito (fear of success): Permitir que las

nicas razones de que los trabajos no se completen
sean de ndole social.

Proyecto del da de la marmota (ground hog day project): Discutir los mismos temas en todas las reuniones, slo para llegar a la conclusin de que algo
debe hacerse.

Moneda en punto otante (oating point currency):

Utilizar una representacin en punto otante para
valores que representan dinero, lo que puede provocar prdida de precisin.

Prueba incompleta (asynchronous unit testing): Descuidar en la etapa de pruebas, algunas unidades en
todos los casos, o todas las unidades en algunos casos.

Morir planicando (death by planning): Invertir ms

esfuerzo (y tiempo) del necesario para establecer un
plan que despus puede ser destruido por las propias

Quiero estimaciones ahora (give me estimates now):

Dar estimaciones sin tener sucientes datos para hacerlas.

20
Requisitos esparcidos por la pared (requirements tossed over the wall): Existe un desorden general en los
requisitos: se encuentran en distinto grado de terminacin, no hay priorizacin de los mismos o es muy
general como para poder hacer una ordenacin adecuada por ese criterio, etc. Esto normalmente es provocado por una colaboracin inadecuada por parte
del rea usuaria.
Requisitos ocultos (Hidden requirements): El equipo
de proyecto conocedor de la dicultad de implementar un determinado requisito lo obvia dentro del catlogo de requisitos, le asigna una prioridad muy baja o lo engloba dentro de un requisito de mayor nivel
quedando difuminado en el mismo. El rea usuaria
no especica un requisito o no lo especica de manera adecuada, solicitando explicaciones a posteriori por la no implementacin de ese requisito o por
su comportamiento incorrecto.
Si funciona, no lo toques (if it is working don't change):.
Somos tontos (we are idiots): Pensar que el conocimiento interno del problema es peligroso (por riesgo
de que sea pobre o equivocado), y pedir validacin
del cliente para cada caracterstica o decisin mayor.
Tarjetas CRCI (CRCI cards): Cuando se usa
la tcnica de tarjetas CRC, se aprovecha e
incluye en la misma la implementacin de la
clase, convirtindose automticamente la tarjeta CRC (Class-Responsibility-Collaboration)
en CRCI (Class-Responsibility-CollaborationImplementation).
Tormenta de reproches (blame storming): En un
equipo de proyecto se llega a la conclusin de que
la mejor forma de analizar las causas de la no consecucin de los objetivos es que se discuta quines
internamente han tenido la culpa.
Torre de vud (tower of voodoo):Se tiene un cdigo
que se sabe que funciona (aunque generalmente no
se sabe muy bien cmo) y se pretende aadir algn
tipo de funcionalidad adicional, en ocasiones no muy
cohesionada con la ya implementada y se le coloca
un envoltorio (wrapper) proporcionando una nueva
interfaz de acceso a ese nuevo componente.
Trampa para osos (bear trap): Invertir mucho en
una herramienta poco adaptada o factible, de manera que despus es imposible deshacerse de ella.
nico punto de salida de funcin (single function exit
point).
Valor por defecto indenido (zero means null): Escoger un valor arbitrario para representar la indenicin, sin garantizar que ese valor no puede realmente
ocurrir.

CAPTULO 7. ANTIPATRN DE DISEO

Violencia intelectual (intellectual violence): De manera interna en un equipo de trabajo o en una
reunin con el cliente y/o con usuarios se utilizan
trminos, generalmente tcnicos, que no son comprendidos o conocidos por la mayora de los interlocutores.

7.4 Vase tambin

Patrn de diseo
Crisis del software
Hediondez del cdigo
No hay balas de plata

7.5 Enlaces externos

[Link] (antipatrones) Portland Pattern Repository's Wiki

Captulo 8

Archivo de cabecera
Se denomina header le, al espaol chero/archivo (de)
cabecera, o include le, al espaol chero de inclusin, en ciencias de computacin, especialmente en el
mbito de los lenguajes de programacin C y C++, al
archivo, normalmente en forma de cdigo fuente, que el
compilador incluye de forma automtica al procesar algn otro archivo fuente. Tpicamente los programadores
especican la inclusin de los header les por medio de
pragmas al comienzo (head o cabecera) de otro archivo
fuente.
Un header le contiene, normalmente, una declaracin
directa de clases, subrutinas, variables, u otros
identicadores. Aquellos programadores que desean
declarar identicadores estndares en ms de un archivo
fuente pueden colocar esos identicadores en un nico
header le, que se incluir cuando el cdigo que contiene
sea requerido por otros archivos.
La biblioteca estndar de C y la biblioteca estndar de
C++ tradicionalmente declaran sus funciones estndar en
header les.

8.1 Motivacin
En la mayora de lenguajes de programacin modernos,
los programadores pueden dividir los programas en componentes de menor tamao (como pueden ser clases y
subrutinas) y distribuir esos componentes entre muchas
unidades por traducir (tpicamente en forma de archivos),
que el sistema puede compilar de forma autnoma. Si una
subrutina se tiene que usar al margen de la unidad por
traducir donde ha sido denida, se tiene que introducir el
concepto de declaracin directa o prototipos de funciones. Por ejemplo, una funcin denida as en un archivo
fuente:

Sin embargo en esta simple ilustracin se requiere que

el programador mantenga la declaracin de la funcin de
add en dos sitios en el archivo que contiene su implementacin y en el archivo que usa la funcionalidad. Si
la denicin de la funcin llega a alterarse, entonces el
programador debe actualizar todos los prototipos repartidos a lo largo del programa. Esto es necesario porque
la implementacin de ambos, C y C++ han de diagnosticar todas las violaciones de lo que en C++ se llama "one
denition rule" (ODR), al espaol regla de una nica
denicin. De hecho, la mayora de ellos se sirven de
un enlazador para realizar esta labor. El enlazador, sin
embargo, suele conocer, de forma muy limitada los tipos
usados en los programas. Por ello, algunas de las violaciones de ODR no se detectan a la hora de implementar el lenguaje. Como resultado, es responsabilidad del
programador el mantener la coherencia de todas las declaraciones que cruzan las fronteras de una unidad por
traducir. Buscar todas estas declaraciones de una entidad
externa y vercar que son compatibles de forma manual
es una tarea ardua. (Ntese que C no dene el trmino
one denition rulees especco del lenguaje C++.
Si declaraciones de la misma entidad en muchos archivos
fuentes de C son diferentes, la funcin no funcionar de
forma adecuada y puede llegarse a un comportamiento
impredecible, independientemente de la regla que se est
violando.)
Para entender una violacin ODR, considrese el siguiente cdigo (correcto):
/* File print-heading.c */ #include <stdio.h> void
print_heading(void) { printf(standard heading\n); }
/* File main.c */ void print_heading(void); int main(void)
{ print_heading(); return 0; }

La unidad por traducir representada por el archivo fuente main.c referencia a la funcin print_heading() que est
denida 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 funcin externa antes del primer uso. Para
puede declararse (con un prototipo de funcin) y ser re- cumplir con este requisito el archivo main.c declara la
ferida desde un segundo archivo fuente como sigue:
funcin en la primera lnea. Esta versin del cdigo funint add(int, int); int triple(int x) { return add(x, add(x, ciona de forma correcta.
x)); }
Posteriormente, el programador que mantiene el archivo

21

22

CAPTULO 8. ARCHIVO DE CABECERA

fuente print-heading.c puede decidir hacer la funcin ms /* File add.c */ #include [Link] add(int a, int b) {
exible y dar soporte a cabeceras a gusto del usuario. Una return a + b; }
posible implementacin podra ser la siguiente:
/* File print-heading.c */ #include <stdio.h> void Normalmente, los programadores slo utilizan los heaprint_heading(const char *heading) { printf("%s\n, der les para especicar los interfaces, y suelen aportar al
heading); }
menos, una pequea cantidad de informacin explicando
cmo usar los componentes declarados en el archivo. Al
Si el programador olvida actualizar la declaracin en igual que en este ejemplo, las implementaciones de sumain.c, se pueden dar resultados devastadores. La fun- brutinas permanecen en un archivo fuente separado, que
cin print_heading() espera un argumento y hace uso del continua siendo compilado de forma independiente. (Una
valor del mismo, sin embargo la funcin main() no pro- excepcin comn entre C y C++ son las "funciones inlivee ningn valor. Al ejecutar este programa se produce un ne", que suelen incluirse en header les porque la mayora
comportamiento impredecible: la aplicacin puede im- de implementaciones no pueden expendir funciones inliprimir basura, terminar de forma inesperada o dar pie a ne de forma adecuada sin ver sus deniciones durante el
resultados impredecibles en la plataforma en la que es eje- tiempo de compilacin.)
cutado.
Por qu se puede compilar y enlazar este cdigo sin problema alguno? El motivo es que el compilador se gua por
la declaracin en main.c a la hora de compilar la unidad
por traducir main.c. Y esa declaracin se ajusta con la forma de la funcin. Ms tarde, cuando el enlazador combina
las unidades de traduccin ya compiladas main.c y printheading.c (en la mayora de implementaciones representadas como archivos main.o o [Link]), probablmente
podra detectar la inconsistencia pero no en C. Las
implementaciones en C referencian las funciones por el
nombre al nivel de archivo objeto y archivo binario, esto
no incluye el valor de retorno o la lista de argumentos. El
enlazador encuentra una referencia a print_heading() en
main.o y una funcin adecuada en print-heading.o. Llegado este punto, toda la informacin relativa a tipos de
argumentos de funciones se pierde.
Cmo es entonces posible llevar a cabo declaraciones
mltiples sin problema alguno? La solucin se llama header le. El header le de un mdulo declara cada funcin,
objeto y tipo de dato que forma parte del interfaz pblico del mdulo por ejemplo, en este caso el header le
incluira slo la delcaracin de add. Todo aquel archivo
fuente que se reera a add usa la directiva #include en el
header le:

8.2 Alternativas
Los header les no son la nica solucin al problema de
acceder identicadores declarados en diferentes archivos.
Tienen la desventaja de que los programadores siguen teniendo que realizar cambios en dos sitios diferentes (en
el archivo fuente y en el header le) cuando se realiza un
cambio en una denicin. Algunos lenguajes ms jvenes (como Java) prescienden de los header les y usan, en
su lugar, una esquema de nombres que permite al compilador localizar los archivos fuente asociados con implementaciones de clases e interfaces (pero, al hacerlo, se
restringe la libertad a la hora de nombrar archivos). En
estos lenguajes, el problema de ODR se suele resolver
por medio de dos tcnicas: la primera, el compilador pone toda la informacin necesaria sobre los tipos en el cdigo compilado y esta informacin es accesisble incluso
cuando el programa se ejecuta.; la segunda, Java y otros
lenguajes modernos tienen la posiblidad de vericar el
nmero y tipo de los argumentos como mtodo de invocacin. Todo esto tiene su precio: un exceso en espacio
y tiempo de ejecucin que no es aceptable para algunas
aplicaciones donde el tiempo de respuesta es crtica.

/* File add.h */ #ifndef ADD_H #dene ADD_H int COBOL y RPG IV tienen una forma de incluir archivos
llamada copybooks. Los programadoresincluyenstos
add(int, int); #endif /* ADD_H */
en la fuente del programa de forma similar a como se hace con los header les, permitiendo tambin reemplazar
(Ntese que el header le utiliza un "Include guard".)
ciertas partes del texto. La palabra clave de COBOL para
/* File triple.c */ #include [Link] triple(int x) { la inclusin es copy, y el reemplazo se realiza por medio
de la clusula replacing...by.
return add(x, add(x, x)); }
Esto reduce la carga del mantenimiento: cuando una denicin cambia, solo se tiene que actualizar una nica
copia de la declaracin (la del chero de cabecera). El
chero de cabecera tambin se puede incluir en el chero fuente que contiene las correspondientes deniciones,
dndole al compilador la oportunidad de comprobar si la
declaracin y la denicin son consistentes.

8.3 Vase tambin

Application Programming Interface
Interface description language
#pragma once

8.4. ENLACES EXTERNOS

8.4 Enlaces externos

Esta obra deriva de la traduccin de Header le de Wikipedia en ingls, publicada por sus editores bajo la Licencia de documentacin libre de
GNU y la Licencia Creative Commons AtribucinCompartirIgual 3.0 Unported.
Organizing Code Files (the potential pitfalls and guidelines for using header les in C++)
C++ header le inclusion rules

23

Captulo 9

Asercin (informtica)
En programacin, una asercin es un predicado (i.e., una 9.1 Uso de las aserciones
sentencia verdadero-falso) incluido en un programa como indicacin de que el programador piensa que dicho En lenguajes como Eiel, las aserciones son parte del propredicado siempre se cumple en ese punto del ujo de ceso de diseo, mientras que en otros, como C o Java,
programa.
solamente son utilizadas para comprobar suposiciones en
Por ejemplo, el siguiente cdigo contiene dos aserciones: tiempo de ejecucin.
x := 5; {x > 0} x := x + 1 {x > 1}

9.1.1 Aserciones en el diseo por contrato

x > 0 y x > 1, y las dos son ciertas en dichos puntos de la
Las aserciones pueden ser una forma de documentacin:
ejecucin.
pueden describir el estado en que el cdigo empieza su
Las aserciones suelen ser tiles para especicar prograejecucin (precondicin), y el estado que el cdigo espera
mas y para razonar la correccin de los mismos. Por
alcanzar cuando nalice (postcondicin); asimismo pueejemplo, una precondicin una asercin al comienzo
den servir de especicacin para los invariantes de clase.
de una seccin de cdigo determina que se espera que
En Eiel, tales aserciones se integran en el cdigo y son
el conjunto de sentencias que la siguen sean ejecutadas.
automticamente extradas para documentar la clase. EsUna postcondicin colocada al nal describe el estato supone una parte importante del mtodo de diseo por
do que se espera alcanzar al nal de la ejecucin.
contrato.
El ejemplo anterior utiliza la notacin introducida por C.
Esta aproximacin tambin resulta til en lenguajes que
A. R. Hoare en su artculo de 1969 "An axiomatic bano las soportan explcitamente: la ventaja de usar sentensis for computer programming" ("Una base axiomcias de asercin en lugar de aserciones en comentarios es
tica para la programacin de ordenadores"). Como esta
que las primeras pueden ser comprobadas en cada ejecunotacin normalmente no es aceptada por los compiladocin; si la asercin no se cumple, puede informarse del
res de los lenguajes actuales, los programadores suelen
error. Esto previene que el cdigo y las aserciones se desincluir aserciones mediante comentarios. A continuacin
fasen (un problema que puede ocurrir con las aserciones
se incluye un ejemplo en C:
comentadas).
x = 5; /* {x > 0} */ x = x + 1; /* {x > 1} */
Se han incluido las llaves para distinguir este uso de los
comentarios de su uso habitual.
Varios lenguajes de programacin modernos incluyen
una sentencia de asercin, que no es ms que una asercin
que se comprueba en tiempo de ejecucin. Si su evaluacin resulta falsa, se produce un error de asercin.
La intencin de estas sentencias de asercin es facilitar la
depuracin del programa, evitando que dicho fallo quede
sin comprobar.

9.1.2 Aserciones en tiempo de ejecucin

Una asercin puede ser utilizada para vericar que una
suposicin hecha por el programador durante la implementacin del programa sigue siendo vlida durante la
ejecucin del programa. Por ejemplo, considrese el siguiente cdigo en Java:
int total = contarUsuarios(); if (total % 2 == 0) { // total es par } else { // total es impar assert(total % 2 == 1); }

El uso de aserciones ayuda al programador en las tareas

En Java, % es el operador resto (no mdulo) si el pride diseo, desarrollo y razonamiento de un programa.
mer operando es negativo, el resultado puede ser tambin
negativo, Aqu, el programador ha asumido que la variable total no es negativa, as que el resto de una divisin
entre 2 siempre ser 0 o 1. La asercin explicita esta su24

9.2. DESACTIVACIN DE LAS ASERCIONES

25

posicin si contarUsuarios devuelve un valor negativo,

es probable que haya un fallo en el programa.

9.2 Desactivacin de las aserciones

Una gran ventaja de esta tcnica es que cuando se produce

algn error ste es inmediata y directamente detectado,
evitando posibles daos colaterales ocultos. Puesto que
un error de asercin normalmente informa de la lnea de
cdigo donde se produce, se puede localizar el error sin
necesidad de una depuracin ms exhaustiva.

Las aserciones suelen ser implementadas de modo que

puedan ser activadas o desactivadas, normalmente en el
conjunto del programa. Sin embargo, los lenguajes que
distinguen entre distintos tipos de aserciones [Link]. pre
y postcondiciones suelen permitir activarlas o desactivarlas de forma independiente. Si las aserciones son desactivadas, no se comprueban en tiempo de ejecucin. De
esta forma el programador puede colocar aserciones en
lugares donde en otro caso no tendra sentido ponerlas
([Link]., comprobar que no se accede a un array mediante ndices fuera de rango). Puesto que las aserciones son
en principio una herramienta de desarrollo, normalmente
son desactivadas cuando el programa en cuestin es publicado. Por otra parte, como algunas versiones del programa pueden incluir aserciones y otras no, es primordial
que su desactivacin no modique el comportamiento del
programa. En otras palabras, las aserciones deben ser libres de efectos colaterales. Una alternativa en el caso de
C o C++ es redenir la macro assert para evaluar la expresin incluso cuando las aserciones estn desactivadas.

Las aserciones tambin suelen colocarse en puntos que

se supone que no se alcanzan durante la ejecucin. Por
ejemplo, las aserciones pueden ser colocadas en la clusula default de una estructura switch en lenguajes como
C, C++ y Java. Los casos que intencionadamente no se
manejan pueden provocar errores que aborten el programa.

En Java, las aserciones han sido parte del lenguaje desde

la versin 1.4. Los errores de asercin resultan en AssertionError cuando el prorgama es ejecutado con los parmetros correctos, sin los cuales las sentencias de asercin
son ignoradas. En C y C++, son aadidas por el chero de
cabeceras estndar assert.h deniendo assert (asercin)
como una macro que devuelve un error en caso de fallo y
La eliminacin de las aserciones del cdigo de producnaliza el programa.
cin es un proceso que se realiza de forma casi automLas inclusin en los lenguajes de construcciones de aser- tica. Normalmente se realiza mediante compilacin concin 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 parmetro de ejecucin, como en
ra independiente que implemente dichas aserciones.
Java. Algunas personas, sin embargo, se oponen a la eliminacin de las aserciones basndose en una analoga que
compara la ejecucin con aserciones y sin ellas en la fase
de desarrollo con la prctica de la natacin en una piscina
9.1.3 Aserciones durante el ciclo de desa- con la vigilancia de un socorrista para despus nadar solo
rrollo
en el mar. Asimismo aaden que las aserciones tambin
ayudan a desarrollar un programa a prueba de fallos.
Durante el ciclo de desarrollo, el programador normalmente ejecuta su programa con las aserciones activadas.
Cuando una asercin resulta falsa y se produce el correspondiente error, el programador automticamente recibe 9.3 Comparacin con los manejaun aviso. Muchas implementaciones adems detienen la
dores de errores
ejecucin del programa esto resulta til ya que si el programa sigue ejecutndose tras la violacin de una aserEs importante establecer las semejanzas y diferencias encin, ste entra en un estado corrupto que puede hacer
tre las aserciones y las rutinas de control de errores. Las
ms difcil la localizacin del problema. Gracias a la inaserciones deberan ser utilizadas para documentar situaformacin proporcionada por el error de asercin (punto
ciones lgicamente imposibles y descubrir posibles errodel cdigo que ha provocado el fallo, quizs el stack trace
res de programacinsi eseimposibleocurre, es que
o incluso todo el contexto de la asercin violada), el proalgo fundamental est claramente equivocado. Esto diegramador puede corregir el problema. De este modo, las
re del control de errores: la mayora de las condiciones de
aserciones sirven como potente herramienta de depuraerror son posibles, aunque deberan ser muy poco probacin.
bles en la prctica. El uso de aserciones como mecanismo
general de control de errores suele ser algo desacertado:
las aserciones no permiten al programa recuperarse de
los errores, y un fallo de asercin suele suponer una ter9.1.4 Aserciones estticas
minacin abrupta del programa. Asimismo las aserciones
Las aserciones que son comprobadas en tiempo de com- no suelen mostrar mensajes de error comprensibles por el
pilacin reciben el nombre de aserciones estticas. Este usuario.
tipo de aserciones resultan particularmente tiles en la Considrese el siguiente ejemplo de uso de aserciones pametaprogramacin de plantillas.
ra manejar un error:

26
int *ptr = malloc(sizeof(int) * 10); assert(ptr != NULL);
// usar ptr
Aqu, el programador advierte que malloc puede devolver un puntero a NULL si no resulta posible realizar la
asignacin de memoria. Esto es posible: el sistema operativo no garantiza que cada llamada a malloc termine con
xito, y el programa debe estar preparado para manejar
el error. Una asercin quizs no es la mejor eleccin en
este caso, ya que un error causado por malloc no es lgicamente imposible es una posibildad legtima, aunque
no es muy comn que suceda. En este ejemplo, es cierto
que la asercin resulta til, aclarando que el programador
ha decidido de forma deliberada no construir una rutina
robusta de control de errores de asignacin de memoria.
El programador tambin puede decidirse por una utilizacin mixta de aserciones y rutinas estndar de control de
errores para un mismo problema. Esto es til en situaciones donde el programador quiere recibir aviso inmediato
del error, pero con la seguridad de que ser manejado de
forma correcta en situaciones reales de explotacin del
programa. En el ejemplo anterior, esto supondra aadir
una rutina de control de errores, pero tambin habra que
mantener la asercin para que el programador supiese del
fallo de memoria durante el proceso de depuracin. Esto
permite al programador localizar errores de forma ms
sencilla, lo que a su vez har que el usuario nal pueda ejecutar el programa sin recibir mensajes de error innecesarios. Esta tctica solamente resulta til cuando el
error especicado no supone la terminacin abrupta del
programa o afecte a los datos que ste maneja, sino que
har que el programa siga funcionando aunque sea ms
lentamente o de forma menos eciente.

9.4 Enlaces externos

Hoare, C. A. R. (2001). Assertions: a personal perspective. [Link]. Archivado desde el original el 02 de diciembre de 2015.
Programming With Assertions in Java. [Link]. Archivado desde el original el 02 de diciembre de 2015.
Using Assertions. [Link]. Artculo tcnico.

CAPTULO 9. ASERCIN (INFORMTICA)

Captulo 10

Automatizacin de tareas
La automatizacin de tareas es, en informtica, el conjunto de mtodos que sirven para realizar tareas repetitivas en un ordenador. Algunos mtodos para la automatizacin de tareas son la programacin simple, los macros,
los intrpretes y las bombas lgicas. Tambin hay algunos
programas especcos que automatizan tareas. Incluso los
virus informticos utilizados de forma benca podran
considerarse otro mtodo para la automatizacin de tareas para el usuario.

27

Captulo 11

Base de cdigo
El trmino codebase, o base de cdigo, es usado en
el desarrollo de software con el signicado de la coleccin completa de cdigo fuente usada para construir una
aplicacin o componente particular. Tpicamente, el codebase incluye solamente los archivos del cdigo fuente
escritos por humanos y no los archivos del cdigo fuente
generados por otras herramientas o archivos de biblioteca
binaria. Sin embargo, incluye generalmente archivos de
conguracin y de propiedades.
El codebase para un proyecto es tpicamente almacenado en un repositorio de control de fuentes. Un repositorio del cdigo fuente es un lugar en donde son guardadas
grandes cantidades de cdigo fuente, tanto pblicamente como privadamente. Son frecuentemente usados por
proyectos de multi-desarrolladores para manejar, de una
manera organizada, varias versiones y los conictos que
se presentan con los desarrolladores sometiendo modicaciones conictivas. Subversion y Mercurial son herramientas populares usadas para manejar este ujo de trabajo, y son comunes en proyectos de fuente abierta.
Rerindose a mltiples codebases como distintosse
declara que hay implementaciones independientes sin cdigo fuente compartido y que histricamente, estas implementaciones no evolucionaron de un proyecto comn.
En el caso de estndares, esto puede ser una manera de
demostrar interoperabilidad mostrando dos piezas independientes de software que implementan un estndar dado.

11.1 Vase tambin

Apache Software Foundation
Bonsai (software)
Codase
Forja (software)
Programas para control de versiones
Control de versiones
SourceForge
Subversion (software)

28

Captulo 12

Bean
Un Bean es un componente software que tiene la particularidad de ser reutilizable y as evitar la tediosa tarea de
programar los distintos componentes uno a uno. Se puede decir que existen con la nalidad de ahorrarnos tiempo
al programar. Es el caso de la mayora de componentes
que manejan los editores visuales ms comunes. Los que
hayan utilizado Visual Studio, Eclipse o Delphi por ejemplo, ya estarn familiarizados con ellos. Un Bean puede
representar desde un botn, un grid de resultados, un panel contenedor o un simple campo de texto, hasta otras
soluciones mucho ms complejas como conexiones a bases de datos, etc.
Son bastante conocidas las EJB (Enterprise JavaBeans)
que ofrecen numerosos Beans para Java.

12.1 Bean en Java

Debe cumplir los siguientes criterios:
- implementacin serializable.
- tener todos sus atributos privados (private).
- tener mtodos set() y get() pblicos de los atributos privados.
- tener un constructor pblico por defecto

12.2 Enlaces externos

JavaBeans de Sun

29

Captulo 13

Beta tester
Un Beta tester es un usuario de programas cuyos ejecutables estn pendientes de terminar su fase de desarrollo,
o alcanzar un alto nivel de funcionamiento, pero que an
no son completamente estables.* [1]

13.1 Generalidades
Los beta testers usan sus conocimientos informticos y su
tiempo para detectar errores en la versin beta del software y as poder informar de stos para que los desarrolladores los corrijan, o corregirlos ellos mismos. Algunas compaas los contratan para asegurarse de que sus
programas van a funcionar lo mejor posible en el mercado. Otro tipo de beta testers son los que trabajan desinteresadamente ofreciendo soporte y ayuda a la comunidad
GNU.
Generalmente elbetatestercomparte una cierta anidad con la herramienta puesta a prueba en cuestin, de ah
el entusiasmo por probarla, vericar nuevas funcionalidades y detectar anomalas en pos de mejorar el desarrollo
de la herramienta en cuestin.

13.2 Alfa tester

Es el mismo concepto, pero aplicado a la versin alfa del
software, es decir, al software que se encuentra en la fase
alfa del desarrollo.

13.3 Vase tambin

Fases del desarrollo de software

13.4 Referencias
[1] S.E. Smith (2003). What is a Beta Tester? (en ingls).
Consultado el 20 de octubre de 2010.

30

Captulo 14

Bifurcacin (sistema operativo)

Este artculo se reere a la bifurcacin
de procesos en sistemas operativos, consulta
Bifurcacin (informtica) para otros usos.

Soy el padre con id 1 id proceso original 1 Soy el hijo con

id 2 id proceso original 1

Una bifurcacin o fork, cuando se aplica en el contexto de un lenguaje de programacin o un sistema operativo, hace referencia a la creacin de una copia de s mismo por parte de un programa, que entonces acta como
un "proceso hijo" del proceso originario, ahora llamado
"padre". Los procesos resultantes son idnticos, salvo que
tienen distinto nmero de proceso (PID).
Ms generalmente, una bifurcacin en un entorno
multihilo signica que un hilo de ejecucin se bifurca.

El orden de la salida ser determinada por diversos parmetros del ncleo del sistema operativo. Como se puede observar, el valor contenido en la variable idPropio es
compartido por proceso padre e hijo; sin embargo, la referencia a la variable no es la misma y su posterior modicacin en cada cdigo, ya sea del padre o del hijo, no se
ver reejada en ambos procesos.

14.2 Vase tambin

Bomba fork
Tubera

14.1 UNIX
En el caso de los sistemas operativos derivados de UNIX,
la llamada al sistema fork permite realizar una bifurcacin del proceso. Esta llamada devuelve el identicador
de proceso del proceso hijo al padre y un 0 al proceso
hijo.
Aqu hay un ejemplo escrito en lenguaje de programacin
C que muestra el uso de esta llamada. El cdigo 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 idPropio; idPropio = getpid(); //Se obtiene el id del proceso
actual idHijo = fork(); //Se crea un proceso 'hijo' if
(idHijo == 1) { //Si hay un cdigo menor que cero,
hubo un error perror(Error al realizar la bifurcacin
); //Se notica al usuario return 1; //Se interrumpe la
ejecucin del proceso con una salida distinta a cero } if
(idHijo == 0) //la ejecucin 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 ejecucin de la llamada al
sistema fork devuelve el identicador al proceso 'padre'
printf(Soy el padre con id %ld id proceso original
%ld\n, (long)getpid(), (long)idPropio); return 0; }
Este cdigo imprimir:
31

Captulo 15

Binding
15.4 Enlaces externos

15.1 Psicologa y educacin

En Psicologa, el trmino binding se reere a una metodologa innovadora (Proyecto Binding) para ensear a leer
que nace de aplicar la evidencia cientca en el mbito
del aprendizaje, desarrollada por la Universidad de Barcelona. Saber cmo trabaja nuestro cerebro para realizar
una tarea tan complicada como la lectura es esencial para poder crear las mejores tcnicas de aprendizaje lector
([Link]
Aunque todava queda mucho camino por recorrer en este sentido, hoy en da se sabe que leer (y comprender) es
el resultado de una gran cantidad de procesos cognitivos:
la memoria de trabajo, el bucle fonolgico, la capacidad
de inferencia y deduccin, entre otros. As pues, Binding
parte de la idea de que la mejor manera de ensear a leer
es entrenar lo que se ha comprobado cientcamente que
es importante a la hora de adquirir la lectura - decodicacin, memoria de trabajo, morfologa, lxico . Los
resultados extrados los ltimos aos de la aplicacin del
Binding as lo avalan.

15.2 Informtica
En informtica, un binding es una ligadurao referencia a otro smbolo ms largo y complicado, y que se
usa frecuentemente. Este otro smbolo puede ser un valor
de cualquier tipo, numrico, de cadena, etc o el nombre
de una variable que contiene un valor o un conjunto de
valores.
En el campo de la programacin, un binding es una adaptacin de una biblioteca para ser usada en un lenguaje de
programacin distinto de aqul 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

[Link] - Informacin sobre el programa 'Binding'

Captulo 16

Bloqueo mutuo
En sistemas operativos, el bloqueo mutuo (tambin conocido como interbloqueo, traba mortal, deadlock, abrazo mortal) es el bloqueo permanente de un conjunto de
procesos o hilos de ejecucin en un sistema concurrente que compiten por recursos del sistema o bien se comunican entre ellos. A diferencia de otros problemas de
concurrencia de procesos, no existe una solucin general
para los interbloqueos.

R1

Todos los interbloqueos surgen de necesidades que no

pueden ser satisfechas, por parte de dos o ms procesos.
En la vida real, un ejemplo puede ser el de dos nios que
intentan jugar al arco y echa, uno toma el arco, el otro
la echa. Ninguno puede jugar hasta que alguno libere lo
que tom.
En el siguiente ejemplo, dos procesos compiten por dos
recursos que necesitan para funcionar, que slo pueden
ser utilizados por un proceso a la vez. El primer proceso
obtiene el permiso de utilizar uno de los recursos (adquiere el lock sobre ese recurso). El segundo proceso toma el
lock del otro recurso, y luego intenta utilizar el recurso
ya utilizado por el primer proceso, por lo tanto queda en
espera. Cuando el primer proceso a su vez intenta utilizar
el otro recurso, se produce un interbloqueo, donde los dos
procesos esperan la liberacin del recurso que utiliza el
otro proceso.

16.1 Representacin de Bloqueos

Mutuos usando grafos

R2
B

Ejemplo de representacin de Bloqueo Mutuo en grafos de alocacin de recursos con dos procesos A y B, y dos recursos R1 y
R2.

16.2 Condiciones necesarias

Tambin conocidas como condiciones de Coman por
su primera descripcin en 1971 en un artculo escrito por
E. G. Coman.
Estas condiciones deben cumplirse simultneamente y no
son totalmente independientes entre ellas.
Sean los procesos P0 , P1 , ..., Pn y los recursos R0 , R1 , ...,
Rm :

El Bloqueo mutuo tambin puede ser representado usando grafos dirigidos, donde el proceso es representado por
un cuadrado y el recurso, por un crculo. Cuando un proceso solicita un recurso, una echa es dirigida del crculo
al cuadrado. Cuando un recurso es asignado a un proceso,
una echa es dirigida del cuadrado al crculo.
En la gura del ejemplo, se pueden ver dos procesos diferentes (A y B), cada uno con un recurso diferente asignado (R1 y R2). En este ejemplo clsico de bloqueo mutuo,
es fcilmente visible la condicin de espera circular en
la que los procesos se encuentran, donde cada uno solicita
un recurso que est asignado a otro proceso.
33

Condicin de exclusin mutua: existencia de al

menos de un recurso compartido por los procesos,
al cual slo puede acceder uno simultneamente.
Condicin de retencin y espera: al menos un proceso Pi ha adquirido un recurso Ri , y lo retiene mientras espera al menos un recurso Rj que ya ha sido
asignado a otro proceso.
Condicin de no expropiacin: los recursos no
pueden ser expropiados por los procesos, es decir,
los recursos slo podrn ser liberados voluntariamente por sus propietarios.

34
Condicin de espera circular: dado el conjunto
de procesos P0 ...Pm (subconjunto del total de procesos original),P0 est esperando un recurso adquirido
por P1 , que est esperando un recurso adquirido por
P2 ,... ,que est esperando un recurso adquirido por
Pm , que est esperando un recurso adquirido por P0 .
Esta condicin implica la condicin de retencin y
espera.

CAPTULO 16. BLOQUEO MUTUO

La condicin de espera circular es la ms fcil de
atacar. Se le permite a un proceso poseer slo un
recurso en un determinado momento, o una jerarqua puede ser impuesta de modo tal que los ciclos
de espera no sean posibles.

16.5 Livelock

Un livelock es similar a un deadlock, excepto que el estado

de los dos procesos envueltos en el livelock constantemente cambia con respecto al otro. Livelock es una forma de
Los bloqueos mutuos pueden ser evitados si se sabe cier- inanicin y la denicin general slo dice que un proceso
ta informacin sobre los procesos antes de la asignacin especco no est procesando.
de recursos. Para cada peticin de recursos, el sistema
En un ejemplo del mundo real, un livelock ocurre por
controla si satisfaciendo el pedido entra en un estado inejemplo cuando dos personas, al encontrarse en un paseguro, donde puede producirse un bloqueo mutuo. De
sillo angosto avanzando en sentidos opuestos, y cada una
esta forma, el sistema satisface los pedidos de recursos
trata de ser amable movindose a un lado para dejar a
solamente si se asegura que quedar en un estado seguro.
la otra persona pasar, pero terminan movindose de lado
Para que el sistema sea capaz de decidir si el siguiente
a lado sin tener ningn progreso, pues ambos se mueven
estado ser seguro o inseguro, debe saber por adelantahacia el mismo lado, al mismo tiempo.
do y en cualquier momento el nmero y tipo de todos los
recursos en existencia, disponibles y requeridos. Existen Livelock es un riesgo con algunos algoritmos que detectan y recuperan los interbloqueos, pues si ms de uno tovarios algoritmos para evitar bloqueos mutuos:
ma cartas en el asunto, la deteccin del interbloqueo puede ser disparada continuamente; pudiendo ser arreglado
Algoritmo del banquero, introducido por Dijkstra.
asegurndose que slo un proceso (escogido al azar o por
Algoritmo de grafo de asignacin de recursos.
prioridad) tome accin.
Algoritmo de Seguridad.

16.3 Evitando bloqueos mutuos

Algoritmo de solicitud de recursos.

16.4 Prevencin
Los bloqueos mutuos pueden prevenirse asegurando que
no suceda alguna de las condiciones necesarias vistas anteriormente.
Eliminando la exclusin mutua: ningn proceso puede tener acceso exclusivo a un recurso. Esto es imposible para procesos que no pueden ser encolados
(puestos en un spool), e incluso con colas tambin
pueden ocurrir interbloqueos.
La condicin de posesin y espera puede ser eliminada haciendo que los procesos pidan todos los recursos que van a necesitar antes de empezar. Este
conocimiento por adelantado muchas veces es imposible nuevamente. Otra forma es requerir a los
procesos liberar todos sus recursos antes de pedir todos los recursos que necesitan. Esto tambin es poco
prctico en general.
La condicin de no expropiacin puede ser tambin
imposible de eliminar dado que un proceso debe poder tener un recurso por un cierto tiempo o el procesamiento puede quedar inconsistente.

Captulo 17

Bodyshopping
Bodyshopping es un trmino ligado al mundo empresarial informtico o tecnolgico que hace referencia a la
venta de capital humano. Conlleva la cesin de personal
de este tipo a terceras empresas con nimo de lucro.
Trmino que proviene del ingls que podramos denir
como anglicismo o extranjerismo y que en su traduccin
literal hace referencia a la compra de cuerpos. Una forma castiza de denominar estas empresas es charcuteras o
crnicas.
Esta prctica es muy habitual en el mundo de la consultora informtica y existen multitud de empresas que basan
su negocio en esta "venta" de personal actuando prcticamente como empresas de trabajo temporal orientadas
a la tecnologa.
En ocasiones ciertas compaas que tienen esta prctica
como ncleo de su negocio, fundamentan sus ingresos en
la contratacin de este personal, normalmente con poca
experiencia y bajo salario, con contratos temporales o
por obra, quienes posteriormente son revendidos a terceras empresas como profesionales altamente cualicados y
con una gran experiencia, siendo sta nica y exclusivamente la base de su negocio y de su Retorno de la inversin, ya que a menos experiencia y salario del personal,
mayor benecio por las altas tarifas cobradas.
La legislacin espaola expone claramente en su Estatuto
de los Trabajadores (Artculo 43. Cesin de trabajadores.)
que el bodyshopping es ilegal.

17.1 Enlaces externos

Trabajo Basura Directorio con estas empresas y experiencias personales de gente que ha trabajado en
ellas.
Trabajungla Experiencias personales y salarios sobre estas empresas revelados de forma annima.
El Informtico Impasible: Outsourcing: OnShore y
OShore
El Sector de la Consultora Informtica en Espaa
Peccata Minuta
Entendiendo el Bodyshopping Peccata Minuta
35

Las consultoras informticas :: [Link]

Podcast monogrco sobre consultora

Captulo 18

BrookGPU
BrookGPU fue desarrollado por la Universidad de Stanford, es un grupo de compiladores y aplicaciones basadas en el lenguaje Brook para utilizar con unidades de
procesamiento grco (GPU). la programacin con unidades GPU es continuamente abreviada con el nombre
de General-purpose computing on graphics processing
units (GPGPU). Para usar este programa es necesario
una unidad de procesamiento grco (GPU) tipo ATI,
NVIDIA o Grcos integrados Intel, capaces de soportar
gran paralelismo. BrookGPU compila programas escritos
en Brook, una extensin de ANSI C diseado para incorporar computacin de datos paralelos y aritmticos con
un ecaz y familiar lenguaje. respecto al modelo general de programacin, por ujo de datos tipo por Stream,
ofrece 2 grandes ventajas respecto a estos:
Paralelismo de datos: permite al programador especicar cmo realizar las mismas operaciones en
paralelo sobre diferentes datos.
Intensidad aritmtica: le da a los programadores
el poder para minimizar la comunicacin global de
las operaciones y maximizar la comunicacin local
de las mismas
Muchos de los progresos en este lenguaje se han visto en
el proyecto de computacin distributiva Folding@home,
adems con el n de expandir las nuevas tcnicas
GPGPU, viene bajo licencia GPL, y as abrir las puertas
a nuevos programadores de Direct3D, OpenGL o hasta
Close to Metal sin dejar los detalles implementados en
estos dichos lenguajes.* [cita requerida]

36

Captulo 19

Caja blanca (sistemas)

En programacin, se denomina cajas blancas a un tipo
de pruebas de software que se realiza sobre las funciones internas de un mdulo. As como las pruebas de caja
negra ejercitan los requisitos funcionales desde el exterior del mdulo, las de caja blanca estn dirigidas a las
funciones internas. Entre las tcnicas usadas se encuentran; la cobertura de caminos (pruebas que hagan que se
recorran todos los posibles caminos de ejecucin), pruebas sobre las expresiones lgico-aritmticas, pruebas de
camino de datos (denicin-uso de variables), comprobacin de bucles (se verican los bucles para 0,1 e interacciones, y luego para las interacciones mximas, mximas
menos uno y ms uno).
Las pruebas de caja blanca se llevan a cabo en primer
lugar, sobre un mdulo concreto, para luego realizar las
de caja negra sobre varios subsistemas (integracin).
En los sistemas orientados a objetos, las pruebas de caja
blanca pueden aplicarse a los mtodos de la clase, pero
segn varias opiniones, ese esfuerzo debera dedicarse a
otro tipo de pruebas ms especializadas (un argumento
podra ser que los mtodos de una clase suelen ser menos complejos que los de una funcin de programacin
estructurada). Dentro de las Pruebas de Caja Blanca encontramos las llamadas coberturas (sentencia, decisin,
condicin y mltiple adems de los mencionados caminos ciclomticos propuestos por McCabe)
Este concepto tambin es utilizado de manera anloga en
la teora general de sistemas.

19.1 Vase tambin

Pruebas de software
Pruebas de caja blanca
Pruebas de caja negra

37

Captulo 20

Caja negra (sistemas)

deber conocer como es la comunicacin con los otros
mdulos (la interfaz), pero no necesitar conocer como
trabajan esos otros mdulos internamente; en otras palabras, para el desarrollador de un mdulo, idealmente, el
resto de mdulos sern cajas negras.
Esquema de una caja negra

En teora de sistemas y fsica, se denomina Caja Negra a

aquel elemento que es estudiado desde el punto de vista de
las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En
otras palabras, de una caja negra nos interesar su forma
de interactuar con el medio que le rodea (en ocasiones,
otros elementos que tambin podran ser cajas negras)
entendiendo qu es lo que hace, pero sin dar importancia a cmo lo hace. Por tanto, de una caja negra deben
estar muy bien denidas sus entradas y salidas, es decir,
su interfaz; en cambio, no se precisa denir ni conocer los
detalles internos de su funcionamiento.

20.1 Justicacin
Un sistema formado por mdulos que cumplan las caractersticas de caja negra ser ms fcil de entender ya que
permitir dar una visin ms clara del conjunto. El sistema tambin ser ms robusto y fcil de mantener, en caso
de ocurrir un fallo, ste podr ser aislado y abordado ms
gilmente.

20.2 Caja negra y programacin

modular

20.3 Pruebas de software

En pruebas de software, conociendo una funcin especca para la que fue diseado el producto, se pueden
disear pruebas que demuestren que dicha funcin est
bien realizada. Dichas pruebas son llevadas a cabo sobre
la interfaz del software, es decir, de la funcin, actuando
sobre ella como una caja negra, proporcionando unas entradas y estudiando las salidas para ver si concuerdan con
las esperadas.

20.4 Caja negra vs 'Cajanegrizar'

Este concepto de caja negra utilizado en fsica, informtica y disciplinas tcnicas o tecnolgicas en general, aunque est relacionado, no debe confundirse con el
'Cajanegrismo'; ste es un concepto ms vinculado a la
sociologa que hace referencia al hecho de que las personas solemos olvidarnos del funcionamiento interno de las
cosas (generalmente nuevos dispositivos tecnolgicos) a
medida que nos familiarizamos con ellos y terminamos
por asimilarlos como de uso cotidiano. A este proceso de
olvidar el funcionamiento interno de las cosas se le conoce con el nombre de 'cajanegrizar'.

Se podra decir que la principal diferencia entre ambos

conceptos es que mientras el primero, el estudio de un sistema como una caja negra, es un proceso de abstraccin,
En programacin modular, donde un programa (o un el segundo, el 'cajanegrismo', es ms bien un proceso de
algoritmo) es dividido en mdulos, en la fase de diseo se olvido.
buscar que cada mdulo sea una caja negra dentro del
sistema global que es el programa que se pretende desarrollar, de esta manera se consigue una independencia en- 20.5 Vase tambin
tre los mdulos que facilita su implementacin separada
por un equipo de trabajo donde cada miembro va a en Teora de sistemas
cargarse de implementar una parte (un mdulo) del pro Modularidad
grama global; el implementador de un mdulo concreto
38

20.5. VASE TAMBIN

Interfaz
Interfaz de usuario
Diseo estructurado
Caja blanca (sistemas)
Abstracto y Abstraccin
Cajanegrizar

39

Captulo 21

CamelCase
En nombres de empresas tales como
BellSouth
CompuServe
LinuxCabal
Microsoft, antiguamente MicroSoft

Ejemplo de CamelCase en un indicador.

PriceWaterhouseCoopers

CamelCase es un estilo de escritura que se aplica a frases

o palabras compuestas. El nombre se debe a que las maysculas a lo largo de una palabra en CamelCase se asemejan a las jorobas de un camello. El nombre CamelCase
se podra traducir como Maysculas/Minsculas Camello.
El trmino case se traduce comocaja tipogrca, que
a su vez implica si una letra es mayscula o minscula y
tiene su origen en la disposicin de los tipos mviles en
casilleros o cajas.
Existen dos tipos de CamelCase:

OmegaSoft
VaxaSoftware
La Sexta
eDreams
En algunos hashtag

21.2 Enlaces externos

UpperCamelCase, cuando la primera letra de cada

una de las palabras es mayscula. Ejemplo: EjemploDeUpperCamelCase.
lowerCamelCase, igual que la anterior con la excepcin de que la primera letra es minscula. Ejemplo:
ejemploDeLowerCamelCase.

21.1 Usos
En varios lenguajes de programacin
Java
.NET
C
C++
Python
C#
Objective-C
ActionScript
PHP
En las primeras herramientas wiki
40

Primer wiki, creado por Ward Cunningham

Caja alta y baja en el DRAE.

Captulo 22

Caml
Caml (Originalmente un acrnimo para Categorical let rec fact = function | 0 -> 1 | n -> n * fact(n - 1);;
Abstract Machine Language, en espaol Lenguaje Mquina Abstracto Categrico) es un dialecto de lafamilia de Esta ltima forma es la denicin matemtica de factorial
losmeta lenguajes, desarrollado en INRIA y anteriormen- como una relacin de recurrencia.
te en ENS.
Note que el compilador inri el tipo de esta funcin para
Como muchos descendientes delML, Caml es un len- ser int -> int, signica que esta funcin mapea enteros a
guaje de tipado esttico, evaluacin estricta, y utiliza enteros. Por ejemplo, 12! Es:
administracin de memoria automtica.
# fact 12;; - : int = 479001600
La primera implementacin de Caml en Lisp fue apodada
CAML pesadodebido a los requisitos de memoria y
CPU relativos a su sucesor Caml Light, aquello fue
implementado en C por Xavier Leroy y Damien Doligez.
Adems de una reescritura completa, CAML Special 22.1.3 Derivacin numrica (funciones de
Lightaadi un potente sistema de mdulos al ncleo
alto orden)
del lenguaje.
Actualmente, la implementacin principal de Caml es Desde que OCaml es un lenguaje de programacin funOCaml, el cual aade muchas caractersticas nuevas al cional, es fcil crear y repasar funciones en programas de
lenguaje, entre ellas una capa de objeto.
OCaml. Esta capacidad tiene un nmero enorme de aplicaciones. Calcular la derivada numrica de una funcin es
una de ellas. La funcind en Caml computa la derivada
22.1 Ejemplos
numrica de una funcin dada f en un punto dado x:
Lo siguiente, # representa el prompt de OCaml.

22.1.1

Hola Mundo

print_endline Hello World!";;

let d delta f x = (f (x +. delta) . f (x . delta)) /. (2. *.

delta);;
Esta funcin requiere un valor innitesimal delta. Una
buena eleccin para delta es la raz cbica del psilon de
la mquina.

El tipo de la funcin d indica que sta mapea un tipo

de dato otante a otra funcin del mismo tipo (oat ->
oat) -> oat -> oat. Esto nos permite aplicar argumen22.1.2 Funcin factorial (recursividad y tos parcialmente. Este estilo funcional es conocido como
programacin puramente funcio- curricacin. En este caso, es til al aplicar parcialmente
el primer argumento delta a d, para obtener una funcin
nal)
ms especializada:
Muchas funciones matemticas, como el factorial, son re- # let d = d (sqrt epsilon_oat);; val d : (oat -> oat) ->
presentadas ms naturalmente en una forma puramente oat -> oat = <fun>
funcional. La siguiente funcin recursiva, puramente funcional implementa la operacin factorial en Caml:
Note que el tipo inferido indica que la sustitucin d espelet rec fact n = if n=0 then 1 else n * fact(n - 1);;
ra una funcin del tipo otante oat -> oat como primer
argumento. Podemos computar una aproximacin numLa funcin puede ser escrita equivalentemente utilizando rica a la derivada de la funcin x3 x 1 en el punto
patrones de emparejamiento:
x = 3 con:
41

42

CAPTULO 22. CAML

# d (fun x -> x *. x *. x . x . 1.) 3.;; - : oat = 26.

ciation of Computer Machinery.

La respuesta correcta es: f (x) = 3x2 1 f (3) =

27 1 = 26

22.4 Enlaces externos

La funcin d se denomina funcin de alto ordenya

que acepta otra funcin (f) como argumento.

[Repositorio de Caml en Github]

[Sitio ocial de Caml]

Los conceptos de funciones curricadas y de alto orden
son tiles evidentemente en programas matemticos. De
[Tutoriales de caml (ingls)]
hecho, estos conceptos son igualmente aplicables a otras
formas de programacin y pueden ser empleados en cdigo de factor mucho ms agresivamente, resultando epro- 22.4.1 Libros
gramas ms 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 nmeros enteros de potencia en base dos puede ser implementada muy sucintamente en Caml y es un ejemplo excelente del uso de la concordancia de patrones sobre listas, tomando pares de elementos (h1 y h2) del frente y
almacenando sus sumas y diferencias en las listas s y d,
respectivamente:
# let haar l = let rec aux l s d = match l, s, d with [s], [],
d -> s :: d | [], s, d -> aux s [] d | h1 :: h2 :: t, s, d -> aux t
(h1 + h2 :: s) (h1 - h2 :: d) | _ -> invalid_arg haarin
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 patrn de emparejamiento permite transformaciones
complicadas para ser representadas claramente y sucintamente (brevemente). Adems, el compilador de OCaml
realiza concordancia de patrones en un cdigo muy ecaz, el tiempo en el que los programas arrojan resultados
es ms corto y ms rpido que el cdigo equivalente escrito con una estructura "switch-case" (Cardelli 1984, p.
210.).

22.2 Vase tambin

OCaml
ML
F#

22.3 Referencias
Cardelli, Luca (1984). Compiling a functional language
ACM simposio en LISP y programacin funcional, Asso-

Captulo 23

Cierre de exclusin mutua

En ciencias de la computacin, los cierres de exclusin Estas son:
mutua o candados son un mecanismo de sincronizacin
que limita el acceso a un recurso compartido por varios
Slo el dueo de un cerrojo puede desbloquearlo
procesos o hilos en un ambiente de ejecucin concurrente,
La readquisicin de un cerrojo no est permitida
permitiendo as la exclusin mutua.
Cuando un elemento es compartido por ms de un hilo,
pueden ocurrir condiciones de carrera si el mismo no es
protegido adecuadamente. El mecanismo ms simple para la proteccin es el cierre o cerrojo. En general cuando
debe protegerse un conjunto de elementos, se le asocia
un cerrojo. Cada proceso/hilo para tener acceso a un elemento del conjunto, deber bloquear, con lo que se convierte en su dueo. Esa es la nica forma de ganar acceso.
Al terminar de usarlo, el dueo debe desbloquear, para
permitir que otro proceso/hilo pueda tomarlo a su vez.
Es posible que mientras un proceso/hilo est accediendo a un recurso (siendo por lo tanto dueo del cerrojo),
otro proceso/hilo intente acceder. Esta accin debe esperar hasta que el cerrojo se encuentre libre, para garantizar la exclusin mutua. El proceso/hilo solicitante queda
entonces en espera o pasa a estado de bloqueo segn el
algoritmo implementado. Cuando el dueo del cerrojo lo
desbloquea puede tomarlo alguno de los procesos/hilos
que esperaban.
Este mecanismo se puede ver en un ejemplo de la vida
real. Supongamos un bao pblico, donde slo puede entrar una persona a la vez. Una vez dentro, se emplea un
cierre para evitar que entren otras personas. Si otra persona pretende usar el bao cuando est ocupado, deber quedar esperando a que la persona que entr anteriormente termine. Si ms personas llegaran, formaran una
cola (del tipo FIFO) y esperaran su turno. En informtica, el programador no debe asumir este tipo de comportamiento en la cola de espera.

Algo muy importante es que todos los procesos/hilos deben utilizar el mismo protocolo para bloquear y desbloquear los cerrojos en el acceso a los recursos, ya que si
mientras dos procesos/hilos utilizan el cerrojo de forma
correcta, existe otro que simplemente accede a los datos
protegidos, no se garantiza la exclusin mutua y pueden
darse condiciones de carrera y errores en los resultados.

23.1 Primitivas y uso

Las funciones de los cerrojos en general son tres: init(),
lock() y unlock(). El cerrojo se inicializa con la funcin
init(). Luego cada proceso/hilo debe llamar a la funcin
lock() antes de acceder a los datos protegidos por el cierre.
Al nalizar su seccin crtica, el dueo del cerrojo debe
desbloquearlo mediante la funcin unlock().

23.2 Bloqueos en bases de datos

Los sistemas gestores de bases de datos suelen utilizar
bloqueos para evitar problemas de concurrencia y, en
ocasiones, garantizar la serializabilidad de las transacciones. Para hacerlo adecuadamente, los mecanismos de bloqueo suelen implementar protocolos como el bloqueo de
dos fases y utilizar registros transaccionales (logs) como
apoyo.

El cerrojo, usado de esta manera, forma una seccin crtica en cada proceso/hilo, desde que es tomado hasta que
se libera. En el ejemplo del bao, dentro de la seccin
crtica se encuentran las funciones que se realizan generalmente dentro de este tipo de instalaciones sanitarias.
Como garantizan la exclusin mutua, muchas veces se los
denomina mutex (por mutual exclusion).
En general hay un nmero de restricciones sobre los cerrojos, aunque no son las mismas en todos los sistemas.

43

Captulo 24

Clase utilidad
En programacin, una clase utilidad es una clase que dene un conjunto de mtodos que realizan funciones, normalmente muy reutilizadas. La mayora de las clases utilidad denen estos mtodos comunes con alcance esttico.
Ejemplos de clases utilidad incluyen [Link]
que proveen muchos mtodos estticos (tales como ordenar) en objetos que implementan una Collection ([Link] ).

24.1 Enlaces externos

Utility Pattern: Para una clase utilidad, que no requiere instanciacin y slo tiene mtodos estticos,
se debe usar un constructor privado.

44

Captulo 25

[Link]
El lenguaje HTML para desarrollar pginas web no permite el alineamiento arbitrario de los objetos dentro del
documento.
Cuando Internet no se encontraba tan desarrollado, y
prcticamente el HTML era lo nico con lo que se contaba para mostrar contenidos, un truco que los desarrolladores utilizaban para poder alinear los textos a la altura y
anchura que se desearan dentro de la pgina, era crear un
archivo transparente de un pxel de tamao y en formato
grco GIF, que en aquel entonces era el nico que permita manejar transparencia en las imgenes. El archivo
era manipulado dentro del cdigo de la pgina web para
que apareciera con cierta alineacin, ya que las imgenes
si permitan la alineacin, pero no el texto.
La transparencia era importante, pues permita que la
imagen no apareciera dentro de la visualizacin de la pgina web.
El archivo era usualmente llamado [Link], aunque
cualquier desarrollador que hiciera la imagen poda crearla con el nombre que quisiera. El nombre de dicho archivo
dio lugar al de la tcnica.
La manera sencilla en la que se hace trabajar este truco
en el cdigo HTML es la siguiente:
<IMG
hspace=x
SRC="/ruta/al/archivo/[Link]">

vspace=y

Donde x y y son las coordenadas de espaciado horizontal y vertical que se desean, y el atributo SRC seala la
ruta hacia el archivo [Link]. El texto que se escriba a
continuacin de ese fragmento de cdigo, se alinear a la
altura y anchura indicada en la etiqueta.

45

Captulo 26

CMake
CMake es una herramienta multiplataforma de generacin o automatizacin de cdigo. El nombre es una abreviatura paracross platform make(make multiplataforma); ms all del uso de makeen el nombre, CMake
es una suite separada y de ms alto nivel que el sistema
make comn de Unix, siendo similar a las autotools.
CMake es una familia de herramientas diseada para
construir, probar y empaquetar software. CMake se utiliza para controlar el proceso de compilacin del software usando cheros de conguracin sencillos e independientes de la plataforma. Cmake genera makeles nativos
y espacios de trabajo que pueden usarse en el entorno
de desarrollo deseado. Es comparable al GNU build system de Unix en que el proceso es controlado por cheros
de conguracin, en el caso de CMake llamados [Link]. Al contrario que el GNU build system, que est
restringido a plataformas Unix, CMake soporta la generacin de cheros para varios sistemas operativos, lo que
facilita el mantenimiento y elimina la necesidad de tener
varios conjuntos de cheros para cada plataforma.

el Visualization Toolkit (VTK), un sistema para grcos

3D y visualizacin libres.
Para crear CMake, Bill Homan en Kitware incorpor
algunas ideas de pcmaker, y aadi ms cosas propias,
con el pensamiento de adoptar algunas de las funcionalidades del GNU build system. La implementacin inicial de CMake tuvo lugar a mediados del 2000, con un
desarrollo acelerado a comienzos del 2001. Muchas mejoras se debieron a inuencias de otros desarrolladores a
la hora de incorporar CMake a sus propios sistemas. Por
ejemplo, la comunidad de VXL adopt CMake, contribuyendo con muchas caractersticas esenciales. Brad King
aadi varias caractersticas para dar soporte a CABLE
y GCC-XML, un juego de herramientas de envoltura automticas; y GE Corporate R&D necesitaba soporte para
su infraestructura de pruebas (DART). Otras funcionalidades se aadieron para soportar la transicin de VTK's
a CMake, y soportar ParaView, un sistema de visualizacin paralela para el Advanced Computing Lab en Los
Alamos National Laboratory.

El proceso de construccin se controla creando uno o ms

cheros [Link] en cada directorio (incluyendo
subdirectorios). Cada [Link] consiste en uno o 26.2 Documentacin y tutoriales
ms comandos. Cada comando tiene la forma COMANDO (argumentos...) donde COMANDO es el nombre del Aparte de la documentacin ocial 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 predenidos y denidos por el usuario. Existen generadores makele para Unix, Borland make, Watcom make, MinGW,
MSYS y Microsoft NMake. Tambin es posible generar 26.3 Principales funcionalidades
cheros de proyecto para Code::Blocks, Eclipse CDT,
Microsoft Visual Studio de la 6 a la 10 incluyendo ver Ficheros de conguracin escritos en un lenguaje de
siones de 64 bits y KDevelop.
scripting especco para CMake
Anlisis automtico de dependencias para C, C++,
Fortran, y Java

26.1 Historia
CMake se cre en respuesta a la necesidad de disponer
de un entorno multiplataforma apropiado de construccin para el Insight Segmentation and Registration Toolkit (ITK) creado por la United States National Library of
Medicine como parte del Visible Human Project. Fue inuenciado por un sistema anterior llamado pcmaker creado por Ken Martin y otros desarrolladores para soportar
46

Soporte para SWIG, Qt, FLTK, a travs del lenguaje

de scripting de CMake
Soporte para varias versiones de Microsoft Visual
Studio, incluyendo la 6, 7, 7.1, 8.0, 9.0 y 10.0
Genera cheros para Eclipse CDT (C/C++ Development Tools)

26.6. VASE TAMBIN

47

Deteccin de cambios en cheros usando timestamps tradicionales

26.6 Vase tambin

Soporte para builds paralelos

Automake

Compilador cruzado

Autoconf

Vista global de todas las dependencias, usando

CMake para generar un diagrama graphviz

premake

Soporte para builds multiplataforma

Linux y otros sistemas POSIX (incluyendo
AIX, *BSD, HP-UX, IRIX/SGI, y Solaris)
Mac OS X
Windows 95/98/NT/2000/XP, Windows Vista, Windows 7 y MinGW/MSYS
Integrado con DART (software), CDash, CTest y
CPack, una coleccin de herramientas para prueba
y liberacin de software

SCons
VTK
Waf

26.7 Enlaces externos

CMake
CMake Wiki
Documentacin

26.4 CTest, CPack, CDash

Listas de correo

Kitware desarroll estas herramientas en colaboracin

con muchos otros. Incluyen CMake, CTest, CPack y
CDash. CPack es una utilidad de empaquetamiento y despliegue. CTest es un cliente de pruebas libre.

26.5 Aplicaciones
CMake
Avidemux
Compiz
Kicad
KVIrc
LMMS
MiKTeX
MuseScore
MySQL
OpenCV
Poppler
PvPGN
Quantum GIS
Scribus
Second Life
SuperTux
OGRE 3D
Ryzom

que

utilizan

Captulo 27

Codecademy
Codecademy es una plataforma interactiva en lnea que
ofrece clases gratuitas de codicacin en lenguajes de
programacin como Python, PHP, JavaScript, y Ruby,
as como lenguajes de marcado incluyendo HTML y
CSS* [2]* [3] y tambin uso de API's. A partir de septiembre del 2011, el sitio ha tenido ms de 550,000 usuarios que han completado ms de seis millones de ejercicios.* [4]* [5] El sitio ha recibido crticas positivas de varios blogs y sitios web, incluyendo el New York Times* [6]
y TechCrunch.* [7]

para aprender como programar, mediante la introduccin

de un nuevo curso cada semana en el 2012.* [12] Ms de
450,000 personas tomaron el curso en el 2012,* [13]* [14]
y Codecademy continua ofertando el programa en el
2013.

27.3 Vase tambin

Academic Earth

Para motivar a los usuarios a participar el sitio cuenta con

un sistema de gamicacin por el que ofrece insignias o
medallas al completar ejercicios, cuenta con foros de discusin y un glosario por curso, y mantiene un registro de
la puntuacin total del usuario y la muestra a los dems. El
sitio tambin permite que cualquier persona pueda crear
y publicar un nuevo curso usando la herramienta de creacin de cursos.

Coursera
Dev Bootcamp
edX
Gilles Babinet
Khan Academy
[Link]

27.1 Historia

Marginal Revolution University

Codecademy fue fundada en 2011 por Zach Sims y Ryan
Bubinski.* [8] Sims dej la universidad Columbia University para centrarse en el lanzamiento de una empresa,
mientras que Bubinski se gradu en Columbia con una licenciatura en ciencias de la computacin y biofsica.* [9]
La compaa actualmente se encuentra en Nueva York.
Obtuvo 2,5 millones de dlares en su primera ronda de nanciacin en octubre de 2011 y 10 millones en la segunda serie en junio de 2012.* [8]* [10] La ltima ronda de
nanciacin fue llevada a cabo por Index Ventures.* [11]

Udacity
Udemy

27.4 Referencias

Finalmente en el ao 2014, la empresa Codecademy decide vender publicidad, comenzando con brindar un banner
al gobierno de la ciudad de buenos aires.

27.2 Code Year

Code Year es un programa gratuito de Codecademy
para cualquiera que este interesado en aprender como
programar. El programa tiene la intencin de ayudar a las
personas a seguir a travs de un New Year's Resolution
48

[1] [Link] Site Info. Alexa Internet. Consultado

el 18 de Septiembre de 2015.
[2] Codecademy. Codecademy. Consultado el 4 de agosto
de 2012.
[3] Indvik, Lauren. Codeacademy Releases Free Ruby Development Courses. Mashable. Mashable. Consultado el
30 de diciembre de 2012.
[4] Frier, Sarah. Codecademy Raises $10M, Sees Job Service as Part of Its Future. Consultado el 19 de junio de
2012.
[5] Kafka, Peter. Codecademy Rounds Up $10 Million for
Web Lessons. Consultado el 19 de junio de 2012.

27.5. ENLACES EXTERNOS

[6] Wortham, Jenna. Codecademy Oers Free Coding Classes for Aspiring Entrepreneurs. The New York Times.
Consultado el 26 de julio de 2012.
[7] Cincaid, Jason. Codecademy Surges To 200,000 Users,
2.1 Million Lessons Completed In 72 Hours. TechCrunch. Consultado el 26 de julio de 2012.
[8] 30 Under 30: Zach Sims and Ryan Bubinski, Codecademy. [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 (27 de octubre de 2011). Codecademy
Lands $2.5 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 (6 de enero de 2012). Code Year draws
200,000 aspiring programmers - Jan. 6, 2012. [Link]. Consultado el 16 de febrero de 2013.
[13] Learning JavaScript With Code Year " Feld Thoughts
Feld Thoughts. [Link]. Consultado el 16 de febrero
de 2013.
[14] Codecademy. Code Year. Code Year. Consultado el 16
de febrero de 2013.

27.5 Enlaces externos

Sitio Web de Codecademy

49

Captulo 28

Cdigo cerrado
En informtica un programa es de cdigo cerrado cuando el cdigo fuente no se encuentra disponible para cualquier usuario, es decir no se hace pblico. Se le llama as
en contraposicin al cdigo abierto.
El software no libre generalmente utiliza un cdigo cerrado. Por su calidad de secreto industrial, su divulgacin
podra ser constituyente de delito en algunos pases.

28.1 Vase tambin

Software privativo

50

Captulo 29

Cdigo compilado
Un cdigo compilado es un cdigo que previamente fue
un cdigo simblico interpretable por un compilador, y
luego ese compilador lo convirti en un cdigo directamente interpretable por un controlador (Cdigo mquina).

51

Captulo 30

Cdigo mutante
En informtica, el trmino cdigo mutante o cdigo
ambiguo se emplea para referirse a un cdigo cuya integridad es modicada por s mismo durante su ejecucin, generalmente este cdigo trata de un malware por
el hecho de que si como algoritmo (cuando es ejecutado) se automodica como informacin (donde est almacenado) fcilmente puede engaar a un programa del tipo antivirus o similar. Aunque de todas maneras, ciertos
programas Antivirus son capaces de detectar este tipo de
modicaciones.

52

Captulo 31

Cdigo objeto
En programacin, se llama cdigo objeto al cdigo que con parmetros incorrectos o inexistentes puede generar
resulta de la compilacin del cdigo fuente.* [1]
un error que generalmente el compilador no detecta ya
Consiste en lenguaje mquina o bytecode y se distribuye que el cdigo objeto no es vericado, nicamente unien varios archivos que corresponden a cada cdigo fuente do. Este tipo de error se puede solucionar reescribiendo
compilado. Para obtener un programa ejecutable se han el cdigo de manera correcta y re compilarlo a cdigo
objeto.
de enlazar todos los archivos de cdigo objeto con un programa llamado enlazador (linker).

31.3 Referencias
[1] [Link]

31.4 Enlaces externos

Fases en la realizazin de software

31.1 Cdigo objeto en lenguajes de

programacin
Un claro ejemplo de lenguaje de programacin que usa
cdigo objeto en sus libreras es Pauscal. Esto le permite
aumentar la velocidad de compilacin de los programas y
reducir su tamao (ya que cada librera objeto puede ser
comprimida), tambin permite a programadores compartir sus libreras/funciones sin tener la necesidad de liberar
sus cdigos fuentes originales. Incluso puede permitir a
distintos lenguajes de programacin compartir funciones
sin necesidad de tener que reescribir el cdigo plano a sus
respectivas sintaxis.

Wikcionario tiene deniciones y otra informacin sobre cdigo [Link]

el cdigo objeto es el resultado de la compilacin del cdigo fuente. Puede ser en lenguaje mquina o bytecode, y
puede distribuirse en varios archivos que corresponden a
cada cdigo fuente compilado. Luego un enlazador (linker) se encarga de juntar todos los archivos de cdigo
objeto para obtener el programa ejecutable. - See more at: [Link]
php#[Link] Cdigo objeto: Conjunto de
instrucciones y datos escritos en un lenguaje que entiende el ordenador directamente: binario o cdigo mquina.
Provienen de la traduccin de cierto cdigo fuente, es un
fragmento del programa nal y es especco de la plataforma de ejecucin.

31.2 Errores comunes

Los cdigo objeto pueden ser muy tiles en muchas situaciones sin embargo consigo traen problemas que pueden generar errores muy difciles de corregir, por ejemplo cuando un objeto importa funciones de otro cdigo
objeto que ha sido modicado, el intento de la librera o
el programa que import la librera de ejecutar el cdigo
53

Captulo 32

Ofuscacin
La ofuscacin se reere a encubrir el signicado de una 32.1.1 Ejemplos
comunicacin hacindola ms confusa y complicada de
interpretar.
Un ejemplo simple de ofuscacin es llamar a las variables
o funciones con palabras reservadas del lenguaje aadiendo algn smbolo
int int_;

32.1 Informtica

Con esta lnea se dene una variable de tipo entero.

En computacin, la ofuscacin se reere al acto delibe- long int _int(int int_){return int_-int_};
rado de realizar un cambio no destructivo, ya sea en el
cdigo fuente de un programa informtico o cdigo mquina cuando el programa est en forma compilada o bi- Con esta lnea denimos una funcin con un parmetro
entero que devuelve un valor long int, que por otra parte
naria, con el n de que no sea fcil de entender o leer.
siempre ser 0.
En Internet, la ofuscacin reere a crear una publicacin
_int-_int;
o formar parte del grupo los Ofuscados.
El cdigo ofuscado es aqul cdigo que, aunque se tiene
el cdigo fuente, ha sido enrevesado especcamente para Esto equivale a poner 0.
ocultar su funcionalidad (hacerlo ininteligible).
(_int-_int)!;
La ofuscacin binaria se realiza habitualmente para impedir o hacer ms difcil los intentos de ingeniera inversa Esto equivale a poner 1.
y desensamblado que tienen la intencin de obtener una
(((!(int_-int_)<<!(int_-int_))<<(!(int_-int_)<<!(int_forma de cdigo fuente cercana a la forma original.
int_)))|(!(int_-int_)<<!(int_-int_)));
Como un efecto lateral, la ofuscacin, en ocasiones, hace
que los programas resultantes sean ms pequeos (aunque
Esto equivale a poner 10.
puede hacer que los programas sean ms grandes en otros
casos).
Algunos tienden ms a la ofuscacin que otros. C, C++
y Perl son los ms citados como fcilmente ofuscables.
Las macros de preprocesador son usadas a menudo para
crear cdigo complicado de leer enmascarando la gramtica y sintaxis estndar del lenguaje del cuerpo principal
de cdigo.

32.2 Otros objetivos

Aparte de los lenguajes ms conocidos, existen lenguajes

de programacin esotricos. Adems, tambin se puede
buscar que el cdigo fuente resulte una obra de ascii art.
Existen otros programas ofuscados llamados quine que al
ejecutarse la salida debe ser el cdigo fuente del programa.

La ofuscacin puede servir para otros propsitos. Los

mdicos han sido acusados de usar una jerga para encubrir hechos desagradables de un paciente. El autor y doctor Michael Crichton ha armado que la escritura mdica
es un intento altamente capacitado y calculado de confundir al lector. De forma similar, el lenguaje basado
Tambin hay programas ofuscadores que pueden actuar en texto, como gyaru-moji y algunas formas de leet speak
sobre el cdigo fuente, cdigo objeto o ambos para di- es ofuscado para hacerlo incomprensible a terceras percultar la ingeniera inversa.
sonas. lomelo
54

32.3. ENLACES EXTERNOS

32.3 Enlaces externos

Competicin de cdigo ofuscado en C
Proteccin online de libreras javascript
The International Obfuscated C Code Contest (Concurso internacional de cdigo en C ofuscado)
Cmo proteger cdigo en Java por medio de la ofuscacin de cdigo
- Ofuscador de Codigo PHP online
FOPO - Free Online PHP Obfuscator
Anlisis de ofuscacin de cdigo en Javscript

55

Captulo 33

ColdFusion
Coldfusion (Adobe ColdFusion) es una plataforma de
desarrollo rpido de aplicaciones web que usa el lenguaje
de programacin CFML. En este aspecto, es un producto
similar a ASP, JSP o PHP.

Es un lenguaje que se ejecuta en el servidor. A diferencia

de JavaScript y Applets Java, que se ejecuta en el cliente,
ColdFusion se ejecuta en el servidor web. Esto signica que los guiones escritos en ColdFusion corrern de la
ColdFusion es una herramienta que corre en forma misma manera en cualquier navegador web.
concurrente con la mayora de los servidores web de
Windows, Mac OS X, Linux y Solaris (tambin en servidores web personales en Windows 98 y puede ser usado 33.1 Historia
para intranets). El servidor de aplicaciones web de ColdFusion trabaja con el servidor HTTP para procesar peti- ColdFusion fue desarrollado inicialmente por J. J. Allaiciones de pginas web. Cada vez que se solicita una pgi- re, y su primera versin apareci en julio de 1995. En
na de ColdFusion, el servidor de aplicaciones ColdFusion 2001, estando en el mercado la versin 5, Allaire fue
ejecuta el guion o programa contenido en la pgina.
adquirido por Macromedia, que en junio de 2002 lanz
El lenguaje de programacin CFML, propio de Coldfu- ColdFusion MX (6.0), llamado de esta manera para sesion, puede crear y modicar variables igual que en otros guir la nomenclatura de sus otros productos. Esta versin
lenguajes de programacin que nos son familiares. Posee fue completamente reescrita en Java desde cero, y fue dicontrol de ujo de programas, como IF, Case, ciclo, etc. seada, entre otros aspectos, para integrarse de manera
Tiene muchas funciones built-in para realizar tareas ms sencilla con Macromedia Flash, el producto estrella de la
complicadas, por ejemplo: para averiguar qu da de la compaa.
semana ser el 3 de agosto del 2027
ColdFusion MX 7 fue lanzado en febrero de 2005, meses
antes de la adquisicin de Macromedia por Adobe SysDayOfWeekAsString(DayOfWeek('2027/08/03'))
tems. En la actualidad est disponible la versin 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 estndar,
las pginas y aplicaciones web pueden fcilmente recuperar, guardar, formatear y presentar informacin dinmicamente.

33.2 Versiones

Muchas de las funciones poderosas de ColdFusion, como leer desde y escribir en discos duros del servidor, son
basadas en tags. As como el tag
puede tener argumentos como 'width' o 'align', el
tag <CFFILE> tiene argumentos que especican 'action=read/write/copy/delete', path=' etc.
El tag <CFFORM> construye automticamente todo el
cdigo JavaScript para vericar los campos requeridos
antes de hacer el formulario. ColdFusion tambin tiene
tags para COM, Corba y Applets y Servlets de Java.
ColdFusion fue diseado para desarrollar sitios complejos y de alto trco. ColdFusion est diseado para correr
en mquinas multi-procesador, y permite construir sitios
que pueden correr en clusters de servidores.
56

1995: Allaire Cold and Fusion, versin 1.0

1996: Allaire Cold and Fusion, versin 1.5
1996: Allaire Cold and Fusion, versin 2.0
Junio 1997: Allaire Cold and Fusion, versin 3.0
Enero 1998: Allaire Cold and Fusion, versin 3.1
Noviembre 1998: Allaire ColdFusion, versin 4.0
(a partir de esta versin se le conoce como ColdFusion, ya que antes era Cold and Fusion)
Noviembre 1999: Allaire ColdFusion, versin 4.5
Junio 2001: Macromedia ColdFusion, versin 5.0
Mayo 2002: Macromedia ColdFusion MX, version
6.0, Updater 1, Updater 2, Updater 3

33.3. EJEMPLOS DE CDIGO

57

Julio 2003: Macromedia ColdFusion MX, version

6.1, hot x, Updater 1

33.3 Ejemplos de cdigo

2005: Macromedia ColdFusion MX 7, 7.0.1, 7.0.2

Consulta a una base de datos:

30 de julio, 2007: Adobe ColdFusion 8

4 de abril, 2009: Adobe ColdFusion 8.0.1

<cfquery
name="nombredelaconsultadatasource="conexion_odbc"> SELECT * FROM table WHERE
campo = 'hola' </cfquery>

5 de octubre, 2009: Adobe ColdFusion 9

Mostrar la respuesta de la consulta:

13 de julio, 2010: Adobe ColdFusion 9.0.1

<cfoutput query="nombredelaconsulta"> #[Link]# <!---Las variables se escriben entre #

#. Este texto es un comentario ---> </cfoutput>

15 de mayo, 2012: Adobe ColdFusion 10

31 de mayo, 2012: Adobe ColdFusion 9.0.2

Dar valores y mostrar variables:

<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<cnvoke webservice="[Link]
date 2
method="pruebareturnVariable="resultado">
16 de octubre, 2012: Adobe ColdFusion 10 Update
3
2 de noviembre, 2012: Adobe ColdFusion 10 Update 4
19 de noviembre, 2012: Adobe ColdFusion 10 Update 5
11 de diciembre, 2012: Adobe ColdFusion 10 Update 6
15 de enero, 2013: Adobe ColdFusion 10 Update 7
27 de febrero, 2013: Adobe ColdFusion 10 Update
8
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 Update 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 Update 15
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 Update 3

33.4 Enlaces externos

Web ocial de ColdFusion en Adobe

Adobe ColdFusion community
Introduccin a Adobe ColdFusion

Captulo 34

Coloreado de sintaxis
34.1 Ejemplo
Abajo se muestra un trozo de cdigo en C++:
// Bucle for normal for (int i=0; i<maximo; i++) {
*(Una_estructura).un_campo = i+5; }
A veces, estos editores pueden resaltar las llaves, parntesis y corchetes de forma que al posicionar el cursor sobre 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 nmero de anidamientos hechos con estos elementos.
Un ejemplo de cdigo HTML con coloreado de sintaxis

El resaltado de sintaxis, a veces llamado coloreado de

sintaxis, es una capacidad de algunas aplicaciones para
tratamiento de textos (como los editores de texto), para
diferenciar elementos de texto (especialmente el llamado
cdigo fuente) mediante diversos colores o estilos tipogrcos, dependiendo de las categoras sintcticas de sus
trminos, conforme a las reglas de algn lenguaje formal
concreto.

34.2 Programas con coloreado de

sintaxis
Scintilla
Notepad++
Notepad2
SciTE

Este resaltado se utiliza a modo de notacin secundaria, habitualmente para mejorar la legibilidad del cdigo
fuente de programas o de textos escritos en algn lenguaje
de marcado, permitiendo aumentar la productividad de
los programadores. Los estilos aplicados por defecto dependen de cada programa informtico, alguno de los cuales permiten congurar los estilos e incluso reconocer diversos lenguajes.

Geany
Vim
Emacs
gedit
El visor de cdigo fuente de la mayora de los
navegadores web.

Presentacin independiente del signicado

La interpretacin del texto no vara en absoluto al resaltar
sus elementos. Los cambios en la representacin del texto
cumplen una funcin visual identicativa y no semntica,
slo se usan para transmitir informacin al lector humano.
Por tanto, en el caso del cdigo fuente de un programa,
los intrpretes y los compiladores lo ignoran. No forman
parte ni del lenguaje formal en s, ni del texto, por lo que
tampoco se guardan en el chero, sino que se analiza cada
vez que se carga.

34.3 Vase tambin

58

Editor de pginas web

Editor de texto
WYSIWYG
WYSIWYM

Captulo 35

Comentario (informtica)
/**
* Simple HelloButton() method.
* @version 1.0
* @author john doe <doe.j@[Link]>
*/
HelloButton()
{
JButton hello = new JButton( "Hello, wor
[Link]( new HelloBtnList

// use the JFrame type until support for t

// new component is finished
JFrame frame = new JFrame( "Hello Button"
Container pane = [Link]();
[Link]( hello );
[Link]();
// display the fra
[Link]();

a un amplio abanico de formas de uso distintas y a la inclusin de informacin intil dentro del cdigo fuente.
Para evitar este inconveniente, muchos programadores y
analistas de software adoptan alguna de las losofas
o metodologas para la correcta utilizacin de los comentarios.

35.1 Informacin general

Los comentarios adoptan por norma general un formato
o bien debloque(tambin denominado deprlogo
) o bien den de lnea(tambin denominadoinline
).* [5]

Un comentario de bloque delimita una zona del cdigo

fuente en la cual es permitido expandirse a varias lneas
Un ejemplo de cdigo fuente de Java, con comentarios de prlogo de texto. Esta regin se reconoce por un delimitador de
en rojo, comentarios entre lneas en verde. Cdigo del prograinicio y un delimitador de nal del comentario. Algunos
ma en azul.
lenguajes de programacin admiten que los comentarios
se aniden recursivamente (e.g., MATLAB), pero otros
En la programacin de computadoras, un comentario lenguajes no lo admiten (e.g., Java).* [6]* [7]* [8]
es una construccin del lenguaje de programacin* [1] Un comentario de n de lnea comienza con un delimitadestinada a incrustar anotaciones legibles al programa- dor y contina hasta el nal de la lnea de texto (es decir,
dor en el cdigo fuente de un Programa informtico.* [2] no es necesario un segundo delimitador). En otros casos,
Estas anotaciones son potencialmente signicativas pa- el comentario de n de lnea comienza en una cierta cora los programadores, pero usualmente ignorados por los lumna dentro del cdigo fuente no siendo necesario un
compiladores e intrpretes.* [3]* [4] Los comentarios son delimitador.* [8]
aadidos usualmente con el propsito de hacer el cdigo
fuente ms fcil de entender con vistas a su mantenimien- Los delimitadores son una secuencia conocida de caracteto o reutilizacin. La sintaxis y reglas para los comenta- res y suelen ser distintos para los comentarios de bloque
rios varan y usualmente son denidas en la especicacin que para los de n de lnea. Por ejemplo, el lenguaje C++
usa, para los comentarios de bloque, los delimitadores /*
del lenguaje de programacin.
y */ mientras que los comentarios de n de lnea utiliza
Se ha de tener en cuenta que los comentarios necesitan el delimitador //. Otros lenguajes solamente admiten un
mantenimiento igual que el cdigo y, por tanto, que un tipo de comentario. Por ejemplo, ADA solamente dispocomentario preciso y conciso es ms fcil de mantener ne de comentarios de n de lnea mediante el delimitador
que uno largo, repetitivo y complicado.
-.* [8]
Los comentarios tienen una amplia gama de posibles
usos: desde la mejora del cdigo fuente con descripciones bsicas hasta la generacin de documentacin exter- 35.2 Usos
na. Tambin se utilizan para la integracin con sistemas
de control de versiones y otros tipos de herramientas de La mejor manera de dar uso a los comentarios es obprogramacin externas.
jeto de controversia con posiciones a menudo enfrentaLa exibilidad proporcionada por los comentarios da pie das.* [9]* [10] Hay una gran variedad de formas de escri59

60

CAPTULO 35. COMENTARIO (INFORMTICA)

bir comentarios y muchos comentaristas que ofrecen, en 35.2.3

ocasiones, consejos contradictorios.* [10]

35.2.1

Planeacin / Revisin

Los comentarios se pueden utilizar como una forma de

pseudocdigo para describir la intencin antes de escribir el cdigo real. En este caso se debe explicar la lgica
detrs del cdigo en lugar del cdigo en s mismo.

Descripcin algortmica

A veces, el cdigo fuente contiene una solucin nueva o

digna de mencionarse a un problema especco. En tales
casos, los comentarios pueden contener una explicacin
de la metodologa. Estas explicaciones pueden incluir diagramas y pruebas matemticas formales. Esto puede ser
la explicacin del cdigo, en lugar de una claricacin
de sus intenciones, pero otros encargados del mantenimiento del cdigo pueden encontrar como fundamental
esta explicacin. Esto puede ser especialmente cierto en
el caso de problemas de dominios de alta especializacin;
as como en optimizaciones, construcciones o llamadas a
funciones de uso no cotidiano.* [13]

/* itera hacia atrs por todos los elementos retornados

por el servidor (estos deben ser procesados cronolgicamente)*/ for (i = (numElementsReturned - 1); i
>= 0; i--){ /* procesa los datos de cada elemento */
Por ejemplo, un programador puede agregar un comentaupdatePattern(i, returnedElements[i]); }
rio para explicar por qu se eligi un Ordenamiento por
insercin en lugar de quicksort, pues el primero es, en
Si se deja este tipo de comentario luego de escribir el c- teora, ms lento que el segundo. Esto podra escribirse
digo, se simplica el proceso de revisin al permitir la de la siguiente manera:
comparacin directa del cdigo con los resultados previstos. Una falacia lgica comn es que el cdigo fcil de list = [f (b), f (b), f (c), f (d), f (a), ...]; // Se requiere un
ordenamiento estable, mientras el desempeo realmente
entender hace lo que tiene que hacer.
no importa. insertion_sort (list);

35.2.2

Descripcin de cdigo

Los comentarios pueden ser utilizados para resumir el cdigo o para explicar la intencin del programador. Se- 35.2.4 Inclusin de recursos
gn esta escuela de pensamiento, re-explicar el cdigo en
lenguaje natural se considera superuo y la necesidad de
volver a explicar el cdigo puede ser un signo de que es Logotipos, diagramas y diagramas de ujo consistentes
en construcciones de arte ASCII pueden ser insertados en
demasiado complejo y debe ser reescrito.
el cdigo fuente en forma de comentario.* [14] Adems,
puede incrustarse como comentarios avisos de derechos
de autor, fecha de creacin, versin del producto, contacNo documentes mal cdigo re-escrbelo.
*
to con el propietario y/o creador, etc..
[11]
El fragmento de cdigo que sigue es un simple diagrama
ASCII que representa el ujo de proceso para un script
Los buenos comentarios no repiten el cdigo,
de administracin de sistemas contenido en un Fichero
ni lo explican. Estos aclaran su intencin. Los
Windows Script que se ejecuta en Windows Script Host
comentarios deben explicar, a un nivel de absA pesar de que la seccin que marca el cdigo aparece cotraccin ms alto que el propio cdigo, lo que
mo un comentario, el diagrama de hecho aparece en una
*
se intenta conseguir [12]
seccin XML CDATA seccin, que tcnicamente se considera distinta de los comentarios, pero que puede servir
*
Los comentarios tambin pueden ser utilizados para ex- para propsitos similares. [15]
plicar por qu un bloque de cdigo no se ajusta a las con- <!-- begin: wsf_resource_nodes --> <resource
<![CDATA[
HostApp
venciones o las buenas prcticas. Esto est especialmente id="ProcessDiagram000">
relacionado con proyectos de escaso tiempo de desarro- (Main_process) | V [Link] (app_cmd) --> ClientApp
(async_run, batch_process) | | V [Link] (mru_history)
llo, o en la correccin de errores. Por ejemplo:
' 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 documentacin
' sobre el comportamiento extrao del servidor, as
que simplemente se codic para resolverlo. vtx =
[Link](local settings)

An cuando este diagrama fcilmente podra haber sido

incluido como un comentario, el ejemplo ilustra un caso en que el programador puede optar por no utilizar los
comentarios, como una forma de incluir recursos en el
cdigo fuente.* [15]

35.3. ESTILOS

35.2.5

Depuracin

61

35.3 Estilos

Una prctica comn entre programadores es comentar un

fragmento de cdigo, es decir, agregar delimitadores de
modo que un bloque de cdigo se convierta en un comentario, y por tanto no se ejecutar en el programa nal. Esto podra hacerse para excluir algunas piezas del cdigo
del programa o, de manera ms comn, para encontrar la
causa de un error. Comentando sistemticamente y ejecutando partes del programa, la causa del error puede ser
determinada, permitiendo su correccin. A continuacin
un ejemplo de cmo comentar cdigo con el propsito de
excluirlo:

Hay muchas alternativas cuando se considera como los

comentarios deben aparecer en el cdigo fuente. Para
grandes proyectos, los estilos de los comentarios se agregan apenas comienzan el proyecto. Normalmente los programadores preeren estilos que son consistentes, no obstructivos, fciles de modicar, y difciles de romper.

El fragmento de cdigo de arriba sugiere que el programador opt por desactivar la opcin de depuracin por
alguna razn. Este estilo especco de comentario es ms
adecuado para la depuracin. Un carcter de barra simple
delante del delimitador de apertura es el que permite habilitar o deshabilitar el comentarios de bloque completo.

Factores tales como la preferencia personal, la exibilidad de las herramientas de programacin, y otras consideraciones tienden a inuir en las variantes de estilo utilizado en el cdigo fuente.

Los siguientes fragmentos de cdigo en C son solo un

ejemplo de como los comentarios pueden variar de estilo,
mientras todos contienen la misma informacin bsica:

/* Este es el cuerpo del comentario. Variante 1 */

if ([Link]
( e)) opt_enabled = true; /* if ([Link] /***********************************\ * * *
(d)) opt_debug = true; // */ //* if ([Link] (v Este es el cuerpo del comentario. * * Variante 2. * * *
\************************************/
)) opt_verbose = true; // */

Muchos EIDs permiten agregar o remover rpidamente

este tipo de comentarios con opciones del men singulares o atajos del teclado. El programador solamente debe
marcar la parte de texto que desea comentar o descomentar y elegir la opcin apropiada. Esto es particularmente
til con fragmentos grandes de cdigo.

35.2.6

Generacin de documentacin

Las herramientas de programacin en ocasiones incorporan documentacin y metadatos en los comentarios.* [16]
Estas pueden incluir las posiciones de insercin para la
inclusin automtica de archivos de cabecera, comandos
para congurar el modo de resaltado de sintaxis* [17] o el
nmero de revisin del archivo.* [18] Estos comentarios
de control funcional son tambin conocidos comnmente como anotaciones. Mantener la documentacin dentro
de comentarios en el cdigo fuente es considerado como una forma de simplicar el proceso de documentacin, as como un aumento en las posibilidades de que la
documentacin se mantendr al da con los cambios en
el cdigo.* [19] Habitualmente este tipos de comentarios
requiere utilizar una sintaxis bsica para que puedan ser
interpretados por el generador de documentacin a diferencia de los comentarios anteriores donde no necesariamente se debe de utilizar una sintaxis predenida.

35.3.1 Etiquetas
Algunas etiquetas se utilizan en los comentarios para ayudar en la indexacin de los problemas comunes. Tales
etiquetas son comnmente resaltado de sintaxis y permite bsquedas con herramientas de programacin comn,
como la utilidad grep de UNIX. Ejemplos de convenios
etiqueta son:
FIXME: para marcar cdigo problemtico potencial
que requiere una atencin especial y/o revisin.
NOTE: peligros potenciales para documentar el funcionamiento interno del cdigo y de indicar.
TODO: para indicar las mejoras planicadas.
XXX: para advertir a otros programadores de cdigo
problemtico o equivoco.
Existe el riesgo de que las etiquetas se acumulan con el
tiempo, es conveniente incluir la fecha y el propietario
de etiqueta en el comentario de etiquetas para facilitar el
seguimiento.

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 programacin esotrico en
PHP.
el cual la sintaxis consiste nicamente en espacios en
C#, F# e implementan una caracterstica similar llamada blanco, tabulador y lneas nuevas, cualquier otro carcter
comentarios XML, que son ledos por IntelliSense para es ignorado, por lo que en este lenguaje cualquier escrito
los ensamblados compilados del [Link].* [20]
es un comentario.

62

CAPTULO 35. COMENTARIO (INFORMTICA)

35.5 Ejemplos

35.5.10 cdigo HTML

35.5.1

En las pginas webs .html se introduce el comentario entre

Ensamblador

;comentario

35.5.2

Java

<!-- --> <!-- esto es un comentario en cdigo HTML //

-->

35.5.11 SQL

//comentario de lnea /*comentario de bloque*/ /** co//esto es un comentario --este tambin /* y este en bloque
mentario que ser usado por javadoc */
*/

35.5.3

C/C++

35.5.12 Visual Basic

//comentario en lnea /* comentario en bloque*/ #if 0 Comentario 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 lnea
{ comentario en bloque }

35.5.14 PHP

(* comentario en bloque *)

//comentario en lnea #este tambin /* comentario en bloEn 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 lnea y que es perfectamente 35.5.15 Cobol
vlido *)
* Comentario

35.5.5

Lua

-- Un comentario de lnea --[[ Un comentario de bloque

]]--

35.5.6

Ruby

#comentario =begin comentario de bloque =end

35.5.7

Python

#comentario

35.5.8

Perl

#comentario

35.5.9

Javascript

En [Link] pueden darse las siguientes formas:

//comentario en lnea /* comentario en bloque */

35.6 Referencias
[1] Para los propsitos de este artculo, los comentarios de
un lenguaje de programacin son tratados indistintamente de comentarios que aparecen en lenguajes de marcas,
archivos de conguracin u otros contextos similares. Ms
an, los lenguajes de marcas con frecuencia se relacionan de manera cercana con cdigo de lenguajes de programacin, especialmente en el contexto de generacin
de cdigo. Ver por ejemplo Ganguli, Madhushree (2002).
Making Use of Jsp (en ingls). Nueva York: Wiley. ISBN
0471219746., Hewitt, Eben (2003). Java for Coldfusion
Developers (en ingls). Upper Saddle River: Pearson Education. ISBN 0130461806.
[2] Source code can be divided into program code (which consists of machine-translatable instructions); and comments
(which include human-readable notes and other kinds of
annotations in support of the program code).Penny Grubb,
Armstrong Takang (2003). Software Maintenance: Concepts and Practice (en ingls). World Scientic. pp. 7,
120121. ISBN 981238426X.
[3] Algunos entornos de programacin incluyen los comentarios como uno de los elementos de la sintaxis del lenguaje
que son retenidos para procesamiento posterior, en lugar

35.7. ENLACES EXTERNOS

de ser descartados una vez han sido reconocidos por el

procesador de lenguaje.
[4] Los comentarios deben ser indicados de tal manera que
sea posible para el procesador de cdigo fuente reconocerlos como tal. Esto es usualmente simplicado al decir
que los comentarios son ignorados(luego de ser reconocidos y desechados) por el procesador.
[5] Dixit, J.B. (2003). Computer Fundamentals and Programming in C (en ingls). Laxmi Publications. ISBN
8170088828.
[6] Desmond, Higham (2005). MATLAB Guide (en ingls).
SIAM. ISBN 0898715784.
[7] Vermeulen, Al (2000). The Elements of Java Style (en ingls). Cambridge University Press. ISBN 0521777682.
[8] Using the right comment in Java (en ingls). Consultado el 24 de julio. Parmetro desconocido |aoacce3so=
ignorado (ayuda)
[9] W. R., Dietrich (2003). Applied Pattern Recognition: Algorithms and Implementation in C++ (en ingls). Springer.
p. 66. ISBN 3528355581. ofrece puntos de vista sobre el
uso adecuado de comentarios en el cdigo fuente
[10] Keyes, Jessica (2003). Software Engineering Handbook
(en ingls). CRC Press. p. 256. ISBN 0849314798. discute los comentarios y la ciencia de la documentacin
[11] The Elements of Programming Style, Kernighan & Plauger
[12] Code Complete, McConnell
[13] Spinellis, Diomidis (2003). Code reading: The Open
Source Perspective (en ingls). Addison-Wesley. ISBN
0201799405.
[14] CodePlotter 1.6 - Add and edit diagrams in your code
with this 'Visio-like' tool. Consultado el 24 de julio de
2007.
[15] Niederst, Jennifer (2006). Web Design in a Nutshell:
A Desktop Quick Reference (en ingls). O'Reilly. ISBN
[Link] ocasiones la diferencia entre uncomentarioy otros elementos de la sintaxis de un lenguaje de
programacin o de marcas implica matices sutiles. Niederst indica una situacin tal al decir: Unfortunately,
XML software thinks of comments as unimportant information and may simply remove the comments from a document before processing it. To avoid this problem, use
an XML CDATA section instead.
[16] Vease e.g., Wynne-Powell, Rod (2008). Mac Os X for
Photographers: Optimized Image Workow for the Mac
User (en ingls). Oxford: Focal Press. p. 243. ISBN
0240520270.
[17] Lamb, Linda (1998). Learning the VI Editor (en ingls).
Sebastopol: O'Reilly & Associates. ISBN 1565924266.
describe el uso de sintaxis modeline en los archivos de
conguracin de Vim
[18] Ver e.g., Berlin, Daniel (2006). Practical Subversion, Second Edition (en ingls). Berkeley: APress. p. 168. ISBN
1590597532.

63

[19] Ambler, Scott (2004). The Object Primer: Agile ModelDriven Development with UML 2.0 (en ingls). Cambridge
University Press. ISBN 1397805218.
[20] Murach. C# 2005. p. 56.

35.7 Enlaces externos

13 consejos para comentar tu cdigo
Como escribir comentarios (en ingls)

Captulo 36

Compatibilidad (informtica)
La compatibilidad es la condicin que hace que un
programa y un sistema, arquitectura o aplicacin logren
comprenderse correctamente tanto directamente o indirectamente (mediante un algoritmo). A este algoritmo que hace que un programa logre ser comprendido
por un sistema, arquitectura o aplicacin se lo denomina emulador por el hecho de que es un intrprete entre el
programa y el sistema, arquitectura o aplicacin.

Un ejemplo:
Ejecucin de orden del programa:
programa_orden_decir=(huta)
Ejecucin del emulador:
emul transformar
ma_realizar_*

programa_orden_*

en

siste-

Ejecucin 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 interpretacin de un programa
por un algoritmo, esto conlleva a una mala ejecucin de
dicho programa o a la imposibilidad de ser ejecutado.
36.3 OpenSource
Un ejemplo prctico:
Hoy en da los programas OpenSource (cdigo abierto),
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
antes adaptar el cdigo a su kernel modicando opciones
interpreta y la ejecuta sin problemas.
de compilacin, generalmente ingresando en la consola el
Incompatibilidad Caso A (Mala ejecucin):
siguiente comando:
programa_orden_decir=(Hola) sistema> Chau
./congure
Compatibilidad:

El programa le indica una orden al sistema y el sistema la Luego compila el cdigo con el siguiente comando:
interpreta pero de forma errnea, devolviendo un resulmake
tado no esperado.
Y por ltimo instala los ejecutables compilados con:
Incompatibilidad Caso B (Imposibilidad de ejecucin):
make-install

programa_orden_da31s4s232sd2453ce sistema> Error

El programa le indica una orden al sistema que para l es Logrando as obtener un programa genrico completamente adaptado al sistema operativo que lo ha compilado.
arbitraria y por ende no logra interpretarla.

36.4 Vase tambin

36.2 Emulacin
La emulacin consiste en utilizar un algoritmo de por medio, denominado emulador que simula ser el sistema, arquitectura o aplicacin para el cual el programa est preparado, el emulador modica los comandos del programa
en memoria para que el sistema pueda interpretarlo como
si estuviera especialmente diseado para l.

64

Compatibilismo e incompatibilismo
Emulador
Software
Wine

36.5. ENLACES EXTERNOS

Compatibilidad hacia atrs

36.5 Enlaces externos

Emulacin de windows para unix
Emuladores
Ms emuladores

65

Captulo 37

Competicin Internacional Universitaria

ACM de Programacin
La Competicin Internacional Universitaria ACM de
Programacin (en ingls ACM International Collegiate Programming Contest, abreviado ACM-ICPC o
simplemente ICPC) es una competicin anual de programacin y algortmica entre universidades de todo el
mundo patrocinada por IBM. En la competicin prima el
trabajo en equipo, el anlisis de problemas y el desarrollo
rpido de software. ICPC es un evento organizado por la
Association for Computing Machinery (ACM).

37.1 Historia
La ACM ICPC es una competicin que hubo en la Universidad A&M de Texas en 1970. Pas a ser una competicin con varias rondas clasicatorias en 1977 y la nal
mundial se organiz en colaboracin con la ACM Computer Science Conference.
De 1977 a 1989, compitieron principalmente equipos de
Estados Unidos y Canad. La sede central est ubicada en
la Universidad de Baylor desde 1989 y las competiciones
regionales se ubican en universidades de todo el mundo,
bajo el auspicio de la ACM y la colaboracin de grandes
empresas de la industria informtica. La ACM ICPC ha
ido aumentando en nmero de participantes y pases por
lo que ahora es una competicin mundial con equipos de
84 pases (en 2005).

universidad antes del concurso. Los estudiantes que hayan competido en dos nales mundiales (World Finals) o
cinco competiciones regionales no pueden participar otra
vez.
Durante la competicin, los equipos tienen 5 horas para resolver entre 8 y 10 problemas (lo normal es 8 para
las competiciones regionales y 10 para la nal). Se deben
programar las soluciones con C, C++ o Java. Los programas enviados por los equipos se compilan y ejecutan con
unos ciertos datos de entrada, si el programa falla al calcular la solucin, el equipo es noticado del error y pueden enviar nuevamente el programa o probar con otros
problemas.
El ganador es el equipo que resuelve ms problemas. Si
hay equipos empatadas con el mismo nmero de problemas resueltos, el orden de clasicacin se calcula a partir
de los que han tardado menos en resolver los problemas.
Ejemplo: si un equipo A ha enviado sus soluciones para 2
problemas los 60 y 120 minutos desde el inicio del concurso, y otro equipo B lo ha hecho a los 80 y 90 minutos.
El desempate entre ambos equipos se hara mirando los
tiempos, para el equipo A: 60+120 = 180 minutos. Para
el equipo B: 80+90 = 170 minutos. El equipo B ganara.

El tiempo que se toma para los desempates es el tiempo

que ha pasado desde el inicio del concurso ms 20 minutos por cada solucin incorrecta enviada. En el ejemplo
anterior, si el equipo A hubiera enviado 2 soluciones inDesde 1997 el principal patrocinador es IBM y la parti- correctas para su primer problema, su tiempo nal sera:
cipacin en la competicin ha aumentado enormemente. 20+20+60+120 = 220.
En 1997 participaron 840 equipos de 560 universidades. El ICPC se diferencia de otras competiciones de prograEn 2005, 5606 equipos de 1737 universidades. El nme- macin (por ejemplo la IOI) en que suele tener un gran
ro de equipos aumenta en un 10 y un 20% cada ao.
nmero de problemas (8 o ms para resolver en 5 horas) y que es una competicin por equipos con un slo
ordenador. Es necesario un buen entendimiento entre los
miembros de un equipo para conseguir la victoria.

37.2 Reglas de la competicin

El ICPC es una competicin por equipos. Las reglas actuales estipulan que cada equipo ha de tener como mximo 3 miembros. Los miembros han de ser estudiantes
universitarios, que hayan estudiado menos de 5 aos en la

66

37.5. GANADORES

37.3 Competiciones locales, regionales y nal mundial

67
- Manila
- Seul
- Teern

La competicin tiene distintas fases clasicatorias. Algunas universidades tienen competiciones locales para elegir a los componentes de los equipos. Cada universidad
puede mandar un mximo de 2 equipos de 3 personas a
la fase regional, si desean participar con un tercer equipo
deben solicitarlo a la organizacin que determinar si les
conceden permiso o no. Las competiciones locales son
opcionales y las organiza cada universidad como estime
conveniente. Algunas universidades optan por seleccionar a los alumnos con notas ms altas o a los que muestran
ms inters.

- Xian

Los equipos de cada universidad participan en la fase regional, con otros equipos de universidades prximas geogrcamente. Hay ms de 30 regiones en todo el mundo.
Algunas regiones agrupan distintos pases (por ejemplo la
SWERC incluye a Espaa, Portugal, Francia y otros pases Europeos), otras son un slo pas (la regin de Brasil)
y otras son slo parte un pas (Estados Unidos est dividido en varias regiones). Los mejor clasicados en cada
competicin regional participarn en la nal mundial. Cada regin enva a la nal un cierto nmero de equipos, no
puedo haber ms de un equipo de una misma universidad.

- Caribe

- Shanghai
- Yokohama
- Hanoi
Regiones de Oceana:
- Pacco sur (SPacic)
Regiones de Amrica Latina:
- Mxico y Centroamrica (CAmerica)
- Brasil
- Suramrica Norte
- Suramrica Sur
Regiones de Norteamrica:
- Pacic Northwest (PacNW)
- North Central (NCNA)
- East Central (ECNA)

La nal mundial se celebra cada ao 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 regionales

- Southern California (Scal)

- South Central (SCUSA)
- Southeast USA (SEUSA)

Regiones de Europa y Rusia:

- Suroeste (SWERC): esta regin comprende Espaa,
Portugal, Francia, Italia, Suiza y el oeste de Austria.* [1]
- Noroeste (NWERC)
- Central (CERC)
- Sureste (SEERC)
- Noreste (NEERC)
Regiones de frica:
- frica y Arabia (AARPC)
- Sudfrica (SAfrica)
Regiones de Asia:
- Beijing

- Mid-Atlantic (MAUSA)

37.5 Ganadores
2015 - Instituto de ptica y Mecnica Fina de San
Petersburgo, Rusia
2014 - Universidad Estatal de San Petersburgo,
Rusia
2013 - Instituto de ptica y Mecnica Fina de San
Petersburgo, Rusia
2012 - Instituto de ptica y Mecnica Fina de San
Petersburgo, Rusia

- Coimbatore (Coim)

2011 - Universidad de Zhejiang, China

- Kanpur (Kolkata)

2010 - Universidad de Shanghai Jiaotong, China

- Dhaka

2009 - Instituto de ptica y Mecnica Fina de San

Petersburgo, Rusia

- Kaohsiun

68

CAPTULO 37. COMPETICIN INTERNACIONAL UNIVERSITARIA ACM DE PROGRAMACIN

2008 - Instituto de ptica y Mecnica Fina de San

Petersburgo, Rusia

1979 - Universidad Washington en San Luis,

Estados Unidos

2007 - Universidad de Varsovia, Polonia

1978 - Instituto Tecnolgico de Massachusetts,

Estados Unidos

2006 - Universidad Estatal de Saratov, Rusia

2005 - Universidad de Shanghai Jiaotong, China
2004 - Instituto de ptica y Mecnica Fina de San
Petersburgo, Rusia
2003 - Universidad de Varsovia, Polonia
2002 - Universidad de Shanghai Jiaotong, China
2001 - Universidad Estatal de San Petersburgo,
Rusia
2000 - Universidad Estatal de San Petersburgo,
Rusia
1999 - Universidad de Waterloo, Canad
1998 - Universidad Carlos, Repblica checa

1977 - Universidad Estatal de Mchigan, Estados

Unidos

37.6 Vase tambin

Olimpiada Internacional de Informtica

37.7 Enlaces
Sitio ocial

37.7.1 Jueces en Lnea

1997 - Harvey Mudd College, Estados Unidos

ACM-ICPC Live Archive Around the World

1996 - Universidad de California, Berkeley, Estados

Unidos

Universidad de Valladolid Online Judge

1995 - Universidad Albert-Ludwigs, Friburgo,

Alemania

Ural State University Online Judge

1994 - Universidad de Waterloo, Canad

1993 - Universidad de Harvard, Estados Unidos
1992 - Universidad de Melbourne, Australia
1991 - Universidad de Stanford, Estados Unidos
1990 - Universidad de Otago, Nueva Zelanda
1989 - Universidad de California, Los ngeles,
Estados Unidos
1988 - Instituto Tecnolgico de California, Estados
Unidos
1987 - Universidad de Stanford, Estados Unidos
1986 - Instituto Tecnolgico de California, Estados
Unidos

Caribbean Online Judge

Tianjin University Online Judge

Saratov State University Online Judge
Sphere Online Judge
A2 Online Judge
Codeforces
MIPT Online Judge
Peking University Online Judge
Jilin University Online Judge
Zhejiang University Online Judge
Harbin Institute of Technology Online Judge
Tianjin University Online Judge

1985 - Universidad de Stanford, Estados Unidos

Fuzhou University Online Judge

1984 - Universidad Johns Hopkins, Estados Unidos

Online Problems Solving System

1983 - Universidad de Nebraska, Estados Unidos

University of Dhaka Online Judge & Contest Training

1982 - universidad Baylor, Estados Unidos

1981 - Universidad de Missouri-Rolla, Estados Unidos
1980 - Universidad Washington en San Luis,
Estados Unidos

Moscow State University Virtual Contest System

[1] [Link]

Captulo 38

Computacin parasitaria
Computacin parasitaria es un paradigma de
programacin por el cual una aplicacin consigue
realizar clculos complejos utilizando interacciones
autorizadas sobre otras aplicaciones. Surge a partir de un
trabajo publicado en Nature en el ao 2000.
En el trabajo original se utilizan dos ordenadores comunicndose a travs de internet y protocolo TCP/IP, en una
sesin de comunicacin estndar. Uno de los ordenadores intenta solucionar un complicado problema, el de la
satisfactibilidad de la lgica booleana, o 3-SAT; Lo hace descomponiendo el problema original en un nmero
considerable de problemas ms pequeos. Cada uno de
estos problemas ms pequeos se codica como una relacin entre un checksum (suma de control) y un paquete
de red, de manera que la comprobacin de si el checksum
es correcto o no es la solucin del problema ms pequeo. El ordenador enva estos paquetes al ordenador que
pretende realice la computacin, el ordenador de destino
comprueba el checksum del paquete recibido, si es correcto solicita mas paquetes, si es incorrecto, solicita la
retransmisin.

38.1 Referencias
1. Parasitic computing, Barabasi et al., Nature, 412:
894-897 (2000).

38.2 Enlaces externos

De esta manera, el ordenador que recibe los paquetes y

comprueba checksums, est realizando computaciones en
benecio del ordenador que las solicita, sin ser consciente
de elllo, y sin hacer nada ms que mantener una sesin
TCP/IP normal.
La prueba de concepto en el trabajo original es extremadamente ineciente, ya que la cantidad de recursos
computacionales necesarios para generar y enviar los paquetes fcilmente exceden los recursos computacionales
solicitados al otro extremo; El problema 3-SAT se podra haber solucionado mucho antes si se analizase nicamente en local. Adems, en la prctica, los paquetes probablemente y ocasionalmente debern ser retransmitidos
realmente cuando ocurran errores de transmisin y/o red
reales.
De todas maneras, la computacin parasitaria a nivel de
checksums simplemente es una prueba de concepto. Los
autores del trabajo original sugieren que a medida que se
mueva la computacin a lo largo de la pila de protocolo,
se puede llegar a un punto en el cual la computacin solicitada al/los ordenadores husped favorezca al parsito.

69

[Link]
[Link]

Captulo 39

Conectiva lgica
En lgica, una conectiva lgica, o simplemente conectiva, (tambin llamado operador lgico o conectores lgicos) es un smbolo o palabra que se utiliza para conectar dos frmulas bien formadas o sentencias (atmicas o
moleculares), de modo que el valor de verdad de la frmula compuesta depende del valor de verdad de las frmulas
componentes.

ya que da el valor de verdad de (C) est completamente

determinado por el valor de (A) y (B) no tiene sentido para el estado (A) y (B) y negar (C). Sin embargo, entonces
en (D) no es un conector lgico, ya que sera bastante razonable para armar (A) y (B) y negar (D): tal vez Pedro
subi a la montaa para ir a buscar un balde de agua, y
no porque Juan subi la montaa.

Los conectivos lgicos ms comunes son los conectivos

binarios (tambin llamados conectivos didicos) que
39.1.2 Lenguajes formales
unen dos frases, que pueden ser consideradas los operandos de la funcin. Tambin es comn considerar a la neEn los lenguajes formales, las funciones de verdad son
gacin como un conectivo mondico.
representadas por smbolos inequvocos. Estos smbolos
Las conectivas lgicas son, junto con los cuanticadores, se llaman conectivos lgicos, operadores lgicos
las principales constantes lgicas de muchos sistemas l- , operadores proposicionales, o, en la lgica clsica,
gicos, principalmente la lgica proposicional y la lgica la de funciones conectivos de [Link] frmude predicados.
las bien formadas para saber las reglas que permiten las
En programacin se utilizan para combinar valores de nuevas frmulas bien formadas sean construidas al junverdad y obtener nuevos valores que determinen el u- tar otras frmulas bien formadas utilizando conectivos de
funciones de verdad.
jo de control de un algoritmo o programa.

39.1 Lenguajes
39.1.1

Lenguaje natural

Los conectivos lgicos pueden ser utilizados para conectar ms de dos armaciones, entonces es comn hablar
de conector lgico n-ario.

39.2 Lista de conectivos lgicos comunes

La gramtica de los lenguajes naturales, dos frases pueden unirse mediante una conjuncin gramatical para formar una oracin gramaticalmente compuesta. Algunas de
estas conjunciones gramaticales, pero no todas, son fun- 39.2.1 Lista de conectivos lgicos comunes
ciones de verdad. Por ejemplo, considere las siguientes
Conectivos lgicos comnmente usados:
frases:
A: Juan subi la montaa.

Negacin (no): , ~

B: Pedro subi a la montaa.

Conjuncin (y): , y,

C: Juan subi a la montaa y Pedro se subi a

la montaa.

Disyuncin (o)

D: Juan subi la montaa, por lo tanto Pedro

subi la montaa.

Implicacin material (Si.. entonces): , ,

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 lgico, xnory bi-implicacin.
70

39.3. REDUNDANCIA

71

Por ejemplo, el signicado de los estados est lloviendo y

estoy en el interior se transforma cuando los dos se combinan con conectivos lgicos:
No est lloviendo
Est lloviendo y estoy dentro de casa (P Q)
Est lloviendo o estoy dentro de casa (P Q)
Si est lloviendo, entonces estoy en casa. (P Q)
Si estoy en casa, entonces est lloviendo. (P Q)
Estoy dentro si y solo si est lloviendo (P Q)
No est lloviendo ( P)

Bicondicional: el smbolo fue utilizado al menos

por Russell en 1908;* [3] se utiliz al menos por
Tarski in 1940;* [9] fue utilizado en Vax; otros
smbolos aparecieron puntualmente en la historia
como en Gentzen,* [10] ~ en Schnnkel* [5] o
en Chazal.* [11]
Verdadero: el smbolo 1 vino de la interpretacin
de Boole de la lgica como un lgebra elemental de
booleana como la lbegra
dos elementos; otras ano
taciones incluyendo fueron encontrados en Peano.
Falso: el smbolo 0 tambin proviene de la interpretacin de Boole de la lgica
como un anillo [?];
otras anotaciones inclusive fueron encontradas en
Peano.

Algunos autores utilizan letras para conectivos en algn

Por declaracin P = Q = Est lloviendo Estoy dentro de momento de la historia: u. para conjuncin (del Alemn
casa.
und, signicay) y el. para la disyuncin (del Alemn
oder,
signica o) en los primeros trabajos de HilTambin es comn considerar la frmula siempre verdabert
(1904);
N para la negacin, K para la conjuncin, A
dera y la frmula siempre falsa como conectivos
para la disyuncin, C para bicondicional en ukasiewicz
(1929).* [12]
Verdadero (, 1 o T)
Falso (, 0 o F)

39.2.2

39.3 Redundancia

Historia de las notaciones

Negacin: el smbolo apareci en Heyting en

1929.* [1]* [2] (comparar con en smbolo

de Frege en Begrisschrift); el smbolo ~ apareci
en Russell en 1908;* [3] una notacin alternativa es
aadir una lnea horizontal encima de la frmula,
como en P ; otra notacin alternativa es utilizar una
comilla simple como en P'.

El conectivo lgico de la implicacin recproca es en

realidad el mismo que el condicional material con las premisas cambiadas, luego el smbolo de implicacin es recripoca es redundante. En algunos clculos lgicos (en
particular, en la lgica clsica, ciertas armaciones compuestas esencialmente diferentes son lgicamente equivalentes. Un ejemplo menos trivial es una redundancia de la
equivalencia clsica entre P Q P y Q. Por lo tanto,
un sistema lgico de base clsica no necesita del operador
condicional "" si "" (no) y "" (o) operador condicional que ya se utilizan, o se puede utilizar el "" solo con
un azcar sintctico para una composicin que tiene una
negacin y una disyuncin.

Conjuncin: el smbolo apareci en Heyting en

1929* [1] (comparar el uso de la notacin de Peano
de notacin de interseccin en teora de conjuntos)* [4]); & apareci al menos en Schnnkel en Hay 16 funciones booleanas que asocian los valores ver1924;* [5] vino la interpretacin de Boole de la l- dad de entrada de P y Q con salidas binarias 4 dgitos.
gica como un lgebra elemental.
Estos corresponden a las posibles opciones conectivos lgicos binarios para la lgica clsica. Una implementacin
Disyuncin: el smbolo apareci en Russell en
diferente de la lgica clsica puede elegir diferentes sub1908 (comparar el uso de Peano de la notacin de
conjuntos de funcionalmente completos de conectivos.
unin en teora de conjuntos); tambin se utiliza
el smbolo +, a pesar de la ambigedad surgida de la Un mtodo consiste en elegir un mnimo establecido y lgebra elemental ordinaria al ser el + considerado jado por cualquier otra manera lgicas como en el ejemun o exclusivo lgicamente interpretado como una plo con el condicional material anteriormente. Los sialianza de dos elementos; puntualmente en la histo- guientes son conjuntos mnimos funcionalmente compleria, un + junto con un punto en la esquina inferior tos de conectivos de los operadores en la lgica clsica,
cuyo aridades no excedan 2:
derecha fue usado por Peirce,* [6]
Implicacin: el smbolo se puede ver en Hilbert Un elemento {}, {}.
en 1917;* [7] fue utilizado por Russell en 1908* [3]
(comparar con la notacin de la C invertida de Dos elementos { , }, { , }, {, }, {, }, {,
Peano); se utiliz en Vax.* [8]
}, {, }, {, }, {, }, {, }, {,

72

CAPTULO 39. CONECTIVA LGICA

}, {, }, {, }, { , }, { , }, {
, }, { , }, { , }, { , }.

Tres elementos { , , }, { , , }, { ,
, }, { , , }, { , , }, { , , }.
Vea ms detalles sobre integridad funcional.
Otro enfoque es utilizar en igualdad de derechos, de un
cierto conjunto conveniente y funcionalmente completo,
pero no mnimo. Este enfoque requiere ms axiomas proposicionales y cada equivalencia entre las formas lgicas
debe ser o bien un axioma o comprobada como un teorema.
Pero la lgica intuicionista tiene una situacin ms complicada. De sus cinco conectivos {, , , , } solamente la negacin tiene que ser reducida a otros conectivos (p (p )). Ni la conjuncin, disyuncin
y condicional material tiene una forma equivalente construida de los otros cuatro conectivos lgicos.

Dualidad: Para leer las asignaciones de valores de

verdad para la operacin desde arriba hacia abajo
en su tabla de verdad es lo mismo que tomar el complemento de lectura de la tabla de la misma u otra
conectiva desde abajo hacia arriba. Sin recurrir a tablas de verdad esto se puede formular como g (a1 ,
..., an ) = g(a1 , ..., an ). E.j., .
Preservacin de la verdad: El compuesto todos los
argumentos son tautologas es una tautologa en s.
E.j., , , , , , . (ver validez)
Falsedad de preservacin: El compuesto de todos
los argumentos son contradicciones es una contradiccin en s. Por ejemplo, , , , , , . (ver
validez)
Involutividad (para conectivos unarios): f(f(a)) =
a. Por ejemplo negacin en la lgica clsica.

En la lgica clsica, tanto la conjuncin y la disyuncin

son asociativas, conmutativas y idempotentes, en la mayora de las variedades de lgica multi-valuada y la lgica
Algunos conectivos lgicos tienen propiedades que se intuicionista. Lo mismo es cierto sobre distributiva de la
pueden expresar en teoremas que contienen el conectivo. conjuncin y la disyuncin sobre ms de conjuncin, as
Algunas de estas propiedades que una conectiva lgica como para la ley de absorcin.
puede tener son:
En lgica clsica y algunas variedades de lgica multi-

39.4 Propiedades

valuada, la conjuncin y la disyuncin son duales, y la

Asociatividad: En una expresin que contiene dos negacin es auto-dual, en la lgica intuicionista, esta lo ms del mismo conectivo asociativo en una lnea, tima tambin 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 computacin
pueden ser intercambiados (uno por el otro), mientras que la preservacin de equivalencia lgica de la
El planteamiento funcional a la verdad a los operadores
expresin original.
lgicos se implementa como puertas lgicas en circuitos
Distributividad: Un conectivo denotado por dis- digitales. Prcticamente todos los circuitos digitales (la
tribuye sobre otra que conecta denotado por el signo principal excepcin es DRAM) se construye a partir de
+, si a (b + c) = (a b) + (a c) para todos los NAND, NOR, NOT y puertas de transmisin; ver ms
detalles en funcin de verdad en informtica. Los operaoperandos a, b, c.
dores lgicos ms de vectores de bits (correspondientes a
Idempotencia: Cuando los operandos de una opera- nita lgebra de boole) son operaciones bit a bit.
cin son iguales, el compuesto es lgicamente equi- Pero no todo uso de un conector lgico en programacin
valente al operando.
informtica tiene una semntica de Boole. Por ejemplo,
a veces se implementa evaluacin perezosa para P Q
Absorcin: Un par de conectivos , satisface la
y P Q, de modo que estos conectores no son conmuley de absorcin si a (a b) = a para todos los
tativo si algunas de las expresiones P, Q tiene efecto seoperandos a, b.
cundario. Tambin, un condicional, que en cierto sentido
Monotonicidad: Si f(a1 ,..., an ) f(b1 ,..., bn ) para corresponde al conectivo condicional material, es esentodo a1 ,..., an , b1 ,..., bn {0,1} tal que a1 b1 , a2 cialmente no-booleano porque para si (P) entonces Q; la
consiguiente Q no se ejecuta si el antecedente P es falso
b2 ,..., an bn . Ej., , , , .
(aunque un compuesto como un todo es exitosa verda Anidad: Cada variable siempre hace una diferen- deraen tal caso). Esto se acerca ms a las pticas intuicia en el valor de verdad de la operacin o nunca cionistas y constructivistas sobre el condicional material,
ms que a las de la lgica clsica.
hace una diferencia. Ej., , , , , .

39.9. ENLACES EXTERNOS

39.6 Conectivas por el nmero de

argumentos

73

[9] Tarski (1940) Introduction to logic and to the methodology

of deductive sciences.
[10] Gentzen (1934) Untersuchungen ber das logische
Schlieen.

Si vemos las distintas conectivas por su nmero de argumentos podemos distinguir:

[11] Chazal (1996): lments de logique formelle.
[12] Vase Roegel

39.6.1

Sin argumentos

Las conectivas lgicas sin argumentos son:

39.6.2

Con un argumento

Las conectivas con solo un argumento son:

39.6.3

Con dos argumentos

Las conectivas que necesitan dos argumentos son:

39.9 Enlaces externos

Hazewinkel, Michiel, ed. (2001), Propositional
connective (en ingls), Encyclopaedia of Mathematics, Springer, ISBN 978-1556080104
Lloyd Humberstone (2011). The Connectives. MIT
Press. ISBN 978-0-262-01654-4.
Bocheski, Jzef Maria (1959). A Prcis of Mathematical Logic. traducido al ingls de las ediciones
francesa y alemana por Otto Bird. Dordrecht, South
Holland.
Enderton, Herbert (2001). A Mathematical Introduction to Logic (2da edicin). Boston, MA: Academic Press. ISBN 978-0-12-238452-3.
Gamut, L.T.F (1991). Chapter 2. En University
of Chicago Press. Logic, Language and Meaning 1.
pp. 5464. OCLC 21372380.

39.7 Vase tambin

39.8 Referencias
[1] Heyting (1929) Die formalen Regeln der intuitionistischen
Logik.
[2] Denis Roegel (2002), Petit panorama des notations logiques du 20e sicle (vase chart en pgina 2).
[3] Russell (1908) Mathematical logic as based on the theory
of types (American Journal of Mathematics 30, p222
262, tambin en From Frege to Gdel edited by van Heijenoort).
[4] Peano (1889) Arithmetices principia, nova methodo exposita.
[5] Schnnkel (1924) ber die Bausteine der mathematischen Logik, translated as On the building blocks of mathematical logic in From Frege to Gdel edited by van Heijenoort.
[6] Peirce (1867) On an improvement in Boole's calculus of
logic.
[7] Hilbert (1917/1918) Prinzipien der Mathematik (Bernays'
course notes).
[8] Vax (1982) Lexique logique, Presses Universitaires de
France.

Humberstone, Lloyd (2010), Sentence Connectives in Formal Logic, Stanford Encyclopedia

of Philosophy, [Link]
connectives-logic/
MacFarlane, John (2005), Logical constants,
Stanford Encyclopedia of Philosophy, [Link]
[Link]/entries/logical-constants/
Esta obra deriva de la traduccin total de Logical
connective de Wikipedia en ingls, concretamente de esta versin, publicada por sus editores bajo la Licencia de documentacin libre de
GNU y la Licencia Creative Commons AtribucinCompartirIgual 3.0 Unported.

Captulo 40

Conguracin regional
En informtica, la conguracin regional* [1] conocida como locale en inglses un conjunto de parmetros
que dene el idioma, pas y cualquier otra preferencia especial que el usuario desee ver en su interfaz de usuario.
Generalmente, un identicador de conguracin regional
consiste como mnimo de un identicador de idioma y un
identicador de regin. Este concepto es de fundamental
importancia en el campo de la localizacin de idiomas.

40.1 Vase tambin

Internacionalizacin y localizacin

40.2 Referencias
[1] Microsoft Corporation. Traduccin del trmino en el
Portal de idiomas de Microsoft. Consultado el 1 de noviembre de 2014.

40.3 Enlaces externos

Esta obra deriva de la traduccin de Locale de
Wikipedia en ingls, publicada por sus editores bajo la Licencia de documentacin libre de
GNU y la Licencia Creative Commons AtribucinCompartirIgual 3.0 Unported.
Unicode Common Locale Data Repository
Language Subtag Registry

74

Captulo 41

Conteo de referencias
Conteo de referencias, en ingls Reference counting, es
una tcnica para contabilizar las veces que un determinado recurso est siendo referido. Por lo general ese recurso
son bloques de memoria y la tcnica permite establecer
cuando no existe ninguna referencia a ese bloque y ste
puede ser liberado. Es una tcnica de muy fcil implementacin, pero tiene una importante desventaja: Si las
referencias forman un ciclo los objetos involucrados no
se liberarn nunca. Otra tcnica ms efectiva es el uso de
un recolector de basura.

41.1 Vase tambin

Recolector de basura
Fuga de memoria

75

Captulo 42

Convencin de Nombres (Programacin)

para mejorar la apariencia esttica y profesional de
producto de trabajo (por ejemplo, al no permitir
nombres excesivamente largos nombres lindo,
cmico o, o las abreviaturas);

En Programacin, una convencin de nombres es un

conjunto de reglas para la eleccin de la secuencia de caracteres que se utilizar para un identicador s que denotan variables, tipos, funciones y otras entidades en el
cdigo fuente y la documentacin.

para ayudar a evitar conictos de nombresque

podran ocurrir cuando se combina el producto del
trabajo de diferentes organizaciones (vase tambin:
espacios de nombres);

Razones para utilizar una convencin de nombres (en lugar de permitir a los programadores elegir cualquier secuencia de caracteres) incluyen los siguientes:

para proporcionar datos signicativos que se utilizarn en los traspasos de proyectos que requieren la
presentacin de cdigo fuente del programa y toda
la documentacin pertinente

para reducir el esfuerzo necesario para leer y entender el cdigo fuente;* [1]
para mejorar la apariencia del cdigo fuente (por
ejemplo, al no permitir nombres excesivamente largos o abreviaturas poco claras).

para proporcionar una mejor comprensin en el caso de la reutilizacin de cdigo despus de un largo
intervalo de tiempo.

La eleccin de las convenciones de nombres puede ser

un problema de enorme polmica, con los partidarios
considerar su tendencia mejor y las dems inferiores.
Coloquialmente, este se dice que es una cuestin de 42.2 Desafos
dogma.* [2] Muchas empresas tambin han establecido su
propio conjunto de convenciones para satisfacer mejor La eleccin de las convenciones de nombres (y la medida
sus intereses.
en que se hacen cumplir) es a menudo un tema polmico,
con partidarios considerando su punto de vista para ser el
mejor y los dems como inferiores. Adems, incluso con
las convenciones de nombres conocidos y bien denidos
42.1 Benecios potenciales
en el lugar, algunas organizaciones pueden no adherirse
constantemente a ellos, haciendo que la incoherencia y
Algunos de los benecios potenciales que se pueden obteconfusin. Estos retos pueden ser exacerbadas si las reglas
ner mediante la adopcin de una convencin de nombres
de la convencin de nomenclatura no tienen coherencia
incluyen los siguientes:
interna, arbitraria, difciles de recordar, o percibida de
otra manera como ms gravosas de lo benecioso.
para proporcionar informacin adicional (es decir,
los metadatos) sobre el uso que se hace de un identicador;

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 mayora de
los usuarios de negocios, identicadores bien escogidos
para permitir el uso de refactorizacin automatizado hacen que sea mucho ms fcil para las siguientes generao buscar y reemplazar herramientas con un potencial ciones de analistas y desarrolladores para entender lo que
mnimo para el error;
hace el sistema y cmo solucionarlo o ampliar el cdigo
para mejorar la claridad en los casos de ambigedad fuente para las nuevas necesidades del negocio.
potencial;

Por ejemplo, aunque la siguiente:

76

42.4. ELEMENTOS COMUNES

a = b * c;
es sintcticamente correcta, su propsito no es evidente.
Contraste esto con:
WEEKLY_PAY = hours_worked * pay_rate;
lo que implica la intencin y el signicado del cdigo
fuente, por lo menos para aquellos que estn familiarizados con el contexto subyacente de la aplicacin.

42.4 Elementos comunes

Las reglas exactas de una convencin de nombres dependen del contexto en que se emplean. Sin embargo, hay
varios elementos comunes que ms inuyen en si no todos los convenios de denominacin de uso comn hoy en
da.

42.4.1

Longitud de identicadores

Un elemento fundamental de todas las convenciones de

nomenclatura son las reglas relacionadas con identicadora longitud (es decir, el nmero nito de caracteres
individuales permitidos en un identicador). Algunas reglas dictan un numrico jo atado, mientras que otros especican heurstica o directrices menos precisos.

77
primeros enlazadores que requeran nombres de variables que se limitan a 6 caracteres para ahorrar
memoria. Un avancems adelante permiti que
los nombres de variables ya que se utilizarn para
la comprensin humana, pero donde slo los primeros caracteres fueron signicativas. En algunas versiones de BASIC como TRS-80 Nivel Bsico 2, los
nombres largos se les permiti, pero slo las dos primeras letras fueron signicativas. Esta caracterstica
permitir el comportamiento errneo de que podra
ser difcil de depurar, por ejemplo, cuando fueron
utilizados y destinados a ser distinto nombres como
VALORy VAI.
editor de cdigo fuente temprana s autocompletar
careciendo
monitores tempranas de baja resolucin con longitud
de lnea limitada (por ejemplo, slo 80 caracteres)
gran parte de la informtica procedentes de las matemticas, donde los nombres de variables son, tradicionalmente, slo una sola letra

42.4.2 Maysculas, minsculas y nmeros

Algunas convenciones de nomenclatura si limitan letras

pueden aparecer en maysculas o minsculas. Otro convenios no restrinjan caso carta, pero conceden una interpretacin bien denido basado en maysculas y minscuReglas de longitud de identicador son impugnadas de
las. Algunas convenciones de nombres especican si alfaforma rutinaria en la prctica, y sujeto a mucho debate
bticos, numricos o alfanumricos caracteres se pueden
acadmico.
usar, y si es as, en qu secuencia.
Algunas consideraciones:
identicadores ms cortos pueden ser preferidos co- 42.4.3 Identicadores de varias palabras
mo ms conveniente, ya que son ms fciles de escribir
Una recomendacin comn es Utilizar identicadores
[Link] sola palabra puede no ser tan signi extremadamente identicadores cortos (por ejemcativa, o especcas, como varias palabras. En conseplo, 'i' o 'j') son muy difciles de distinguir de forma
cuencia, algunas convenciones de nombres especican las
nica mediante la bsqueda automtica y reemplareglas para el tratamiento de identicadores compueszar herramientas
tosque contienen ms de una palabra.
identicadores ms largos pueden ser preferidos Como en la mayora de los lenguajes de programacin no
porque identicadores cortos no pueden codicar la estn permitidos los espacios en blanco en los identiinformacin suciente o parecer demasiado crptico cadores, se necesita un mtodo de delimitacin de cada
identicadores ms largos pueden ser desfavorecido palabra (para que sea ms fcil para los lectores posteriores para interpretar personajes que pertenecen a cada
debido a la confusin visual
palabra).
Es un tema de investigacin abierto si algunos programadores preeren identicadores ms cortos porque son ms
fciles de escribir, o inventan, de los identicadores ms
largos, o porque en muchas situaciones un identicador
ya simplemente estorba el cdigo visible y proporciona
no perciben benecio adicional.

Palabras delimitadores separados

Un enfoque consiste en delimitar palabras separadas con

un carcter no alfanumrico. Los dos caracteres ms usados para este n son el guin ("-") y el guin bajo ("_);
La brevedad en la programacin podra ser en parte atri- por ejemplo, el nombre de dos palabras two wordsse
representara como two-wordso two_words. El
buido a:

78

CAPTULO 42. CONVENCIN DE NOMBRES (PROGRAMACIN)

guin es usado por casi todos los programadores que es- ve en los 8,3 (mximo 8 caracteres con periodo separador
criben COBOL, Forth, y Lisp; tambin es comn que los seguido de 3 caracteres tipo de archivo) estilo MS-DOS.
nombres de selector en Cascading Style Sheets. La mayora de los otros idiomas (por ejemplo, las lenguas en las
familias C y Pascal) se reservan el guin para su uso como el operador injo resta, por lo que no est disponible 42.5.3 Esquema de palabra compuesta (del
lenguaje)
para su uso en los identicadores y por lo tanto se utilizan
en lugar de subrayado. Vase el caso de serpientes.
Uno de los sistemas de convenciones publicadas primeros fue de IBM del lenguajedocumentada en un IMS
Carta de los casos separados palabras
(Information Management System) 1980 Manual * [cita
requerida].
Otro enfoque consiste en indicar los lmites de palabra utilizando capitalizacin medial (tambin llamado Se detalla el esquema de palabra PRIME-MODIFIER"CamelCase" y muchos otros nombres), haciendo as CLASS, que consista en nombres como MEM-ACTtwo wordsya sea comotwoWordsoTwoWords NOpara indicar nmero de cuenta del cliente.
. Esta convencin se utiliza comnmente en Java, C# y PRIME palabras estaban destinadas a indicar las princiVisual Basic. Tratamiento de las siglas en identicadores pales entidadesde inters para un sistema.
(por ejemplo, elXMLyHTTPen XMLHttpRequest
) vara. Algunos dictan que sean en minsculas (por Palabras MODIFIER fueron utilizados para el renaejemplo XmlHttpRequest ) para facilitar la mecanogra- miento adicional, la cualicacin y la legibilidad.
fa y la lectura, mientras que otros los dejan upperca- Palabras CLASS ideal sera una lista muy corta de los
sed (por ejemplo XMLHTTPRequest ) para la exacti- tipos de datos relevantes para una aplicacin particular.
tud. Una opcin menos popular es ampliar siempre las Clase de palabras comunes pueden ser: NO (nmero),
siglas (por ejemplo ExtensibleMarkupLanguageHyper- ID (identicador), TXT (texto), AMT (cantidad), CANT
TextTransferProtocolRequest ).
(cantidad), FL (bandera), CD (cdigo), W (trabajo) y as
sucesivamente. En la prctica, la clase de palabras disponibles sera una lista de menos de dos docenas de trmi42.5 Metadatos y convenciones h- nos.

bridas
Algunas convenciones de nombres representan normas o
requisitos que van ms all de los requisitos de un proyecto especco o dominio del problema, y en lugar de
reejar una mayor conjunto general de principios denidos por la arquitectura de software, lenguaje de programacin subyacente u otro tipo de metodologa entre
proyectos.

42.5.1

Notacin hngara

Palabras CLASS, normalmente situados a la derecha (sujo), sirven el mismo propsito como prejos de notacin
hngara.
El propsito de la clase de palabras, adems de la consistencia, era especicar al programador el tipo de datos de
un campo de datos particular. Antes de la aceptacin de
BOOLEAN (dos valores nicos) Campos, FL (bandera)
indicaran un campo con slo dos valores posibles.

42.6 Convenciones especcas del

lenguaje

Tal vez la ms conocida es la notacin hngara, que codica ya sea el propsito (Aplicaciones de Hungra)
o el tipo (Sistemas de Hungra) de una variable en su 42.6.1 ActionScript
nombre.* [3] Por ejemplo, el prejoszpara el szName
variable indica que la variable es una cadena de cero (es
Las convenciones y las mejores prcticas de codicadecir null-) terminado.
cin de Adobe sugieren estndares de nomenclatura para
ActionScript que en su mayora son consistentes con los
de ECMAScript. * [cita requerida] El estilo de identica42.5.2 Notacin posicional
dores es similar a la de Java.
Un estilo utilizado para muy cortas (8 caracteres y menos)
podra ser: LCCIIL01, donde LC sera la aplicacin (cartas de crdito), C para COBOL, IIL para el subconjunto 42.6.2
proceso en particular, y el 01 un nmero de secuencia.

Ada

Este tipo de convenciones se encuentra todava en uso En Ada, el nico estilo recomendado de identicadores
activo en mainframes que dependen de JCL y tambin se es Mixed_Case_With_Underscores.* [4]

42.6. CONVENCIONES ESPECFICAS DEL LENGUAJE

42.6.3

79

C y C++

lugar de parseDBMXMLFromIPAddress ). Tambin se

puede establecer el lmite en dos o ms letras (por ejemEn C y C++, las palabras clave e identicadores de la bi- plo parseDbmXmlFromIpAddress ).
blioteca estndar son en su mayora en minsculas. En
la biblioteca estndar de C, los nombres abreviados son
los ms comunes (por ejemplo isalnum para una prueba 42.6.5 JavaScript
de la funcin si un carcter es alfanumrico), mientras
que la biblioteca estndar C++ menudo utiliza un guin Las bibliotecas incorporadas de JavaScript utilizan las
como separador de palabra (por ejemplo out_of_range ). mismas convenciones de nomenclatura como Java. Las
Identicadores representan macros son, por convencin, clases utilizan camel case superior (RegExp, TypeError,
escrito usando slo letras maysculas y guiones bajos (es- XMLHttpRequest, DOMObject) y mtodos utilizar loto est relacionado con la convencin en muchos lengua- wer camel case (getElementById, getElementsByTagNajes de programacin de la utilizacin de todo mayscu- meNS, createCDATASection). Con el n de ser consislas identicadores de constantes). Nombres que contie- tentes desarrolladores ms de JavaScript siguen estas con*
nen doble guin o que comienzan con un guin bajo y venciones. [cita requerida] Ver tambin: convenciones
una letra mayscula se reservan para la implementacin de Douglas Crockford
(compilador, biblioteca estndar) y no deben ser usados
(por ejemplo reserved__ o _Reserved ).* [5]* [6] Esto es
supercialmente similar a alar, pero la semntica die- 42.6.6 Lisp
re: los subrayados son parte del valor del identicador, en
lugar de ser carcter delimitador (como se ala): el valor La prctica comn en la mayora 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 identicadores, como en with-open-le y make-hash-table.
un espacio de nombres diferente).
Nombres de variables globales convencionalmente comienzan y terminan con asteriscos: *map-walls*. Nombres Constantes estn marcadas por signos de suma:
42.6.4 Java
+map-size+.* [10]
En Java, las convenciones de nombres para los identicadores se han establecido y propuesto por varias comunidades de Java como Sun Microsystems,* [7] Netscape,* [8] AmbySoft,* [9] etc Una muestra de las convenciones de nomenclatura establecidas por Sun Microsystems se enumeran a continuacin, donde un nombre en
"CamelCase" es un compuesto de un nmero de palabras
unidas sin espacios, con letra inicial de cada palabra en
maysculas - por ejemplo CamelCase.

42.6.7 .NET

Microsoft NET recomienda UpperCamelCase para la

mayora de los identicadores. (LowerCamelCase se recomienda para los parmetros y variables) y es una convencin comn para los [Link].* [11] Microsoft
recomienda tambin que no se utilicen pistas de tipo prejo (tambin conocido como notacin hngara).* [12] En
Compiladores Java no hacen cumplir estas reglas, pe- lugar de utilizar la notacin hngara se recomienda terro no seguir las mismas pueden dar lugar a confusin minar el identicador con el nombre de la clase base; Lo*
y cdigo errneo. Por ejemplo, [Link]() y Wid- ginButton en lugar de BtnLogin. [13]
[Link]() implica signicativamente diferentes comportamientos: [Link]() implica una invocacin al
mtodo expand() en una instancia con nombre widget, 42.6.8 Objective-C
mientras que [Link]() implica una invocacin al
Objective-C tiene un estilo comn de codicacin que
mtodo esttico expand() en la clase Widget.
tiene sus races en Apple ejemplo de cdigo.
Un estilo de programacin Java ampliamente utilizado dicta que UpperCamelCase ser utilizado para Entidades de primer nivel, incluyendo clases, protocolos,
clases y lowerCamelCase utilizarse para instancias y categoras, as como construcciones de C que se utilizan
mtodos.* [7] Reconociendo este uso, algunos IDE como en los programas de Objective-C como variables y funEclipse, implementar atajos basados en CamelCase. Por ciones globales, estn en UpperCamelCase con una breve
ejemplo, en el contenido de Eclipse funcin de asisten- maysculas-espacio de nombres que denota prejo, como
cia, escribiendo nicamente las letras maysculas de una NSString, UIAppDelegate, NSApp o CGRectMake. Las
palabra CamelCase sugerir ningn nombre de la clase constantes pueden ser opcionalmente precedidos por una
a juego o mtodo (por ejemplo, al escribir NPEy letra minscula kcomo kCFBooleanTrue.
activando ayuda de contenido podra sugerir NullPointe- variables de instancia de un uso objeto lowerCamelCase
rException ).
precedidos por un guin, como _delegate y _tableView.
Siglas de tres o ms letras se camelCase en lugar de Nombres de los mtodos utilizan mltiples partes lowermaysculas (por ejemplo, parseDbmXmlFromIPAddress CamelCase separados por dos puntos que delimitan argu-

80

CAPTULO 42. CONVENCIN DE NOMBRES (PROGRAMACIN)

mentos, como: aplicacin: didFinishLaunchingWithOp- [11] Microsoft NET Framework Estilos de Capitalizacin
tions:, stringWithFormat: y IsRunning.

[12] Gua de NET Framework Developer - Convenciones de

nomenclatura general

42.6.9

Perl

[13] [Framework Instrucciones de diseo, Krzysztof Cwalina,

Brad Abrams Pgina 62]

Perl toma algunas seales de su patrimonio C para convenciones. A nivel local ambito de variables y nombres [14] Perl style guide.
de subrutinas son minsculas con guiones bajos injos. [15] perlmodlib - constructing new Perl modules and nding
Subrutinas y variables con la intencin de ser tratado coexisting ones.
mo privado estn prejadas con un guin bajo. Las variables del paquete son ttulo entubado. Constantes de- [16] [Gua de Estilo [Link]
pep-0008/ de cdigo Python PEP8]
claradas son maysculas. Los nombres de paquetes son
camel case-exceptuando prgmata por ejemplo, strict y
mro -que son minsculas. * [14] * [15]

42.9 Enlaces externos

42.6.10

Python y Ruby

Python y Ruby tanto recomiendan UpperCamelCase para nombres de clases, CAPITALIZED_WITH_UNDERSCORES para las constantes
y lowercase_separated_by_underscores para otros
nombres. En Python, si un nombre est destinado a ser
privado, que est precedido de un guin bajo.* [16]

42.7 Vase tambin

42.8 Referencias
[1] Derek M. Jonesnombres operando la inuencia del operador decisiones de precedenciaUn experimento que investiga el efecto de los nombres de variables de seleccin
de prioridad de operador
[2] Raymond, Eric S. (1 de octubre de 2004), religious
issues, The Jargon File (version 4.4.8 edicin), http://
[Link]/jargon/html/R/[Link], consultado el 7 de noviembre de 2011
[3] [Link]
[4] [Link]
95style/html/sec_3/[Link]
[5] ISO/IEC 9899:1999 Programming languages -- C. ISO.
[6] ISO/IEC 14882:2011 Information technology -- Programming languages -- C++. ISO.
[7]Convenciones de cdigo para el lenguaje de programacin Java, Seccin 9:Convenciones de nomenclatura
[8]SOFTWARE DE NETSCAPE Normas de codicacin
GUA PARA JAVA, Collab Software Codicacin Gua
de Normas para Java
[9] AmbySoft Inc. Estndares de Codicacin para v17.01d
Java
[10] [Link]

Americana Name Society - Promueve la onomstica, el estudio de los nombres y las prcticas de asignacin de nombres, tanto en Estados Unidos como
en el extranjero.
[Link] tiene una de 100 pginas pdf que usa la lingstica y la psicologa para
intentar un anlisis de costo / benecio de las cuestiones de nomenclatura de identicadores
Convenciones de nomenclatura de Ontologa La
aplicacin de etiquetado o las convenciones de nomenclatura unicadas en la ingeniera de la ontologa ayudarn a armonizar la apariencia y aumentar
la robustez de las unidades de representacin ontolgica, como nombres de clases y relaciones dentro
del conjunto ortogonal de ontologas OBO Foundry.

Captulo 43

Cracking (software)
El cracking es la modicacin del software con la intencin de eliminar los mtodos de proteccin de los cuales
este disponga: proteccin de copias, versiones de prueba, nmeros de serie, claves de hardware, vericacin de
fechas, vericacin de CD o publicidad y adware.
La distribucin y uso de copias modicadas es ilegal en
casi todos los pases desarrollados. Muchos juicios se han
llevado a cabo debido al cracking de software; sin embargo, la mayora de estos han tenido que ver con la distribucin de copias duplicadas en vez de con el proceso de quebrantar la proteccin, debido a la dicultdad de construir
pruebas vlidas de culpabilidad individual en el segundo caso. En Estados Unidos, la aprobacin de la Digital
Millennium Copyright Act (DMCA) declar a la modicacin de software, as como a la distribucin de informacin que habilita el cracking de software, ilegal. Sin
embargo, la ley ha sido apenas probada en el poder judicial de EE. UU. en casos de ingeniera inversa para nico uso personal. La Unin Europea aprob la Directiva
de la Unin Europea sobre derecho de autor en mayo de
2001, haciendo la infraccin de los derechos de autor de
software ilegal en los estados miembros, una vez que la
legislacin nacional fuera promulgada en favor de la directiva.

43.1 Vase tambin

Crack informtico
Cracker
Password cracking
Razor 1911

81

Captulo 44

Cuaderno de carga
El cuaderno de carga es, dentro de la terminologa
informtica, el modo de comunicacin ms frecuente entre el analista y el programador de un proyecto. En l el
analista detalla las especicaciones que el programador
debe seguir para desarrollar un programa informtico.

82

Captulo 45

Curricacin
En la ciencia de la computacin, curricar es la tcnica inventada por Moses Schnnkel y Gottlob Frege que
consiste en transformar una funcin que utiliza mltiples
argumentos (o ms especcamente una n-tupla como argumento) en una funcin que utiliza un nico argumento.

45.4 Enlaces externos

Wikcionario tiene deniciones y otra informacin sobre [Link]

Currying in Python
Implicit currying in Scheme

45.1 Nomenclatura

Currying in Ruby

El nombre curricar, acuado por Christopher Strachey en 1967, es una referencia al lgico Haskell Curry.
Un nombre alternativo, Schnnkelisation, ha sido propuesto.* [1]

Currying in Smalltalk
Currying in Algol68G
Currying != Generalized Partial Application! - post
at [Link]
Currying in Scala

45.2 Denicin

Currying in Perl

Dada una funcin f del tipo f : (X Y ) Z , curricndola sera una funcin del tipo curry(f ) : X
(Y Z) . En otras palabras, curry(f ) toma un argumento del tipo X y retorna una funcin del tipo Y Z
. Descurricar es la transformacin inversa.
Intuitivamente, la curricacin expone queSi jas algunos argumentos, tendrs una funcin de los argumentos
restantes. Por ejemplo, si la funcin div signica la versin curricada de la operacin x / y, entonces div con
el parmetro x jado en 1 es otra funcin: igual que la
funcin inv que devuelve la inversa multiplicativa de sus
argumentos, denida por inv(y) = 1 / y.
La motivacin prctica para curricar es que en ocasiones, muy seguidas, las funciones obtenidas al utilizar algunos, pero no todos, los argumentos en una funcin curricada pueden resultar tiles; por ejemplo, muchos lenguajes tienen una funcin o un operador similar
a plus_one. Curricar hace fcil denir dichas funciones.

45.3 Referencias
[1] I. Heim and A. Kratzer (1998). Semantics in Generative
Grammar. Blackwell.

83

Captulo 46

Cdigo enhebrado
En ciencias de la computacin, el trmino cdigo enhebrado se reere a una tcnica de implementacin
del compilador donde el cdigo generado tiene una forma que esencialmente consiste enteramente en llamadas a subrutinas. El cdigo puede ser procesado por un
intrprete, o simplemente puede ser una secuencia de instrucciones de llamadas a cdigo de mquina.
Una de las principales ventajas del cdigo enhebrado es
que es muy compacto, comparado al cdigo generado
por tcnicas alternativas de generacin del cdigo y de
convencin de llamadas. Esta ventaja usualmente viene a
expensas de una velocidad de ejecucin ligeramente ms
lenta (usualmente apenas una sola instruccin de mquina). Sin embargo, a veces hay un efecto sinergtico - a
veces un cdigo ms compacto es ms pequeo y signicativamente ms rpido que el cdigo no enhebrado.* [1] Un programa sucientemente pequeo para caber enteramente en la memoria de acceso aleatorio puede correr ms rpido que un programa menos compacto
en el espacio de intercambio que requiere un constante
acceso mecnico de la unidad de disco, aunque sufra de
la sobrecarga en la interpretacin del cdigo enhebrado.
Similarmente, un programa lo sucientemente pequeo
para caber enteramente en el cach del procesador de la
computadora puede correr ms rpido que un programa
menos compacto que sufra fallas de cach constantes.

plataforma de hardware especca. Un acercamiento diferente usa un conjunto de instrucciones de una mquina
virtual - que no tiene un destino particular de hardware.
Un intrprete lo ejecuta en cada nuevo hardware de destino.
Los computadores tempranos tenan relativamente poca
memoria. Por ejemplo, la mayora de los Data General
Nova, IBM 1130, y muchas computadores Apple II tenan solamente 4 k palabras de memoria RAM instalada.
Consecuentemente se pasaba mucho tiempo intentando
encontrar formas de reducir el tamao de los programas
de tal manera que pudieran caber en la memoria disponible. Al mismo tiempo, los computadores eran relativamente lentos, as que la interpretacin simple era perceptiblemente mucho ms lenta que ejecutar el cdigo de
mquina.
En vez de escribir cada paso de una operacin en cada
parte del programa donde era necesaria, los programadores ahorraban memoria escribiendo cada paso de tales
operaciones una sola vez y ponindolo en una subrutina
(ver "no te repitas").

Este proceso - la refactorizacin de cdigo - es usado hoy,

aunque por diversas razones. En estos programas, la aplicacin del nivel superior puede consistir de nada ms que
llamadas a subrutinas. A su vez, muchas de estas subrutinas, tambin no consisten nada ms que llamadas a suEl cdigo enhebrado es bien conocido como la tcnica brutinas de nivel inferior.
de implementacin comnmente usada en el lenguaje de
programacin Forth. Tambin fue usado en las versiones Los mainframes y algunos microprocesadores tempranos
tempranas del lenguaje de programacin B, as como en tales como el RCA 1802 requeran varias instrucciones
muchas implementaciones de BASIC, y algunas imple- para llamar a una subrutina. En la aplicacin de nivel sumentaciones de COBOL y de otros lenguajes para pe- perior y en muchas subrutinas, esa secuencia es constantemente repetida, slo cambiando la direccin de la suqueos microcomputadores.
brutina desde una llamada a la siguiente. Usando la memoria para almacenar las mismas instrucciones repetidamente era un desperdicio.

46.1 Historia que llev al cdigo

enhebrado

La manera comn de hacer programas de computadora es

usando un compilador paratraducirun programa escrito en una cierto lenguaje simblico al cdigo de mquina.
El cdigo es tpicamente rpido pero no es portable puesto que el cdigo binario ejecutable es diseado para una

La respuesta simple fue una tabla de saltos (es decir una

tabla consistiendo solo en las direcciones contiguas de las
subrutinas - usualmente extradas usando un ndice, un
registro de propsitos generales o un puntero). Las direcciones pueden ser directas o indirectas, contiguas o no
contiguas (encadenadas por punteros), relativas o absolutas, resueltas en de tiempo de compilacin o construidas
dinmicamente - pero el programa se convierte en una

84

46.3. MODELOS DE ENHEBRADO

lista de puntos de entrada al cdigo real a ser ejecutado.
Esta tcnica se ha reinventadocon los nombres de
cdigo enhebrado, tabla de despachoo tabla de
mtodo virtual- todas estas tcnicas llenan propsitos
similares.

46.2 Desarrollo del cdigo enhebrado

85
*tp++
Esto se llama cdigo enhebrado directo (DTC). Aunque
la tcnica sea ms vieja, el primer uso extensamente circulado del trminocdigo enhebradoes probablemente
el artculo cdigo enhebradode Bell de 1973.* [2]
En 1970, Charles H. Moore invent una notacin ms
compacta para su mquina virtual Forth: el cdigo enhebrado indirecto (ITC). Originalmente, Moore invent esto porque era fcil y rpido en los minicomputadores de NOVA, que tenan un bit de indireccin en cada
direccin. Moore dijo (en comentarios publicados en la
edicin de la revista Byte sobre Forth) que l encontr
esto tan conveniente que lo propag en todos los diseos
Forth posteriores.

Para ahorrar espacio, los programadores exprimieron las

listas cdigos de llamadas a subrutinas y las convirtieron
en simples listas con solo las direcciones de las subrutinas,
y usaron un pequeo loop para llamar a cada subrutina
una por una. Por ejemplo:
Algunos compiladores Forth compilan los programas
start: thread: pushA: *sp++ = A tp = &thread &pushA Forth en cdigo enhebrado directo, mientras que otros
jump top top: &pushB pushB: *sp++ = B jump *tp++ hacen cdigo enhebrado indirecto. Los programas actan
&add jump top ... add: *sp++ = *--sp + *--sp jump top igual de cualquier manera.
En este caso, la decodicacin de los bytecodes se realiza
una sola vez, durante la compilacin o la carga de programa, as que no es repetida cada vez que una instruccin
es ejecutada. Esto puede ahorrar mucho tiempo y espacio cuando la sobrecarga por la decodicacin (decode)
y el enviar (dispath) es grande comparado al costo de la
ejecucin.
Observe, sin embargo, que las direcciones en thread para
&pushA, &pushB, etc., tienen dos o ms bytes, comparados a tpicamente un byte, para el intrprete de decodicar (decode) y enviar (dispath) descrito arriba. En general
las instrucciones para un intrprete de decodicar y enviar pueden ser de cualquier tamao. Como ejemplo, un
intrprete de decodicar y enviar para simular un Intel
Pentium decodica las instrucciones con un rango de 1
a 16 bytes. Sin embargo, los sistemas de bytecode eligen
tpicamente cdigos de 1 byte para las operaciones ms
comunes. As, el enhebrado a menudo tiene un costo de
espacio ms alto que los bytecodes. En la mayora de los
usos, la reduccin en costo de decodicar compensa el
aumento en costo de espacio.

46.3 Modelos de enhebrado

Prcticamente todo el cdigo enhebrado ejecutable usa
uno u otro de estos mtodos para invocar subrutinas (cada
mtodo es llamado un modelo de enhebrado).

46.3.1 Enhebrado directo

Las direcciones en el enhebrado son las direcciones del

lenguaje de mquina. Esta forma es simple, pero puede
tener sobrecargas porque el enhebrado consiste solo de
direcciones de mquina, as que todos los otros parmetros deben ser cargados indirectamente desde la memoria. Algunos sistemas Forth producen cdigo enhebrado
Observe tambin que mientras que los bytecodes son no- directo. En muchas mquinas el enhebrado directo es ms
minalmente independientes de la mquina, el formato y rpido que el enhebrado de subrutina (ver la referencia
el valor de los punteros en el enhebrado generalmente abajo).
dependen de la mquina destino que est ejecutando al
intrprete. As, un intrprete puede cargar un programa Como ejemplo, una mquina de pila puede ejecutar la secuenciapush A, push B, add. Eso puede ser traducido
bytecode portable, decodicar los bytecodes para generar
cdigo enhebrado independiente de la plataforma, luego al enhebrado y rutinas siguientes, donde el tp es inicializado apuntando hacia la direccin de &thread.
ejecutar el cdigo enhebrado sin referencia adicional a los
thread: pushA: *sp++ = A pushB: *sp++ = B add: *sp++
bytecodes.
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 ...
mquina necesarias para ejecutar cada instruccin del in- Alternativamente, los operandos pueden estar incluidos
trprete. Como ejemplo:
en el enhebrado. Esto puede remover alguna indireccin
start: thread: pushA: *sp++ = A tp = thread &pushA necesaria arriba, pero hace el enhebrado ms 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

86

46.3.2

CAPTULO 46. CDIGO ENHEBRADO

Enhebrado indirecto

El enhebrado indirecto usa punteros que apuntan hacia

localizaciones que a su vez apuntan al cdigo de mquina. El puntero indirecto puede ser seguido por los operandos que son almacenados en elbloqueindirecto en
vez de estar almacenados repetidamente en el enhebrado. As, el cdigo indirecto es a menudo ms compacto
que el cdigo enhebrado directo, pero la indireccin tpicamente tambin lo hace ms lenta, aunque usualmente
todava ms rpida que los intrpretes de bytecode. Donde los operandos del handler incluyen tanto valores como
tipos, los ahorros de espacio sobre el cdigo enhebrado
directo pueden ser signicativos. Los sistemas Forth ms
antiguos producan tpicamente cdigo enhebrado indirecto.

thread: pushA: pushB: add: call pushA *sp++ = A *sp++

= B *sp++ = *--sp + *--sp call pushB ret ret ret call add

46.3.4 Enhebrado de token

El cdigo enhebrado de token usa listas de ndices de 8

12 bits a una tabla de punteros. El cdigo enhebrado
de token es notablemente compacto, sin mucho esfuerzo especial por un programador. Tiene usualmente entre
la mitad y tres cuartas partes el tamao de otros cdigos enhebrados, los cuales a su vez tienen entre la cuarta
y la octava parte del tamao del cdigo compilado. Los
punteros de la tabla pueden ser tanto indirectos como directos. Algunos compiladores Forth producen cdigo enhebrado de token. Algunos programadores consideran al
p-codegenerado por algunos compiladores de Pascal,
Como ejemplo, si la meta es ejecutar elpsuh A, push B,
al igual que los bytecodes usados por .NET, Java, BASIC,
add, lo siguiente puede ser usado. Aqu, el tp es iniciay algunos compiladores C, como enhebrado de token.
lizado apuntando a la direccin &thread, cada fragmento
del cdigo (push, add) es encontrado por doble indirec- Histricamente, un acercamiento comn es el bytecode,
cin por medio del tp; y los operandos para cada frag- que utiliza opcodes de 8 bits y, a menudo, una mquina
mento de cdigo son encontrados en el primer nivel de virtual basada en pila. Un interpretador tpico es conocido
como "decode and dispatch interpreter" y sigue la forma:
indireccin siguiendo la direccin del fragmento.
thread: i_pushA: push: add: &i_pushA &push *sp++ =
*(*tp + 1) *sp++ = *--sp + *--sp &i_pushB &A jump
*(*tp++) jump *(*tp++) &i_add i_pushB: &push &B
i_add: &add

46.3.3

Enhebrado de subrutina

El cdigo enhebrado de subrutina(tambin llamado

cdigo enhebrado de llamada) consiste en una serie
de instrucciones callen lenguaje de mquina (o solo
las direcciones de las funciones call, en oposicin el
enhebrado directo el cual usajump). Los compiladores tempranos para el ALGOL, FORTRAN, COBOL y
algunos sistemas Forth produjeron a menudo cdigo enhebrado de subrutina. El cdigo en muchos de estos sistemas operaba una pila de operandos LIFO (last-in-rsout), que tena una bien desarrollada teora del compilador. La mayora de los procesadores modernos tienen
soporte especial del hardware para las subrutinas con las
instrucciones cally return, as que la sobrecarga de una instruccin de mquina adicional por envo es
disminuida; pero segn mediciones de Antn Ertl, en
contraste con los mitos populares, el enhebrado de subrutina es usualmente ms lento que el enhebrado directo.
[3] Pruebas ms recientes de Ertl demuestran que el enhebrado directo es el modelo de enhebrado ms rpido
en los procesadores Xeon, Opteron, y Athlon, mientras
que el enhebrado indirecto es el modelo de enhebrado
ms rpido en procesadores Pentium M, y el enhebrado
de subrutina es el modelo de enhebrado ms rpido en el
Pentium 4, el Pentium III, y procesadores PPC.
Como un ejemplo de enhebrado de llamada, elpush A,
push B, add":

bytecode: top: pushA: pushB: add: 0 /*pushA*/ i = decode(vpc++) *sp++ = A *sp++ = B *sp++ = *--sp + *--sp
1 /*pushB*/ addr = table[i] jump top jump top jump top
2 /*add*/ jump *addr
Si la mquina virtual usa solamente instrucciones del tamao de un byte, el decode() es simplemente un ferch
desde el bytecode, pero a menudo hay instrucciones comunes de 1 byte ms instrucciones menos comunes de
mltiples bytes (ver CISC), en este caso, decode() es ms
complejo. La decodicacin de opcodes de un solo byte puede ser muy simple y ecientemente manejado por
una tabla de saltos usando el opcode directamente como
un ndice.
Para, en las instrucciones donde las operaciones individuales son simples, por ejemplo pushy add, la
sobrecarga implicada en decidir lo que se debe ejecutar
es ms grande que el costo real de la ejecucin, tales intrpretes son a menudo mucho ms lentos que el cdigo de
mquina. Sin embargo para instrucciones (compuestas
) ms complejas, el porcentaje de sobrecarga es proporcionalmente menos signicativo.

46.3.5 Enhebrado de Human

El cdigo enhebrado de Human consiste en listas de
cdigos Human. Un cdigo de Human es una cadena de bits de longitud variable usada para identicar un
elemento nico. Un intrprete de enhebrado de Human
localiza las subrutinas usando una tabla de ndice o un rbol de punteros que pueden ser navagados por el cdigo
Human. El cdigo enhebrado de Human es una de las
ms compactas representaciones conocidas para un programa de computadora. Bsicamente el ndice y los cdi-

46.6. REFERENCIAS
gos estn organizados midiendo la frecuencia en que cada
subrutina ocurre en el cdigo. A las llamadas frecuentes se le dan los cdigos ms cortos. Las operaciones con
frecuencias aproximadamente iguales se le dan cdigos
con longitudes de bits casi iguales. La mayora de los sistemas enhebrados de Human han sido implementados
como sistemas Forth de enhebrado directo, y son usados
para grandes cantidades de paquetes de cdigo corriendo
lentamente dentro de pequeos y baratos [[microcontrolador}}es. La mayora de las aplicaciones publicadas han
estado en juguetes, calculadoras o relojes.

87
SP o s (puntero de pila de parmetros, usado para
pasar parmetros entre las palabras)
A menudo, las mquinas virtuales enhebradas tales como
las implementaciones de Forth tienen una mquina virtual
simple en su corazn, consistiendo en tres primitivas. sas
son:
nest, tambin llamado docol
unnest, o semi_s (; s)

46.3.6

Enhebrados menos usados

Enhebrado de cadena, donde las operaciones son

identicadas por cadenas, usualmente buscados en
una tabla hash. Esto fue usado por Charles H. Moore en las implementaciones ms tempranas de Forth
y en el lenguaje de computadora experimental interpretado por hardware de la Universidad Illinois.
Tambin se utiliza en Bashforth.

46.4 Bifurcaciones
Los ejemplos de arriba no muestran bifurcaciones. Para
todos los intrpretes, una bifurcacin cambia el puntero
del enhebrado (arriba indicado como tp). Como ejemplo,
una bifurcacin condicional cuando el valor tope de la pila es cero puede ser codicada como sigue. Observe que
el &thread[123] es la localizacin a saltar (jump), no la
direccin de un handler, y as que debe ser saltada (tp++)
independientemente de si la bifurcacin es tomada.
thread: brz: ... tmp = *tp++ &brz if (*sp++ == 0) &thread[123] tp = tmp ... jump *tp++

46.5 Amenidades comunes

En una mquina, la separacin de las pilas de datos y de
retorno elimina mucho del cdigo para el manejo de la
pila, reduciendo substancialmente el tamao del cdigo
enhebrado. El principio de la doble pila fue originado tres
veces independientemente: para los grandes sistemas de
Burroughs, el Forth y el PostScript, y es usado en algunas
mquinas virtuales de Java.
Tres registros estn a menudo presentes en una mquina
virtual enhebrada. Otro existe para pasar datos entre las
subrutinas (palabras). stos son:
IP o i (puntero de instruccin); llamado tp en los
ejemplos de arriba

next
En una mquina virtual de enhebrado indirecto, la que
est dada aqu, las operaciones es:
next: (ip)+ -> w ; jmp (w)+ nest: ip -> -(rp) ; w -> ip ;
next unnest: (rp)+ -> ip ; next
ste es quizs el intrprete ms simple y ms rpido o
mquina virtual.

46.6 Referencias
[1] Speed of various interpreter dispatch techniques V2
[2] James R. Bell, Threaded Code, CACM, 1973, 16, 6,
pp 370372

46.7 Lectura adicional

Anton Ertl's explanatory page What is Threaded
Code? describes dierent threading techniques and
provides further references.
The Development of the C Language by Dennis M.
Ritchie describes B (a precursor of C) as implemented using threaded code.
Thinking Forth Project includes the seminal (but out
of print) book Thinking Forth by Leo Brodie published in 1984.
Starting FORTH online version of the book Starting
FORTH by Leo Brodie published in 1981.
Brad Rodriguez's Moving FORTH: Part 1: Design
Decisions in the Forth Kernel covers threading techniques in depth.

w (puntero de trabajo)

Historia de los CPU de propsito general

rp o r (puntero de pila de retorno)

GCC extensions. Labels as Values

88

46.8 Vase tambin

Compilacin en tiempo de ejecucin
Tabla de saltos
Forth

CAPTULO 46. CDIGO ENHEBRADO

Captulo 47

Cdigo inalcanzable
En programacin, el cdigo inalcanzable es una parte
del cdigo fuente que nunca podr ser ejecutado porque
no existe ningn camino dentro de las estructuras de control en el resto del programa para llegar a este cdigo.* [1]

Cdigo complejo obsoleto que se retuvo intencionalmente, pero se dej inalcanzable para que pueda
ser utilizado ms adelante en el desarrollo si es necesario.

Suele referirse a este tipo de cdigo como cdigo muerto,

aunque entre ellos hay una diferencia (el cdigo muerto
se ejecuta pero no produce cambios en la salida del programa).* [2]

Construcciones de depuracin y vestigios de cdigo

durante el desarrollo que an no se han retirado del
programa.

El cdigo inalcanzable generalmente se considera indeEn los ltimos cinco casos, el cdigo que es inalcanzaseable por las siguiente razones:
ble, a menudo existe como parte de un legado, es decir,
cdigo que una vez fue til, pero ya no se utiliza o no
1. Ocupa memoria innecesaria.
se requiere. Sin embargo, el cdigo inalcanzable tambin
2. Genera almacenamiento innecesario en la cach de puede ser parte de un componente complejo (biblioteca,
instrucciones de la CPU - lo que tambin disminuye mdulo o rutina), donde el cdigo sigue siendo til en
la localidad de datos.
conjuncin con diferentes datos de entrada (nunca gene3. Desde la perspectiva de mantenimiento de soft- rada por la aplicacin actual) o en condiciones que no se
ware, se pierde tiempo y esfuerzo en mantener y cumplen en el entorno de ejecucin actual, haciendo el
documentar una pieza de cdigo que nunca se eje- cdigo correspondiente inalcanzable, pero puede ocurrir
en otros entornos de ejecucin, para que el componente
cuta.
no ha sido desarrollado.
Un ejemplo de tal cdigo condicionalmente inalcanzable
puede ser la implementacin de una funcin printf() en
la biblioteca de tiempo de ejecucin de un compilador, el
La existencia de cdigo inalcanzable puede ser debido a cual contiene el cdigo complejo para procesar todos los
argumentos de cadenas posibles, de los que en realidad
varios factores, tales como:
es slo un pequeo subconjunto utilizados en el progra Errores de programacin en situaciones complejas ma. Sin tener que recompilar la biblioteca de ejecucin,
los compiladores normalmente no sern capaces de elide saltos condicionales.
minar las secciones de cdigo no utilizadas en tiempo de
Consecuencia de las transformaciones internas rea- compilacin.
lizadas por un compilador optimizador.

47.1 Causas

Pruebas de software incompletas que no se pudo detectar cdigo inalcanzable.

47.2 Ejemplo

Cdigo obsoleto que un programador se haya olvidado de borrar.

Considerando el siguiente cdigo en C:
Cdigo 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 cdigo funcional.
La denicin de Z = X*Y nunca es alcanzada debido a
Cdigo condicionalmente til que nunca ser alcan- que la funcin 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 denicin puede ser
que el cdigo va a ser ejecutado.
descartada.
89

90

CAPTULO 47. CDIGO INALCANZABLE

47.3 Anlisis
La deteccin de cdigo inalcanzable es una forma de
anlisis esttico y consiste en realizar un anlisis de control de ujo para encontrar el cdigo que nunca se ejecutar independientemente de los valores de las variables y otras condiciones en tiempo de ejecucin. En algunos lenguajes (como Java* [3]) algunas formas de cdigo inalcanzable no estn permitidas y no es posible compilar el programa con este tipo de cdigo. Se conoce a
la optimizacin que remueve cdigo inalcanzable como
eliminacin de cdigo muerto (que es la misma para el
cdigo muerto y cdigo redundante).
A veces el cdigo puede volverse inalcanzable por alguna optimizacin introducida por el compilador como por
ejemplo: eliminacin de subexpresiones comunes.
En la prctica la sosticacin del anlisis realizado tiene
un impacto signicativo en la cantidad de cdigo inalcanzable que se detecta. Por ejemplo, el plegamiento de
constantes y un simple anlisis de control de ujo muestra que la declaracin a = 2 en el siguiente cdigo no se
puede alcanzar:
int N = 2 + 1; if (N == 4) { a = 2; }
Sin embargo se necesita mas sosticacin para determinar si esta declaracin a = 2 es o no inalcanzable debido
que con un mtodo tradicional habra que calcular la raz
cuadrada en tiempo de compilacin:
double d = sqrt(2); if (d > 5) { a = 2; }

47.3.1

Proling

A veces se pueden utilizar prolers para detectar cdigo

inalcanzable, un proler no prueba nada acerca de si el
cdigo realmente es o no inalcanzable pero es una buena heurstica para buscar cdigo potencialmente inalcanzable. Una vez detectado las partes potenciales se puede
llevar a cabo en las mismas un anlisis ms profundo.

47.4 Vase tambin

Cdigo muerto
Cdigo redundante
Cobertura de cdigo

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 ingls). New York, USA:

ACM Transactions on Programming Languages & Systems (TOPLAS). Bibcode:378-415. |autor= y |apellido=
redundantes (ayuda)
[2] Eliminacin de Cdigo Inalcanzable y Cdigo Muerto.
[3] Java Language Specication.

47.6 Bibliografa
Muchnick S. S. 1997 Advanced Compiler Design
and Implementation. Morgan Kaufmann.
Appel, A. W. 1998 Modern Compiler Implementation in Java. Cambridge University Press.

47.7 Enlaces externos

Cdigo inalcanzable java

Captulo 48

Cdigo muerto
En programacin, se conoce como cdigo muerto a una
parte del cdigo fuente que se ejecuta pero sus resultados
nunca se usan.* [1]* [2] La ejecucin de este tipo de cdigo
consume tiempo de computo en algo que jams se utiliza.
Es frecuente confundirlo con el cdigo inalcanzable aunque conservan una diferencia (este jams se ejecuta, y si
bien los dos son indeseables el cdigo muerto es ms grave que el inalcanzable).
Adems de consumir tiempo de computo el cdigo muerto puede arrojar excepciones o afectar un estado global
del programa. por lo tanto si bien los resultados jams
se utilizan remover este cdigo puede cambiar la salida
del programa y evitar bugs innecesarios. Esta es una razn por la cual el cdigo muerto es menos deseado que el
cdigo inalcanzable.

mente cuando algn mdulo entero quede muerto.* [3]

Algunos IDE (como Visual Studio 2010* [4] y
Eclipse* [5]) poseen la habilidad de detectar cdigo
muerto durante tiempo de compilacin.

48.3 Vase tambin

Cdigo inalcanzable
Cdigo redundante

48.4 Referencias

48.1 Ejemplo

[1] Debray, S. K., Evans, W., Muth, R., and De Sutter, B.

2000. Compiler techniques for code compaction. ACM
Trans. Program. Lang. Syst. 22, 2 (Mar. 2000), 378-415.

int foo (int X, int Y) { int Z = X/Y; return X*Y; }

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

Java. Cambridge University Press.
[3] Douglas W. Jones Dead Code Maintenance, Risks 8.19
(Feb. 1, 1989)

En el cdigo anterior la divisin entre X e Y se calcula pero jams se utiliza, adems, en el caso que Y sea 0
el programa arrojara una excepcin con posibilidad de
abortar la ejecucin, por lo tanto la salida del programa
se ve afectada por esta lnea.

[4] Habib Heydarian, Microsoft Corp.

[5] Eclipse Developer Guide

48.5 Bibliografa

48.2 Anlisis
Se puede utilizar una optimizacin de compilador llamada eliminacin de cdigo muerto para eliminar este
cdigo. Este anlisis se puede llevar a cabo mediante el
anlisis de variable viva, que es una forma de anlisis esttico de software y anlisis de ujo de datos. Esta tambin
es una diferencia con respecto al cdigo inalcanzable que
se descubre mediante un anlisis de control del ujo.

Muchnick S. S. 1997 Advanced Compiler Design

and Implementation. Morgan Kaufmann.
Appel, A. W. 1998 Modern Compiler Implementation in Java. Cambridge University Press.

48.6 Enlaces externos

La eliminacin de cdigo en general es la misma tcnica

que se usa para eliminar el cdigo inalcanzable y el cdigo
redundante.
En los proyectos de programacin grandes, a veces es
difcil de reconocer y eliminar cdigo muerto, especial91

Optimizacin de cdigo
Dead Code Detector (DCD) Java/JEE
Comparacin de DCD para Java

92
UCDetector Plugin Eclipse para encontrar cdigo
muerto Java

CAPTULO 48. CDIGO MUERTO

Captulo 49

Cdigo redundante
En programacin, se conoce como cdigo redundante 49.2 Eliminacin
a cualquier parte del cdigo fuente que tenga algn tipo
de redundancia tales como recalcular un valor que ha sido Existen tcnicas de optimizacin de software comnmencalculado previamente y todava esta disponible.* [1]
te llevadas a cabo por un compilador optimizador para
Una instruccin NOP podra ser considerado como cdi- eliminar el cdigo redundante del cdigo fuente. La ms
go redundante que ha sido explcitamente insertado para comn es la eliminacin de cdigo muerto.
rellenar el ujo de instrucciones o introducir un retardo
de tiempo, por ejemplo para crear un bucle de temporizacin paraperder el tiempo. Los identicadores que se 49.3 Vase tambin
declaran, pero nunca se les hace referencia, se denominan
declaraciones redundantes.
Cdigo muerto
Cdigo 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
Trans. Program. Lang. Syst. 22, 2 (Mar. 2000), 378415.

int foo(int X) { int Y = X*2; return X*2; }

En este ejemplo la instruccin int Y = X*2; puede ser removida para evitar calcular el valor dos veces, o tambin
se puede retornar el valor de la variable Y (aunque particularmente este mtodo consume mas memoria).
Considerando:
#dene min(A,B) ((A)<(B)?(A):(B)) int magnitud_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 cdigo totalmente redundante e ineciente, sin embargo debido a que los macros de mximo y
mnimo son muy utilizados los compiladores modernos
detectan estas situaciones y corrigen el cdigo generado.
93

Captulo 50

Dato
Un dato es una representacin simblica (numrica, alfabtica, algortmica, espacial, etc.) de un atributo o variable cuantitativa o cualitativa. Los datos describen hechos
empricos, sucesos y entidades. Es un valor o referente
que recibe el computador por diferentes medios, los datos
representan la informacin que el programador manipula
en la construccin de una solucin o en el desarrollo de
un algoritmo.

Dato experimental

50.2 Enlaces externos

Los datos aisladamente pueden no contener informacin

humanamente relevante. Slo cuando un conjunto de datos se examina conjuntamente a la luz de un enfoque,
hiptesis o teora se puede apreciar la informacin contenida en dichos datos. Los datos pueden consistir en nmeros, estadsticas o proposiciones descriptivas. Los datos convenientemente agrupados, estructurados e interpretados se consideran que son la base de la informacin
humanamente relevante que se pueden utilizar en la toma de decisiones, la reduccin de la incertidumbre o la
realizacin de clculos. Es de empleo muy comn en el
mbito informtico y, en general, prcticamente en cualquier investigacin cientca.
En programacin, un dato es la expresin general que describe las caractersticas de las entidades sobre las cuales
opera un algoritmo.
En estructura de datos, es la parte mnima de la informacin.
Datos

Procesamiento

Informacin

Un dato por s mismo no constituye informacin, es el procesamiento de los datos lo que nos proporciona informacin.

50.1 Vase tambin

Informacin
Conocimiento
Sabidura
Metadato
Estadstica
94

Wikcionario tiene deniciones y otra informacin sobre [Link]

Datos Grcos: Web que permite generar grcos a

partir de datos del Instituto Nacional de Estadstica.
[Link]: Tienda on-line de grcas
para uso digital e impreso. Servicio de produccin
de grcas a la medida para empresas y particulares.
Stat4You: En stat4you tienes todas las estadsticas
del INE y del ISTAC para que crees tus grcos fcilmente.
Centro de datos - Lanzarote: La mayor coleccin de
datos y estadsticas de la Isla de Lanzarote en Internet.

Captulo 51

Depuracin de programas
51.1 Origen

Una fotografa del supuestamente primer bug(bicho) real, el

cual fue depurado (debugged) en 1947.

Existe una controversia acerca del origen del trmino depuracin o debuggingen ingls. Los trminos bug
y debuggingson atribuidos popularmente a la almirante Grace Murray Hopper por los aos 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 coment que cuando se sac aquella polilla le haban hecho
debuggingal sistema. Sin embargo el trmino bug
cmo signicado de error tcnico data cerca de 1878, y
el trmino debuggingo depuracin ha sido usado en
aeronutica antes de entrar al mundo de las computadoras.

51.2 Aplicacin
Como el software y los sistemas electrnicos se vuelven
generalmente ms complejos, se han desarrollado varias
tcnicas comunes de depuracin para detectar anomalas,
corregir funcionalidades y optimizar cdigo fuente. ExisDepuracin de programas es el proceso de identicar y
ten algunos acionados que consideran la depuracin cocorregir errores de programacin. En ingls se le conoce
mo una forma de arte.
como debugging, es que se asemeja a la eliminacin de
bichos (bugs), manera en que se conoce informalmente a
los errores de programacin. Se dice que el trmino bug
proviene de la poca de los ordenadores de vlvula ter- 51.3 Vase tambin
moinica, en los cuales los problemas se generaban por
Depurador
los insectos que eran atrados por las luces y estropeaban
el equipo. Si bien existen tcnicas para la revisin siste Error de software
mtica del cdigo fuente y se cuenta con medios computacionales para la deteccin 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 desafa la paciencia,
la imaginacin y la intuicin del programador. Muchas
veces se requiere incluir en el cdigo fuente instrucciones auxiliares que permitan el seguimiento de la ejecucin del programa, presentando los valores de variables
y direcciones de memoria y ralentizando la salida de datos (modo de depuracin). Dentro de un proceso formal
de aseguramiento de la calidad, puede ser asimilado al
concepto de prueba unitaria.
95

Captulo 52

Desarrollador de software
El desarrollador de software es una persona
programadora que se dedica a uno o ms aspectos
del proceso de desarrollo de software. Se trata de un
mbito ms amplio de la programacin.
El desarrollador puede contribuir a la visin general del
proyecto ms a nivel de aplicacin que a nivel de componentes o en las tareas de programacin individuales.
Conforme pasa el tiempo, las diferencias entre el diseo
de sistemas informticos, el desarrollo de software y la
programacin se van haciendo ms claras. En el nicho de
mercado puede encontrarse una separacin entre programadores y desarrolladores, siendo estos ltimos los que
disean la estructura o jerarqua de clases. Incluso esos
desarrolladores se convierten en arquitectos de sistemas
informticos, aquellos que disean la arquitectura a varios 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
colaboracin entre varios desarrolladores, que tratan cada uno una parte del programa, y tambin de
otros colaboradores como los comerciales, que denen con el cliente la nalidad del producto, diseadores grcos que denen el aspecto y la ergonoma,
entre otros temas.
concepcin o diseo: a partir de un pliego de condiciones (user requirement specications), denir las
especicaciones tcnicas (estructura de los datos,
comunicacin entre los mdulos, etctera).
pruebas: que sirven para detectar las disconformidades y los errores
mantenimiento: la correccin de los errores despus
de la salida del programa informtico, y la mejora
para hacer evolucionar el producto.

52.1 Vase tambin

Ambiente de desarrollo integrado
Desarrollador de videojuegos
96

Ingeniera del software

Interfaz de programacin de aplicaciones
Programacin
Software

Captulo 53

Desarrollo en cascada
En Ingeniera de software el desarrollo en cascada, tambin llamado modelo en cascada (denominado as por la
posicin de las fases en el desarrollo de esta, que parecen caer en cascada por gravedad hacia las siguientes fases), es el enfoque metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo de
software, de tal forma que el inicio de cada etapa debe
esperar al trmino de la etapa anterior.* [1] Al nal de cada etapa, el modelo est diseado para llevar a cabo una
revisin nal, que se encarga de determinar si el proyecto
est listo para avanzar a la siguiente fase. Este modelo fue
el primero en originarse y es la base de todos los dems
modelos de ciclo de vida.

Requisitos
Diseo

Implementacin
Vericacin

Maintenimiento

Un ejemplo de una metodologa de desarrollo en cascada

El modelo cascadasin modicar. El progreso uye de arriba
es:
haca abajo, como una cascada.

1. Anlisis de requisitos.
qu objetivos debe cubrir. De esta fase surge
una memoria llamada SRD (documento de especicacin de requisitos), que contiene la especicacin completa de lo que debe hacer el
sistema sin entrar en detalles internos.

2. Diseo del Sistema.

3. Segregacin del programa.
4. Diversicacin.
5. Vericacin integral.

Es importante sealar que en esta etapa se debe

consensuar todo lo que se requiere del sistema
y ser aquello lo que seguir en las siguientes
etapas, no pudindose requerir nuevos resultados a mitad del proceso de elaboracin del software de una manera.

6. Ordeado del programa.

De esta forma, cualquier error de diseo detectado en

la etapa de prueba conduce necesariamente al rediseo
y nueva programacin del cdigo afectado, aumentando
los costos del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms 53.1.2 Diseo del Sistema
avanzadas de un proyecto.
Descompone y organiza el sistema en elemenSi bien ha sido ampliamente criticado desde el mbito
tos que puedan elaborarse por separado, aproacadmico y la industria* [cita requerida], sigue siendo el
vechando las ventajas del desarrollo en equipo.
paradigma ms seguido al da de hoy* [cita requerida].
Como resultado surge el SDD (Documento de
Diseo del Software), que contiene la descripcin de la estructura relacional global del sis53.1 Fases del modelo
tema y la especicacin de lo que debe hacer
cada una de sus partes, as como la manera en
que se combinan unas con otras.
53.1.1 Anlisis de requisitos
En esta fase se analizan las necesidades de los
usuarios nales del software para determinar

Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El

97

98

CAPTULO 53. DESARROLLO EN CASCADA

primero de ellos tiene como objetivo denir la
estructura de la solucin (una vez que la fase de
anlisis ha descrito el problema) identicando
grandes mdulos (conjuntos de funciones que
van a estar asociadas) y sus relaciones. Con ello
se dene la arquitectura de la solucin elegida. El segundo dene los algoritmos empleados
y la organizacin del cdigo para comenzar la
implementacin.

53.1.3

Diseo del Programa

Es la fase en donde se realizan los algoritmos

necesarios para el cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para saber qu herramientas usar
en la etapa de Codicacin

53.1.4

Codicacin

Es la fase en donde se implementa el cdigo

fuente, haciendo uso de prototipos as como de
pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programacin y
su versin se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso
mucho ms rpido.

53.2 Variantes
Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y
en la que se establece un ciclo antes de llegar
a la fase de mantenimiento, vericando que el
sistema nal este libre de fallos.
Otros ejemplos de variantes del modelo en cascada son el modelo en cascada con fases solapadas, cascada con subproyectos, y cascada
con reduccin de riesgos.* [2]

53.3 Ventajas
Realiza un buen funcionamiento en equipos
dbiles y productos maduros, por lo que se requiere de menos capital y herramientas para
hacerlo funcionar de manera ptima.
Es un modelo fcil de implementar y entender.
Est orientado a documentos.
Es un modelo conocido y utilizado con frecuencia.
Promueve una metodologa de trabajo efectiva: Denir antes que disear, disear antes que
codicar.* [3]

53.4 Desventajas
53.1.5

Pruebas

Los elementos, ya programados, se ensamblan

para componer el sistema y se comprueba que
funciona correctamente y que cumple con los
requisitos, antes de ser entregado al usuario nal.

53.1.6

Vericacin

En la vida real, un proyecto rara vez sigue una

secuencia lineal, esto crea una mala implementacin del modelo, lo cual hace que lo lleve al
fracaso.
El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de
prueba y hasta que el software no est completo
no se opera. Esto es la base para que funcione
bien.

Es la fase en donde el usuario nal ejecuta el

sistema, para ello el o los programadores ya
realizaron exhaustivas pruebas para comprobar
que el sistema no falle.

Cualquier error de diseo detectado en la etapa

de prueba conduce necesariamente al rediseo
y nueva programacin del cdigo afectado, aumentando los costos del desarrollo.

En la creacin de desarrollo de cascada se implementa los cdigos de investigacin y pruebas del mismo.

Una etapa determinada del proyecto no se puede llevar a cabo a menos de que se haya culminado la etapa anterior.

53.1.7

Mantenimiento

Una de las etapas ms crticas, ya que se destina

un 75 % de los recursos, es el mantenimiento
del Software ya que al utilizarlo como usuario
nal puede ser que no cumpla con todas nuestras expectativas.

53.5 Vase tambin

Ingeniera de software
Desarrollo en espiral
Modelos de desarrollo de software: Cascada vs V

53.7. ENLACES EXTERNOS

53.6 Referencias
[1] S. Pressman, Roger. Ingeniera del Software: Un enfoque
prctico, 3. Edicin, Pag. 26-30.
[2] , Patricia Arieta Melgarejo, Modelos del ciclo de vida de
software.
[3] , Ruby Casallas, Andrs Yie, Ingeniera de Software: Ciclos de Vida y Metodologas.

53.7 Enlaces externos

Ciclo de vida del software

99

Captulo 54

Desarrollo en espiral
El desarrollo en espiral es un modelo de ciclo de vida
del software denido por primera vez por Barry Boehm
en 1986,* [1] utilizado generalmente en la Ingeniera de
software. Las actividades de este modelo se conforman en
una espiral, en la que cada bucle o iteracin representa un
conjunto de actividades. Las actividades no estn jadas
a ninguna prioridad, sino que las siguientes se eligen en
funcin del anlisis de riesgo, comenzando por el bucle
interior.

54.1 Introduccin

Enhancement.* [1] En 1988, Boehm public un artculo

similar* [2] destinado a una audiencia ms ampla. Bsicamente consiste en una serie de ciclos que se repiten en
forma de espiral, comenzando desde el centro. Se suele
interpretar como que dentro de cada ciclo de la espiral se
sigue un Modelo Cascada, pero no necesariamente debe
ser as. El Espiral puede verse como un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP
con los aspectos controlados y sistemticos del Modelo
Cascada, con el agregado de gestin de riesgo.

54.2 Ciclos o Iteraciones

La Ingeniera de software, se vale y establece a partir de En cada vuelta o iteracin hay que tener en cuenta:
una serie de modelos que establecen y muestran las distintas etapas y estados por los que pasa un producto soft Los Objetivos: qu necesidad debe cubrir el proware, desde su concepcin inicial, pasando por su desaducto.
rrollo, puesta en marcha y posterior mantenimiento, hasta
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 modeobjetivos de forma exitosa, desde diferentes puntos
lo concebido fue el de Royce, ms comnmente conocido
de vista como pueden ser:
como desarrollo en cascada o desarrollo lineal secuencial.
Este modelo establece que las diversas actividades que se
1. Caractersticas: experiencia del personal, requisivan realizando al desarrollar un producto software sucetos a cumplir, etc.
den de forma lineal.
Boehm, autor de diversos artculos de ingeniera del soft2. Formas de gestin del sistema.
ware; modelos de estimacin 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 enfoque distinto al tradicional en Cascada: El Modelo Evo Desarrollar y Vericar: Programar y probar el
lutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiesoftware.
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 implemenriesgo ms 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 planicaran 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 mejorndose con otro
la radial y la angular:
nuevo ciclo.
Este modelo fue propuesto por Boehm en 1986 en su artculo A Spiral Model of Software Development and
100

1. Angular: Indica el avance del proyecto del software

dentro de un ciclo.

54.3. MECANISMOS DE CONTROL

2. Radial: Indica el aumento del coste del proyecto,
ya que con cada nueva iteracin se pasa ms tiempo
desarrollando.
Este sistema es muy utilizado en proyectos grandes y
complejos como puede ser, por ejemplo, la creacin de
un Sistema Operativo.

101
Dependiendo del resultado de la evaluacin de los
riesgos, se elige un modelo para el desarrollo, el que
puede ser cualquiera de los otros existentes, como
formal, evolutivo, cascada, etc. As si por ejemplo
si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podra ser
la construccin de prototipos evolutivos. Si lo riesgos de proteccin son la principal consideracin, un
desarrollo basado en transformaciones formales podra ser el ms apropiado.

Al ser un modelo de Ciclo de Vida orientado a la gestin

de riesgo se dice que uno de los aspectos fundamentales
de su xito radica en que el equipo que lo aplique tenga
la necesaria experiencia y habilidad para detectar y cataAnlisis del riesgo
logar correctamente los riesgos.

54.2.1

Tareas

Para cada ciclo habr cuatro actividades:

Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los
daos y consecuencias que stas puedan producir.
Se evalan 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
uno de los ambitos

2. Anlisis del riesgo.

3. Desarrollar y probar.

54.3 Mecanismos de control

4. 'Planicacin.'

La dimensin radial mide el coste.

Determinar objetivos

Anlisis del riesgo

La dimensin angular mide el grado de avance del

proyecto.

54.4 Variaciones del Modelo En

Espiral
Planicacin

Desarrollar y probar

Modelo en Espiral Tpico de seis regiones

Modelo en espiral(Boehm, 1986).

Determinar o jar objetivos

El modelo en espiral puede adaptarse y aplicarse a lo largo

de la vida del software de computadora, a diferencia del
modelo de proceso clsico que termina cuando se entrega
el software.

Fijar tambin los productos denidos a obtener: re- Las 6 regiones que componen este modelo son las siguienquisitos, especicacin, manual de usuario.
tes:
Fijar las restricciones.
Identicacin de riesgos del proyecto y estrategias
alternativas para evitarlos.
Hay una cosa que solo se hace una vez: planicacin
inicial.

Comunicacin con el cliente - Tareas necesarias para plantear la comunicacin entre el desarrollador y
el cliente.
Planicacin - Tareas inherentes a la denicin de
recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.

Tareas de la actividad propia y de prueba.

Anlisis de riesgos Tareas para evaluar riesgos tcnicos y otras informaciones relacionadas con el proyecto.

Anlisis de alternativas e identicacin resolucin

de riesgos.

Ingeniera - Tareas para construir una o ms representaciones de la aplicacin.

Desarrollar, vericar y validar(probar)

102
Construccin y adaptacin - Tareas requeridas para
construir, probar, instalar y proporcionar soporte a
los usuarios.

CAPTULO 54. DESARROLLO EN ESPIRAL

54.7 Inconvenientes

Planicar un proyecto con esta metodologa es a menudo

imposible, debido a la incertidumbre en el nmero de ite Evaluacin del cliente - Tareas requeridas para ob- raciones que sern necesarias. En este contexto la evaluatener la reaccin del cliente segn la evaluacin de cin de riesgos es de la mayor importancia y, para granlas representaciones del software creadas durante la des proyectos, dicha evaluacin requiere la intervencin
etapa de ingeniera e implementacin durante la eta- de profesionales de gran experiencia.
pa de instalacin.* [3]
El IEEE clasica al desarrollo en espiral como modelo no
operativo en sus clasicaciones de MCV.* [5]
Modelo en espiral WIN WIN
El modelo Win-Win es una adaptacin del modelo espiral
que se enfatiza en la participacin del cliente en el proceso de desarrollo de un producto de software. En un caso ideal, el desarrollador simplemente pregunta al cliente
lo que se requiere y el cliente proporciona suciente informacin y detalles para proceder. Sin embargo esto no
suele ocurrir en la mayora de los casos y es necesario
que se establezcan negociaciones signicativas entre ambas partes para equilibrar la funcionalidad y rendimiento
con los costos y tiempo de salida al mercado del producto. El modelo Win-Win deriva su nombre del objetivo de
estas negociaciones, es decir, ganar-ganar. El cliente
recibe el producto que satisface la mayora de sus necesidades, y el desarrollador trabaja para alcanzar presupuestos y fechas de entrega. Para lograr este objetivo, se
realizan varias actividades de negociacin al principio de
cada paso alrededor de la espiral.* [4]

54.5 Ventajas
El anlisis del riesgo se hace de forma explcita y clara.
Une los mejores elementos de los restantes modelos.
Reduce riesgos del proyecto
Incorpora objetivos de calidad
Integra el desarrollo con el mantenimiento, etc.
Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodologa, ya que este
ciclo de vida no es rgido ni esttico.

54.6 Desventajas
Genera mucho tiempo en el desarrollo del sistema
Modelo costoso
Requiere experiencia en la identicacin de riesgos

54.8 Vase tambin

Ingeniera de Software
Desarrollo de Software
Modelo en Cascada o Secuencial
Modelo Iterativo Incremental
Modelo por Prototipos
Modelo de Desarrollo Rpido

54.9 Referencias
[1] Boehm B, A Spiral Model of Software Development
and Enhancement, ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, Agosto 1986.
[2] Boehm B, A Spiral Model of Software Development
and Enhancement", IEEE Computer, IEEE, 21(5):61-72,
May 1988
[3] [Link]
[Link]
[4] [Link]
[5] Developing a Software Project Life Cycle Process (IEEE
1074), 30 de marzo de 2006.

54.10 Enlaces externos

A Spiral Model of Software Development and Enhancement. artculo original de Barry Boehm en el
que propona el modelo de desarrollo en espiral (en
ingls)

Captulo 55

Desarrollo iterativo y creciente

Desarrollo iterativo y creciente (o incremental) es un ed Process y el Dynamic Systems Development Metproceso de desarrollo de software creado en respuesta a hod. El desarrollo incremental e iterativo es tambin una
las debilidades del modelo tradicional de cascada.
parte esencial de un tipo de programacin conocido coBsicamente este modelo de desarrollo, que no es ms mo Extreme Programming y los dems frameworks de
desarrollo rpido de software.
que un conjunto de tareas agrupadas en pequeas etapas
*
repetitivas (iteraciones), [1] es uno de los ms utilizados
en los ltimos tiempos ya que, como se relaciona con novedosas estrategias de desarrollo de software y una pro- 55.2 Ciclo de vida
gramacin extrema, es empleado en metodologas diversas.
La idea principal detrs de mejoramiento iterativo es
El modelo consta de diversas etapas de desarrollo en cada desarrollar un sistema de programas de manera increincremento, las cuales inician con el anlisis y nalizan mental, permitindole al desarrollador sacar ventaja de lo
que se ha aprendido a lo largo del desarrollo anterior, incon la instauracin y aprobacin del sistema.* [2]
crementando, versiones entregables del sistema. El aprendizaje 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 implementacin 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 iteracin, se realiSe planica un proyecto en distintos bloques temporales zan cambios en el diseo y se agregan nuevas funcionalique se le denominan iteracin. En una iteracin se repite dades y capacidades al sistema.
un determinado proceso de trabajo que brinda un resul- Bsicamente este modelo se basa en dos premisas:
tado ms completo para un producto nal, de forma que
quien lo utilice reciba benecios de este proyecto de ma Los usuarios nunca saben bien que es lo que necesinera creciente.
tan para satisfacer sus necesidades.
Para llegar a lograr esto, cada requerimiento debe tener
En el desarrollo, los procesos tienden a cambiar.* [4]
un completo desarrollo en una nica iteracin que debe de
incluir pruebas y una documentacin 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 inicializacin
Lo que se busca es que en cada iteracin los componentes
logren evolucionar el producto dependiendo de los completados de las iteraciones antecesoras, agregando ms
opciones de requisitos y logrando as un mejoramiento
mucho ms completo.

Etapa de iteracin
Lista de control de proyecto

55.2.1 Consideraciones sobre el momento

Una manera muy primordial para dirigir al proceso iterade aplicacin

tivo incremental es la de priorizar los objetivos y requerimientos en funcin 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 suciente con asignar tcnicas de usabilidad a acmodelo se han creado frameworks (entornos de trabajo), tividades de desarrollo, puesto que no todas las tcnicas
de los cuales los dos ms famosos son el Rational Uni- de usabilidad son aplicables en cualquier momento de un
103

104

CAPTULO 55. DESARROLLO ITERATIVO Y CRECIENTE

desarrollo iterativo. Por ejemplo, las tcnicas para desarrollar el concepto del producto estn concebidas para su
aplicacin en los primeros esfuerzos del desarrollo, cuando las necesidades se identican y el esquema general del
sistema se establece. Aunque es aconsejable aplicarlas
tambin ms tarde, para renar el concepto, su principal esfuerzo de aplicacin esta en las tareas iniciales de
desarrollo.* [5]

55.2.2

Etapa de inicializacin

Se crea una versin del sistema. La meta de esta etapa

es crear un producto con el que el usuario pueda interactuar, y por ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del problema y
proveer una solucin lo sucientemente simple para ser
comprendida e implementada fcilmente. Para guiar el
proceso de iteracin se crea una lista de control de proyecto, que contiene un historial de todas las tareas que
necesitan ser realizadas. Incluye cosas como nuevas funcionalidades para ser implementadas, y areas de rediseo
de la solucin ya existente. Esta lista de control se revisa
peridica y constantemente como resultado de la fase de
anlisis.

55.2.3

Etapa de iteracin

Esta etapa involucra el rediseo e implementacin de una

tarea de la lista de control de proyecto, y el anlisis de la
versin ms reciente del sistema. La meta del diseo e
implementacin de cualquier iteracin es ser simple, directa y modular, para poder soportar el rediseo de la
etapa o como una tarea aadida a la lista de control de
proyecto. El cdigo puede, en ciertos casos, representar
la mayor fuente de documentacin del sistema. El anlisis de una iteracin se basa en la retroalimentacin del
usuario y en el anlisis de las funcionalidades disponibles
del programa. Involucra el anlisis de la estructura, modularidad, usabilidad, conabilidad, eciencia y ecacia
(alcanzar las metas). La lista de control del proyecto se
modica bajo la luz de los resultados del anlisis.
Las guas primarias que guan la implementacin y el anlisis incluyen:
Cualquier dicultad en el diseo, codicacin y
prueba de una modicacin debera apuntar a la necesidad de redisear o recodicar.

Las modicaciones deben ser ms fciles de hacer

conforme avanzan las iteraciones. Si no es as, hay un
problema primordial usualmente encontrado en un
diseo dbil o en la proliferacin excesiva de parches
al sistema.
Los parches normalmente deben permanecer solo
por una o dos iteraciones. Se hacen necesarios para
evitar el rediseo durante una fase de implementacin.
La implementacin existente debe ser analizada frecuentemente para determinar qu tal se ajusta a las
metas del proyecto.
Las facilidades para analizar el programa deben ser
utilizadas cada vez para ayudar en el anlisis de implementaciones parciales.
La opinin del usuario debe ser solicitada y analizada para indicar deciencias en la implementacin
referida por l.

55.3 Caso prctico

La mejora iterativa fue exitosamente aplicada al desarrollo de una familia extensa de compiladores para una familia de lenguajes de programacin en una gama de arquitecturas de hardware. Un conjunto de 17 versiones del
sistema se desarrollaron en un lugar, generando 17 mil lneas de cdigo fuente de lenguaje de alto nivel (6500 de
cdigo ejecutable). El sistema posteriormente fue desarrollado en dos sitios diferentes, llegando a dos versiones
diferentes del lenguaje base: una versin esencialmente
se enfocaba en aplicaciones matemticas, aadiendo nmeros reales y varias funciones matemticas, y la otra se
centr en aadir capacidades para escribir del compilador. Cada iteracin fue analizada del punto de vista de
los usuarios (las capacidades del lenguaje fueron determinadas en parte por las necesidades del usuario) y el
punto de vista del desarrollador (el diseo del compilador evolucion para ser ms fcilmente modicable, por
ejemplo, para aadir nuevos tipos de datos). Mediciones
tales como acoplamiento y modularizacin fueron seguidas sobre mltiples versiones.

55.4 Caractersticas

Las modicaciones deben ajustarse fcilmente a los

Usando anlisis y mediciones como guas para el procemdulos fciles de encontrar y a los aislados. Si no
so de mejora es una diferencia mayor entre las mejoras
es as, entonces se requiere algn grado de rediseo.
iterativas y el desarrollo rpido de aplicaciones, princi Las modicaciones a las tablas deben ser especial- palmente por dos razones:
mente fciles de realizar. Si dicha modicacin no
ocurre rpidamente, se debe aplicar algo de rediseo.

Provee de soporte para determinar la efectividad de

los procesos y de la calidad del producto.

55.7. DEBILIDADES DE ESTE MODELO DE DESARROLLO

Permite estudiar y despus mejorar y ajustar el proceso para el ambiente en particular.
Estas mediciones y actividades de anlisis pueden ser
aadidas a los mtodos de desarrollo rpido existentes.
De hecho, el contexto de iteraciones mltiples conlleva
ventajas en el uso de mediciones. Las medidas a veces
son difciles de comprender en lo absoluto, aunque en los
cambios relativos en las medidas a travs de la evolucin
del sistema puede ser muy informativo porque proveen
una base de comparacin. Por ejemplo, un vector de medidas m1, m2,..., mn puede ser denido para caracterizar
varios aspectos del producto en cierto punto, como pueden ser el esfuerzo total realizado, los cambios, los defectos, los atributos lgico, fsico y dinmico, consideraciones del entorno, etctera. As el observador puede decir
como las caractersticas del producto como el tamao, la
complejidad, el acoplamiento y la cohesin incrementan
o disminuyen en el tiempo. Tambin puede monitorearse el cambio relativo de varios aspectos de un producto o
pueden proveer los lmites de las medidas para apuntar a
problemas potenciales y anomalas.

55.5 Ventajas del desarrollo incremental

En este modelo los usuarios no tienen que esperar
hasta que el sistema completo se entregue para hacer
uso de l. El primer incremento cumple los requerimientos ms importantes de tal forma que pueden
utilizar el software al instante.
Los usuarios pueden utilizar los incrementos iniciales como prototipos y obtener experiencia sobre los
requerimientos de los incrementos posteriores del
sistema.
Existe muy pocas probabilidades de riesgo en el sistema. Aunque se pueden encontrar problemas en algunos incrementos, lo normal es que el sistema se
entregue sin inconvenientes al usuario.
Ya que los sistemas de ms alta prioridad se entregan primero, y los incrementos posteriores se integran entre ellos, es muy poco probable que los sistemas ms importantes sean a los que se les hagan
ms pruebas. Esto quiere decir que es menos probable que los usuarios encuentren fallas de funcionamiento del software en las partes ms importantes
del sistema.* [6]

55.6 Ventajas del desarrollo iterativo

En el desarrollo de este modelo se da la retroalimentacin muy temprano a los usuarios.

105

Permite separar la complejidad del proyecto, gracias

a su desarrollo por parte de cada iteracin o bloque.
El producto es consistente y puntual en el desarrollo.
Los productos desarrollados con este modelo tienen
una menor probabilidad de fallar.
Se obtiene un aprendizaje en cada iteracin que es
aplicado en el desarrollo del producto y aumenta las
experiencias para prximos proyectos.* [7]

55.7 Debilidades de este modelo de

desarrollo
La entrega temprana de los proyectos produce la
creacin de sistemas demasiados simples que a veces se ven un poco montonos a los ojos del personal
que lo recibe.* [6]
La mayora de los incrementos se harn en base de
las necesidades de los usuarios. Los incrementos en
si ya son estipulados desde antes de la entrega del
proyecto, sin embargo hay que ver cmo se maneja
el producto para ver si necesita otros cambios adems de los estipulados antes de la entrega del proyecto. Este problema no se ve frecuentemente ya
que la mayora de las veces los incrementos estipulados suplen satisfactoriamente al usuario.* [6]
Los incrementos no deben constar de muchas lneas
de cdigo ya que la idea de los incrementos es agregar accesorios al programa principal (o funcional),
para que este tenga una y mil formas de desenvolverse en su tarea; llenar los incrementos de muchas
lneas de cdigo provocara que se perdiera la objetividad o base de lo que se trata el desarrollo incremental.* [6]
Requiere de un cliente involucrado durante todo el
curso del proyecto. Hay clientes que simplemente no
estarn dispuestos a invertir el tiempo necesario.
El trato con el cliente debe basarse en principios
ticos y colaboracin mutua, ms que trabajar cada parte independientemente, defendiendo slo su
propio benecio.* [8]
La entrega de un programa que es parcial pero funcional puede hacer vulnerable al programa debido
a la falta de robustez en su sistema, provocando que
agentes ajenos puedan interferir con el correcto funcionamiento del programa en s.* [6]
Infunde responsabilidad en el equipo de desarrollo
al trabajar directamente con el cliente, requiriendo
de profesionales sobre el promedio.

106

CAPTULO 55. DESARROLLO ITERATIVO Y CRECIENTE

Sufre fuertes penalizaciones en proyectos en los cuales los requerimientos estn previamente denidos,
o para proyectostodo/nadaen los cuales se requiere que se completen en un 100% el producto para ser
implementado (por ejemplo, licitaciones) otro punto 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 Vase tambin

Scrum
Iteracin
Desarrollo en cascada
Ingeniera 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 incremental| [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
[5] 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)
[6] Ian Sommerville (2005). Entrega Incremental. Ingeniera del Software, Sptima edicin edicin... Espaa: Pearson.
[7] |Proceso de Desarrollo Iterativo| [Link]
[Link]/?p=13
[8] |Desarrollo iterativo e incremental| [Link]
[Link]/desarrollo-iterativo-incremental

Captulo 56

Deteccin dinmica de invariantes

La generacin dinmica de invarianteses una tcnica dinmica para el anlisis informtico, normalmente
orientado a la prueba y monitorizacin de software

56.1 Implementaciones
La implementacin ms famosa es Daikon

107

Captulo 57

Diagrama de colaboracin
Un diagrama de colaboracin en las versiones de UML
1.x es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los
diagramas de secuencia, los diagramas de colaboracin,
tambin llamados diagramas de comunicacin, muestran
explcitamente las relaciones de los roles. Por otra parte, un diagrama de comunicacin no muestra el tiempo
como una dimensin aparte, por lo que resulta necesario
etiquetar con nmeros de secuencia tanto la secuencia de
mensajes como los hilos concurrentes.

implcitas. Un diagrama de comunicacin muestra relaciones entre roles geomtricamente y relaciona los mensajes con las relaciones, pero las secuencias temporales
estn menos claras.

57.2 Tipos

Es til marcar los objetos en cuatro grupos: los que exis Muestra cmo las instancias especcas de las clases
ten con la interaccin entera; los creados durante la intrabajan juntas para conseguir un objetivo comn.
teraccin (restriccin {new}); los destruidos durante la
Implementa las asociaciones del diagrama de clases interaccin (restriccin {destroyed}); y los que se crean
mediante el paso de mensajes de un objeto a otro. y se destruyen durante la interaccin (restriccin {transient}).
Dicha implementacin es llamada enlace.
Un diagrama de comunicacin es tambin un diagrama
de clases que contiene roles de clasicador y roles de asociacin en lugar de slo clasicadores y asociaciones. Los
roles de clasicador y los de asociacin describen la conguracin de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicacin.
Cuando se instancia una comunicacin, los objetos estn
ligados a los roles de clasicador y los enlaces a los roles
de asociacin. El rol de asociacin puede ser desempeado por varios tipos de enlaces temporales, tales como
argumentos de procedimiento o variables locales del procedimiento. Los smbolos de enlace pueden llevar estereotipos para indicar enlaces temporales.

Aunque las comunicaciones muestran directamente la

implementacin de una operacin, pueden tambin mostrar la realizacin de una clase entera. En este uso, muestran el contexto necesario para implementar todas las
operaciones de una clase. Esto permite que el modelador
vea los roles mltiples que los objetos pueden desempear en varias operaciones.
No hay ejemplos de los diagramas, diferentes casos o sistemas, ya que con UML se modelan reas de un negocio
as como los sistemas que estos requieren

57.3 Mensajes
57.1 Usos
Un uso de un diagrama de colaboracin es mostrar la implementacin de una operacin. La comunicacin muestra los parmetros y las variables locales de la operacin,
as como asociaciones ms permanentes. Cuando se implementa el comportamiento, la secuencia de los mensajes corresponde a la estructura de llamadas anidadas y el
paso de seales del programa.
Un diagrama de secuencia muestra secuencias en el tiempo como dimensin geomtrica, pero las relaciones son

Los mensajes se muestran como echas etiquetadas unidas a los enlaces. Cada mensaje tiene un nmero de secuencia, una lista opcional de mensajes precedentes, una
condicin opcional de guarda, un nombre, una lista de
argumentos y un nombre de valor de retorno opcional.
El nombre de serie incluye el nombre (opcional) de un
hilo. Todos los mensajes del mismo hilo se ordenan secuencialmente. Los mensajes de diversos hilos son concurrentes a menos que haya una dependencia secuencial
explcita. En conclusin en un diagrama muy sencillo de
hacer.

108

57.5. CAMBIOS EN VERSIONES RECIENTES DE UML

57.4 Flujos
Generalmente, un diagrama de comunicacin contiene un
smbolo para un objeto durante una operacin completa.
Sin embargo, a veces, un objeto contiene diferentes estados que se deban hacer explcitos. Por ejemplo, un objeto
pudo cambiar de localizacin o sus asociaciones pudieron
diferenciarse.
Los diferentes smbolos de objeto que representan un objeto se pueden conectar usando ujosbecomeoconversin. Un ujobecomees una transicin, a partir
de un estado de un objeto a otro. Se dibuja como una echa de lnea discontinua con el estereotipo becomeo
conversiny puede ser etiquetado con un nmero de
serie para mostrar cuando ocurre. Un ujo de conversin
tambin se utiliza para mostrar la migracin de un objeto
a partir de una localizacin a otra distinta para otro lugar
tambin se deben marcar con el nmero en secuencias.

57.5 Cambios en versiones recientes de UML

En versiones recientes de UML este diagrama ha sido reemplazado por el diagrama de comunicacin.

109

Captulo 58

Diagrama de ujo
La lmpara no
funciona

Est
enchufada
la lmpara?

No

Enchufar
la lmpara

Est
quemada la
ampolleta?

Cambiar la
ampolleta

No
Comprar
nueva lmpara
Diagrama de ujo sencillo con los pasos a seguir si una lmpara
no funciona.

El diagrama de ujo o diagrama de actividades es la

representacin grca del algoritmo o proceso. Se utiliza
en disciplinas como programacin, economa, procesos
industriales y psicologa cognitiva.
En Lenguaje Unicado de Modelado (UML), un diagrama 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 ujos entre pasos que mueven elementos fsicos (p. ej., ga- Diagrama de actividades para un loop a(bucle
solina) o energa (p. ej., presin). Los cambios adicionales
permiten al diagrama soportar mejor ujos de comportamiento y datos continuos.
Estos diagramas utilizan smbolos con signicados deni- tan el ujo de ejecucin 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 tomaUn diagrama de ujo presenta generalmente un nico das dentro de un proceso.
punto de inicio y un nico punto de cierre, aunque puede La especicacin del Lenguaje de Noticacin Unicado
tener ms, siempre que cumpla con la lgica requerida.
(UNL) dene un diagrama de actividad como:
Las siguientes son acciones previas a la realizacin del una variacin de los estados de una mquina, los cuales
diagrama de ujo:
representan el rendimiento de las acciones o subactividades y las transiciones se provocan por la realizacin de las
*
Identicar las ideas principales al ser incluidas en el acciones o subactividades. [1]
diagrama de ujo. Deben estar presentes el autor o El propsito del diagrama de actividad es modelar un proresponsable del proceso, los autores o responsables ceso de ujo de trabajo (workow) y/o modelar operaciodel proceso anterior y posterior y de otros proce- nes.
sos interrelacionados, as como las terceras partes
Una Operacin es un servicio proporcionado por un obinteresadas.
jeto, que est disponible a travs de una interfaz.
Denir qu se espera obtener del diagrama de ujo.
Una Interfaz es un grupo de operaciones relacionadas con
la semntica.
Identicar quin lo emplear y cmo.
Establecer el nivel de detalle requerido.
Determinar los lmites del proceso a describir.
Los pasos a seguir para construir el diagrama de ujo son:
Establecer el alcance del proceso a describir. De esta manera quedar jado el comienzo y el nal del
diagrama. Frecuentemente el comienzo es la salida
del proceso previo y el nal la entrada al proceso
siguiente.
Identicar y listar las principales actividades/subprocesos que estn incluidos en el proceso a
describir y su orden cronolgico.
Si el nivel de detalle denido incluye actividades
menores, listarlas tambin.
Identicar y listar los puntos de decisin.
Construir el diagrama respetando la secuencia cronolgica y asignando los correspondientes smbolos.
Asignar un ttulo al diagrama y vericar que est
completo y describa con exactitud el proceso elegido.

58.3 Tipos de diagramas de ujo

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
la informacin que se considere necesaria, segn su
propsito.
Formato horizontal: En l, el ujo o la secuencia de
las operaciones, va de izquierda a derecha.
Formato panormico: El proceso entero est representado en una sola carta y puede apreciarse de una
sola mirada mucho ms rpido que leyendo el texto, lo que facilita su comprensin, aun para personas
no familiarizadas. Registra no solo en lnea vertical,
sino tambin horizontal, distintas acciones simultneas y la participacin de ms de un puesto o departamento que el formato vertical no registra.
Formato Arquitectnico: Describe el itinerario de
ruta de una forma o persona sobre el plano arquitectnico del rea de trabajo. El primero de los ujogramas es eminentemente descriptivo, mientras que
los utilizados son fundamentalmente representativos.

58.2 Descripcin
En UML 1.x, un diagrama de actividades es una variacin
del diagrama de estado UNL donde los estadosrepresentan operaciones, y las transiciones representan las
actividades que ocurren cuando la operacin se completa.
El diagrama de mensajes de UML 2.0, mientras que es
similar en aspecto al diagrama de actividades UML 1.x,
ahora tiene semnticas basadas en redes de Petri. En
UML 2.0, el diagrama general de interaccin est basado
en el diagrama de actividades. El diagrama de actividad

58.4 Simbologa y signicado

valo o Elipse: Inicio y Final (Abre y cierra el diagrama).
Rectngulo: Actividad (Representa la ejecucin de
una o ms actividades o procedimientos).
Rombo: Decisin (Formula una pregunta o cuestin).

112
Crculo: Conector (Representa el enlace de actividades con otra dentro de un procedimiento).

CAPTULO 58. DIAGRAMA DE FLUJO

58.6 Historia

Tringulo boca abajo: Archivo denitivo (Guarda

un documento en forma permanente).
Tringulo boca arriba: Archivo temporal (Proporciona un tiempo para el almacenamiento del docuLa paternidad del diagrama de ujo es en principio algo
mento).
difusa. El mtodo estructurado para documentar grcamente un proceso como un ujo de pasos sucesivo y alternativos, elproceso de diagrama de ujo, fue expuesto
58.5 Cursograma
por Frank Gilbreth, en la Sociedad Americana de Ingenieros Mecnicos (ASME), en 1921, bajo el enunciado
Se trata de la ms comn y prctica entre todas las clases de Proceso de Grcas-Primeros pasos para encontrar
de diagramas de ujo. Describe el ujo de informacin el mejor modo. Estas herramientas de Gilbreth rpidaen un ente u organizacin, sus procesos, sistemas admi- mente encontraron sitio en los programas de ingeniera
nistrativos y de control. Permite la impresin visual de los industrial.
procedimientos y una clara y lgica interpretacin.
Al principio de los 30, un ingeniero industrial, Allan H.
Mogensen comenz la formacin de personas de nego58.5.1 Simbologa y normas del cursogra- cios en Lake Placid, Nueva York, incluyendo el uso del
diagrama de ujo. Art Spinanger, asistente a las clases de
ma
Mogesen, utiliz las herramientas en su trabajo en Procter & Gamble, donde desarroll suPrograma Metdico
Crculo: Procedimiento estandarizado.
de Cambios por Etapas. Otro asistente al grupo de gra Cuadrado: Proceso de control.
duados en 1944, Ben S. Graham, director de ingeniera
Lnea continua: Flujo de informacin va formula- de Formcraft Standard Register Corporation, adapt la
grca de ujo de procesos al tratamiento de la informario o documentacin en soporte de papel escrito.
cin en su empresa. Y desarroll la grca del proceso
Lnea interrumpida: Flujo de informacin va for- de mltiples ujos en mltiples pantallas, documentos, y
mulario digital.
sus relaciones. En 1947, ASME adopt un conjunto de
smbolos derivados de la obra original de Gilbreth como
Rectngulo: Formulario o documentacin. Se graNorma ASME para los grcos de procesos (preparada
fca con el doble de ancho que su altura.
Mishad, Ramsan y Raiaan).
Rectngulo Pequeo: Valor o medio de pago (che- Sin embargo, segn explica Douglas Hartree fueron orique, pagar, etc.). Se grafca con el cudruple de an- ginalmente Herman Goldstine y John von Neumann quiecho que su altura, siendo su ancho igual al de los for- nes desarrollaron el diagrama de ujo (inicialmente llamularios.
madodiagrama) para planicar los programas de ordenador. Las tablas de programacin original de ujo de
Goldstine y von Neumann, aparecen en un informe no pu Tringulo Invertido (base superior): Archivo blicado, Planicacin y codicacin de los problemas
Transitorio.
de un instrumento de computacin electrnica, la Parte
II, Volumen 1 "(1947), reproducido en las obras comple Semivalo: Demora.
tas de von Neumann.
Rombo: Divisin entre opciones.
Inicialmente los diagramas de ujo resultaron un medio
popular para describir algoritmos de computadora, y an
Trapezoide: Carga de datos al sistema.
se utilizan con este n. Herramientas como los diagra Elipsoide: Acceso por pantalla.
mas de actividad UML, pueden ser considerados como
evoluciones del diagrama de ujo.
Hexgono: Proceso no representado.
En la dcada de 1970 la popularidad de los diagramas de
Pentgono: Conector.
ujo como mtodo propio de la informtica disminuy,
Cruz de Diagonales: Destruccin de Formularios. con el nuevo hardware y los nuevos lenguajes de programacin de tercera generacin. Y por otra parte se conSegn la normativa, el ujo presupuesto es de izquierda virtieron en instrumentos comunes en el mundo emprea derecha y de arriba hacia abajo, siendo optativo el uso sarial. Son una expresin concisa, legible y prctica 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 simplicacin y
la echa.
expresin lgica de procesos, etc.
Tringulo (base inferior): Archivo denitivo.

58.9. VASE TAMBIN

113

58.7 Ventajas de los diagramas de 58.9 Vase tambin

ujo
58.10 Referencias
Favorecen la comprensin del proceso al mostrarlo
como un dibujo. El cerebro humano reconoce muy
fcilmente los dibujos. Un buen diagrama de ujo
reemplaza varias pginas de texto.
Permiten identicar los problemas y las oportunidades de mejora del proceso. Se identican los pasos,
los ujos de los reprocesos, los conictos de autoridad, las responsabilidades, los cuellos de botella, y
los puntos de decisin.
Muestran las interfaces cliente-proveedor y las
transacciones que en ellas se realizan, facilitando a
los empleados el anlisis de las mismas.
Son una excelente herramienta para capacitar a los
nuevos empleados y tambin a los que desarrollan la
tarea, cuando se realizan mejoras en el proceso.
Al igual que el pseudocdigo, el diagrama de ujo
con nes de anlisis de algoritmos de programacin
puede ser ejecutado en un ordenador, con un IDE
como Free DFD.

58.8 Software para diseo de diagramas de ujo

Actualmente existe una gran cantidad de software para la
elaboracin de diagramas de ujo. A continuacin se listan los programas ms comunes para elaborar diagramas
de ujo.
Microsoft Oce ofrece 3 herramientas tiles para
la elaboracin de diagramas. Uno de ellos es Microsoft Oce Word, que nos permite crear diagramas
de ujo bsicos a travs de la opcinFormasque
tiene un apartado especial para diagramas de ujo.
De igual manera Microsoft Oce Power Point ofrece las mismas opciones para crear los diseos de diagramas de ujo. Otra herramienta un poco ms sosticada es Microsoft Oce Visio, que adems de
la simbologa bsica de los diagramas de ujo cuenta 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 eciente y muy fcil de usar es el programa Diaque brinda una solucin rpida para
la creacin de diagramas de ujo adems de otro tipo de diagramas usados en el ambiente informtico.
Es considerado la versin no comercial de Microsoft
Visio.

[1] Bellows, Jeannie, Castek (2000). Activity Diagrams and

Operation Architecture. Technologies Group Inc.

58.11 Enlaces externos

Wikimedia Commons alberga contenido multimedia sobre Diagrama de ujoCommons.

Wikimedia Commons alberga contenido multimedia sobre diagrama de actividadesCommons.

Documentos de la Especicacin UML 2.0

Introduccin a los Diagramas de Actividades UML
2
Microsoft Oce Visio Tutorial
PSeInt herramienta para asistir a un estudiante en
sus primeros pasos en programacin.

Captulo 59

Diagrama Nassi-Shneiderman
En programacin de computadores un diagrama NassiShneiderman (o NSD por sus siglas en ingls), tambin
conocido como diagrama de Chapin* [1]* [2] es una representacin grca que muestra el diseo de un programa
estructurado.

do lo que se puede representar con un diagrama NassiShneiderman se puede representar con un diagrama de
ujo. Las nicas excepciones se dan en las instrucciones
GOTO, break y continue.

59.2 Referencias
[1] Molina Marco, A.; Letelier Torres, P.; Snchez Palma, P.;
Snchez Daz, J. (1997). Mtodos para especicacin
de mdulos. Metodologa y tecnologa de la programacin. Valencia: Universidad Politcnica de Valencia. p. 50.
ISBN 8477215197. Consultado el 26 de agosto de 2013.
[2] Eslava Muoz, V.J. (2012). Diseo de algoritmos.
Aprendiendo a programar paso a paso con C. Bubok Publishing. p. 42. ISBN 9788468610610. Consultado el 26
de agosto de 2013.

Ejemplo de un diagrama Nassi-Shneiderman.

Fue desarrollado en 1972 por Isaac Nassi y Ben Shneiderman. Este diagrama tambin es conocido como estructograma, ya que sirve para representar la estructura de los
programas. Combina la descripcin textual del pseudocdigo con la representacin grca del diagrama de ujo.

59.1 Descripcin

Nassi, I.; Shneiderman, B.: Tcnicas de diagramas

de ujo para programacin estructurada, SIGPLAN
Notices XII, Agosto 1973.

59.3 Enlaces externos

Wikimedia Commons alberga contenido mulBasado en un diseo top-down (de lo complejo a lo simtimedia sobre Diagrama Nassi-Shneiderman.
ple), el problema que se debe resolver se divide en subCommons
problemas cada vez ms pequeos - y simples - hasta que
solo queden instrucciones simples y construcciones para
A short history of structured owcharts (Nassiel control de ujo. El diagrama Nassi-Shneiderman reShneiderman Diagrams), por Ben Shneiderman
eja la descomposicin del problema en una forma simple usando cajas anidadas para representar cada uno de
los subproblemas. Para mantener una consistencia con los
59.3.1 Software
fundamentos de la programacin estructurada, los diagramas Nassi-Shneiderman no tienen representacin para las
Structorizer Editor de diagramas Nassiinstrucciones GOTO.
Shneiderman para Linux, Mac OS X & Microsoft
Windows, distribuido bajo GNU General Public
Los diagramas Nassi-Shneiderman se utilizan muy raraLicense
mente en las tareas de programacin formal. Su nivel de
abstraccin es muy cercano al cdigo de la programacin
Nessi Editor e intrprete de diagramas Nassiestructurada y ciertas modicaciones requieren que se reShneiderman, multiplataforma (Java), distribuido
dibuje todo el diagrama.
bajo GNU General Public License
Los diagramas Nassi-Shneiderman son (la mayora de
las veces) isomrcos con los diagramas de ujo. To114

Captulo 60

di
En informtica, di es una utilidad para la comparacin
de archivos que genera las diferencias entre dos archivos o los cambios realizados en un archivo determinado
comparndolo con una versin anterior del mismo archivo. Di expone los cambios realizados por lnea en los
archivos de texto. Las implementaciones modernas tambin soportan archivos binarios.* [1] El resultado se conoce como di o patch ya que el mismo puede ser aplicado
con el programa Unix patch. El resultado de la comparacin de un archivo similar tambin se llama di.
De la misma manera que se usa la palabra "grep" para
describir la accin de buscar, la palabra di se usa en la
jerga como un verbo que se reere al clculo de cualquier
diferencia. Un ejemplo de di.

60.1 Historia
La utilidad di fue desarrollada a comienzos de los aos
setenta en el sistema operativo Unix que estaba crendose en AT&T Bell Labs en Murray Hill, Nueva Jersey. La
versin nal, que apareci por primera vez con la 5 edicin de Unix en 1974, fue toda ella escrita por Douglas
McIlroy. Este trabajo fue publicado en un artculo de
1976 co-escrito con James W. Hunt que desarroll un
prototipo inicial de di.* [2]
El trabajo de McIlroy fue precedido e inuido por el programa comparison de Steve Johnson en GECOS y por
el programa proof de Mike Lesk tambin originado en
Unix y, como di, produca cambios lnea a lnea e incluso utilizaba parntesis angulares (">" y "<") para presentar las inserciones y borrados de lnea en el resultado
del programa. Las heursticas utilizadas en estas primeras aplicaciones fueron, sin embargo, juzgadas como no
ables. La utilidad potencial de la herramienta di provoc que McIlroy acometiese la investigacin y diseo
de una herramienta ms robusta que poda usarse en una
gran variedad de tareas pero que al tiempo se condujese
bien en los procesos y con las limitaciones de tamao del
hardware de PDP-11. Su anlisis del problema lo llev
a cabo con la colaboracin de distintas personas de Bell
Labs como Alfred Aho, Elliot Pinson, Jerey Ullman y
Harold S. Stone.

vea di con la habilidad natural para crear rdenes de

edicin tiles. Estas rdenes de edicin, cuando se grababan en un archivo, podan, junto con el archivo original, ser reconstituidas completamente por ed en el archivo modicado. Esto reduca enormemente el necesario
almacenamiento secundario para mantener las distintas
versiones de un archivo. McIlroy consider escribir un
post-procesador para di donde una variedad de formatos de resultados pudiesen ser diseados e implementados, pero encontr que era ms frugal y sencillo hacer
que di fuese el responsable de generar la sintaxis y la informacin de entrada de orden contrario aceptada por el
comando ed. En 1985, Larry Wall compuso una utilidad
separada, patch, que generaliz y extendi la habilidad
para modicar archivos con resultado di. Los modos de
Emacs permiten tambin convertir el formato de patches
e incluso editar patches interactivamente.
En los primeros aos de di, los usos habituales eran la
comparacin de cambios en la fuente del cdigo del software y el marcado de documentos tcnicos, la vericacin de la salida de errores de programa, la comparacin
de listados de sistemas de archivos y el anlisis del cdigo del montaje del ordenador. La salida apuntada por ed
fue modicada para proporcionar compresin a una secuencia de modicaciones hecha a un archivo. La Source
Code Control System (SCCS) y su habilidad para archivar revisiones apareci a nales de los aos setenta como
consecuencia de almacenar rdenes de edicin de di.
El Project Xanadu es un predecesor conceptual de di.
Era un proyecto de hipertexto concebido por primera vez
en 1960 que deba incluir una versin de un sistema de seguimiento necesario para su caracterstica detranspointing windows. La caracterstica subsuma las diferencias
de archivos en el trmino expansivo "transclusin", en el
que un documento inclua en l partes de otros documentos o revisiones.

60.2 Algoritmo
La operacin de di se basa en resolver el problema
Problema de Subsecuencia Comn mas Larga (LCS).

En el contexto de Unix, el uso del editor de lnea ed pro- En el problema LCS, se tienen dos secuencias de tems:
115

116
abcdfghjqzabcdefgijkrxyz

CAPTULO 60. DIFF

60.4 Variantes

y se desea encontrar la secuencia ms larga de tems que

se presenta las dos secuencias originales en el mismo orden. Esto es, se quiere encontrar una nueva secuencia que
pueda obtenerse de la primera secuencia eliminando algunos tems, y de la segunda secuencia eliminando otros
tems. Se quiere tambin que esta secuencia sea tan larga
como sea posible. En este caso es:

La mayora de las implementaciones de di se han mantenido aparentemente sin cambios desde 1975. Las modicaciones consisten en mejoras en el algoritmo base,
la adicin de caractersticas tiles al comando y el diseo de un nuevos formatos de salida. El algoritmo bsico
se describe en el artculo An O(ND) Dierence Algorithm
and its Variations de Eugene W. Myers* [4] y en A File
abcdfgjz
Comparison Program de Webb Miller and Myers.* [5] El
De la subsecuencia comn ms larga solo hay un pequeo algoritmo fue descubierto independientemente y descripaso para conseguir un resultado del tipo de di:
to en Algorithms for Approximate String Matching, de E.
Ukkonen.* [6] Las primeras ediciones del programa di
ehiqkrxy+-+-++++
fueron diseadas para la comparacin de lneas de archivos de texto dejando que el carcter newline delimitase
las lneas. En los aos ochenta, la ayuda para los archivos
binarios dio lugar a un cambio en el diseo y la implementacin de la aplicacin.

60.3 Uso
Es invocado desde la lnea de comando con los nombres
de dos archivos: di original new. El resultado del comando representa los cambios requeridos para hacer que
el archivo original se convierta en el nuevo archivo.

60.4.1 Edit script

Un edit script puede generarse por medio de versiones
modernas de di con la opcin -e. option. El edit script
resultante para el ejemplo anterior es el siguiente:

24a Este prrafo contiene importantes nuevas adiciones

a este documento. . 17c detenidamente este documento.
Si original y nuevo son directorios, entonces di se ejecu- Por . 8,14c comprimir nada. . 0a Esta es una importante
tar sobre cada archivo que exista en ambos directorios. noticia! Debera por lo tanto ser situada al comienzo de
Una opcin, -r, har que cualesquiera subdirectorios em- este documento! .
parejados comparen archivos entre directorios.
Todos los ejemplos en el artculo usan los archivos original y nuevo:
El comando di original nuevo produce el siguiente resultado di normal:
0a1,6 > Esta es una importante > noticia. Debera > por
lo tanto situarse al > comienzo de este > documento! >
8,14c14 < comprimir el tamao de los < cambios. < <
Este prrafo contiene < texto que est anticuado. < Ser
borrado en < breve. --- > comprimir nada. 17c17 < deternidamente este documento. Por --- > detenidamente
este documento. Por 24a25,28 > > Este prrafo contiene
> importantes nuevas adiciones > a este documento.

En este formato de salida tradicional, a sustituye a aadido, d a borrado (deleted) y c a cambiado. Los nmeros
de lnea del archivo original aparecen antes de a/d/c y los
del archivo modicado despus. Los parntesis angulares
aparecen al comienzo de las lneas que son aadidas, borradas o cambiadas. Las lneas aadidas se incluyen en el
archivo original para aparecer en el archivo nuevo. Las
lneas borradas se eliminan del archivo original para ser
borradas en el archivo nuevo.
Por defecto, las lneas comunes a los dos archivos no se
muestran. Las lneas que se han movido se muestran como aadidas en su nuevo lugar y como borradas en su
antiguo lugar.* [3]

60.5 Referencias
[1] MacKenzie et al. Binary Files and Forcing Text Comparisonin Comparing and Merging Files with GNU Di
and Patch. Descargado el 28 de abril de 2007.
[2] James W. Hunt and M. Douglas McIlroy (June 1976).
An Algorithm for Dierential File Comparison. Computing Science Technical Report, Bell Laboratories 41.
[3] David MacKenzie, Paul Eggert, and Richard Stallman
(1997). Comparing and Merging Files with GNU Di and
Patch. ISBN 0-9541617-5-0.
[4] E. Myers (1986). An O(ND) Dierence Algorithm and
Its Variations. Algorithmica 1 (2): 251266.
[5] Webb Miller and Eugene W. Myers (1985). A File Comparison Program. Software Practice and Experience 15
(11): 10251040. doi:10.1002/spe.4380151102.
[6] E. Ukkonen (1985). Algorithms for Approximate
String Matching. Information and Control 64: 100118.
doi:10.1016/S0019-9958(85)80046-2.

60.6 Vase tambin

Distancia de Levenshtein

60.7. ENLACES EXTERNOS

60.7 Enlaces externos

Sitio ocial (en ingls)

117

Captulo 61

Direccin de retorno
Direccin de retorno es un trmino de programacin
informtica con el que se reere a un dato almacenado
dentro de la pila, dato que le indica al programa en qu
lnea situarse luego de nalizar una funcin.

118

Captulo 62

Diseo estructurado
En programacin y diseo de algoritmos, el diseo estructurado persigue elaborar algoritmos que cumplan la
propiedad de modularidad, para ello, dado un problema
que se pretende resolver mediante la elaboracin de un
programa de ordenador, se busca dividir dicho programa
en mdulos siguiendo los principios de diseo de Descomposicin por renamientos sucesivos, creacin de
una Jerarqua modular y elaboracin de mdulos Independientes.

Ciencias de la Computacin Niklaus Wirth, que consiste precisamente en volver a aplicar el estudio descendente
Top-Down a cada subproblema una y otra vez hasta obtener subproblemas sucientemente pequeos, que puedan
ser resueltos por mdulos que cumplan, en la medida de
lo posible, las caractersticas deseables en un mdulo en
el mbito de la programacin. En palabras del propio Niklaus Wirth:
En cada paso (del renamiento), una o varias instrucciones del programa dado, se descomponen en
instrucciones ms detalladas. Esta descomposicin
sucesiva o renamiento de especicaciones termina
cuanto todas las instrucciones estn expresadas en
trminos de la computadora usada o del lenguaje de
programacin...

62.1 Etapas del Diseo estructurado

62.1.1

Descomposicin

Conforme se renan las tareas, tambin los datos

pueden ser renados, descompuestos o estructurados, siendo lo natural renar las especicaciones del
programa y de los datos en paralelo.

Para ello se requiere un adecuado anlisis de dicho problema, siendo necesario denir primeramente el problema, para lo cual deber de contener una detallada pero
concisa descripcin del mismo, un problema bien denido es aquel que lleva implcitas tanto una situacin inicial
como nal claras

Cada paso de renamiento implica algunas decisiones de diseo. Es importante que el programador sea
consciente de los criterios subyacentes (en las decisiones de diseo adoptadas) y de la existencia de
soluciones alternativas...

Por qu descomponer un problema en partes? Experimentalmente est comprobado que:

Un problema complejo cuesta ms de resolver que

Problema del renamiento sucesivo
otro ms sencillo (de Perogrullo).
La complejidad de un problema global es mayor que Cundo parar el renamiento?. Un renamiento excesiel valor de las complejidades de cada una de sus par- vo podra dar lugar a un nmero tan grande de mdulos
que hara poco prctica la descomposicin. Se tendrn en
tes por separado.
cuenta estos criterios para dejar de descomponer:
Segn esto, merece la pena el esfuerzo de dividir un problema grande en subproblemas ms pequeos. Si el objetivo es elaborar un programa para resolver dicho problema grande, cada subproblema (menos complejo) podr
ser resuelto por un mdulo (subalgoritmo) relativamente fcil de implementar (ms que el programa global No
dividido). Ahora la cuestin es cmo realizar la descomposicin?; realizando un estudio descendente Top-Down
que nos lleve desde la concepcin del problema (programa o algoritmo) global hasta identicar sus partes (mdulos). Esta tcnica se repite aplicando una estrategia llamada de renamiento sucesivo propuesta por el experto en

Cuando no haya tareas bien denidas.

Cuando la interfaz de un mdulo sea tan complicada
como el propio mdulo

62.1.2 Jerarqua de mdulos

sta es una consecuencia directa de la descomposicin
del problema mediante renamientos sucesivos, el resultado ser un conjunto de mdulos estraticados en capas a modo de pirmide donde en la cima habr un nico

119

120

CAPTULO 62. DISEO ESTRUCTURADO

mdulo que representar al programa global y en los niveles inferiores aparecern los mdulos resultantes de las
sucesivas divisiones.
Al nal, debe obtenerse una estructura piramidal donde
los mdulos de los niveles superiores se encargan de las
tareas de coordinacin, lgica de la aplicacin y manipulacin de los mdulos inferiores; estos otros debern
realizar tareas de clculo, tratamiento y entrada/salida de
informacin.

62.1.3

Independencia

Acoplamiento Comn.- Dos mdulos acceden a un

mismo recurso comn, tpicamente memoria compartida, una variable global o un chero. Una variante de este tipo de acoplamiento es el acoplamiento
externo:
Acoplamiento externo.- Los mdulos estn
ligados a componentes externos. Por ejemplo,
dispositivos de E/S, protocolos de comunicaciones... etc.
Acoplamiento de contenido.- Ocurre cuando un
mdulo necesita acceder a una parte de otro mdulo.

Ver 'Independencia en Caractersticas de un mdulo.

62.2.2 Cohesin
Se dene como la medida de fuerza o relacin funcional existente entre las sentencias o grupos de sentencias de un mismo mdulo. Un mdulo cohesionado
Para evaluar o determinar cmo es de bueno un diseo ejecutar una nica tarea sencilla interactuando muy poco
estructurado se utilizan los conceptos de acoplamiento o nada con el resto de mdulos del programa. Se persigue
y cohesin; stos estn muy relacionados entre s, tanto que los mdulos tengan una alta cohesin.
que difcilmente se puede variar uno sin que eso afecte
al otro. Tambin cabe decir que estos conceptos no son En el diseo estructurado podemos encontrarnos con los
medidas que se puedan cuanticar numricamente, son siguientes 7 tipos de cohesin (de la mejor o ms deseable
ms bien magnitudes cualitativas. Tambin se tienen en a la menos recomendable):
consideracin los conceptos de fan-in y fan-out.
Cohesin funcional: Los elementos del mdulo estn relacionados en el desarrollo de una nica fun62.2.1 Acoplamiento
cin.

62.2 Evaluando el diseo

Se dene como el grado de interdependencia que hay

entre los distintos mdulos de un programa; lo deseable es que esta interdependencia sea lo menor posible, es
decir, un bajo acoplamiento. Los niveles de acoplamiento, ordenados de menor (ms deseable) a mayor (menos
deseable) son:
Acoplamiento normal.- Un mdulo llama a otro de
un nivel inferior y tan solo intercambian datos (parmetros de entrada/salida). Dentro de este tipo de
acoplamiento podemos encontrarnos 3 subtipos, dependiendo de los datos que intercambien los mdulos:
Acoplamiento de datos: Los mdulos se comunican mediante parmetros.
Acoplamiento de marca o por estampado: Los
mdulos se pasan datos con estructura de registro. No es muy deseable si el mdulo receptor slo requiere parte de los datos que se le
pasan.
Acoplamiento de control: Los datos que se intercambian entre los mdulos son controles.
Debido a que en este subtipo un mdulo controla la ejecucin del otro, no es un buen acoplamiento, ya que impide que sean totalmente
independientes.

Cohesin secuencial: Un mdulo realiza distintas

tareas en secuencia, de forma que las entradas de
cada tarea son las salidas de la tarea anterior. No es
una mala cohesin si las tareas implicadas no son
muy complejas y requieren pocas lneas de cdigo.
Cohesin comunicacional: El mdulo realiza actividades paralelas usando los mismos datos de entrada y salida. Como en el caso anterior, tampoco
se trata de un mal tipo de cohesin si las tareas son
relativamente sencillas.
Cohesin procedimental: El mdulo tiene una serie de funciones relacionadas por un procedimiento
efectuado por el cdigo (a modo de biblioteca). Es
similar a la secuencial, pero puede incluir el paso de
controles. Ser deseable que las funciones estn relacionadas o realicen tareas dentro del mismo mbito
(p.e. la biblioteca string.h de C contienen funciones
para operar con cadenas de caracteres).
Cohesin temporal: Los elementos del mdulo estn implicados en actividades relacionadas con el
tiempo.
Cohesin lgica: Las actividades que realiza el mdulo tienen la misma categora. Esto es, es como si
se tuvieran partes independientes dentro del mismo
mdulo.

62.3. VASE TAMBIN

Cohesin casual o coincidente: Los elementos del
mdulo contribuyen a las actividades relacionndose
mutuamente de una manera poco signicativa. Este
tipo de cohesin viola el principio de independencia
y de caja negra de los mdulos.

62.2.3

Fan-In y Fan-Out

Adems de los dos conceptos anteriores, se deben tener en

cuenta el grado de absorcin (fan-in) y la diseminacin
del control (fan-out) de los mdulos para garantizar la
calidad del diseo.
Fan-In: Tambin llamado grado de absorcin. Es
el nmero de superordinados inmediatos que tiene
el mdulo en cuestin. Es conveniente maximizar el
fan-in durante el proceso de diseo, ya que cada instancia de fan-in mltiple indica que se ha evitado la
duplicacin de cdigo.
Fan-Out: Tambin llamado diseminacin del control. Es el nmero de subordinados inmediatos que
tiene el mdulo en cuestin. Conviene no tener un
fan-out ni muy alto ni muy bajo, ya que eso es un
posible indicador de un diseo pobre. Si no es posible evitarlo, es preferible un fan-out bajo antes que
uno alto.

62.3 Vase tambin

Diseo orientado a objetos
Programacin estructurada
Programacin modular
Dinmica de sistemas
Sistema complejo
Sistema dinmico
Encapsulamiento (programacin orientada a objetos)
Abstraccin (programacin orientada a objetos)

121

Captulo 63

Distancia de Damerau-Levenshtein
En la teora de la informacin y en la ciencia de computadores, se llama distancia de Damerau-Levenshtein o
distancia de edicin al nmero mnimo de operaciones
requeridas para transformar una cadena de caracteres en
otra. Se entiende por operacin, bien una insercin, eliminacin, sustitucin o transposicin de dos caracteres.
Lo que la distingue de la distancia de Levenshtein es que
esta ltima cuenta como una sola operacin de edicin a
cualquiera de las tres primeras, pero cuenta la transposicin como dos operaciones de edicin.

63.1 Vase tambin

Ispell

63.2 Enlaces externos

Implementacin en C++ de la distancia de
Damerau-Levenshtein como UDF para MySQL

63.3 Referencias

122

Captulo 64

Distancia de Levenshtein
La distancia de Levenshtein, distancia de edicin o
distancia entre palabras es el nmero mnimo de operaciones requeridas para transformar una cadena de caracteres en otra, se usa ampliamente en teora de la informacin y ciencias de la computacin. Se entiende por
operacin, bien una insercin, eliminacin o la sustitucin de un carcter. Esta distancia recibe ese nombre en
honor al cientco ruso Vladimir Levenshtein, quien se
ocup de esta distancia en 1965. Es til en programas que
determinan cun similares son dos cadenas de caracteres,
como es el caso de los correctores de ortografa.

lenStr2+1 columns declare int d[0..lenStr1, 0..lenStr2]

// i and j are used to iterate over str1 and str2 declare int
i, j, cost for i from 0 to lenStr1 d[i, 0] := i for j from 0
to lenStr2 d[0, j] := j for i from 1 to lenStr1 for j from
1 to lenStr2 if str1[i] = str2[j] then cost := 0 else cost :=
1 d[i, j] := minimum( d[i-1, j] + 1, // deletion d[i, j-1]
+ 1, // insertion d[i-1, j-1] + cost // substitution ) return
d[lenStr1, lenStr2]

El invariante mantenido a travs del algortmo es que pueda transformar el segmento inicial str1[1..i] en str2[1..j]
empleando un mnimo de d[i,j] operaciones. Al nal, el
Por ejemplo, la distancia de Levenshtein entre casay elemento ubicado en la parte INFERIOR derecha de la
callees de 3 porque se necesitan al menos tres ediciones matriz contiene la respuesta.
elementales para cambiar uno en el otro.
1. casa cala (sustitucin de 's' por 'l')

64.2 Implementacin

2. cala calla (insercin de 'l' entre 'l' y 'a')

A continuacin se puede ver la implementacin de la funcin para varios lenguajes de programacin. Otros lenSe le considera una generalizacin de la distancia de guajes de ms alto nvel, 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 operacin la sustitucin. Hay implementarla para ser usada.
otras generalizaciones de la distancia de Levenshtein, como la distancia de Damerau-Levenshtein, que consideran
el intercambio de dos caracteres como una operacin.
64.2.1 C
3. calla calle (sustitucin de 'a' por 'e')

Como buenadistancia, cumple (aunque es complicado

int
Levenshtein(char
*s1,char
*s2)
{
int
demostrarlo formalmente), que:
t1,t2,i,j,*m,costo,res,ancho; // Calcula tamanios
Dist(A,B) == Dist(B,A)
strings t1=strlen(s1); t2=strlen(s2); // Verica
que exista algo que comparar if (t1==0) reDist(A,B) + Dist(B,C) >= Dist(A,C)
turn(t2); if (t2==0) return(t1); ancho=t1+1; // Reserva matriz con malloc m[i,j] = m[j*ancho+i]
!!
m=(int*)malloc(sizeof(int)*(t1+1)*(t2+1));
if
64.1 El algoritmo
(m==NULL) return(1); // ERROR!! // Rellena primera la y primera columna for (i=0;i<=t1;i++) m[i]=i;
Se trata de un algoritmo de tipo bottom-up, comn en for (j=0;j<=t2;j++) m[j*ancho]=j; // Recorremos resto
programacin dinmica. 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 pseudocdigo costo=1; m[j*ancho+i]=Minimo(Minimo(m[j*ancho+ipara una funcin 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 // Devoly 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

64.2.2

CAPTULO 64. DISTANCIA DE LEVENSHTEIN

C++

#include <string> #include <vector> #include <algorithm> using namespace std; int levenshtein(const string
&s1, const string &s2) { int N1 = [Link](); int N2 =
[Link](); int i, j; vector<int> T(N2+1); for ( i = 0; i <=
N2; i++ ) T[i] = i; for ( i = 0; i < N1; i++ ) { T[0] = i+1;
int corner = i; for ( j = 0; j < N2; j++ ) { int upper =
T[j+1]; if ( s1[i] == s2[j] ) T[j+1] = corner; else T[j+1]
= min(T[j], min(upper, corner)) + 1; corner = upper; } }
return T[N2]; }

64.2.5 Perl

sub fastdistance { my $word1 = shift; my $word2 = shift;

return 0 if $word1 eq $word2; my @d; my $len1 = length
$word1; my $len2 = length $word2; $d[0][0] = 0; for
(1.. $len1) { $d[$_][0] = $_; return $_ if $_!=$len1
&& substr($word1,$_) eq substr($word2,$_); } for (1..
$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][$_1]+1, $d[$i-1][$_-1]+($w1 eq substr($word2,$_-1,1) ? 0
64.2.3 C#
: 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]; // Verica 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 rani++) ; 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 ranmatriz 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 disporcentaje = ((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]
= i end (0..[Link]).each do |j| distance[0][j] = j end
return d[m, n]; }
(1..[Link]).each do |i| (1..[Link]).each do |j| distance[i][j] = [distance[i - 1][j] + 1, distance[i][j - 1] + 1,
distance[i - 1][j - 1] + ((self[i - 1] == other[j - 1]) ? 0
: 1)].min end end distance[[Link]][[Link]] end end
64.2.4 Java
puts [Link] calle#=> 3
Implementado como una clase esttica.
public class LevenshteinDistance { private static int
minimum(int a, int b, int c) { if(a<=b && a<=c) { return
a; } if(b<=a && b<=c) { return b; } return c; } public static int computeLevenshteinDistance(String
str1, String str2) { return computeLevenshteinDistance([Link](),
[Link]());
} private static int computeLevenshteinDistance(char [] str1, char [] str2) { int [][]distance
= new int[[Link]+1][[Link]+1]; for(int
i=0;i<=[Link];i++) { distance[i][0]=i; } for(int
j=0;j<=[Link];j++) { distance[0][j]=j; } for(int
i=1;i<=[Link];i++) { for(int j=1;j<=[Link];j++)
{ distance[i][j]= minimum(distance[i-1][j]+1, distance[i][j-1]+1, distance[i-1][j-1]+ ((str1[i-1]==str2[j1])?0:1)); } } return distance[[Link]][[Link]]; }
}

64.2.8 PHP
<?php $lev = levenshtein($input, $word); ?>

64.2.9 Delphi
function LevenshteinDistance(Str1, Str2: String): Integer; var d : array of array of Integer; Len1, Len2
: Integer; i,j,cost:Integer; begin Len1:=Length(Str1);
Len2:=Length(Str2); SetLength(d,Len1+1); for i :=
Low(d) to High(d) do SetLength(d[i],Len2+1); for i := 0
to Len1 do d[i,0]:=i; for j := 0 to Len2 do d[0,j]:=j; for i:=
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

125

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

s2 As String) As Integer Dim coste As Integer = 0
Dim n1 As Integer = [Link] Dim n2 As Integer =
[Link] Dim m As Integer(,) = New Integer(n1, n2)
{} For i As Integer = 0 To n1 m(i, 0) = i Next For i As
Integer = 1 To n2 m(0, i) = i Next For i1 As Integer = 1
To n1 For i2 As Integer = 1 To n2 coste = If((s1(i1 - 1) =
s2(i2 - 1)), 0, 1) m(i1, i2) = [Link]([Link](m(i1
- 1, i2) + 1, m(i1, i2 - 1) + 1), m(i1 - 1, i2 - 1) + coste)
Next Next Return m(n1, n2) End Function

64.2.11

ActionScript 3.0

public class StringUtils { public static function

levenshtein(s1:String, s2:String):int { if ([Link]
== 0 || [Link] == 0) return 0; var m:uint = [Link]
+ 1; var n:uint = [Link] + 1; var i:uint, j:uint,
cost:uint; var d:Vector.<Vector.<int>> = new Vector.<Vector.<int>>(); for (i = 0; i < m; i++) { d[i] =
new Vector.<int>(); for (j = 0; j < n; j++) d[i][j] = 0;
} 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 <
n; j++) { cost = ([Link](i - 1) == [Link](j - 1)) ?
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]; } }

64.3 Aplicaciones
El proyecto ASJP usa la distancia de Levenshtein
total en una lista de palabras en diferentes lenguas
del mundo, para medir la similaridado cercanade las mismas, esa distancia calculada puede
emplearse para proponer una clasicacin logentica tentativa de las lenguas del mundo.* [1]
La distancia de Damerau-Levenshtein es una generalizacin de la distancia de Levenshtein usada
por los correctores ortogrcos y en la deteccin de
fraudes en listas de datos.

64.4 Vase tambin

Distancia de Damerau-Levenshtein
Algoritmo Needleman-Wunsch
Algoritmo Smith-Waterman
Algoritmo Bitap
Autmata de Levenshtein
Espacio mtrico
Agrep

64.2.12 ColdFusion
<cfscript> function levDistance(s,t) { var d = ArrayNew(2); var i = 1; var j = 1; var s_i = A"; var t_j =
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
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,j1,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[i1][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 Buer((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]

Ratcli/Obershelp
Dynamic time warping
Distancia de Jaro-Winkler

64.5 Referencias
[1] ASJP - World Language Tree

Captulo 65

DLO
La expresin DLO (Document Like Object) est ampliamente reconocida en la literatura sobre metadatos para
aludir a los documentos de Internet (texto, imagen, audio, video, etc.) y se utiliza para referirse a una unidad
documental o al documento digital mnimo, que forma parte de una coleccin digital, al cual se le aplican
metadatos para su descripcin y recuperacin.
El acrnimo 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 empez a utilizarse para diferenciar nociones individuales que
constituyen un objeto discreto, digno de una descripcin
individual a travs de metadatos.
En el tercer taller que se realiz se ampli su signicado
para referirse a cualquier recurso de informacin especco que se caracterizase por ser estable (es decir,
que tena un contenido idntico para cada usuario).

65.1 Enlaces externos

Glosario web y proyecto de investigacin de efectividad
de metadatos
Pgina ocial de Dublin Core

126

Captulo 66

Driver Chain Manager

Driver Chain Manager (DCM) es una tecnologa de 66.1.2 Capacidades de DCM
Microsoft que facilita instalar y trabajar con mltiples
1. Cuando mltiples drivers estn instalados y solo se
tecnologas de asistencia que utilizan la interfaz del driest ejecutando uno, los dems no interferirn en sver de la pantalla (Display Driver Interface o DDI) en un
ta independientemente de su posicin.
mismo equipo.
DCM permite a un programa tener conocimiento de la
existencia de las otras aplicaciones de asistencia. Permite evitar que se produzcan problemas entre ellas., como
fallos, mal funcionamiento, que se corrompan o incluso
que no funcionen.

2. Un usuario puede instalar o desinstalar un driver en

cualquier momento sin afectar a los dems.

La tecnologa DCM viene instalada en Windows. La

biblioteca se actualiza cuando se actualizan las ayudas.
Un programador puede utilizar DCM en sus aplicaciones
programando desde Microsoft Visual Studio empleando
la biblioteca MSDN.

4. Todos los drivers de la cadena usarn el mismo cdigo de escape para controlar la comunicacin entre
los usuarios y los controladores.

3. Existen aplicaciones de control remoto que tambin

se basan en este encadenamiento.

5. En caso de que se cambie el adaptador de la pantalla

se detectar si el ajuste de la cadena puede llevarse
a cabo.
6. Los drivers instalados no interferirn con los nuevos.

66.1 Qu hace?
DCM es un conjunto de rutinas de la biblioteca MSDN
usada por la tecnologa de asistencia de Windows. Permite la instalacin, desinstalacin y mantenimiento de interceptadores del driver grco.

66.1.3 Cuestiones fuera del alcance de

DCM
1. DCM no garantiza que 2 drivers se puedan ejecutar al mismo tiempo. Esto queda en manos de los
desarrolladores de stos.

Las aplicaciones de asistencia utilizan stas rutinas para

saber en que posicin de la cadena de drivers deben colocar el suyo, de manera que no intereran con las dems
aplicaciones y stas con ella

66.1.1

2. Para los vendedores que soportan DCM, Los drivers instalados pueden permanecer despus de los
que usan DCM. Sin embargo DCM no tendr conocimiento de ellos.
3. Puede haber otros driver que no usen DCM, pero
DCM no tendr conocimiento de ellos.

Objetivos

4. DCM no soporta usuarios con mltiples monitores.

1. Proporcionar suciente informacin sobre los objetos en la pantalla.

66.2 Sotrware que utiliza DCM

2. Asegurarse de que otras aplicaciones de asistencia
instaladas en el sistema no intereran con las que ya
66.2.1
se estn ejecutando.

Aplicaciones que utilizan DCM

Las siguientes aplicaciones ya utilizan esta tecnologa.

3. Asegurarse de que varias aplicaciones de asistencia
pueden ejecutarse simultneamente.
127

Dolphin Computer Access:

128

CAPTULO 66. DRIVER CHAIN MANAGER

Hal 5.20 y superior,
Lunar 5.20 y superior,
Lunar Plus 5.20 y superior,
Supernova 5.20 y superior.

Freedom Scientic:
JAWS 4.51 y superior,
Magic 8.1 y superior.
GW Micro:
Window-Eyes 4.21 y superior.
Ai Squared:

haya eliminado la informacin que el segundo necesita,

imposibilitando su funcionamiento.
Actualmente no existe ninguna regla que diga en que orden se ejecutan los controladores, eso sin tener en cuenta
que puede haber ms de un lector o magnicador instalados en la misma mquina. En caso de haber 2 magnicadores surgira el problema de cual magnca la pantalla o
si se ampla 2 veces consecutivas (ampliacin de la ampliacin).
Adems las dos aplicaciones no tienen conocimiento una
de la otra, por lo que no pueden solucionar el problema.
El problema se agrava si son software de diferentes compaas.

Otro problema se crea al desinstalar uno de los drivers,

ZoomText 7,11 con el programa de utilidad pudindose producir que se rompa la cadena y por ello
que se pierda el controlador nal.
del driver.
ZoomText 8.0 o superior (DCM built-in).

66.3.2 Forma de solucionarlo

66.2.2

Empresas desarrolladoras

66.2.3

Sistemas operativos que soportan 66.4

DCM

DCM aporta a los desarrolladores de estas aplicaciones

DCM es el resultado de un esfuerzo comn de Microsoft una aplicacin llamadaDCMUtilque les permite may de las empresas asociadas Ai Squared, Dolphin Com- nejar el orden de los drivers y ajustarlos para un correcto
funcionamiento.
puter Access, GW Micro, y Freedom Scientic.

DCM 1.0 es compatible con Windows NT versin 4,

Windows 2000 y Windows XP.

66.3 Funcionamiento de la cadena

de drivers

Otras aplicaciones que utilizan DCM

Existen otras aplicaciones, de distintas tipologas, 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.5 Vase tambin

El sistema operativo Windows permite instalar una cadena de drivers para la generacin de la imagen de la pantalla. El primer driver obtendr la informacin de las aplicaciones y se la pasar al siguiente driver y as sucesivamente con el resto de los drivers, esta cadena acabar en
el driver de la tarjeta grca. Al colocar otros drivers lo
que se pretende es capturar y/o modicar la informacin.
Por ejemplo, un lector de pantalla no modicar la informacin que reciba, pero capturar los datos necesarios
que requiera para poder leer por el altavoz. Por el contrario un magnicador de pantalla recortar un rectngulo
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 aleatorio. Algunas aplicaciones deben ejecutar sus rutinas antes que otras. Por ejemplo, si ejecutamos el magnicador
antes que un lector de pantalla, es posible que el primero

Tiotecnologa.
Windows.
MSDN.

66.6 Fuentes y referencias

1. biblioteca MSDN: DCM (en ingls).

Captulo 67

Dublin Core
Dublin Core es un modelo de metadatos elaborado y auspiciado por la DCMI (Dublin Core Metadata Initiative),
una organizacin dedicada a fomentar la adopcin extensa de los estndares interoperables de los metadatos y a
promover el desarrollo de los vocabularios especializados
de metadatos para describir recursos para permitir sistemas ms inteligentes el descubrimiento del recurso.

Elementos relacionados principalmente con el contenido del recurso.

Elementos relacionados principalmente con el recurso cuando es visto como una propiedad intelectual.

Elementos relacionados principalmente con la instanciacin del recurso.

Las implementaciones de Dublin Core usan generalmente
XML y se basan en el Resource Description Framework.
Dublin Core se dene por ISO en su norma ISO 15836 Dentro de cada clasicacin encontramos los siguientes
del ao 2003, y la norma NISO Z39.85-2007.
elementos:
El nombre viene por Dublin, Ohio, Estados Unidos, ciu- Contenido:
dad que en 1995 alberg la primera reunin a nivel mundial de muchos de los especialistas en metadatos y Web
Ttulo: el nombre dado a un recurso, habitualmente
de la poca.
por el autor.
Etiqueta: [Link]

67.1 Descripcin general

Dublin Core es un sistema de 15 deniciones semnticas descriptivas que pretenden transmitir un signicado
semntico a las mismas.
Estas deniciones:
Son opcionales

Claves: los temas del recurso. Tpicamente, Subject

expresar las claves o frases que describen el ttulo o
el contenido del recurso. Se fomentar el uso de vocabularios controlados y de sistemas de clasicacin
formales.
Etiqueta: [Link]

Se pueden repetir
Pueden aparecer en cualquier orden
Este sistema de deniciones fue diseado especcamente para proporcionar un vocabulario de caractersticas
base, capaces de proporcionar la informacin descriptiva bsica sobre cualquier recurso, sin que importe el formato de origen, el rea de especializacin o el origen cultural.

67.2 Clasicacin y elementos

Descripcin: una descripcin textual del recurso.

Puede ser un resumen en el caso de un documento o una descripcin del contenido en el caso de un
documento visual.
Etiqueta: [Link]
Fuente: secuencia de caracteres usados para identicar unvocamente un trabajo a partir del cual proviene el recurso actual.
Etiqueta: [Link]

En general, podemos clasicar estos elementos en tres

grupos que indican la clase o el mbito de la informacin
que se guarda en ellos:
129

Tipo del Recurso: la categora del recurso. Por

ejemplo, pgina personal, romance, poema, diccionario, etc.

130

CAPTULO 67. DUBLIN CORE

Etiqueta: [Link]

Relacin: es un identicador de un segundo recurso y su relacin con el recurso actual. Este elemento
permite enlazar los recursos relacionados y las descripciones de los recursos.
Etiqueta: [Link]
Cobertura: es la caracterstica de cobertura espacial y/o temporal del contenido intelectual del recurso.
La cobertura espacial se reere a una regin fsica, utilizando por ejemplo coordenadas.
La cobertura temporal se reere al contenido
del recurso, no a cundo fue creado (que ya lo
encontramos en el elemento Date).
Etiqueta: [Link]
Propiedad Intelectual:
Autor o Creador: la persona u organizacin responsable de la creacin del contenido intelectual del
recurso. Por ejemplo, los autores en el caso de documentos escritos; artistas, fotgrafos e ilustradores
en el caso de recursos visuales.
Etiqueta: [Link]
Editor: la entidad responsable de hacer que el recurso se encuentre disponible en la red en su formato actual.

Fecha: una fecha en la cual el recurso se puso a disposicin del usuario en su forma actual. Esta fecha
no se tiene que confundir con la que pertenece al
elemento Coverage, que estara asociada con el recurso en la medida que el contenido intelectual est
de alguna manera relacionado con aquella fecha.
Etiqueta: [Link]
Formato: es el formato de datos de un recurso, usado para identicar el software y, posiblemente, el
hardware que se necesitara para mostrar el recurso.
Etiqueta: [Link]
Identicador del Recurso: secuencia de caracteres
utilizados para identicar unvocamente un recurso.
Ejemplos para recursos en lnea pueden ser URLs
y URNs. Para otros recursos pueden ser usados
otros formatos de identicadores, como por ejemplo ISBN (International Standard Book Number
).
Etiqueta: [Link]
Lengua: lengua/s del contenido intelectual del recurso.
Etiqueta: [Link]

67.3 Usos

Cualquier persona puede utilizar los metadatos de Dublin

Core para describir los recursos de un sistema de inforEtiqueta: [Link]
macin. Las pginas Web son uno de los tipos ms comunes de recursos que utilizan las descripciones de Dublin
Otros Colaboradores: una persona u organizacin Core.
que haya tenido una contribucin intelectual signicativa, pero que esta sea secundaria en comparacin Los metadatos de Dublin Core estn siendo utilizados cocon las de las personas u organizaciones especi- mo la base para los sistemas descriptivos para varios grucadas en el elemento Creator. (por ejemplo: editor, pos de inters como por ejemplo:
ilustrador y traductor).
Organizaciones educativas
Etiqueta: [Link]
Bibliotecas
Derechos: son una referencia (por ejemplo, una
URL) para una nota sobre derechos de autor, para
un servicio de gestin de derechos o para un servicio
que dar informacin sobre trminos y condiciones
de acceso a un recurso.
Etiqueta: [Link]
Instanciacin:

Instituciones del gobierno.

Sector cientco de la investigacin.
Autores de pginas Web.
Negocios que requieren lugares ms investigables.
Corporaciones con sistemas de gerencia extensos en
conocimiento

67.5. ENLACES EXTERNOS

67.4 Ventajas
La simplicidad
La exibilidad
La independencia sintctica
La interoperabilidad semntica
Alto nivel de normalizacin formal
Crecimiento y evolucin del estndar a travs de una
institucin formal consorciada: la DCMI.
Consenso internacional
Modularidad de Metadatos en la Web
Arquitectura de Metadatos para la Web

67.5 Enlaces externos

Pgina web ocial (en ingls)

SEDIC
y documentos XML/RDF para Recuperacin

131

Captulo 68

eAthena
eAthena es emulador de cdigo abierto de Ragnarok Online. Est escrito en C, aunque se est trabajando en una
versin en C++ llamada eApp(eA++). eAthena soporta
Linux 32bit y 64bit y Win32/64, aunque se recomienda
el uso de Linux para su mejor desempeo y seguridad.
eAthena est bajo licencia GPL. eAthena posee 2 versiones, TXT y SQL. Como sus nombres lo dicen SQL trabaja con bases de datos MySQL mientras que txt trabaja
con archivos de texto. Se recomienda utilizar SQL para un mejor desempeo. Est actualizado segn 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 modicables y no son el juego en si, es solo una emulacin a
diferencia de los servidores basados en el mismo cdigo de Ragnarok Online que son ilegales ya que violan los
Derechos de autor que impone Gravity Corp..
Algunos de los servidores ms 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 ociales y que Gravity Corp, solamente exime a
Gravity de toda responsabilidad por ello, incluido su servidor gratuito de prueba.

68.1 Enlaces externos

Foro ocial de eAthena
Foro ocial de Soporte en Espaol de eAthena
Repositorio SVN ocial de eAthena

132

Captulo 69

Efecto Hover
El efecto Hover consiste en la alteracin del aspecto de
un elemento de la interfaz grca* [1] cuando se sita
el puntero sobre el mismo, pero no se ha seleccionado
an.* [2]

69.1 Referencias
[1] Ejemplo de efecto Hover sobre un enlace.
[2] Blog de Andrs Nieto

69.2 Enlaces de inters

Efecto Hover segn W3C. (en ingls)
Programacin de efecto Hover en JavaScript.
Ms ejemplos de programacin.
Efecto Hover en Microsoft.
Efecto Hover en Developing Webs dot Net (en ingls)
Tutorial de Efecto Hover en Texto

133

Captulo 70

Emtp
EMTP es un programa de computadora destinado al an- sistema simulado.
lisis de circuitos elctricos, especialmente en rgimen
transitorio. El programa permite modelar matemticamente sistemas elctricos, mecnicos y de control, mo- 70.4 Distribucin de EMTP-ATP
nofsicos y polifsicos. Su nombre proviene del acrnimo
ingls ElectroMagnetic Transients Program.
El ATP se distribuye por medio de los grupos de usuarios
existentes en varias regiones del mundo. Cualquier persona 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 aos nales de la dcada de
Canadian/American EMTP User Group
1960 por Hermann W. Dommel. Aos ms tarde l cede European EMTP-ATP Users Group Assoc.
ra los derechos de autor sobre el programa a la Bonneville
(EEUG)
Power Administration (BPA) de los Estados Unidos.
Japanese ATP User Group (JAUG)
Latin American EMTP User Group (CAUE)

70.2 ATP

Argentinian EMTP User Group (CAUE)

El programa ATP, Alternative Transients Program surge
del ao 1984 cuando los Drs. W. Scott Meyer y Tsu-huei
Liu no aprobaron la comercializacin del EMTP por parte
de DCG (EMTP Development Coordination Group de la
BPA) y EPRI (Electric Power Research Institute). Los Drs.
Meyer y Liu empezaron el desarrollo del ATP como una
alternativa no comercializada del EMTP, pero basado en
una copia de ste colocada en el dominio pblico.

Australian EMTP User Group (AEUG)

Korean EMTP User Group
Republic of China EMTP User Group
Indian EMTP User Group
South African ATP User Group

Aunque el programa puede ser adquirido sin costo, ATP

no es del dominio pblico, se requiere una licencia antes 70.5 Enlaces externos
que los materiales puedan ser recibidos por el interesado. Los requerimientos para usar el ATP son honestidad
en su manejo y el compromiso de no participacin en la Pgina principal de EMTP-ATP con historia e informacomercializacin de EMTP o de otros programas de si- cin de contacto de los grupos de usuarios
mulacin de transitorios.* [1]
Grupo de usuarios de EMPT-ATP de Europa
En trminos generales, el programa es el mismo y suele
mencionarse como EMTP, ATP o bien EMTP-ATP.

70.3 Mtodo de solucin

SIMULACIN DE SISTEMAS ELCTRICOS

CON ATP-EMTP APLICACIONES

70.6 Referencias

El programa EMTP-ATP utiliza el mtodo de integracin

trapezoidal para resolver las ecuaciones diferenciales del
134

[1] Historia y licencia del programa ATP

Captulo 71

Enlace dinmico
Un enlace dinmico es aquel en el cual una biblioteca de
cdigo es enlazada cuando un determinado programa se
ejecuta (en oposicin a un enlace esttico, que se produce en tiempo de compilacin). La ventaja de este tipo de
enlace es que el programa es ms liviano, y que evita la
duplicacin de cdigo (por ejemplo, cuando dos programas requieren usar la misma biblioteca, se necesita slo
una copia de sta).
Las bibliotecas de enlace dinmico, o bibliotecas compartidas, suelen encontrarse en directorios especcos del
sistema operativo, de forma que, cada vez que un programa necesite usar alguna, el sistema operativo conozca el
lugar en el que se encuentra, para as poder enlazarla. Esto
ocasiona algunos problemas de dependencias, principalmente 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 dinmico, despus del ensamblaje, podemos enlazar cada procedimiento en el momento en que es llamado.

135

Captulo 72

Enlace esttico
Una biblioteca esttica es aquella que se enlaza en tiempo
de compilacin (en oposicin a una de enlace dinmico,
que se enlaza en tiempo de ejecucin). 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 ms fcil su distribucin.
El enlazado permite al programador y al propio sistema
operativo dividir un programa en varios archivos llamados mdulos, que pueden ensamblarse por separado y enlazarse en una ocasin posterior, el enlace puede ser de
naturaleza esttica o dinmica. El enlace esttico da como
resultado, un archivo ejecutable con todos los smbolos y
mdulos respecti