Lenguajes Algoritmicos

LENGUAJES ALGORITMICOS
ÍNDICE
1. - Introducción y conceptos 11. – Introducción a la
básicos. ................................................ 8 Programación Orientada al
1.1. - Lenguaje................................................ 8 Objeto. ...............................................205
1.2. - Programación. ...................................... 8 11.1. – Introducción. ...................................205
1.3. - Programa. ............................................. 8 11.2. – Vocabulario OOPS..........................206
1.4. - Lenguaje de programación. .................. 9 11.3. – Conceptos básicos. ..........................206
1.4.1. Lenguaje Máquina................................ 9 11.4. – Clarificando conceptos. ..................208
1.4.10. – Semántica. ..................................... 12 11.4.1. - ¿ Qué es una clase ? .....................208
1.4.2. Lenguajes de Alto Nivel........................ 9 11.4.2. - ¿ Qué es un objeto ? .....................209
1.4.3. – Traductores. ...................................... 9 11.4.3.- El concepto de herencia.................209
1.4.3.1. – Intérpretes. ...................................... 9 11.4.4.- El concepto de jerarquía................209
1.4.3.2. – Compiladores. ................................ 9 11.5. – Conclusiones. ..................................210
1.4.4. – Palabras reservadas........................ 10 11.5.1. – Lo mejor. ......................................210
1.4.5. – Código. ............................................ 10 11.5.2. – Lo peor. ........................................210
1.4.5.1. - Código fuente............................... 10 11.5.3. – Posibles soluciones. .....................210
1.4.5.2. – Código objeto. .............................. 10
1.4.5.3. – Código ejecutable. ........................ 10 12. - Introducción a la
1.4.6. – Compilación. ................................... 10 Programación dirigida por
1.4.7. – Enlazado.......................................... 11
1.4.8. – Librerías. ......................................... 11 eventos. .............................................211
1.4.8.1. – Librerías preenlazadas. ................. 11 13. - Documentación de
1.4.9. – Sintaxis. ........................................... 11
1.5. - Sistema informático o aplicación........ 12 programas......................................215
1.6. - Programador....................................... 12 13.1.- Manual del Sistema...........................215
1.7. - Técnicas de programación.................. 12 13.2. - Manual del programa. .....................216
1.8. - Usuario. .............................................. 12 13.3. - Manual del usuario. .........................216
10. – Introducción a la 2. - Tipos y estructuras
Programación Dirigida por básicas de datos. ........................13
2.1. - Dato. ....................................................13
los Datos......................................... 197 2.2. - Tipos de datos. .....................................13
10.1. – Programación Código-Fijo (Hard- 2.2.1. - Datos numéricos. ..............................13
Code). ..................................................... 197 2.2.2. - Datos tipo carácter. ..........................13
10.2. – Programación Dirigida por los Datos 2.2.3. - Datos alfanuméricos, de cadena o
(Data-Driven). ........................................ 198 string. ........................................................14
10.3. – Diccionario de datos. ..................... 202 2.2.4. - Datos lógicos (booleanos). ...............14
10.4. – Programación de plantillas............ 202 2.3. - Constantes, variables y funciones........14
10.4.1. - ¿ Qué es una plantilla ? ............... 202 2.4. - Expresiones. .........................................14
10.4.2. – Ventajas de una plantilla............. 203 2.4.1. - Expresiones aritméticas. ...................15
10.4.3. – Cuando utilizar una plantilla. ..... 203 2.4.2. - Expresiones alfanuméricas. ..............16
10.4.4. – Generadores de Código............... 203
Realizó: Ing. Domingo Olivares Barrios Pág. 1

2.4.3. - Expresiones lógicas (booleanas)...... 16 5.3.4. - Estructura de " para hasta ". ............51
2.4.3.1. - Operadores de relación.................. 16 5.3.5. - Estructura de " hacer mientras ". .....53
2.4.3.2. - Operadores lógicos........................ 17 5.3.6. - Estructura de " hacer hasta ". (repetir
2.4.4. – Reglas globales de prioridad o hasta).........................................................54
precedencia. ............................................. 18 6. - Herramientas de
2.5. - Arreglos (arrays)................................. 18
2.5.1. - Arreglos unidimensionales............... 18 programación. ..............................56
2.5.2. - Arreglos bidimensionales................. 19 6.1. - El contador. .........................................56
2.5.3. - Arreglos multidimensionales. .......... 19 6.2. - El acumulador o sumador....................56
6.3. - La bandera o indicador. ......................57
3. - Técnicas de 6.4. - Salida de un programa por opción. .....58
Programación. ............................ 20 6.5. - Salida de un programa por centinela. .59
3.1. - Importancia......................................... 20 6.6. – Subrutinas, procedimientos y funciones.
3.2. - Objetivo............................................... 20 ...................................................................59
3.3. - Estilos de programación. .................... 20 6.6.1.- Subrutinas. .........................................59
3.4. La Notación Húngara y otras 6.6.2.- Procedimientos...................................63
convenciones. ........................................... 21 6.6.3.- Funciones. ..........................................63
6.6.3.1.- Funciones Implícitas. ......................64
4. - Técnica de diseño general 6.6.3.2.- Funciones de Usuario......................64
o elemental. ................................... 27 6.6.4.- Parámetros en procedimientos y
4.1. - Fases de resolución de problemas. ..... 27 funciones. ..................................................64
4.2. - Simbología de diagramas de bloques o 6.6.4.1.- Parámetros por valor. ......................64
diagramas de flujo de sistemas. ............... 33 6.6.4.2.- Parámetros por referencia (por
4.3. - Simbología de diagramas de flujo. ..... 34 variable).....................................................66
4.4. - Recomendaciones para el desarrollo de 6.6.5.- Variables en procedimientos y
diagramas................................................. 35 funciones. ..................................................67
4.4.1. - Diagramas de bloques o diagramas de 6.6.5.1.- Variables Globales. .........................67
flujo de sistemas. ...................................... 35 6.6.5.2.- Variables Locales............................67
4.4.2. - Diagramas de flujo. ......................... 35 6.6.5.3.- Reglas de ámbito.............................67
4.5. - Resolución de problemas aplicando la 6.6.5.4.- Efectos laterales. .............................69
Técnica de diseño general o elemental. ... 36 6.6.6.- Recursividad. .....................................71
6.7. - Encadenamiento de programas. ..........74
5. - Diagramas de flujo. ........... 48
5.1. - Tipos de diagramas de flujo................ 48 7. - Técnica de diseño
5.1.1. - Diagramas de flujo lineales. ............ 48 modular. ............................................75
5.1.2. - Diagramas de flujo cíclicos. ............ 48
7.1. - Fases de resolución de problemas.......75
5.2. - Estructuras de diagramas de flujo
7.2. - Estructuras jerárquicas o en árbol. .....75
lineales. .................................................... 48
7.3. - Resolución de problemas aplicando la
5.2.1. - Estructura de secuencia. .................. 48
Técnica de diseño modular........................78
5.2.2. - Estructura de decisión. .................... 49
5.2.3. - Ramificaciones. ................................ 49 8. - Técnica de diseño
5.3. - Estructuras de diagramas de flujo descendente. .................................100
cíclicos...................................................... 50 8.1. - Fases de resolución de problemas.....100
5.3.1. - Creación de ciclos, iteraciones o 8.2. - Resolución de problemas aplicando la
bucles........................................................ 50 Técnica de diseño descendente. ..............102
5.3.2. - Pasos de un ciclo o bucle................. 50
5.3.3. - Ciclos o bucles anidados. ................ 51

9. – Introducción a la 9.4.2. – Gestión de archivos directos. .........159
9.4.3. – Gestión de archivos indexados.......174
programación para gestión 9.4.4. – Gestión de una base de datos
de archivos. .................................. 117 relacional constituida por dos archivos..190
9.1. - Conceptos básicos............................. 117 APENDICE A.............................222
9.1.1. - Archivo. .......................................... 117
9.1.2. - Campo. ........................................... 117 APENDICE B.............................225
9.1.3. - Registro. ......................................... 117
9.1.4. - Base de datos. ................................ 118
APENDICE C.............................227
9.2. - Tipos de Archivos y accesos.............. 119 BIBLIOGRAFIA.....................252
9.2.1. - Archivos secuenciales .................... 119 IMPRESIÓN DE UNA LISTA
9.2.2. - Archivos directos............................ 119
ENLAZADA ........................................237
9.2.3. – Archivos indexados........................ 119
9.2.4. – Otros tipos de archivos. ................ 120 INSERCIÓN EN UNA LISTA
9.3. – Bases de datos. ................................. 120 ENLAZADA. .......................................238
9.3.1. - ¿ Qué es un SGBD ? ...................... 120 LIBRERIAS ...........................................222
9.3.2. – La independencia de los datos. ..... 121 OBJETIVOS. ..........................................7
9.3.3. – Lenguajes y Bases de Datos. ......... 122 PILAS, COLAS, COLAS DOBLES,
9.3.4. – Los tres enfoques. .......................... 122
9.3.4.1. – Enfoque jerárquico. .................... 122
ÁRBOLES BINARIOS. .................246
9.3.4.2. – Enfoque de red (Codasyl). .......... 124 PREFACIO......................................................5
9.3.4.3. – Enfoque relacional...................... 125 PROGRAMACION SEGMENTADA
9.3.5. – Diseño de Bases de Datos. ............ 127 .................................................................225
9.3.6. – El modelo Entidad-Relación.. ....... 128 PRÓLOGO ......................................................4
9.3.7. – Normalización. .............................. 131 PUNTEROS Y LISTAS
9.3.7.1. – Formas normales. ....................... 132 ENLAZADAS. ...................................229
9.3.8. – Índices y ordenaciones. ................. 135 S O L U C I O N E S ...................................218
9.3.9. – Lenguajes de cuarta generación (4GL). SUPRESIÓN EN UNA LISTA
................................................................ 137 ENLAZADA ........................................242
9.4. – Gestión de archivos de datos............ 138
9.4.1. – Gestión de archivos secuenciales.. 142
VARIABLES DINÁMICAS. ............227

PRÓLOGO
Puesto que no se puede ser universal y saber todo lo que se puede saber acerca de todo, hay
que saber poco de todo. Porque es mucho más hermoso saber algo de todo que saber todo de una
cosa. Blaise Pascal (Pensamientos, 37)
Fue Confucio quien dijo, <<Lo que oigo lo olvido, lo que veo lo recuerdo, lo que hago lo
comprendo>>.
Este libro se ha escrito con esas ideas en mente. He llenado este libro de ejemplos,
especialmente en el capítulo <<soluciones>>, de manera que pueda ver y entender cómo las teorías y
conceptos presentados son aplicables a situaciones de empresa de la vida real.
El presente trabajo, lo inicie por Marzo de 1993, con la idea de hacer un manual que unificara
criterios y se utilizara como guía para los maestros de una escuela donde, desde su fundación, participe
como catedrático y finalmente como director administrativo. Sin embargo, en ese tiempo por diversas
circunstancias, a pesar de que se estrenaba la materia de Lenguajes Algorítmicos (la cual propuse que se
implantara), ni el manual ni yo, tuvimos el tiempo ni la aceptación suficiente, de mis compañeros, ni de
la dirección académica, para presentarlo y mucho menos aplicarlo (en otras palabras, no les intereso);
de tal manera que únicamente lo aplique1 a los grupos a los cuales impartía la primera materia de
programación, BASIC; puesto que anteriormente, no estaba contemplada la materia de Lenguajes
Algorítmicos o Algorítmica (como le llaman algunos). En dicho manual, pretendí recopilar lo
aprendido en la escuela, la experiencia y algo de documentación que tenía a mano, en aquellos años.
Por azares de la vida, el trabajo se vio interrumpido, en varias ocasiones, por muchas y muy
diversas causas. Aunque ese tiempo no se perdió, puesto que fui adquiriendo mayor experiencia en
cuanto al desarrollo de programas y análisis de sistemas, así como en lo que respecta a impartir clases
en diversas escuelas y a muchos particulares; también fui acrecentando mis conocimientos en la diaria
investigación que esta motivada por la curiosidad y las ganas de aprender2. Todo esto, ha servido para
enriquecer el que inicialmente se quería fuese un manual y, posteriormente se deseo desarrollarlo como
un libro3. En ese punto, querido lector, usted dirá después de estudiarlo, si se logro el último objetivo.
1
Como venía haciéndolo –aunque sin una estructura claramente definida-.
2
Siempre he dicho que mi profesión es de las más difíciles, ya que ser ESTUDIANTE no es nada fácil.
3
Esto fue creando con fragmentos de diversas fuentes, notas, experiencias y memorias profesionales, sin ánimo alguno de
lucro. Y lo menciono por aquello de que alguien quiera hacer algún reclamo por los copyrights.

PREFACIO
Durante todos estos años en el área de sistemas, he podido observar que a todos los estudiantes
que inician la carrera de sistemas computacionales de cualquier nivel (técnico o licenciatura), más que
tener problemas con los lenguajes de programación (más adelante veremos la definición técnica, por lo
pronto, son “idiomas” que utilizamos para comunicarnos con la computadora), tienen muchos
problemas con la LÓGICA.
Respecto a esto, y fuera de los conceptos teóricos puros e ideológicos de la LÓGICA formal; y
desde un punto de vista más personal y práctico, podría decir (perdónenme los puristas) que la
LÓGICA, es la forma estructurada y ordenada de nuestros pensamientos, ideas y acciones. Claro debe
estar que, todos tenemos LÓGICA (léase pensamiento lógico), solo que algunos más desarrollada que
otros. Una prueba de ello es el hecho de que primero nos ponemos la ropa interior y después el resto, o
que, cuando tenemos la lengua de fuera, primero la metemos para cerrar la boca y no mordernos (salvo
casos motivados por problemas de salud, en los cuales no tiene nada que ver la lógica y que sin
embargo seguimos teniendo), ya que si no tuviéramos LÓGICA, nos veríamos ridículamente vestidos
con la ropa interior por fuera, o sufriríamos constantes mordidas de lengua, ¿o no?. -
La LÓGICA al igual que los músculos de nuestro cuerpo, necesitamos ejercitarla, y esta por
demás decir, que algunas personas tienen cuerpos atléticos y otras son muy delgadas o bien obesas; sin
embargo, todos tenemos músculos. De la misma manera, todos tenemos LÓGICA, si bien, algunos al
igual que estas personas que tienen cuerpos atléticos, tienen su LÓGICA ágil, firme y bien desarrollada;
otros, como las personas delgadas u obesas, la tenemos muy débil, lenta o mal desarrollada.
Y bien, siguiendo este ejemplo, podríamos decir que para tener un cuerpo atlético (ignorando el
aspecto de herencia en los genes, para no complicarnos el asunto) debemos ejercitar mucho nuestros
músculos; pues, de la misma manera, para tener una LÓGICA ágil, firme y bien desarrollada, debemos
ejercitar nuestra mente.
El desarrollo de nuestra lógica y habilidades de programación es similar a la construcción de

una casa: si empezamos con una base fuerte e incrementamos nuestro conocimiento de forma gradual,
evitaremos muchos problemas a largo plazo. Piense en el presente libro como ese trabajo de base. En él
aprenderemos a construir pequeñas soluciones o programas para aplicar los conceptos de programación
fundamentales, y posteriormente añadir, a nuestros sólidos conocimientos los conceptos de
programación avanzados.
Podemos crear soluciones de muchas diferentes maneras para elaborar la misma tarea. No
obstante, algunas maneras son mejores que otras. En este libro se explicará, paso a paso, la mejor
manera para crear una solución. La ventaja del aprendizaje por pasos consiste en que podremos ver por
qué ciertas tareas se realizan de una manera particular y podremos entender cómo se ajustan las partes
individuales afectando así a la totalidad. Podríamos limitarnos simplemente a mostrar la solución y
decir “Aquí está la solución” y explicarla, pero eso no serviría de mucho a largo plazo. Existe un
antiguo proverbio que dice, “Dadle al hombre un pescado y lo alimentaréis por un día, enseñadle a
pescar y lo alimentaréis de por vida”. En este caso quisiera enseñarle a pescar.
Este libro está dirigido a quienes quieren convertirse en diseñadores de soluciones

(desarrolladores de programas o programadores), y necesitan aprender los conceptos básicos de
programación, así como desarrollar su lógica; y no a quienes ya son diseñadores de soluciones o que
son programadores expertos.
Para convertirse en un diseñador de soluciones, primero tendrá que aprender las bases y
comprender los conceptos que esconden algunos de los temas avanzados. Podremos considerar este

libro como un escalón hacia libros de programación avanzados y especificos para cada lenguaje.
Además de una buena lógica, un buen diseñador de soluciones debe tener un conocimiento
general sólido sobre qué utilidades tiene un producto (traductor de algún lenguaje de programación) y
qué funcionalidad nos proporciona dicho producto.
En este libro aprenderá a convertirse en un hábil diseñador de soluciones y aprovechará las

potentes utilidades de desarrollo de las técnicas y estilos de programación, con el fin de construir
verdaderas soluciones de empresa reales con éxito. Entendemos como <<soluciones de empresa
reales>> el tipo de soluciones que han de tomar en cuenta los programadores y diseñadores en su
trabajo diario.

OBJETIVOS.
El primero y más directo es el de aportar una guía básica y sencilla para que, cualquier persona
que se interese y le agrade el área de sistemas computacionales, aprenda, partiendo de la nada, a
desarrollar soluciones (programas).
Otro objetivo, no menos importante, es el de dar a conocer, a través de los conceptos básicos y
una gran cantidad de ejercicios, las técnicas de programación.
Aunque, en realidad, dejar satisfecho al lector que tenga en sus manos este libro y que estas
líneas ayuden en su aprendizaje a quien ha puesto su confianza en él, es el mayor y principal objetivo
de cualquier autor.
Debo hacer notar que para comprender algunos conceptos de este libro, primero debe haberse
tomado un pequeño curso previo de Introducción a la Computación y sería fantástico si se tomo un
curso de algún Sistema Operativo previo, para comprender algunos de los conceptos, como son la
memoria de la computadora, los componentes básicos que la conforman, y su funcionamiento
elemental, ya que el presente libro no pretende cubrir estos aspectos.

1. - Introducción y conceptos básicos.
INTRODUCCION
En el mundo de la computación, uno de los aspectos más importantes es la resolución de

problemas con la ayuda de la computadora, para agilizar los procesos y el manejo de información. Sin
embargo debemos recordar que la computadora no puede resolver problemas por sí sola, ya que solo es
una “máquina” o dispositivo electrónico que nos es útil como herramienta de trabajo, para el manejo
de grandes cantidades de información; por esto, somos nosotros quienes debemos darle las
instrucciones necesarias para que ella desarrolle los procesos que le indiquemos. Estas instrucciones
deben tener un cierto orden y deben ser especificadas concienzudamente y bien detalladas.
Para lo anterior, se siguen ciertas reglas para poder escribir las instrucciones que resuelvan un
problema en particular. Es aquí donde entra el uso de los Lenguajes Algorítmicos.
Un lenguaje algorítmico, es una forma de escribir las instrucciones u ordenes, en forma de
pasos lógicos para resolver problemas específicos, en el lenguaje que normalmente utilizamos; siendo
en nuestro caso, el español; de una manera sencilla y simple.
La palabra ALGORITMICO, proviene de la palabra ALGORITMO4, que en una de sus
definiciones básicas nos dice que es: Un procedimiento paso a paso para resolver un problema en una
cantidad determinada (finita) de tiempo.
Por lo anteriormente descrito, se puede decir que la materia de Lenguajes Algorítmicos es
primordial, ya que nos enseña a resolver problemas, y así escribir las instrucciones para la
computadora, y que ésta realice los procesos.
A continuación y para entendernos mejor, se dan algunos conceptos básicos utilizados en la

computación, y específicamente en el ambiente de los programadores.
1.1. - Lenguaje.
Un lenguaje es un medio de comunicación, que hace uso de símbolos, caracteres y

palabras, para expresar ideas.
1.2. - Programación.
Es la actividad de desarrollar programas, que serán suministrados a la computadora.
1.3. - Programa.
Es un conjunto de instrucciones, escritas en una secuencia lógica, en un lenguaje de

programación.
4
Algoritmia: f. Ciencia del cálculo aritmético y algebraico.
Algoritmo: m. Conjunto ordenado y finito de operaciones que permiten la resolución de un problema; p. Ej. La extracción
de raices cuadradas o el cálculo de una suma, producto o división de números. (Enciclopedia Textual Permanente Salvat).

1.4. - Lenguaje de programación.
Es el conjunto de caracteres y reglas de utilización, aplicadas para desarrollar programas

y comunicarnos con la computadora, para así darle las instrucciones adecuadas; y que ésta
desarrolle una determinada actividad o labor.
1.4.1. Lenguaje Máquina.
Es el “idioma” de la computadora, y lógicamente, solo entendible por ella. Este

lenguaje implica las instrucciones que son entendibles por la computadora.
La computadora solo entiende o capta impulsos eléctricos, los cuales procesa a
través de una compleja red de dispositivos electrónicos. Dichos impulsos eléctricos,
nosotros los humanos los representamos como “circuitos apagados” o “encendidos”, o
bien 0 y 1; los cuales relacionamos con el sistema binario de numeración (base 2).
1.4.2. Lenguajes de Alto Nivel.
Es un lenguaje de programación que utilizamos para comunicarnos con la

computadora, el cual utiliza palabras o abreviaturas, casi siempre del idioma inglés (aún
no he visto un lenguaje que use palabras de otro idioma5). Estos lenguajes implican
instrucciones fácilmente entendibles por cualquier programador, y que están listas para
ser traducidas a lenguaje máquina, por el programa traductor adecuado.
1.4.3. – Traductores.
En computación, se define como traductor, a un programa cuya función es la de

traducir las instrucciones en lenguaje de alto nivel a lenguaje máquina, para que ésta
efectúe las operaciones que se le indican.
1.4.3.1. – Intérpretes.
Un intérprete, es un programa traductor, el cual debe permanecer en la

memoria de la computadora para realizar la traducción a lenguaje máquina de un
programa escrito en lenguaje de alto nivel, así como su ejecución simultánea.
Muchos de estos lenguajes han desaparecido o bien, tienden a desaparecer.
1.4.3.2. – Compiladores.
Un compilador, es un programa traductor, el cual realiza la traducción del

programa escrito en lenguaje de alto nivel, durante un proceso llamado
compilación del código fuente, obteniendo un código objeto, el cual
posteriormente, pasa al proceso de enlazado, para obtener un código ejecutable
5
Salvo el caso de unos amigos de la escuela, cuya tarea era hacer un lenguaje compilado, y lo llamaron lenguaje LEPERO
(Lenguaje en Español Pseudoestructurado pero Revuelto con Otros), el cual nunca terminaron totalmente, solo lo que
necesitaron para aprobar, hasta donde tengo entendido.

por la computadora.
Al obtener el código ejecutable, es posible ejecutar el programa sin
necesidad de recurrir al compilador, puesto que el código ejecutable es
independiente y entendido directamente por la computadora, sin necesidad del
compilador.
1.4.4. – Palabras reservadas.
Son aquellas palabras propias de un lenguaje de programación, las cuales no

pueden ser utilizadas para describir datos o información del usuario, es decir, nombres
de variables, funciones o procedimientos de usuario.
1.4.5. – Código.
Desde el punto de vista informático, el Código, son las instrucciones de un

programa, escritas en un lenguaje de programación.
El proceso de traducir nuestro algoritmo (escrito en lenguaje común) a código
fuente (escrito en un lenguaje de programación) se denomina codificación.
1.4.5.1. - Código fuente.
Son las instrucciones de un programa, escritas en un lenguaje de

programación de alto nivel.
Normalmente el código fuente es capturado en un programa editor de
textos, que bien puede ser independiente al traductor o estar incluido dentro del
mismo.
1.4.5.2. – Código objeto.
Son las instrucciones de un programa, escritas en un formato intermedio

de traducción. Todos los compiladores generan el código objeto a partir del
código fuente, como un paso intermedio para obtener el código ejecutable.
1.4.5.3. – Código ejecutable.
Son las instrucciones de un programa, escritas en lenguaje máquina, por

un programa enlazador.
Todos los compiladores generan el código ejecutable a partir del código
objeto; y dicho código ejecutable, como su nombre lo indica, puede ser ejecutado
directamente por la computadora sin necesidad de recurrir al compilador o
traductor.
1.4.6. – Compilación.
Es el proceso de traducción del código fuente a un formato intermedio de

traducción, llamado código objeto.

1.4.7. – Enlazado.
Es el proceso de traducción del código objeto a código ejecutable, por medio de

un programa de enlazado o enlazador.
Durante este proceso, las instrucciones, funciones y procedimientos escritos por
el compilador en código objeto se relacionan o enlazan con el código ejecutable, que se
encuentra en las librerías propias del lenguaje de programación.
Código Compilador Código Enlazador Código

fuente objeto ejecutable
Librería(s)
1.4.8. – Librerías.
Una librería de funciones es un archivo, normalmente con extensión.LIB, que

contiene un conjunto de rutinas compiladas, que han sido diseñadas para realizar una
tarea en particular, y que el enlazador añade a los programas conforme éste las necesita.
Las librerías pueden ser específicas para un tema (p. e. Gráficos), para una
aplicación en particular, para un compilador (p. e. Clipper) o bien tener un carácter
estándar, con funciones de todo tipo, reutilizables en cualquier aplicación.
Un compilador se acompaña, normalmente, de una o más librerías que son las
que contienen las funciones del lenguaje en general6.
1.4.8.1. – Librerías preenlazadas.
Son aquellas librerías que contienen módulos objeto previamente

enlazados, y por lo tanto sus instrucciones, funciones y procedimientos ya están
traducidos a lenguaje máquina. Normalmente son almacenados como archivos
con extensión.PLL (Pre Linked Library) u otra similar.
Algunos compiladores nos permiten crear archivos con librerías
preenlazadas de forma que, al enlazar nuestra aplicación final, el ejecutable
ocupe una cantidad mínima debido a que toma una cantidad muy importante de
aquello que necesita para trabajar de un archivo.PLL (Pre Linked Library).
Dicho en otra forma, al compilar y enlazar nuestra aplicación, solo se
traducirán a lenguaje máquina aquellas instrucciones, funciones o
procedimientos que no se encuentren en la librería preenlazada, puesto que, el
resto ya están enlazadas en el archivo PLL, y cuando se ejecute el programa, éste
llamará a las funciones de la librería preenlazada y las ejecutará directamente.
La ventaja de utilizar librerías preenlazadas, básicamente es el ahorro de
espacio en disco, sin embargo, por lo general el tiempo de carga de la aplicación
(inicialización del programa) a memoria es mayor.
1.4.9. – Sintaxis.
6
En el apéndice A se trata con un poco más de detalle el tema de las librerías. Sin embargo, se recomienda tratar estos temas
cuando ya se tenga un poco más de conocimientos acerca de la programación avanzada.

Son las reglas de escritura de las instrucciones del lenguaje de programación.
1.4.10. – Semántica.
Son las reglas, normas o técnicas que permiten dar legibilidad al código de un
programa, es decir, que permiten que el código sea fácil de entender y comprender.
1.5. - Sistema informático o aplicación.
Conjunto de programas que funcionan coordinados entre sí, para el manejo de grandes
volúmenes de información.
1.6. - Programador.
Es la persona que desarrolla programas para computadoras.
1.7. - Técnicas de programación.
Conjunto de reglas o normas utilizadas para el desarrollo de programas.
1.8. - Usuario.
Es cualquier persona que hace uso de una computadora.

2. - Tipos y estructuras básicas de datos.
2.1. - Dato.
Un dato es la expresión general que describe los objetos con los cuales opera una
computadora.
A los datos se les puede considerar como la materia prima que se da a un proceso para
obtener un producto terminado, llamado información.
2.2. - Tipos de datos.
2.2.1. - Datos numéricos.
Un tipo numérico es el conjunto de valores numéricos, con los cuales podemos

realizar operaciones aritméticas. Estos pueden representarse en dos formas distintas:
- Tipo numérico entero (integer).

- Tipo numérico real (real).
El tipo numérico entero (integer), como su nombre lo indica son aquellos valores
numéricos que no cuentan con una parte fraccionaria o fracción; y obviamente no tienen
en su estructura el punto decimal o formato de fracción.
Ejemplos de tipos numéricos enteros: 5, 3, 8, 23, …
El tipo numérico real (real), son aquellos valores numéricos que incluyen en su
estructura el punto decimal o formato de fracción, y desde luego una parte fraccionaria o
fracción.
Ejemplos de tipos numéricos reales: 1.5, 2.34, 0.47, ¾, 5 ½, …
Normalmente en las computadoras, los números reales se representan en formato

decimal (p. Ej. 1.5, 3.56, …); y en raras ocasiones en formato fraccionario (p. Ej. ¾, 3½,
1¾, …).
2.2.2. - Datos tipo carácter.
El tipo carácter es el conjunto finito (limitado) y ordenado de caracteres que la

computadora reconoce. Un tipo de dato carácter contiene un solo carácter.
Los caracteres que reconocen las diferentes computadoras no son estándar; sin
embargo, la mayoría reconoce los siguientes caracteres alfabéticos y numéricos:
- Caracteres alfabéticos (A, B, C,..., Z, a, b, c,..., z).

- Caracteres numéricos (0,1,2,3,4,5,6,7,8,9).
- Caracteres especiales (!, ", $, %, &, /, ...).

2.2.3. - Datos alfanuméricos, de cadena o string.
Una cadena (string) de caracteres es una sucesión de caracteres que se encuentran

delimitados por una comilla (apóstrofo), dobles comillas, o corchetes ([]); según el tipo
de lenguaje de programación. La longitud de una cadena de caracteres es el número de
ellos comprendidos entre los separadores o delimitadores.
2.2.4. - Datos lógicos (booleanos).
El tipo lógico (también denominado booleano) es aquel dato que solo puede
tomar uno de dos valores:
CIERTO o VERDADERO (true) y FALSO (false)
Este tipo de datos se utiliza para representar las alternativas (SI / NO) a
determinadas condiciones. Por ejemplo, cuando se pide si un valor entero es par, la
respuesta será verdadera o falsa, según sea par o impar.
2.3. - Constantes, variables y funciones.
CONSTANTES
Son valores estáticos, es decir, que no cambian, y se mantienen fijos durante la ejecución
de un programa.
Pueden ser de cualquiera de los tipos de datos vistos anteriormente.
Ejemplos: 23,”España”, Verdadero.
VARIABLES
Una variable es un objeto o partida de datos cuyo valor puede cambiar durante la
ejecución de un programa. A estos objetos o partida de datos se les puede asignar un nombre,
que será el NOMBRE DE VARIABLE, para identificarlos.
Ejemplos: Edad, Nombre, Salario.
FUNCIONES
Son un conjunto de operaciones predefinidas dentro de un lenguaje de programación o

por el programador.
2.4. - Expresiones.
Las expresiones son combinaciones de constantes, variables, símbolos de operación,

paréntesis y nombres de funciones especiales.

2.4.1. - Expresiones aritméticas.
Son semejantes a las formulas aritméticas. Las variables y constantes son

numéricas (reales o enteras) y las operaciones son las aritméticas. Los operadores
aritméticos son los siguientes:
+ SUMA
- RESTA
* MULTIPLICACIÓN
/ DIVISIÓN
^, ** EXPONENCIACIÓN
DIV DIVISIÓN ENTERA
\,MOD MÓDULO (resto, residuo)
Los cuales se rigen sobre la base de ciertas REGLAS DE PRIORIDAD o

PRECEDENCIA, que permiten determinar el orden de las operaciones, y que se basan en
reglas matemáticas, las cuales son:
A. - Las operaciones que están encerradas entre paréntesis se evalúan primero. Si

existen diferentes paréntesis anidados (interiores unos a otros), las expresiones más
internas se evalúan primero.
B. - Las operaciones aritméticas dentro de una expresión suelen tener el siguiente

orden de prioridad.
1. - Operador exponencial ^ o **.

2. - Operadores *, /.
3. - Operadores +, -.
4. - Operadores DIV y MOD.
En caso de coincidir varios operadores de igual prioridad en una expresión

encerrada entre paréntesis o no, el orden de prioridad en este caso es de izquierda a
derecha.
Ejemplos:
EXPRESION OPERACIONES RESULTADO
5 DIV 2 División entera 2
5 MOD 2 Módulo o residuo 1
4+6/2 4+3 7
(4+6)/2 10/2 5
((3+5)/2^2)+1 (8/2^2)+1 = (8/4)+1 = 2+1 3
4*2/4 8/4 2
2^2/4 4/4 1

2.4.2. - Expresiones alfanuméricas.
Son expresiones que incluyen asignaciones o funciones especiales, de datos

carácter o de cadena (string).
Ejemplo de concatenamiento.- “Casa” + “segura” = “Casa segura”
2.4.3. - Expresiones lógicas (booleanas).
Una expresión lógica es una expresión que solo puede tomar uno de dos valores,
ya sea VERDADERO o FALSO. Se denominan también EXPRESIONES BOOLEANAS
en honor del matemático británico George Boole, que desarrollo el Algebra lógica, de
Boole o Booleana.
2.4.3.1. - Operadores de relación.
Los operadores relacionales o de relación permiten realizar

comparaciones de valores de tipo numérico, carácter o de cadena. Los
operadores de relación sirven para expresar las condiciones en los
algoritmos. Los operadores relacionales son:
< MENOR QUE

> MAYOR QUE
= IGUAL QUE
<= MENOR O IGUAL A
>= MAYOR O IGUAL A
<> DIFERENTE A
Ejemplos:
EXPRESION RELACIONAL RESULTADO

5<3 FALSO
3<5 VERDADERO
8>2 VERDADERO
2>8 FALSO
3=3 VERDADERO
3=2 FALSO
3 <= 5 VERDADERO
6 <= 5 FALSO
3 >= 5 FALSO
6 >= 5 VERDADERO
3 <> 3 FALSO
3 <> 2 VERDADERO

2.4.3.2. - Operadores lógicos.
Los operadores lógicos o booleanos básicos son NOT (no), AND (y) y
OR (o), y nos permiten unir expresiones booleanas o de relación.
Las estructuras para el uso de los operadores lógicos son:
Expresión Lógica 1 AND Expresión Lógica 2

Expresión Lógica 1 OR Expresión Lógica 2
NOT Expresión Lógica
Los resultados del uso de los operadores lógicos se pueden observar en

las siguientes TABLAS DE VERDAD:
Expresión Lógica 2
AND Verdadera Falsa
Expresión Verdadera Verdadera Falsa Resultados
Lógica 1 Falsa Falsa Falsa
Resultados
OR Verdadera Falsa
Expresión Verdadera Verdadera Verdadera Resultados
Lógica 1 Falsa Verdadera Falsa
Resultados
NOT Resultado
Expresión Verdadera Falsa
Lógica Falsa Verdadera
Existe otro operador lógico, llamado XOR, que es utilizado en algunos

lenguajes de programación, y es considerado un OR exclusivo. Su tabla de
verdad es la siguiente.
XOR Verdadera Falsa
Expresión Verdadera Falsa Verdadera Resultados
Lógica 1 Falsa Verdadera Falsa
Resultados
Como se puede observar, únicamente se obtiene un resultado verdadero

cuando solo una de las expresiones lógicas es verdadera. Si las dos llegan a ser
verdaderas el resultado es falsa; ya que una expresión verdadera excluye a la
otra.

2.4.4. – Reglas globales de prioridad o precedencia.
Como ya se menciono, para el caso de los operadores aritméticos, existen ciertas

Reglas de Prioridad o Precedencia. Pero estas reglas de precedencia para operadores
aritméticas, no son únicas ya que existen otras de mayor jerarquía, las cuales llamaremos
REGLAS GLOBALES DE PRIORIDAD O PRECEDENCIA, ya que implican de manera
general a las expresiones, las cuales para resolverse siguen el siguiente orden o
precedencia:
1. Operaciones Aritméticas, Operaciones Alfanuméricas.

2. Operaciones Relacionales.
3. Operaciones Lógicas.
2.5. - Arreglos (arrays).
Un arreglo (array) es un conjunto limitado y ordenado de elementos similares (del

mismo tipo de dato) que reciben el mismo nombre.
La propiedad "ordenado" significa que el elemento primero, segundo, tercero, .., n-ésimo
de un arreglo puede ser identificado por medio de un índice o subíndice.
2.5.1. - Arreglos unidimensionales.
Es el tipo más simple de arreglos, también reciben el nombre de VECTORES,

solo cuenta con un subíndice, es decir, solo tiene una dimensión, ya que solo contará con
un número determinado de filas, o bien de columnas, únicamente. Para hacer referencia
a un elemento se puede indicar de la siguiente manera: X(4) ó X[4].
Si representamos gráficamente un vector con cuatro elementos, tendremos:
Cuatro columnas,
Cuatro filas
NOTA: Debo anotar que la posición 0 (cero), en los lenguajes de programación

se define automáticamente como una posición de arreglo válida, de tal manera que si
definimos un vector X(4) de, aparentemente, 4 posiciones, realmente representará un
vector de 5 posiciones, que van desde X(0) hasta X(4). De la misma manera será para
los demás tipos de arreglos. Sin embargo, para no confundir al lector, tomaremos los

conceptos matemáticos sobre arreglos, con fines de explicación, en los cuales no se
considera la posición 0.
2.5.2. - Arreglos bidimensionales.
Estos arreglos tienen dos dimensiones, es decir, cuentan con un número

determinado de filas y columnas; también reciben el nombre de MATRICES o TABLAS.
Para hacer referencia de uno de sus elementos se deben utilizar dos subíndices
(A[f, c]).
Si representamos gráficamente una tabla con cinco filas y cuatro columnas
tendremos:
1 2 3 4
2
3
4
5
2.5.3. - Arreglos multidimensionales.
Cuando un arreglo cuenta con tres o más subíndices, se dice que es un arreglo
multidimensional, ya que cuenta con múltiples dimensiones.
Si representamos gráficamente una matriz tridimensional con
F filas, C columnas y N niveles tendremos:
F filas
N niveles
C columnas
Cuando un arreglo tiene más de tres dimensiones, no es posible representarlo
gráficamente, sin embargo, tanto matemáticamente como en la computadora si es
posible manejarlo.

3. - Técnicas de Programación.
3.1. - Importancia.
El dominio y aplicación de las técnicas de programación, es de gran importancia, ya que

el uso de éstas nos facilita en gran medida el desarrollo de programas que resolverán problemas
prácticos, puesto que nos ayudan a determinar muchos aspectos y detalles durante la resolución
de problemas, y con esto se reducen los errores al mínimo, y se obtienen programas o
aplicaciones en una menor cantidad de tiempo, mayor calidad, legibilidad y funcionalidad, ya
que nos permite planificar, con mínimo error, los programas que hemos de desarrollar.
3.2. - Objetivo.
Es el de economizar tiempo, disminuir la cantidad de errores que se pudieran presentar

durante el desarrollo de una aplicación o programa, y con esto reducir los costos de elaboración
de software.
3.3. - Estilos de programación.
El estilo en la construcción de programas, al igual que el estilo de escritura, no es una

cosa que pueda adquirirse solo a partir del conocimiento de las reglas de sintaxis de un lenguaje
y las técnicas básicas de programación. El estilo en programación como en otras actividades de
la vida es una cuestión de gustos personales; sin embargo, en programación es posible unir la
inventiva y la ingeniosidad del programador con unas reglas de disciplina y orden en el diseño
de programas.
El estilo de la buena programación está íntimamente unido con la legibilidad de los
programas. La legibilidad de un programa es el criterio más sencillo para evaluar la calidad de
un programa; si el programa es fácil de leer, probablemente será un buen programa; si es
difícil de leer, no es un buen programa (Kernighan* y Planger. Software Tools. Addison-
Wesley, 1976).
La legibilidad es la clave para la comprensión de un programa; un programa que no se
puede comprender, no se le podrá modificar ni mantener actualizado. Es muy importante
distinguir entre legibilidad (semántica) y facilidad de escritura (sintaxis). Las técnicas de
programación deben facilitar la escritura de programas y posteriormente facilitar su lectura.
La escritura de algoritmos y su posterior codificación conduce a la creación de hábitos
de programación. La formación de buenos hábitos de programación, desde el inicio de su
aprendizaje de programación, será, sin duda, uno de los puntos más importantes en los que
deberá prestar atención.
La calidad de un programa se puede medir con diferentes parámetros; entre ellos
destacaremos:
A). - Un programa debe funcionar.

Obviamente es la característica más simple e importante.

B). - La documentación.
Desde luego debe contener en su código los comentarios necesarios para
explicar detalladamente su funcionamiento, así como la documentación que se
utilizo y desarrollo durante la fase de análisis de los problemas.
C). - La eficiencia.
El programa debe ser óptimo, es decir, debe utilizar únicamente aquellos
recursos de hardware (principalmente RAM, entre otros) estrictamente
necesarios, y nunca desperdiciarlos; también debe ser rápido, es decir, debe
procesar la información lo más rápidamente posible.
D). - Corrección.
Debe ser fácil la localización de errores en el código, y por ende, permitir
realizar las correcciones necesarias en el menor tiempo posible. De ahí que
nuestra programación debe ser estructurada (por ejemplo, técnica modular o
descendente, que se verán más adelante), evitando saltos de una línea del
programa a otra, y tratando de hacerlo lo más aproximado a un programa lineal,
es decir, que se ejecute línea a línea sin saltos.
E). - Flexibilidad.
Debe estar estructurado de tal manera que permita realizar cambios o
actualizaciones de manera rápida y sin modificar gran cantidad de código. Esto
con el fin de cubrir rápidamente las necesidades de los usuarios.
F). - Fiabilidad.
El proceso de la información y entrega de resultados del programa al
usuario final debe ser totalmente confiable, ya que dicho usuario espera que los
resultados que obtenga a través de nuestros programas sean 100% correctos (A
excepción expresa de los errores de captura que el propio usuario pueda cometer,
y que no pudiéramos evitar).
G). - La presentación.
El programa deberá tener una presentación agradable e intuitiva para el
usuario, es decir, que las pantallas de intercambio de información (interfases)
sean sencillas, ordenadas, fáciles de comprender, y; en lo posible, con toques de
colores e imágenes agradables al usuario.
3.4. La Notación Húngara y otras convenciones.
A la hora de desarrollar programas o sistemas, el algoritmo o código puede a veces

volverse complejo y terminar por ser bastante largo. Un algoritmo o código largo y entrevesado
puede resultar difícil de leer si necesitásemos depurarlo, o si lo que estamos es regresando a él,
después de una larga ausencia. Por ello a través del tiempo y la experiencia de los primeros
programadores, se han creado varias convenciones que facilitan la comprensión, y así poder
seguir las acciones que nuestro programa va ejecutando.
Pese a que no hemos escrito ningún algoritmo o código hasta el momento, deberíamos
familiarizarnos con las convenciones que facilitarán la legibilidad de nuestro código. Estas

convenciones nos permiten hacer lo siguiente:
- Añadir comentarios a nuestro algoritmo o código.

- Escribir múltiples sentencias en una sola línea (dependiendo del lenguaje utilizado).
- Utilizar el carácter de continuación de línea (también dependiendo del lenguaje
utilizado).
- Aplicar sangrías sobre el código, es decir, indentarlo o tabularlo.
Como primer punto tenemos que, los comentarios son líneas del programa que se
introducen para dar legibilidad al código y siempre son ignorados por los traductores.
¿Para qué usarlos entonces? La finalidad es darle claridad al programa, expresando qué
hace cada una de sus partes.
Resulta recomendable agregar comentarios a nuestro algoritmo o código, con el fin de
explicar claramente el objetivo o tarea de un grupo de ordenes o instrucciones. En todos los
lenguajes de programación esta situación ha sido contemplada; así por ejemplo tenemos que en
BASIC y sus “dialectos” (perdón a los puristas por –dialecto-) (por ejemplo: GWBASIC, Quick
BASIC, Turbo BASIC, Visual BASIC, etc.), una línea de comentario empieza con la palabra o
sentencia REM, de REMark (-comentario- en inglés) o un apóstrofe (‘), mientras que en los
lenguajes xBase (por ejemplo: DBase, Clipper, Fox Base, Fox Pro, etc.) tenemos los caracteres
*, //, /* */ ó &&, dependiendo del lenguaje xBase; en Pascal los caracteres (* *), y así por el
estilo.
Para el caso especifico de los algoritmos, es recomendable anotar y resaltar los
comentarios; por eso algunos programadores acostumbramos diferenciarlos anotando un
asterisco (*) al inicio del comentario, aunque cada programador resalta los comentarios como
más le parece y conviene. Los primeros libros de programación (que conocí) y desde luego
también los primeros programadores; acostumbraban anotar comentarios inclusive en el
diagrama de flujo del programa7; pero en lo personal, me confunden más y no me ayudan.
Ejemplo:
* Este es un comentario, y el que sigue también.

* Lo que sigue son las primeras tres instrucciones de un programa.
Instrucción 1
Instrucción 2
Instrucción 3
* A continuación siguen otras dos instrucciones.
Instrucción 4
Instrucción 5
* Este es el final del pseudo código o algoritmo.
En el segundo punto de la lista, se nos marca el uso de múltiples sentencias en una sola
línea, y aunque acortan un poco el código y evitan que se vea excesivamente largo, en lo
personal, a veces me pierdo y no visualizo las sentencias correctamente, pues me confunden y
7
No te preocupes si este término es nuevo para ti, son simplemente unos gráficos representando un algoritmo o código, mas
adelante conocerás su definición exacta y hasta soñarás con ellos.

pienso que es una sola instrucción; sin embargo, allí queda la opción para quien le guste usarla,
y además le sea posible programarla así, en el lenguaje que escoja y más le guste. Pues no todos
los lenguajes de programación permiten esta característica, algunos de los que si lo permiten son
el BASIC y algunos de sus “dialectos”, así como Clipper y Pascal, entre otros.
Ejemplo:
Instrucción 1
Instrucción 2: Instrucción 3: Instrucción 4: Instrucción 5
Instrucción 6
Como puedes ver, solo ocupa tres líneas, y no seis, por lo cual se ve mas corto el pseudo
código.
Para el tercer punto anotado, cabe hacer mención que la mayoría de los traductores
entienden que cada mandato o función se va a poner en una sola línea. Cuando el traductor se
encuentra con un salto de línea en la instrucción (carácter 13 <intro> del código ASCII), a todos
los efectos, ésta ha finalizado.
A medida que profundicemos en la programación, veremos que las expresiones se
pueden complicar cuanto queramos, a veces más de lo que sería deseable.
No es recomendable, por cuestión de legibilidad, que una línea supere el margen derecho
de nuestra pantalla cuando capturemos el código fuente del programa. Para solventar este evento
disponemos de un carácter especial, que varía dependiendo del lenguaje, el cual indica al
traductor que el código se corta en ese punto, pero el que viene en la o las siguientes líneas es
continuación de éste. (como ejemplo de carácter especial tenemos el punto y coma -;- en los
lenguajes xBase).
La ubicación de este carácter especial, en la mayoría de los casos, es flexible, pero no
puede ponerse indiscriminadamente. Por ejemplo, las palabras reservadas o el nombre de las
variables, no pueden cortarse.
Ejemplo:
Instrucción Larga;
Continuación de la Instrucción Larga
Si se anotara en una sola línea se escribiría:
Instrucción Larga Continuación de la Instrucción Larga
Sin embargo no es válido hacer esto:
Instr;
ucción larga
Por último, tenemos la aplicación de sangrías al código, es decir, indentación o

tabulación. Esto se aplica para diferenciar el inicio y finalización de instrucciones compuestas,
es decir, de aquellas instrucciones que dentro de su estructura o sintaxis pueden incluir otras

instrucciones independientes a la compuesta.
Ejemplo:
Inicio de la Instrucción Compuesta 1

Instrucción 1
Instrucción 2
Instrucción 3
Continuación de la Instrucción Compuesta 1
Instrucción 4
Instrucción 5
Fin de la Instrucción Compuesta 1
Instrucción Compuesta 2
Instrucción 6
Instrucción 7
Instrucción 8
Instrucción Compuesta 3
Instrucción 9
Instrucción 10
Fin de Instrucción Compuesta 3
Fin de Instrucción Compuesta 2
Como puede observarse las instrucciones 1 a 3 se ejecutarán dentro de la primera

sección de la Instrucción Compuesta 1 y las instrucciones 4 y 5 en la segunda parte de la misma;
pues después de esto termina la instrucción compuesta.
La Instrucción Compuesta 2 incluye dentro de su estructura las Instrucciones 6 a 8 y la
Instrucción Compuesta 3; cuya estructura incluye a su vez a las Instrucciones 9 y 10.
Espero quede claro que es más fácil revisar un grupo de instrucciones indentadas, pues
fácilmente encontraremos el inicio y fin de las instrucciones compuestas.
Como habrás notado, los humanos nos entendemos a fuerza de convenciones. La

escritura de un programa es un asunto lleno de estas ceremonias. ¿Por qué indentamos el
código? ¿Por qué escribimos cosas en mayúsculas y cosas en minúsculas? Las razones están
claras: para hacernos entender mejor. Este es el objetivo principal de cualquier sistema de
notación. Todo programador, de acuerdo a su estilo, ha empleado un sistema de notación propio
basado en las reglas que más lo han ido convenciendo de los distintos métodos que ha visto. Sin
embargo, es recomendable ajustarse al estándar. Y este estándar no es ni más ni menos que la
notación húngara, un invento maléfico de un programador magiar que trabaja para Microsoft y
que está a punto de conseguir que media humanidad escriba programas tal como a él le dé la
gana que lo hagan. Simonyi se llama el bárbaro en cuestión, y sus reglas ya han sido asumidas
por todos los productos de Microsoft y por bastantes de la competencia. Por lo tanto, es
recomendable, intentar siempre ajustarnos al estándar y en este libro intentamos que se dé el
primer paso para ello.
Así, pues, hemos tomado las mismas normas de la notación húngara que Nantucket (una
empresa de software) ha asumido para algunos de sus productos. Esto no supone asumir dicha
notación en su totalidad. Esto es así porque Simonyi escribió sus convenciones pensando en el
lenguaje C y este lenguaje tiene sus diferencias con otros lenguajes. Por ejemplo en C es

obligatorio escribir todas las funciones del sistema en minúsculas, y por ello, una norma de la
notación húngara es que todas estas funciones han de ir escritas en dicha tipografía. En otros
lenguajes (por su traductor), cosas como esta no son necesarias. Por ello en el sistema de
notación que empleamos los mandatos y las funciones de las librerías del sistema se escriben
con mayúsculas8. En fin, el conjunto de normas que seguimos son:
1. La primera letra de una variable siempre ha de escribirse en minúscula y debe indicar el tipo
de la misma:
a Array
b Codeblock (para lenguaje Clipper).
c Cadena
d Fecha
l Lógica
n Numérica
o Objeto
x Cualquier tipo
2. Los mandatos y funciones del sistema se escriben siempre en mayúsculas. Por ejemplo:
RETORNAR (RETURN en inglés), FECHA() (DATE en inglés), etc.
3. Los nombres de cualquier objeto introducido por el usuario: variable, función, etc. Nunca
deben separarse mediante el símbolo del subrayado sino poniendo en mayúsculas la primera
letra de cada trozo de palabra con significado. Por ejemplo: DbMenu(), StrCount(),
nFilaInicial, etc. (Técnica WordMixing –Mezcla de palabras-)
Como has visto, la notación húngara se trata de un sistema de convenciones de escritura

de código que hacen que los programas, sean más legibles.
A casi todos los traductores no les importa que una palabra, sea mandato, variable,
función o lo que sea, esté escrita en mayúsculas o minúsculas (salvo en casos específicos del
lenguaje, como C), con uno o más blancos por delante o por detrás, etc. Al que sí le importa es
al que tiene que leer eso, es decir, a nosotros.
Como en casi todas las normas, existen corrientes, la notación húngara no podía ser
menos. En algunos libros de programación y lenguajes, por ejemplo; las obras realizadas y/o
editadas por grupo EIDOS9, se sigue la llamada notación gallega inversa, una mezcla del 95%
de notación húngara y un 5% de especifidades (de la cosecha del grupo EIDOS) y chanza (el
8
En general seguimos la adaptación de la Notación Húngara para Clipper realizada por Robert DiFalco en Reference
(Clipper) Vol. V, núm. 5, de mayo de 1991 y por Antonio Linares en clippeRmanía núm. 3, de julio de 1991.
9
Grupo EIDOS es una empresa especializada en el área de lenguajes xBase. Sus actividades abarcan la edición de
documentación técnica (entre la que destacan la revista clippeRmanía así como varios libros sobre productos de entorno xBase
publicados a través de Editorial RAMA, la formación, la consultoría, el desarrollo, la producción y distribución de productos
software. Grupo EIDOS es VAR (Distribuidor Autorizado de Valor Añadido) y Centro de Formación Autorizado de Computer
Associates. Sus dos centros en Madrid y Valencia cubren la totalidad de los aspectos reseñados.
En el área de la formación, Grupo EIDOS ha organizado en España en 1992 y 1993 los ENCUENTROS DE USUARIOS
CLIPPER y en Argentina en 1993 (a través de WorldNet, su representante en la zona) los PRIMEROS ENCUENTROS
LATINOAMERICANOS DE USUARIOS CLIPPER; todos ellos con la asistencia de los más cualificados desarrolladores en
Clipper y el patrocinio de las principales empresas del sector. Asimismo, mantiene un aula de formación permanente para
programadores dentro de este mismo entorno.

nombrecito es fruto de una mezcolanza entre la notación polaca y una deferencia para uno de
sus mejores amigos y colaboradores: Ramón Delgado, gallego él).
A continuación se muestran las normas seguidas por la notación gallega inversa, en la

que se podrán notar las similitudes y diferencias con relación a la notación húngara, y son:
1. Los nombres de las variables han de ir precedidos en minúsculas por un identificador de su

tipo:
c Carácter o memo
n Numérica
l Lógica
d Fecha (date)
o Objeto (genérico)
b CodeBlock (para lenguaje Clipper)
x Tipo indeterminado (no conocido a priori)
a Array
ac Array de cadenas (todos los elementos tipo c)
a… Array de … (todos los elementos de tipo …)
Si la variable contiene un objeto específico, del que conocemos su tipo (su clase),
entonces usaremos como identificador 3 letras (consonantes) para representar ese tipo de
Objeto:
vntTest vnt -> Ventana

kktPrueba kkt -> Kikito
2. Utilización de la técnica WordMixing (mezcla de palabras) para diferenciar las distintas

partes de un nombre.
cEjemploTipico
3. No usar subrayados “_” para separar esas partes de los nombres.

4. A todos los efectos, los nombres que demos a nuestras funciones y métodos seguirán las
mismas reglas de codificación. A fin de cuentas tanto el nombre de una variable como el
nombre de una función son símbolos que contienen un valor (unos lo tienen y otros lo
generan). Aplicar indistintamente estas técnicas en variables y funciones evitará un buen
montón de errores.
5. Todos los mandatos se escribirán en mayúsculas.
Cada programador tiene su propio método o estilo, pero todo apunta hacia una unificación
de criterios, y esta notación húngara (o la similar gallega inversa) es la de mayor aceptación.

4. - Técnica de diseño general o elemental.
Esta técnica es aplicable a cualquier tipo de problema que se presente, pero tiene el
inconveniente de que, en el desarrollo de grandes sistemas, resulta muy poco recomendable su uso, ya
que resultaría confusa y laboriosa su aplicación. Por lo tanto, es recomendable para proyectos en
pequeña escala o módulos del proyecto.
4.1. - Fases de resolución de problemas.
TECNICA DE DISEÑO GENERAL O ELEMENTAL

Las fases o pasos para resolver problemas con esta técnica, y obtener programas en
lenguajes de alto nivel, son:
1. - Determinar el objetivo o problema.

2. - Análisis del problema:
A) Determinar los datos de salida solicitados, y los datos de entrada necesarios.
B) Determinar los pasos para resolver el problema.
C) Comprender y detallar los pasos para resolver el problema.
3. - Desarrollar el diagrama de bloques o diagrama de flujo de sistemas.
4. - Diseñar el diagrama de flujo.
5. - Desarrollar el algoritmo o pseudo código.
6. - Codificar el programa.
7. - Capturar la codificación.
8. - Prueba y detección de errores.
9. - Depuración del programa.
10. - Ejecución y puesta en operación del programa.
A continuación se explica detalladamente cada uno de los pasos indicados.
La determinación de un objetivo o problema, generalmente lo hace el Ingeniero, Técnico en

Sistemas Computacionales o Programador Analista, el cual sobre la base de una serie de estudios
(Análisis de Sistemas), enfocados a la administración de una empresa, detecta las fallas de ésta y
propone soluciones, las cuales serán los objetivos o problemas que resolverá el Técnico en Informática,
Técnico Programador o Programador de Computadoras.
Para resolver este paso nos apoyaremos en el punto 1, y definiremos que es lo

que se nos esta pidiendo, es decir, "hacia donde vamos"; y determinaremos que es lo
que necesitamos para obtener lo que se nos pide, en otras palabras, "de donde

partiremos".
Aquí, debe pensarse como se resolvería el problema a mano, paso a paso, y

anotarlos. Se debe tener el cuidado de revisar los pasos especificados.
Se desglosaran todos y cada uno de los pasos listados en el punto anterior,

tratando de que se detallen todos los aspectos, y posibles casos que se pudiesen
presentar.
3. - Desarrollar el diagrama de bloques o diagrama de flujo de sistemas.
El diagrama de bloques es la representación gráfica, de manera general, de la resolución

de un problema. Para resolver este punto nos apoyaremos en el paso 2b. Más adelante veremos
todo lo relacionado con los diagramas de bloques.
4. - Diseñar el diagrama de flujo.
Un diagrama de flujo es la representación gráfica de la resolución de un problema. Para

resolver este punto nos apoyaremos en el paso 2c. Posteriormente veremos con mayor detalle el
tema de diagramas de flujo.
5. - Desarrollar el algoritmo o pseudo código.
En este caso, el algoritmo o pseudo código se considera como la traducción del diagrama
de flujo a instrucciones en lenguaje común, es decir, el que utilizamos cotidianamente. Por
ejemplo, en nuestro caso, el español.
Dependiendo del estilo de programación que se tenga, se pueden usar palabras
reservadas de algún lenguaje de programación, mezcladas con palabras del lenguaje que
comúnmente utilizamos.
La codificación de un programa, puede ser considerada como, la traducción de las

instrucciones en lenguaje común a un lenguaje de programación, es decir, la traducción del
algoritmo o pseudo código a un lenguaje de programación.
A continuación se muestra un cuadro con las instrucciones más comúnmente utilizadas
al programar, así como sus equivalentes en algunos lenguajes de programación.

Lenguaje Común Lenguaje Basic Lenguaje Pascal Lenguaje Clipper Lenguaje C
Desplegar Print Write Say Printf
(en pantalla) (imprimir) (escribir) (decir) (imprimir)
Introducir Input Read Get-Read Scanf
(por teclado) (introducir) (leer) (tomar-leer) (examinar)
Sí-Entonces-Sino If-Then-Else If-Then -Else-; If-Else-EndIf If-Else-;
(Si-Entonces-Sino) (Sí-Entonces-Sino) (Sí—Sino-FinSí) (Sí—Sino-;)
En caso On-goto Case Of Do Case Switch-Case
(Según-ir a) (Caso de) (Hacer en caso) (Interruptor-Caso)
Para-Hasta-Siguiente For-To-Next For-To-; For-To-Next For(){};
(Para-Hasta-Siguiente) (Para-Hasta-;) (Para-Hasta-Siguiente) (Para()-{}-;)
Hacer Mientras While-Wend While-Do-; Do While-EndDo While-;
(Mientras-FinMientras) (Mientras-Hacer-;) (Hacer-Mientras-FinHacer) (Mientras-;)
Hacer Hasta Do-Until Do-while-;
(Hacer-Hasta) (Hacer-Mientras-;)
Como se puede observar, cada instrucción en lenguaje común tiene su equivalente en

cada uno de los lenguajes de programación mencionados en la tabla.
A continuación daré una breve descripción del uso de cada instrucción, sin embargo
debo anotar, que cada una de las instrucciones se verá con mayor detalle a continuación, claro
está, sin profundizar en ningún lenguaje de programación, pues no es el objetivo.
La instrucción Desplegar tiene como objetivo mostrar información en la pantalla de

la computadora.
La instrucción Introducir tiene como objetivo el indicarle a la computadora que tome,
recoja o lea datos del teclado.
La instrucción Sí-entonces-sino es utilizada para ejecutar grupos de instrucciones
dependiendo del resultado que arroje una expresión lógica, es decir, Sí la expresión lógica es
verdadera entonces ejecuta el primer grupo de instrucciones sino es así ejecuta el segundo
grupo de instrucciones.
La sentencia En Caso, es utilizada para ejecutar un grupo de instrucciones específico
dependiendo del valor o condición de una o más variables en una expresión lógica, o bien, del
resultado de una o más expresiones lógicas.
La sentencia Para-Hasta-Siguiente, tiene como objetivo ejecutar un grupo de
instrucciones o sentencias un determinado número de veces.
La sentencia Hacer-Mientras, es similar a la anterior, pero en este caso el número de
veces que se ejecute el grupo de instrucciones es indeterminado y dependerá del resultado de
una expresión lógica, la cual se evalúa primero.
La sentencia Hacer-Hasta, es parecida a la anterior pero, en esta, se evalúa la expresión
lógica después de que se ejecuto el grupo de instrucciones al menos una vez.
La captura de la codificación es la introducción de las instrucciones escritas en un

lenguaje de programación, en la computadora. Este trabajo normalmente lo realiza el personal

de Captura de datos, o bien el auxiliar del programador, cuando se labora en una empresa de
gran tamaño, y que en su estructura estén considerados estos puestos; pero si no es así, la realiza
el Técnico o Ingeniero que desarrollo los programas.
Cuando el programador ya tiene suficientes “horas de vuelo”, inclusive omite todos los
puntos anteriores y directamente codifica “al vuelo”, sin embargo, es recomendable, para el
principante no omitir ningún paso, hasta que se sienta lo suficientemente experimentado para
hacerlo.
Y, aún cuando un programador tenga suficiente experiencia, siempre es aconsejable
desarrollar los pasos anteriores, inclusive aún cuando ya tenga funcionando el programa en el
sistema, puesto que todo eso servira como documentación del programa y sustentará la
información global de un sistema más complejo.
Una vez que se ha codificado un programa, es necesario probarlo, para ello

introduciremos datos que serán procesados y de los cuales previamente conocemos el resultado;
para esto debemos realizar el proceso a mano con cuando menos, dos series de datos de entrada
hasta obtener los resultados finales. El objetivo de dichas pruebas es la detección o localización
de errores en nuestro programa.
TIPOS DE ERRORES
Existen dos tipos de errores, del programador, que se pueden presentar durante el
desarrollo de un programa: Errores de sintaxis y errores de lógica. Los primeros, la mayoría de
las veces son fáciles de detectar y localizar, ya que la mayoría de los traductores nos indican,
aproximadamente, donde está el error. Estos errores generalmente se cometen durante la captura
de la codificación, y casi nunca alteran la lógica del programa, aunque en ocasiones puede
existir un error de sintaxis que no detecte el traductor y altere la lógica de nuestros programas,
pero esto resulta ser en casos muy raros (en lo personal me paso en una ocasión con GwBasic).
En el segundo caso, con los errores de lógica, debemos preocuparnos un poco mas, ya
que estos errores son difíciles de detectar y localizar, y vienen de malos planteamientos en la
resolución del problema, así que en caso de presentarse, deberemos revisar la resolución del
problema desde el principio y los planteamientos que se especificaron al inicio de la resolución,
hasta localizar el error.
Por último, otro tipo de errores, no imputables al programador, que debemos contemplar
y prever, son los que se generan en tiempo de ejecución (cuando la aplicación o programa está
en marcha),.
En tiempo de ejecución, si el usuario intenta una operación que el sistema o programa no
puede realizar, entonces se produce lo que se conoce como un error en tiempo de ejecución.
Supongamos, por ejemplo, que vamos a hacer que nuestra aplicación vuelque (grabe) alguna
información a un disco flexible, o incluso a otro disco fijo (también llamado duro). ¿Qué tipos
de errores podríamos anticipar? Que dicha unidad no exista, que el disco se encuentre lleno o
que el disco no se encuentre formateado. Puede que queramos escribir código que se refiera a un
archivo de datos y luego renombremos el archivo sin actualizar nuestro código: aunque nuestra
sintaxis sea correcta, resulta que el objeto o archivo no existe y se producirá un error en tiempo
de ejecución.

Los errores en tiempo de ejecución son habitualmente más difíciles de arreglar que los
errores de sintaxis, simplemente porque los errores en tiempo de ejecución pueden ser
ocasionados por múltiples razones. Además, las fuentes de los errores en tiempo de ejecución
no siempre serán obvias; a menudo tendremos que hacer algunas verificaciones para
encontrarlos. Por ejemplo, puede darse el caso de que una aplicación funcione bien bajo ciertas
circunstancias, puede que no lo haga si un usuario introduce de manera accidental un tipo de
datos erróneo. Tendremos que ser capaces de crear rutinas de tratamiento de errores para
interceptar dichos errores en tiempo de ejecución y actuar de manera especifica sobre ellos,
dependiendo del tipo que sean.
CONTROL DE ERRORES EN TIEMPO DE EJECUCION.
Al controlar los errores en tiempo de ejecución, haremos que nuestra aplicación sea más
tolerante con los errores que se encuentre. Podremos tratar estos errores utilizando rutinas de
tratamiento de errores, haciendo así que nuestra aplicación parezca más robusta y permitiendo
salidas de programa más elegantes cuando se produzca lo inesperado.
Las aplicaciones que controlan errores en tiempo de ejecución podrán manejar los
errores de usuario más comunes sin necesidad de parar la aplicación. Cuanto más habilidad
tengamos de anticipar los errores convencionales (tales como que nuestra aplicación esté
esperando que el usuario introduzca un número y éste introduce un carácter) y protegernos
frente a ello, menos posibilidades tendrá nuestra aplicación de interrumpirse. Por ejemplo, en
una situación en la cual nuestra aplicación está esperando que el usuario introduzca un número,
podríamos utilizar una rutina de tratamiento de errores que solicite al usuario a que inserte un
número en vez de un carácter alfabético.
CIERRE DE LA APLICACIÓN EN FORMA ADECUADA.
En aquellas ocasiones en las que una rutina de tratamiento de errores no pueda resolver
un error en tiempo de ejecución, todavía podrá ejecutar importantes acciones, tales como cerrar
cualquier archivo de datos abierto (y potencialmente guardando considerables cantidades de
datos que de manera contraria se perderían). En el ejemplo anterior, si el usuario no introduce
un número cuando se le solicita, la aplicación se podría cerrar, de tal manera que no le esté
preguntando continuamente al usuario que introduzca un número. Procure generar salidas
delicadas al crear su rutina de tratamiento de errores.
En otras palabras, para prever los errores en tiempo de ejecución, debemos pensar en los
posibles errores que podría generar el usuario e intentar hacer programas a prueba de usuarios
novatos, por no decir lo que me decían mis maestros (ahí te lo dejo a la imaginación).
La depuración de un programa, es en sí, el proceso de localización y corrección de los

errores detectados. Cuando se ha localizado un error de sintaxis, basta con colocar el cursor
donde el traductor nos lo indica, y corregirlo de acuerdo a la sintaxis de la instrucción.
Cuando se ha detectado un error de lógica, el proceso de depuración resulta ser muy
complicado ya que, es muy poco probable (casi imposible) que un error de sintaxis haya
modificado la lógica de nuestro programa, pero aun así, lo primero que debemos hacer es
obtener un listado impreso del programa para revisarlo a conciencia, y en caso de ser necesario

hacer una "corrida de escritorio" (simular manualmente la ejecución de cada instrucción)
directamente con la codificación del programa (la corrida será únicamente con el segmento que
realiza el proceso en sí).
Otra forma de localizar un error de lógica, es intercalar algunas instrucciones de
despliegue, en algunos puntos del programa, tratando de que se nos muestren los valores de las
variables que utilizamos y en las cuales se nos muestra el error (dichas instrucciones serán
temporales). En él ultimo de los casos, para detectar un error, ejecutaremos una a una las
instrucciones del programa para observar los resultados que arroja; y si con esto no se localiza el
error, se deberá revisar en su totalidad la resolución del problema desde el primer punto, hasta
eliminar todos los errores.
Actualmente, la gran mayoría de los traductores traen consigo, una opción llamada
Depurador, que, sinceramente nos ayuda bastante si lo sabemos aprovechar; pues nos permite
ejecutar instrucción por instrucción y ver los valores almacenados en cada variable, entre otras
muchas facilidades que nos brinda.
Después de una depuración, se deberá probar nuevamente el programa, y depurarlo si
existen errores, y así sucesivamente, hasta que el programa funcione correctamente, y no se
detecte ningún error de sintaxis o de lógica, o se crea que se hayan previsto los posibles errores
en tiempo de ejecución que se pudieran presentar.
En la actualidad debemos considerarnos afortunados, ya que los traductores cuentan con
una opción para depurar10 o eliminar errores, y estas opciones nos permiten llevar un
seguimiento del contenido de las variables en nuestro programa, así como ejecutar línea a línea
el mismo, con el fin de evitar las “corridas de escritorio” y encontrar más rápidamente los
errores11, para corregirlos al momento.
Una vez que se ha probado el programa y no se han detectado errores de ningún tipo;
antes de integrarlo a un sistema de información, debemos ejecutarlo a manera de prueba,
durante un buen período de tiempo, con copias de la información utilizada en el sistema, para
evitar que la información original pueda ser dañada por algún error que haya pasado
desapercibido.
Después que el programa ha estado funcionando correctamente, trabajando con copias
de la información del sistema, y arrojado resultados satisfactorios, entonces podremos integrarlo
al sistema principal de información, para que pueda trabajar con la información original y
complementar el sistema, resolviendo así el problema planteado.
10
Debug en inglés. Proviene de BUG, que significa bicho, y con la preposición DE, podría traducirse textualmente como
desbichar, quitar bichos, o literalmente quitar errores.
11
Bugs en inglés, que aunque quiere decir bichos, se tomo para denominar técnicamente así a los errores, los cuales se
consideran como plagas, tales como la de los insectos o bichos.

4.2. - Simbología de diagramas de bloques o diagramas de flujo de sistemas.
Aunque hay muchos tipos y formas de diagramas de bloques, así como símbolos, a
continuación se presentarán los más utilizados, así como el significado o descripción que le dan
la mayoría de los programadores.
SIMBOLO DESCRIPCIÓN
Proceso
Automático
Proceso
Manual
Almacenamiento en medio
magnético en general
(archivos)
Almacenamiento físico
(archivo físico manual)
magnético (disco duro o fijo)
magnético (cinta magnética)
Entrada/Salida general de
información
Salida de información,
reporte por impresora

4.3. - Simbología de diagramas de flujo.
De la misma manera que en el punto anterior, aunque hay muchos tipos y formas de
diagramas de flujo, así como símbolos, a continuación se presentarán los más conocidos, así
como el significado o descripción que le dan la mayoría de los programadores.
SIMBOLO DESCRIPCIÓN
OPERACION
ENTRADA/SALIDA DE
INFORMACION (ARCHIVOS)
SALIDA DE DATOS POR IMPRESORA
CONECTOR
TOMA DE DECISION
SUBRUTINA
(PROCEDIMIENTO O FUNCION)
ENTRADA DE DATOS POR TECLADO
INICIO/FIN DEL DIAGRAMA
SALIDA DE DATOS POR PANTALLA
CONECTOR FUERA DE PÁGINA

4.4. - Recomendaciones para el desarrollo de diagramas.
4.4.1. - Diagramas de bloques o diagramas de flujo de sistemas.
RECOMENDACIONES PARA EL DESARROLLO DE

DIAGRAMAS DE BLOQUES
O
DIAGRAMAS DE FLUJO DE SISTEMAS
Realmente, no se puede decir que exista alguna regla escrita acerca de la diagramación,
pero si se establecen ciertas recomendaciones, como las que se indican:
1. - No interceptar (cruzar) líneas de flujo de información.

2. - Usar claves dentro de los símbolos, y especificar la nomenclatura correspondiente.
4.4.2. - Diagramas de flujo.
RECOMENDACIONES PARA EL DISEÑO DE DIAGRAMAS DE FLUJO
1. El símbolo de inicio y fin, solo se utilizara dos veces, al principio y al final del
diagrama.
2. La línea de flujo debe "tocar" tanto al símbolo del que sale como al símbolo al que
llega.
3. Pueden existir varios conectores de "salida", pero solo uno de "llegada"; con el
mismo carácter o símbolo dentro de ellos.
4. El carácter que esta dentro del conector de salida debe ser igual al carácter dentro del
conector de llegada, donde continuara el flujo del diagrama.
5. Al diagramar trataremos siempre que el flujo sea de arriba hacia abajo y de izquierda
a derecha.
6. A cualquier símbolo solo llegara una línea de flujo y saldrá de éste una línea de
flujo; con excepción del símbolo de toma de decisión, al cual llega una línea de flujo
y salen dos de él; y también el conector y el símbolo de inicio y fin, del cual
solamente saldrá una línea o llegara una línea de flujo.
7. No interceptar (cruzar) líneas de flujo.

4.5. - Resolución de problemas aplicando la Técnica de diseño general o elemental.
EJEMPLO DE RESOLUCION DE PROBLEMAS USANDO LA
TECNICA DE DISEÑO GENERAL O ELEMENTAL

(Deberá especificarse por el maestro el problema en sí).
- Diseñar un programa que solicite los siguientes datos de un empleado: Ficha, nombre, puesto,
antigüedad, sueldo diario, días trabajados; que calcule y muestre el sueldo total neto a pagar, así como
las cuotas por pagar por el patrón por sus prestaciones sobre su sueldo total bruto: un 3 % del Seguro
Social, 1 % de Apoyo a la Educación, 5 % de Infonavit, 2 % de I.S.P.T. (Impuesto Sobre Productos del
Trabajo; y 3 % del SAR (Sistema de Ahorro para el Retiro. Sí el empleado tiene 5 años o más de
antigüedad, se le dará un bono del 5 % sobre su sueldo total bruto.
DATOS DE SALIDA: Total neto a pagar, salario total a pagar, Cuotas del I. M. S. S., de Apoyo
a la Educación, del Infonavit, del S.A.R., Retención del I.S.P.T., Importe del Bono.
DATOS DE ENTRADA: Nombre, puesto, antigüedad, salario diario, días trabajados.
1. Solicitar los datos del empleado.

2. Calcular el salario total a pagar.
3. Calcular las cuotas por pagar.
4. Calcular el Total Neto a Pagar.
5. Mostrar los importes del sueldo total neto a pagar, sus prestaciones y deducciones.
1. Inicializar variables.
2. Pedir el Nombre.
3. Pedir el Puesto.
4. Pedir la Antigüedad.
5. Pedir el Salario Diario.
6. Pedir los Días Trabajados.
7. nSalarioTotalAPagar = nDiasTrabajados*nSalarioDiario
8. nImss = nSalarioTotalAPagar * 0.03
9. nApoyoEducación = nSalarioTotalAPagar * 0.01
10. nInfonavit = nSalarioTotalAPagar * 0.05
11. nSar = nSalarioTotalAPagar * 0.03
12. nIspt = nSalarioTotalAPagar * 0.02

13. ¿ nAntigüedad => 5 años ?
SI: nBono = nSalarioTotalAPagar * 0.05
NO: nBono = 0
14. nTotalAPagar = nSalarioTotalAPagar + nBono
15. Mostrar: nImss
16. Mostrar: nApoyoEducación
17. Mostrar: nInfonavit
18. Mostrar: nSar
19. Mostrar: nIspt, nBono
20. Mostrar: nSalarioTotalAPagar
21. Mostrar: nTotalAPagar.
1. Desarrollar el diagrama de bloques.
Datos del Calculo del Calculo de las Total de deducciones,

Empleado Sueldo deducciones y prestaciones y Total a
prestaciones Pagar

2. Diseñar el diagrama de flujo.
1 2
INICIO
“Salario nInfonavit =
INICIALIZAR Diario:” nSalTotAPag * 0.05
VARIABLES
“Dame los nSar =

siguientes datos:”
nSalDia nSalTotAPag * 0.03
“Días
“Nombre:” Trabajados:” nIspt =
nSalTotAPag * 0.02
cNombre nDiasTrab NO
¿ nAntig >= 5 ? 3
“Puesto:”
nSalTotAPag =
SI
nDiasTrab * nSalDia
nBono =
nSalTotAPag * 0.05
cPuesto
nImss = 3
nSalTotAPag * 0.03
nTotNetoAPagar =
“Antigüedad:” nSalTotAPag + nBono
nApEduc =
nSalTotAPag * 0.01
nAntig “Resultados:”,
“IMSS:”; nImss, “ISPT:”; nIspt,
“SAR:”; nSar, “Ap. Educ.:”; nApEduc,
“Infonavit:”; nInfonavit,
2
1 “Bono:”; nBono,
“Sal. Total a Pagar:”; nSalTotAPag,
“Tot. Neto a Pagar:”; nTotNetoAPagar
FIN

3. Desarrollar el algoritmo o pseudo código.
NOTA: Por esta única ocasión, tanto en el algoritmo como en las codificaciones que se veran a
continuación, se resaltan en rojo las palabras reservadas y los operadores; así mismo se resaltan en
azul los nombres de variables. El objetivo es que establezcas la relación entre las palabras utilizadas
en el algoritmo y su equivalente en los diferentes lenguajes de programación.
2. Desplegar "Dame los siguientes datos:"
3. Desplegar "Nombre:"
4. Introducir cNombre
5. Desplegar "Puesto:"
6. Introducir cPuesto
7. Desplegar "Antigüedad:"
8. Introducir nAntig
9. Desplegar "Salario Diario:"
10. Introducir nSalDia
11. Desplegar "Días Trabajados:"
12. Introducir nDiasTrab
13. nSalTotAPag = nDiasTrab * nSalDia
14. nImss = nSalTotAPag * 0.03
15. nApEduc = nSalTotAPag * 0.01
16. nInfonavit = nSalTotAPag * 0.05
17. nSar = nSalTotAPag * 0.03
18. nIspt = nSalTotAPag * 0.02
19. Sí nAntig >= 5 entonces
nBono = nSalTotAPag * 0.05
sino
nBono = 0
20. nTotNetoAPagar = nSalTotAPag + nBono
21. Desplegar “Resultados:”
22. Desplegar “IMSS:”; nImss
23. Desplegar “ISPT:”; nIspt
24. Desplegar “SAR:”; nSar
25. Desplegar “Ap. Educ.:”; nApEduc
26. Desplegar “Infonavit:”; nInfonavit
27. Desplegar “BONO:”; nBono
28. Desplegar “Sal. Total a Pagar:”; nSalTotAPag
29. Desplegar “Tot. Neto a Pagar:”; nTotNetoAPagar
30. FIN.
Esta actividad se realiza cuando se domina algún lenguaje de programación, por ejemplo Basic,
Pascal, C, Clipper, etc.
A continuación presentare la codificación del programa anterior en algunos lenguajes.

Lenguaje Basic.
10 REM Programa EJEMGBAS.BAS

20 REM Método de Diseño General o Elemental.
30 REM Programa Principal.
40 REM ***********************************************************************
50 REM Inicializando variables.
60 REM ***********************************************************************
70 CNOMBRE$="":CPUESTO$="":NANTIG=0:NSALDIA=0:NDIASTRAB=0:NSALTOTAPAG=0
80 NIMSS=0:NAPEDUC=0:NINFONAVIT=0:NSAR=0:NISPT=0:NBONO=0:NTOTNETOAPAGAR=0
90 CLS 'Borra la pantalla
100 REM ***********************************************************************
110 REM Solicitud de datos al usuario.
120 REM ***********************************************************************
130 PRINT "Dame los siguientes datos:"
140 PRINT "Nombre:";
150 INPUT CNOMBRE$
160 PRINT "Puesto:";
170 INPUT CPUESTO$
180 PRINT "Antigüedad:";
190 INPUT NANTIG
200 PRINT "Salario Diario:";
210 INPUT NSALDIA
220 PRINT "Dias Trabajados:";
230 INPUT NDIASTRAB
240 REM ***********************************************************************
250 REM Cálculos de ingresos y cuotas.
260 REM ***********************************************************************
270 NSALTOTAPAG = NDIASTRAB * NSALDIA
280 NIMSS = NSALTOTAPAG * .03
290 NAPEDUC = NSALTOTAPAG * .01
300 NINFONAVIT = NSALTOTAPAG * .05
310 NSAR = NSALTOTAPAG * .03
320 NISPT = NSALTOTAPAG * .02
330 IF NANTIG >= 5 THEN NBONO = NSALTOTAPAG * .05 ELSE NBONO = 0
340 NTOTNETOAPAGAR = NSALTOTAPAG + NBONO
350 REM ***********************************************************************
360 REM Despliegue de Resultados.
370 REM ***********************************************************************
380 PRINT "Resultados:"
390 PRINT "IMSS: ";NIMSS
400 PRINT "ISPT: ";NISPT
410 PRINT "SAR: ";NSAR
420 PRINT "Apoyo a la Educación: ";NAPEDUC
430 PRINT "INFONAVIT: ";NINFONAVIT
440 PRINT "Bono: ";NBONO
450 PRINT "Salario Total a Pagar: ";NSALTOTAPAG
460 PRINT "Total Neto a Pagar: ";NTOTNETOAPAGAR
470 END 'Fin del programa.

Lenguaje Quick Basic. (Podríamos considerar éste, como un dialecto del Basic).
REM Programa EJEGQBAS.BAS

REM Método de Diseño General o Elemental.
REM Programa Principal.
REM Inicializando variables.
cNombre$ = "": cPuesto$ = "": nAntig = 0: nSalDia = 0: nDiasTrab = 0

nSalTotAPag = 0: nImss = 0: nApEduc = 0: nInfonavit = 0: nSar = 0: nIspt = 0
nBono = 0: nTotNetoAPagar = 0
CLS 'Borra la pantalla.
REM Solicitud de datos al usuario.
PRINT "Dame los siguientes datos:"

PRINT "Nombre:";
INPUT cNombre$
PRINT "Puesto:";
INPUT cPuesto$
PRINT "Antigüedad:";
INPUT nAntig
PRINT "Salario Diario:";
INPUT nSalDia
PRINT "Días Trabajados:";
INPUT nDiasTrab
REM Cálculos de ingresos y deducciones.
nSalTotAPag = nDiasTrab * nSalDia

nImss = nSalTotAPag * .03
nApEduc = nSalTotAPag * .01
nInfonavit = nSalTotAPag * .05
nSar = nSalTotAPag * .03
nIspt = nSalTotAPag * .02
IF nAntig >= 5 THEN

nBono = nSalTotAPag * .05
ELSE
nBono = 0
END IF
nTotNetoAPagar = nSalTotAPag + nBono
REM Despliegue de Resultados.
PRINT "Resultados:"
PRINT "IMSS: "; nImss
PRINT "ISPT: "; nIspt
PRINT "SAR: "; nSar
PRINT "Apoyo a la Educación: "; nApEduc
PRINT "INFONAVIT: "; nInfonavit
PRINT "Bono: "; nBono
PRINT "Salario Total a Pagar: "; nSalTotAPag
PRINT "Total Neto a Pagar: "; nTotNetoAPagar
END

Lenguaje Pascal.
PROGRAM Ejemplo;
(* Programa EJEGPASC.PAS *)
(* Método de Diseño General o Elemental. *)
(* Programa Principal. *)
(* Especificación del dispositivo o unidad de salida *)
USES CRT; (* Usar el monitor –Catodic Ray Tube, Tubo de Rayos Catódicos- *)
(* Declarando variables. *)
VAR cNombre : STRING[10];

cPuesto : STRING[10];
nAntig : REAL;
nSalDia : REAL;
nDiasTrab : REAL;
nSalTotAPag : REAL;
nImss : REAL;
nApEduc : REAL;
nInfonavit : REAL;
nSar : REAL;
nIspt : REAL;
nBono : REAL;
nTotNetoAPagar : REAL;
BEGIN (* Inicio *)
(* Inicializando variables. *)
nAntig := 0;
nSalDia := 0;
nDiasTrab := 0;
nSalTotAPag := 0;
nImss := 0;
nApEduc := 0;
nInfonavit := 0;
nSar := 0;
nIspt := 0;
nBono := 0;
nTotNetoAPagar := 0;
CLRSCR; (* Borra la pantalla *)
(* Solicitud de datos al usuario. *)
WRITELN('Dame los siguientes datos:');

WRITE('Nombre: ');
READLN(cNombre);
WRITE('Puesto: ');
READLN(cPuesto);
WRITE('Antigüedad: ');
READLN(nAntig);
WRITE('Salario Diario: ');
READLN(nSalDia);
WRITE('Días Trabajados: ');
READLN(nDiasTrab);
(* Cálculos de ingresos y deducciones. *)

nSalTotAPag := nDiasTrab * nSalDia;
nImss := nSalTotAPag * 0.03;
nApEduc := nSalTotAPag * 0.01;
nInfonavit := nSalTotAPag * 0.05;
nSar := nSalTotAPag * 0.03;
nIspt := nSalTotAPag * 0.02;
IF nAntig >= 5 THEN

nBono := nSalTotAPag * 0.05
ELSE
nBono := 0;
nTotNetoAPagar := nSalTotAPag + nBono;
(* Despliegue de Resultados. *)
WRITELN('Resultados:');
WRITELN('IMSS: ',nImss:10:2);
WRITELN('ISPT: ',nIspt:10:2);
WRITELN('SAR: ',nSar:10:2);
WRITELN('Apoyo a la Educación: ',nApEduc:10:2);
WRITELN('INFONAVIT: ',nInfonavit:10:2);
WRITELN('Bono: ',nBono:10:2);
WRITELN('Salario Total a Pagar: ',nSalTotAPag:10:2);
WRITELN('Total Neto a Pagar: ',nTotNetoAPagar:10:2);
END.

Lenguaje Clipper12.
FUNCTION Ejemplo()
* Programa EJEGCLIP.PRG
* Método de Diseño General o Elemental.
* Programa Principal.
* Declarando e Inicializando variables.
LOCAL cNombre := " ", cPuesto := " ",;

nAntig := 0, nSalDia := 0, nDiasTrab := 0, nSalTotAPag := 0,;
nImss := 0, nApEduc := 0, nInfonavit := 0, nSar := 0,;
nIspt := 0, nBono := 0, nTotNetoAPagar := 0
CLS //Borra la pantalla.
* Solicitud de datos al usuario.
@ 1,10 SAY "Dame los siguientes datos:"

@ 2,10 SAY "Nombre:"
@ 2,30 GET cNombre
@ 3,10 SAY "Puesto:"
@ 3,30 GET cPuesto
@ 4,10 SAY "Antigüedad:"
@ 4,30 GET nAntig
@ 5,10 SAY "Salario Diario:"
@ 5,30 GET nSalDia
@ 6,10 SAY "Días Trabajados:"
@ 6,30 GET nDiasTrab
READ
* Cálculos de ingresos y deducciones.
nSalTotAPag := nDiasTrab * nSalDia

nImss := nSalTotAPag * .03
nApEduc := nSalTotAPag * .01
nInfonavit := nSalTotAPag * .05
nSar := nSalTotAPag * .03
nIspt := nSalTotAPag * .02
IF nAntig >= 5
nBono := nSalTotAPag * .05
ELSE
nBono := 0
END IF
nTotNetoAPagar := nSalTotAPag + nBono
* Despliegue de Resultados.
@ 8,10 SAY "Resultados:"

@ 9,10 SAY "IMSS: "
12
Aunque algunos programadores van muy lejos negándole el título de lenguaje a Clipper, eso es una verdad a medias. La
mayoría sabemos que los programas generados por Clipper son en realidad P-CODE, es decir pseudo código (muy
optimizado por cierto), que se interpreta en tiempo de ejecución, en lugar de ejecutarse directamente. Ese posible “defecto”
no resta valor alguno a una de las mejores y mas potentes herramientas de programación existentes en el mercado. Tanto que
inclusive ha incursionado en las tendencias de programación orientada al objeto y programación dirigida por eventos,
logrando con esto crear aplicaciones incluso para ambiente Windows. En el presente ejemplo, se utilizo la versión 5.2e

@ 9,35 SAY nImss
@ 10,10 SAY "ISPT: "
@ 10,35 SAY nIspt
@ 11,10 SAY "SAR: "
@ 11,35 SAY nSar
@ 12,10 SAY "Apoyo a la Educación: "
@ 12,35 SAY nApEduc
@ 13,10 SAY "INFONAVIT: "
@ 13,35 SAY nInfonavit
@ 14,10 SAY "Bono: "
@ 14,35 SAY nBono
@ 15,10 SAY "Salario Total a Pagar: "
@ 15,35 SAY nSalTotAPag
@ 16,10 SAY "Total Neto a Pagar: "
@ 16,35 SAY nTotNetoAPagar
RETURN

C++
/* Programa EJEMGC.C
Método de Diseño General o Elemental.
Programa Principal. */
#include <stdio.h> /* Incluir archivo stdio.h –stANDARd iNPUT oUTPUT. hEADING- */

/* Encabezado Normal o Universal de Entrada Salida*/
main () /* Inicio del programa principal */
{ /* Declarando e inicializando variables. */

char cNombre[10];
char cPuesto[10];
float nAntig = 0;
float nSalDia = 0;
float nDiasTrab = 0;
float nSalTotAPag = 0;
float nImss = 0;
float nApEduc = 0;
float nInfonavit = 0;
float nSar = 0;
float nIspt = 0;
float nBono = 0;
float nTotNetoAPagar = 0;
/* Solicitud de datos al usuario. */
printf("Dame los siguientes datos:\n");

printf("Nombre: ");
scanf("%s",cNombre);
printf("Puesto: ");
scanf("%s",cPuesto);
printf("Antigüedad: ");
scanf("%f",&nAntig);
printf("Salario Diario: ");
scanf("%f",&nSalDia);
printf("Días Trabajados: ");
scanf("%f",&nDiasTrab);
/* Cálculos de ingresos y deducciones. */
nSalTotAPag = nDiasTrab * nSalDia;

nImss = nSalTotAPag * 0.03;
nApEduc = nSalTotAPag * 0.01;
nInfonavit = nSalTotAPag * 0.05;
nSar = nSalTotAPag * 0.03;
nIspt = nSalTotAPag * 0.02;
if(nAntig >= 5)
nBono = nSalTotAPag * 0.05;
else
nBono = 0;
nTotNetoAPagar = nSalTotAPag + nBono;
/* Despliegue de Resultados. */
printf("Resultados:\n");
printf("IMSS: %f\n",nImss);
printf("ISPT: %f\n",nIspt);
printf("SAR: %f\n",nSar);

printf("Apoyo a la Educación: %f\n",nApEduc);
printf("INFONAVIT: %f\n",nInfonavit);
printf("Bono: %f\n",nBono);
printf("Salario Total a Pagar: %f\n",nSalTotAPag);
printf("Total Neto a Pagar: %f\n",nTotNetoAPagar);
} /* Fin del programa. */
Esta actividad, consiste en introducir las instrucciones del programa ya codificado, en la

computadora. Generalmente, cuando ya se tiene un poco de experiencia en la programación, el
programador captura directamente el código.
En el disquete que acompaña a esta obra, vienen los códigos fuentes del programa de ejemplo,
así como los ejecutables del mismo, en su respectivo lenguaje.

Se realiza esta actividad, tras terminar la captura del programa.
Es la corrección de los errores detectados durante las pruebas efectuadas en la actividad

anterior.
Después de estar probado el programa, y de estar ejecutándolo durante un tiempo, a prueba, con
copias de la información original, el programa se incorpora al sistema principal, donde trabajara con
información original.

5. - Diagramas de flujo.
5.1. - Tipos de diagramas de flujo.
5.1.1. - Diagramas de flujo lineales.
Los diagramas de flujo lineales, son aquellos en los cuales, el conjunto de

instrucciones se ejecutan una sola vez.
INICIO
OPERACIÓN 1
OPERACIÓN 2
OPERACIÓN 3
FIN
5.1.2. - Diagramas de flujo cíclicos.
Los diagramas de flujo cíclicos, son aquellos en los cuales, un conjunto de

instrucciones o todas se ejecutan una cantidad determinada o indeterminada de veces.
5.2. - Estructuras de diagramas de flujo lineales.
5.2.1. - Estructura de secuencia.
Una estructura de secuencia se representa ya sea por medio del símbolo de

proceso o el símbolo de proceso predefinido (subrutinas, procedimientos o funciones).
También es posible tener símbolos múltiples de proceso o de proceso predefinido dentro
de una sola estructura de secuencia. Sin embargo, existe solo una entrada a una
estructura de secuencia y una salida a partir de ésta; éste es un punto muy importante que
se cumple para todas las estructuras. En la siguiente figura se muestra una estructura de
secuencia que contiene pasos múltiples.

5.2.2. - Estructura de decisión.
El símbolo de decisión representa una decisión que se efectúa y las rutas lógicas
alternativas que deben seguirse como resultado. Existe una entrada a un símbolo de
decisión y dos salidas a partir de él; sin embargo, sigue existiendo solo una entrada a la
estructura de decisión y una salida a partir de esta. El símbolo de decisión es solo una
parte de la estructura de decisión. Este punto se muestra en la siguiente figura.
5.2.3. - Ramificaciones.
Un tipo común de decisión en varios sentidos depende de la forma en que el

contenido de una variable cambia, y las diversas opciones que se presenten, este es el
caso de la estructura "EN CASO", en la cual puede tomarse una de varias

ramificaciones, dependiendo del contenido de una variable o del resultado de una
expresión booleana.
CONDICION CONDICION CONDICION CONDICION CONDICION
5.3. - Estructuras de diagramas de flujo cíclicos.
5.3.1. - Creación de ciclos, iteraciones o bucles.
En diagramas de flujo en donde se están leyendo registros o datos múltiples (las

más de las veces) siempre se efectúa una ramificación de regreso a la verificación de
BANDERA-FIN después de leer otro registro al final de la rutina PROCESO. Este
proceso de re-utilizar el mismo conjunto de lógica para cada registro que se procesa es
un ejemplo de CICLO. La creación de ciclos consta de ejecutar cualquier serie de
instrucciones en forma repetida. Sin embargo, los ciclos no tienen que incluir toda la
rutina de PROCESO; pueden cubrir solo una pequeña parte de la rutina (PROCESO u
otra). En algunas ocasiones a los bucles también se les llama como ANILLOS.
5.3.2. - Pasos de un ciclo o bucle.
En cualquier proceso de ciclo están presentes algunos pasos estándar. Estos

pasos, excepto el primero, pueden encontrarse en casi cualquier orden que se necesite
para producir el efecto deseado. La principal diferencia es en cuanto a la parte del ciclo
en que se efectúan la modificación y la prueba, lo que provocara que el ciclo se conozca
como controlado desde el inicio o controlado desde la salida. Dependiendo del lenguaje
que se este utilizando para implantar el diagrama de flujo, el proceso de inicialización,
modificación y prueba tal vez requiera dos o más instrucciones reales de programación
para lograr las acciones necesarias.
1. Inicialización: Paso en el que se da un valor inicial a los elementos. Estos

elementos se utilizaran para determinar cuando puede concluir el ciclo. Esto
puede implicar trasladar un valor como UNO a un área.
2. Procesamiento: Paso o pasos en el ciclo en los que el procesamiento real

presente dentro del ciclo se efectúa.
3. Modificación: Paso del ciclo en que efectúa algún tipo de alteración al

elemento que se inicializo en el paso 1. Esto podrá ser sumar UNO a un
contador, leer el siguiente registro disponible o modificar el valor de alguna

variable.
4. Prueba: Paso del ciclo en el que se prueba el valor de un elemento (como

determinar si el registro es de datos o el valor de un contador ha excedido un
valor dado) para determinar si el ciclo debe continuarse o concluirse.
5.3.3. - Ciclos o bucles anidados.
También es posible que un diagrama de flujo contenga múltiples ciclos y que un

ciclo este dentro de otro más grande. Cuando un ciclo esta dentro de otro más grande, se
dice que el que se encuentra en el interior esta anidado.
5.3.4. - Estructura de " para hasta ".
Esta estructura es muy especial ya que el número de ciclos que se efectuaran es,
normalmente, fijo; y se basa en la verificación de una variable numérica; ejecutándose el
proceso hasta que dicha variable numérica excede el número establecido de ciclos.
ENTRADA
V=I VERDADERO
SALIDA
V > F
FALSO
INC
PROCESO
En este tipo de bucle, a la VARIABLE (V) numérica se le asigna el valor

INICIAL (I) a la cual se le sumara el INCREMENTO (INC) después de cada ejecución
de las instrucciones del PROCESO hasta que alcance un valor mayor que el valor
FINAL (F).

El símbolo aquí presentado, es exclusivo de este tipo de bucle; desglosándolo se
tendría el siguiente diagrama de flujo:
ENTRADA
V=I
A
VERDADERO
V>F SALIDA
FALSO
PROCESO
INC
Como es de notar, el primer diagrama es más compacto, razón por la cual es el

más utilizado cuando se hace necesario diagramar este tipo de bucle.
El algoritmo se escribiría de la siguiente manera:
ESPAÑOL INGLÉS
Entrada Entrada
PARA V = I HASTA F INCREMENTO INC FOR V = I TO F STEP INC
PROCESO PROCESO
SIGUIENTE NEXT
Salida Salida
Donde la sentencia SIGUIENTE (NEXT), implica que automáticamente se suma

INC al valor de la variable V y regresa el flujo del programa a la sentencia PARA (FOR)
donde se evalúa la condición.
En este punto, a propósito y de ahora en adelante, se mostrará el algoritmo de las
estructuras básicas, en el idioma inglés, para dar una aproximación a lo que será el
código en algún lenguaje de programación, ya que será común el manejo de este idioma
en casi todos los lenguajes de programación.

5.3.5. - Estructura de " hacer mientras ".
Estas estructuras se utilizan para procesos cíclicos. En la siguiente figura se

muestra la estructura "hacer mientras" (do while ó while do), en donde el proceso se
realiza mientras la condición en el símbolo de toma de decisión es verdadera; y cuando
resulta ser falsa, se sale del ciclo.
ENTRADA
A
NO
CONDICION SALIDA
SI
PROCESO
En el segmento de diagrama mostrado, el PROCESO se realizara mientras la

CONDICION sea verdadera (SI); cuando sea falsa (NO), se dará por terminado el ciclo o
bucle y se saldrá de esa línea de lógica.
ESPAÑOL INGLÉS
Entrada Entrada
HACER MIENTRAS Condición=Verdadera DO WHILE Condición=Verdadera
PROCESO PROCESO
FIN MIENTRAS END WHILE
Salida Salida
El equivalente al conector A del diagrama es el FIN MIENTRAS (END

WHILE); y esto implica que dicha sentencia hace que regrese el flujo del programa a la
sentencia HACER MIENTRAS (DO WHILE) donde se evalúa la condición.

5.3.6. - Estructura de " hacer hasta ". (repetir hasta)
Esta estructura es similar a la estructura "hacer mientras", solo que la prueba de

la condición se efectúa después de realizar, al menos una vez, el proceso. En la siguiente
figura se muestra la estructura "hacer hasta" (repeat until - repetir hasta).
ENTRADA
A
PROCESO
NO
CONDICION A
SI
SALIDA
En el segmento de diagrama mostrado, el PROCESO se REPETIRA HASTA

que la condición sea verdadera (SI); y si ésta es falsa (NO), se efectuará nuevamente el
PROCESO.
Como se puede observar, al estar la evaluación de la condición después del
proceso, esto asegura que el PROCESO se realice forzosamente, como mínimo, una
vez.
ESPAÑOL INGLÉS
Entrada Entrada
REPETIR REPEAT
PROCESO PROCESO
HASTA Condición=Verdadera UNTIL Condición=Verdadera
Salida Salida
Otra forma podría ser:
ESPAÑOL INGLÉS
Entrada Entrada
HACER DO
PROCESO PROCESO

VUELTA HASTA Condición=Verdadera LOOP UNTIL Condición=Verdadera
Salida Salida
La sentencia HASTA o VUELTA HASTA, además de evaluar la Condición; en

caso de que sea falsa regresara el flujo del programa a la instrucción REPETIR o
HACER, si es verdadera, saldrá del bucle.
O bien, como caso especial, y usando lógica inversa:
Entrada Entrada
HACER DO
PROCESO PROCESO
MIENTRAS Condición=Falsa WHILE Condición=Falsa
Salida Salida
Que también podría quedar como:
Entrada Entrada
HACER DO
PROCESO PROCESO
MIENTRAS Condición<>Verdadero WHILE Condición<>Verdadero
Salida Salida
Y como puede observarse, cuando la condición alcance el valor Verdadero,

terminará el bucle. En otras palabras, mientras la condición sea falsa, se ejecutará el
bucle, y en cuanto sea verdadera, como en los casos anteriores, se saldrá del bucle.

6. - Herramientas de programación.
Las herramientas de programación, como le llamamos algunos programadores, no son otra cosa
que aquellos conceptos y operaciones básicas de lógica utilizadas en los programas; las cuales son
fórmulas lógicas muy sencillas, frecuentemente utilizadas en cualquier programa.
6.1. - El contador.
Un contador es una variable numérica cuyo valor se incrementa o decrementa en una

cantidad constante en el flujo de un programa, y normalmente se utiliza en los bucles. Su
estructura es la siguiente:
VARIABLE CONTADOR = VARIABLE CONTADOR + INCREMENTO
Ejemplos:
nC = nC + 1 Cuenta de uno en uno.

nValor = nValor + 2 Cuenta de dos en dos.
nNum = nNum + 3 Cuenta de tres en tres.
6.2. - El acumulador o sumador.
Un acumulador o sumador es una variable numérica cuyo valor se incrementa o

decrementa en una cantidad variable, representada por otra variable, en el flujo de un programa,
y normalmente se utiliza en los bucles. Su estructura es la siguiente:
VARIABLE ACUMULADOR = VARIABLE ACUMULADOR + VARIABLE INCREMENTO
Ejemplos:
nC = nC + nS
nValor = nValor + nCant
nNum = nNum + nPar

6.3. - La bandera o indicador.
Es una variable de tipo booleano o, en ocasiones, tipo carácter, la cual solo adquiere uno
de dos valores, considerándolos como 0 (apagado) ó false, y 1 (encendido) ó true. Dicha
variable se utiliza en estructuras de control en una bifurcación condicional, tal y como se
muestra en el siguiente ejemplo:
ENTRADA
BANDERA = Valor
lógico 1
PROCESO A
BANDERA NO ó SI
Operador lógico
PROCESO B
Valor lógico 2
SI ó NO
A
A
SALIDA
La aplicación práctica de una BANDERA o INDICADOR, es la de condicionar una

acción dentro de nuestro programa, tal y como se muestra en el diagrama. Se dice que la
BANDERA se “enciende” (TRUE o 1) cuando se ha logrado una condición o resultado y se
“apaga” (FALSE o 0) en caso contrario. Cuando el valor de la BANDERA es modificada, se
efectuará o no un proceso alternativo, o bien se sale o no, de un bucle o programa.
En el diagrama del ejemplo, se inicializa la variable BANDERA a un Valor lógico 1
(TRUE o FALSE, 1 o 0), posteriormente se realiza el PROCESO A, el cual dentro de su lógica
modifica o no el valor de la variable BANDERA, y al terminar el PROCESO A, se compara el
valor de la variable BANDERA con el Valor lógico 2 (TRUE o FALSE, 1 o 0), y dependiendo
del resultado que arroje se ejecutara o no, el PROCESO B alternativo.

6.4. - Salida de un programa por opción.
En este tipo de herramienta, se establece una rutina, que consiste en preguntar al usuario
si desea continuar con un proceso o finalizar, inmediatamente se verifica la respuesta y se
ejecuta la acción correspondiente, que es continuar con la ejecución del proceso o finalizar.
El siguiente diagrama muestra uno ejemplo de esta salida.
ENTRADA
PROCESO
“¿ Desea
Continuar
(S/N) ?
cRespuesta
cRespuesta SI
= A
“S”
NO
SALIDA
En el despliegue se colocara el mensaje de acuerdo al proceso que se este desarrollando,

y en la toma de decisión el carácter puede ser “N”, aunque esto invertiría el orden de las salidas
(SI y NO).

6.5. - Salida de un programa por centinela.
Una salida por centinela, se establece cuando una condición o condiciones se cumplen o
no, lo cual genera en su caso la finalización del programa o no, dependiendo de la condición que
establezca el programador. A continuación se ilustra un diagrama mostrando la lógica de
operación de una salida por centinela.
ENTRADA
PROCESO
SI ó NO
CONDICIÓN A
NO ó SI
SALIDA
En el diagrama, el PROCESO puede solicitar datos por teclado o bien leer datos de un
archivo, y cuando se tome un dato determinado, este se compara en la CONDICIÓN el cual
contendrá un valor determinado, y en función del resultado de la expresión lógica
(CONDICION) se saldrá o no del programa.
6.6. – Subrutinas, procedimientos y funciones.
6.6.1.- Subrutinas.
Una Subrutina, es un grupo de instrucciones que efectúa una parte identificable del
programa general. Y normalmente se crean para evitar la codificación repetitiva de grupos de
instrucciones a lo largo del programa. Son ejemplos representativos de elementos que podrían
encontrarse en subrutinas:
1. Rutinas de mantenimiento.
2. Rutinas de encabezado.
3. Rutinas de cálculo.
4. Rutinas de procesamiento de tablas.
5. Rutinas de edición.
6. Inicializar variables o Colocar contadores en cero.
El diagrama que sigue, muestra en líneas discontinuas lo que sería el flujo de un

programa que llama a una subrutina.
ENTRADA
PROCESO
SUBRUTINA
A SUBRUTINA
A
PROCESO DE LA
SUBRUTINA
PROCESO
RETORNO
SUBRUTINA
A
PROCESO C
SALIDA
Como se puede observar en el diagrama, la llamada a la Subrutina transfiere el flujo del

programa a otro punto donde inicia la Subrutina, y al término de esta, se retorna
automáticamente el flujo a la instrucción que sigue del lugar donde se hizo la llamada.
Las subrutinas pueden ser internas o externas. Las internas, están físicamente en el
programa y este las utiliza en el procesamiento. Las subrutinas externas las usa el programa pero
no son físicamente parte de él y de alguna forma debe efectuarse el acceso a ella para que
puedan utilizarse.

Archivo de Código de Programa con llamada a Subrutina Interna.
INICIA CODIGO DEL PROGRAMA.

…
INICIA CODIGO DE LA SUBRUTINA INTERNA.
…
…
FIN DEL CODIGO DE LA SUBRUTINA INTERNA.
CONTINUA CODIGO DEL PROGRAMA.
…
…
LLAMADA A LA SUBRUTINA
…
…
…
FIN DEL CODIGO DEL PROGRAMA.
Archivo de Código de Programa con llamada a Subrutina Externa.
INICIA CODIGO DEL PROGRAMA.

…
…
…
…
…
…
…
…
…
…
…
Archivo Independiente de Código que contiene las instrucciones de la Subrutina Externa.
INICIA CODIGO DE LA SUBRUTINA EXTERNA.

…
…
FIN DEL CODIGO DE LA SUBRUTINA EXTERNA.
Las subrutinas internas pueden ser abiertas o cerradas. Las primeras se escriben dentro
de la lógica principal del programa, por lo general como parte de la rutina PROCESO, mientras
que las cerradas están fuera de la lógica principal del programa (pero siguen siendo parte de
este) y debe efectuarse una ramificación hacia ellas a fin de ejecutarlas. Las subrutinas cerradas
normalmente se utilizan para las tres subrutinas principales (indicadas en la lista al inicio de este
tema) en la lógica de línea principal y cuando la rutina debe ejecutarse en varios puntos del

programa para evitar la redundancia. Sin las subrutinas cerradas, el proceso realizado por la
subrutina necesitaría volverse a realizar o a codificar en cualquier parte en que se deseara
efectuar la rutina. La forma de representar en diagrama de flujo los dos tipos se muestra en la
siguiente figura:
Archivo de Código de Programa con Subrutina Abierta.
INICIA CODIGO PRINCIPAL DEL PROGRAMA.

…
INICIA CODIGO DE LA SUBRUTINA ABIERTA.
…
…
FIN DEL CODIGO DE LA SUBRUTINA ABIERTA.
…
…
…
…
…
Archivo de Código de Programa con Subrutina Cerrada.
INICIA CODIGO DE LA SUBRUTINA CERRADA.

…
…
FIN DEL CODIGO DE LA SUBRUTINA CERRADA.
INICIA CODIGO PRINCIPAL DEL PROGRAMA.

…
…
…
…
…
…
…
Y por último, debo mencionar que se pueden pasar o transferir datos del programa
principal a la subrutina a través de variables, y ésta a su vez puede regresar valores al programa
principal a través de las mismas u otras variables. También es posible que una subrutina llame a
otra subrutina, y ésta a su vez pueda llamar a otra, y así sucesivamente; teniendo como límite las
características del lenguaje o de memoria del equipo.
Hasta este punto, hemos visto las subrutinas que fueron el intento de los primeros
programadores para estructurar los programas; y aunque este comentario haga parecer que éstas

son teorías pasadas, no es así, puesto que los mismos conceptos son aplicables a los
procedimientos y funciones, los cuales veremos a continuación.13
6.6.2.- Procedimientos.
Un Procedimiento, es similar a una subrutina, puesto que también es un

grupo de instrucciones que efectúa una parte identificable del programa general,
y normalmente se crean para evitar la codificación repetitiva de grupos de
instrucciones a lo largo del programa, así mismo tienen características parecidas
en cuanto al paso o transferencia de datos y las llamadas a otros procedimientos.
Pero a diferencia de las subrutinas, el paso o transferencia de datos se da
a través de variables llamadas parámetros. El objetivo de estos parámetros es la
de aislar de cierta manera los datos manipulados para evitar errores, confusiones
y creación de excesivos nombres de variables, así como permitir la re-usabilidad
del código. Generalmente los procedimientos son llamados para su ejecución
cual si fueran instrucciones del lenguaje y, no retornan o devuelven ningún valor
al programa principal o procedimiento que los llama.
6.6.3.- Funciones.
Una Función en un lenguaje de programación realiza una serie de

operaciones automáticamente, al llamarla por su nombre específico. Algunos
ejemplos de funciones son las funciones trigonométricas, tales como el Seno,
Coseno, Tangente, o las funciones matemáticas como el logaritmo natural de un
número; entre otras. Una de las características más importantes de las
funciones, es que podemos pasarle o transferirle datos, los cuales procesan y
nos devuelven uno o más resultados. Los datos que se transfieren son conocidos
como parámetros, y en algunos casos van encerrados entre paréntesis.
Principalmente se usan cuando se quiere devolver por lo menos un valor
a la función, programa o procedimiento llamador. En algunos lenguajes,
generalmente en una Función, el nombre actual de la Función, es el identificador
de la variable que transmite el valor de vuelta.
En cualquier lenguaje de programación se cuenta con al menos los
siguientes tipos de funciones: Alfanuméricas, de fecha, y matemáticas.
Algunos lenguajes permiten al usuario crear sus propias funciones, a las
cuales se les nombra comúnmente como Funciones de Usuario.
Generalmente las funciones pueden ser llamadas desde cualquier punto
de un programa e inclusive pueden ser pasadas como parámetros a una
instrucción o función del lenguaje.
13
Antes debo comentar que las subrutinas son utilizadas en algunos lenguajes tales como el BASIC, los cuales no están
plenamente orientados a la programación estructurada, tal como PASCAL por ejemplo.

6.6.3.1.- Funciones Implícitas.
Una función implícita es aquella que ya se encuentra incluida dentro de la

estructura del lenguaje de programación, y tiene su nombre definido, por lo tanto,
solo es necesario “llamarlas” para que se ejecuten cuando las necesitemos.
6.6.3.2.- Funciones de Usuario.
Una Función de usuario, es similar a una subrutina, puesto que también

es un grupo de instrucciones que efectúa una parte identificable del programa
general, y normalmente se crean para evitar la codificación repetitiva de grupos
de instrucciones a lo largo del programa, así mismo tienen características
parecidas en cuanto al paso o transferencia de datos y las llamadas a otros
procedimientos o funciones.
Pero a diferencia de las subrutinas y al igual que en los procedimientos, el
paso o transferencia de datos se da a través de parámetros.
6.6.4.- Parámetros en procedimientos y funciones.
Los parámetros pueden ser pasados a los procedimientos o funciones por

referencia (por variable) o por valor.
Las variables dadas al procedimiento o función al llamarlo se llaman
parámetros actuales. El procedimiento o función se escribe usando nombres de
variables, llamadas parámetros formales, listadas en sus cabeceras.
6.6.4.1.- Parámetros por valor.
El paso de un parámetro por valor a un procedimiento o función,

sucede cuando solo se pasa el valor de una variable origen a otra variable
destino, y ésta última puede ser modificada en su contenido, lo cual no
afectará al contenido de la variable origen. En otras palabras, le pasamos
una copia del valor, y por tanto, si el procedimiento o función modifica el
valor de la copia, el valor original no se modificará.
A continuación se presenta un diagrama describiendo lo anterior:

Inicio del Código del Programa Principal.
…
… VariableOrigen
… Este cuadro representa el área de
VariableOrigen = 5 memoria donde se almacena el
5
LlamadaAlProcedimientoA(VariableOrigen) valor de VariableOrigen.
Desplegar Variable Origen
…
…
… Parámetro Actual
Fin del Código del Programa Principal.
Cabecera del Parámetro Formal

Procedimiento o Función
Este cuadro representa el área de
LlamadaAlProcedimiento(ParámetroPorValor) 5 memoria donde se almacena el
valor de ParámetroPorValor. El
Inicio del Código de un Procedimiento o Función. ParámetroPorValor cual es una copia del original.
… Como puedes observar, la
… modificación del valor se realiza en el
ParametroPorValor = ParametroPorValor+2 área de memoria donde se almaceno la
… copia del valor, y no en el área de
… 7 memoria donde tenemos el valor
Fin del Código de LlamadaAlProcedimiento original. Esto es útil cuando no
ParámetroPorValor
Retorno (RETURN) al Programa Principal. queremos que se modifique el valor
original o inicial.

6.6.4.2.- Parámetros por referencia (por variable).
El paso de un parámetro por referencia (variable) a un

procedimiento o función, sucede cuando se pasa el valor de una variable
origen a otra variable destino, y ésta última cuando se modifica en su
contenido altera el contenido de la variable origen. En otras palabras, le
pasamos el original del valor, y por tanto, si el procedimiento o función
modifica el parámetro o variable destino, el valor original se modificará.
También se podría decir que a la misma dirección de memoria en la que
se almacena el valor original, se le asigna un segundo nombre de
variable, por tanto, al hacer referencia al primer nombre o al segundo,
indistintamente se estará usando la misma dirección de memoria.
A continuación se presenta un diagrama describiendo lo anterior:
Inicio del Código del Programa Principal.

…
…
… Este cuadro representa el área de
VariableOrigen = 5 memoria donde se almacena el
LlamadaAlProcedimientoA(VariableOrigen) valor de la VariableOrigen.
Desplegar Variable Origen
…
…
Parámetro Actual VariableOrigen VariableOrigen
…
Fin del Código del Programa Principal.
5 7
ParámetroPorVariable ParámetroPorVariable
Cabecera del Parámetro Formal
Procedimiento o Función
Este cuadro representa el área de

LlamadaAlProcedimiento(ParámetroPorVariable) memoria donde se almacena el
valor del ParámetroPorValor. El
Inicio del Código de un Procedimiento o Función. cual es una copia del original.
…
…
ParametroPorVariable = ParametroPorVariable+2
…
… Como puedes observar, los dos nombres de
Fin del Código de LlamadaAlProcedimiento variables hacen referencia a la misma posición de
Retorno (RETURN) al Programa Principal. memoria, por lo tanto, al modificar el valor de
ParámetroPorVariable, también se modificara el
valor de VariableOrigen, puesto que ambos
nombres de variables apuntan a la misma posición
de memoria.

Como últimas notas con relación a los parámetros, debo comentar que es posible usar
los mismos nombres de variables en los parámetros actuales y los formales, ya que esto
por lo general, no creara confusión al interprete del lenguaje, sin embargo, en la vida real
es poco práctico pues podría crearnos confusiones a nosotros; y además, creo que
resultaría útil usar las siguientes reglas para determinar si un parámetro debe ser por
valor o por referencia (por variable).
1. Si el procedimiento o función lee valores o calcula valores que el procedimiento,

función o programa que le llama necesita usar, estos parámetros deben ser
parámetros por referencia (por variable).
2. Si el procedimiento o función lee valores o calcula valores que el procedimiento,
función o programa que le llama necesita para darlo a otro procedimiento o función,
estos parámetros tienen que ser parámetros por referencia (por variable).
3. Los nombres de archivo pasados como parámetros deber ser parámetros por
referencia (por variable).
4. Todos los demás parámetros deben ser por valor. (Salvo aquellas excepciones
propias de cada lenguaje de programación).
6.6.5.- Variables en procedimientos y funciones.
Puesto que ya conocemos la definición de variable y todas sus características,

solo resta decir, que las variables también cuentan con un ámbito de utilización, es decir,
estas pueden ser utilizadas por todo el programa (Variables Globales) o solamente por
segmentos (procedimientos o funciones) de dicho programa (Variables Locales).
6.6.5.1.- Variables Globales.
Cualquier variable declarada en el cuerpo del programa principal es

conocida por cualquier procedimiento o función que no declare una variable con
el mismo nombre.
6.6.5.2.- Variables Locales.
Estas variables son las que los procedimientos o funciones

necesitan para sí mismos. Las variables contadoras son ejemplos de
variables que se necesitan frecuentemente dentro de un procedimiento o
función.
6.6.5.3.- Reglas de ámbito.

Cualquier variable o constante definida en un bloque se conoce
(llamada global) en cualquier procedimiento que esté dentro de ese
bloque. Examinemos el programa TRASPONER en términos de bloques
definidos y veamos lo que esto significa.

PROGRAMA Trasponer
VARIABLE Primera
PROCEDIMIENTO SaltarBlancos
PROCEDIMIENTO ObtenerPrimera
VARIABLE Ch
PROCEDIMIENTO ImprApellido
VARIABLE Ch
PROCEDIMIENTO EncontrarUltimo
PROCEDIMIENTO SaltarNombre
PROCEDIMIENTO Imprimir
DIAGRAMA DE ÁMBITOS
En este ejemplo Primera es una variable conocida o utilizable en

cualquier procedimiento puesto que está definida en el PROGRAMA
PRINCIPAL (Trasponer). La variable local Ch definida en ImprApellido es
global a EncontrarApellido, SaltarNombre e Imprimir puesto que
ImprApellido, SaltarNombre e Imprimir están definidas dentro del
procedimiento ImprApellido. Las reglas que gobiernan dónde se conocen esos
identificadores se llaman reglas de ámbito. El ámbito de la variable Ch definida
en ImprApellido incluye a ImprApellido, SaltarNombre e Imprimir.
¿Por qué entonces usamos la lista de parámetros? Porque una buena
práctica en programación es que la comunicación entre los módulos de nuestros
programas debe establecerse explícitamente. Esto limita la posibilidad de que un
módulo interfiera accidentalmente con otro. En otras palabras, a cada
procedimiento o función se le da sólo lo que necesita saber. Los “buenos”
programas se escriben usando este principio. Hay algunos casos en los que es
correcto referenciar globalmente a variables. En ejemplos posteriores veremos
algunos de esos casos en los que es aceptable referenciar a variables globales.
Si se declara el mismo nombre de variable (identificador) en un
procedimiento o función y en el programa principal, no hay confusión. La
declaración de una variable local en un procedimiento o función hace que se
desconozca a la variable global del mismo nombre. Llamamos a esto
“precedencia de nombre”.

6.6.5.4.- Efectos laterales.
Puesto que las listas de parámetros de los procedimientos o funciones

pueden ser muy complicadas según la elección de parámetros por valor y por
referencias (por variables), se puede tener la tentación de referenciar
directamente variables globales sin pasarlas a través de las listas de parámetros.
¡No hacerlo! Es un mal hábito. Puede conducir a cometer errores que son
extremadamente difíciles de localizar. Si la comunicación entre módulos de
programas se reduce a las listas de parámetros y todas las variables que no sean
de salida son parámetros por valor, cada módulo queda aislado de lo que suceda
en otras partes del programa. En otras palabras, el código en un procedimiento no
debe tener efectos laterales a otras partes del programa, excepto a través de una
interfase bien definida en la lista de parámetros.
Otra forma de decir esto es que los procedimientos sólo deben usar las
variables definidas en su lista de parámetros formales o en su propia sección de
declaración de variables. Crear módulos independientes con una clara interfase
de comunicación.
Programa principal
Otros módulos
Y
Otros procedimientos
Efectos Laterales
Lista de parámetros Interface de

comunicación
Un procedimiento
típico Módulo
EFECTOS LATERALES
Se deben evitar los efectos laterales porque normalmente es difícil seguir

el flujo de ejecución.
Por otra parte, las funciones se utilizan cuando se va a devolver un valor

simple. Sin embargo, si una función tiene parámetros por referencia (variable)
en la lista de parámetros formales, los correspondientes parámetros actuales
pueden indudablemente ser cambiados. El enviar o cambiar más de un valor en
una llamada a función se llama un efecto lateral de la función y debe evitarse.
Una buena regla es: No poner nunca parámetros por referencia (variable)
en la lista de parámetros formales de una función. Si debe tenerlos, entonces
debería usar un procedimiento y no una función. De hecho puede usar tantos
parámetros por valor como necesite.
Otro ejemplo de un efecto lateral es cuando un procedimiento o función

referencia directamente a una variable global y no lo hace a través de su lista de
parámetros formales. Recordar, la comunicación entre módulos de un programa
debe reducirse a las listas de parámetros formales y actuales.
El siguiente ejemplo ilustra los dos tipos de efectos laterales.
PROGRAMA Inesperado(Entrada, Salida)
VARIABLES A, B
FUNCION Lateral (VARIABLES X, Y)
INICIO (* Lateral *)
X=X+Y
A=X+1
Lado = X + A
FIN (* Lateral *)
INICIO (* Principal *)
A=0
B=1
Despliega(Lateral(A,B))
Despliega(Lateral(A,B))
Despliega(Lateral(B,A))
Despliega(Lateral(B,A))
FIN (* Principal *)
Es lógico esperar que las primeras dos sentencias de despliegue

produzcan la misma salida y las segundas dos sentencias de despliegue
produzcan la misma salida también. Es decir, se espera que una función devuelva
el mismo resultado cuando tiene la misma entrada. Desdichadamente, la función
LATERAL tiene efectos laterales y no devuelve el mismo valor para dos
llamadas sucesivas idénticas. Hagamos un recorrido del algoritmo y veamos lo
que sucede.
Sentencia A B X Y LATERAL
(Valores iniciales) 0 1 ? ? ?
LATERAL(A,B) (cuando se llama) 0 1 0 1 ?
X=X+Y 1 1 1 1 ?
A=X+1 2 1 2 1 ?
LATERAL = X + A 2 1 2 1 4 Lo que se
imprime

X=X+Y 3 1 3 1 ?
A=X+1 4 1 4 1 ?
imprime

X=X+Y 4 5 5 4 ?
A=X+1 6 5 5 6 ?
imprime

X=X+Y 6 11 11 6 ?
A=X+1 12 11 11 12 ?
imprime
Debido a que el primer parámetro es un parámetro por referencia (por

variable), cuando se cambia el parámetro formal también se cambia el parámetro
actual. Puesto que A se referencia globalmente, la función está cambiando
también cada vez. Como puede verse por la salida de la función LATERAL
(valores marcados con negritas), no sólo se devuelven valores diferentes para la
misma entrada, sino que ni siquiera se sigue una pauta.
6.6.6.- Recursividad.
En algunos lenguajes de programación, (p. e. Pascal), se permite que una función

o procedimiento se llame a sí mismo. La habilidad de una función o procedimiento de
llamarse a sí mismo se llama recursividad.
La recursividad es una poderosa característica de los lenguajes que lo permiten y
se utilizará en los trabajos más avanzados. Para el principiante, significa sólo que no
debe usarse el nombre de una función en una expresión en el cuerpo de esta función. Por
tanto se debe definir y usar una variable local y asignar al nombre de la función el valor
de la variable local antes de salir de la función.
Por si le pica la curiosidad, se incluye un ejemplo recursivo. Lenguajes como el
Pascal no tienen un operador de exponenciación, por lo que vamos a escribir una
función para calcular:
Xn
Donde X y n son enteros positivos no nulos. La fórmula es:
Xn = X * X*X*…*X
n veces
Otra forma de escribir esta relación sería:
Xn = X * (X*X*…*X)
(n-1) veces
Si conocemos Xn-1, podemos calcular Xn puesto que Xn = X(Xn-1). De la misma

forma podemos reducir Xn-1 a:
Xn = X*(X*(X*…*X))
(n-2) veces
Si conocemos lo que vale Xn-2, podemos calcular Xn-1 y entonces calcular Xn

puesto que Xn es igual a X(X(Xn-2)). Podemos continuar este proceso hasta que la
expresión más interior sea X1. Conocemos lo que es X1, su valor es X.
Expresamos este razonamiento mediante la siguiente función recursiva
POTENCIA, la cual tiene dos parámetros, nX y nN.
FUNCION Potencia(nX, nN : Enteros) : Enteros
INICIO (* Potencia *)
SI nN = 1 ENTONCES
Potencia = nX
SINO
Potencia = nX * Potencia(nX, nN-1)
FIN DEL SI
FIN.
Cada llamada a la función POTENCIA pone los parámetros actuales en la

interfase de comunicación para la versión a la que se está llamando. El valor para X será
el mismo para cada versión de POTENCIA, pero el valor de N se disminuirá en 1 por
cada llamada hasta que N-1 sea igual a 1. La llamada a la función PTENCIA cuando N
es 1 para la cadena de llamadas, porque ahora POTENCIA puede dar un valor. A
POTENCIA se le asigna un valor (X para ser exactos) el cual se pasa a la versión de la
función POTENCIA que hizo la última llamada. El valor de POTENCIA para esa
versión puede ahora calcularse y pasarse a la versión que la llamó a ella. Esto continúa
hasta que el valor de POTENCIA puede pasarse a la llamada original.
Veamos lo que hace una llamada a POTENCIA con X = 2 y N = 3. La sentencia:
nNum = POTENCIA(2,3)
En el cuerpo del programa asigna el valor devuelto por la llamada a la variable

nNum. El valor devuelto por POTENCIA y asignado a nNum debe ser 8 (23 es 2 x 2 x
2).
Para ilustrar el proceso supongamos que cada llamada a POTENCIA crea una
versión completa de POTENCIA. Cada caja en el siguiente diagrama representa el
algoritmo para POTENCIA listado anteriormente, junto con los valores de los
parámetros actuales para esa versión. Use el diagrama y el código para ver por sí mismo
que la función POTENCIA hace lo que se supone que debe hacer. Cada versión
POTNECIA va a la interfase de comunicación para obtener los valores que se le dejan
en ella. No hay confusión sobre qué nN se está usando porque nN es un parámetro
formal.

NNum = Potencia(2,3)
El valor devuelto es 8
Llamada a POTENCIA(2,3)
FUNCION
Potencia
nX nN
2 3
El valor devuelto es 4
FUNCION
Potencia
nX nN
2 2 El valor devuelto es 2
FUNCION
Potencia
nX nN
2 1

Aquellos que encuentren este ejemplo no sólo claro como el cristal, sino además
obvio, sigan adelante y utilicen la recursividad. Es una técnica poderosa. El resto no se
debe sentir intimidado. El comprender la recursividad no es uno de los objetivos de este
tema. Deben continuar en informática, más adelante estudiarán sin ninguna duda la
recursividad con detenimiento.
6.7. - Encadenamiento de programas.
El encadenamiento de programas consiste en realizar programas que se "llamen" entre

sí, y se ejecuten. Esto se realiza creando un archivo que contenga el programa principal y los
demás los programas auxiliares o complementarios. No todos los lenguajes de programación
permiten esta característica, pero si permiten la inclusión de archivos, es decir, en un archivo se
almacena el programa principal y en otro u otros los procedimientos o subrutinas adicionales
(subrutinas externas), los cuales pueden ser llamados desde el archivo que contiene el programa
principal al compilar el programa principal, y quedar incluidos en el programa objeto.

7. - Técnica de diseño modular.
Esta técnica de programación es recomendable para el desarrollo de sistemas de información
complejos, ya que podemos combinarla con cualquier otra técnica conocida (p. e. La técnica de diseño
elemental), para facilitar el desarrollo de una aplicación.
TECNICA DE DISEÑO MODULAR
Esta técnica se basa en el principio del "divide y vencerás"; es decir, debemos desglosar
o dividir un problema en partes o problemas más pequeños (módulos o bloques); y si alguna(s)
de esta(s) parte(s), son aun grandes, trataremos de dividirlo aun más.
Es recomendable desarrollar un diagrama en árbol, colocando en la parte superior el
problema principal, y después colocar en niveles inferiores, las divisiones o módulos de este
problema.
Después que se ha desglosado un problema, empezaremos a resolverlo desarrollando los
programas de cada módulo, empezando desde los módulos de nivel más bajo y en un orden
conveniente según nuestro criterio.
Para resolver cada módulo, es recomendable aplicar la técnica general o elemental de
programación; aunque podemos usar alguna otra técnica particular. Pero siempre debemos
evitar el tratar de resolver un módulo o problema codificándolo directamente. En general, las
fases o pasos de resolución de problemas aplicando esta técnica son:
1. Determinar el objetivo o problema.
2. Analizar el problema, describiendo de manera general los pasos para

resolverlo, cada uno de los cuales será un módulo de primer nivel.
3. Dividir sucesivamente los módulos, hasta que no se puedan dividir más.
4. Desarrollar un diagrama en árbol, en el cual se indicaran los módulos definidos

previamente.
5. Resolver los módulos de los niveles más bajos hacia los mas altos aplicando
cualquier técnica de programación, en un orden conveniente.
6. Agrupar los módulos de acuerdo a cada rama del diagrama en árbol,

codificarlos e integrarlos en un solo programa, o bien, a través de
"encadenamientos".
7.2. - Estructuras jerárquicas o en árbol.
El “árbol” es una estructura fundamental en informática, muy utilizada en todos sus

campos, porque se adapta a la representación natural de informaciones homogéneas organizadas
y de una gran comodidad y rapidez de manipulación. Esta estructura se encuentra en todos los

dominios (campos) de la informática, desde la pura algorítmica14 a la compilación15 o incluso
los dominios de la inteligencia artificial (árboles de juegos, árboles de decisiones, de resolución,
etc.).
Las estructuras tipo árbol se usan principalmente para representar información con una
relación jerárquica entre sus elementos, como son árboles genealógicos, tablas, etc.
Un “árbol” es un conjunto finito de uno o más nodos tales que:
1. Existe un nodo especial denominado RAIZ del árbol.
2. Los nodos restantes se dividen en un número mayor o igual que cero, conjuntos;
cada uno de los cuales es, a su vez, un árbol. Estos árboles se llaman sub-árboles
del RAIZ (ramas).
14
Métodos de clasificación y búsqueda.
15
Árboles sintácticos para representar las expresiones o producciones posibles de un lenguaje.

A continuación se muestra un diagrama ejemplificando lo anterior.
ESTRUCTURA JERÁRQUICA O EN ÁRBOL.
NIVEL 0 RAIZ
NIVEL 1
Sub-árbol Sub-árbol Sub-árbol Sub-árbol

O O O O
Nodo Nodo Nodo Nodo
NIVEL 2
Sub-árbol Sub-árbol Sub-árbol Sub-árbol Sub-árbol
O O O O O
Nodo Nodo Nodo Nodo Nodo
ESPEJO
Sub-árbol Sub-árbol Sub-árbol Sub-árbol Sub-árbol

O O O O O
NIVEL 2 Nodo Nodo Nodo Nodo Nodo
Sub-árbol Sub-árbol Sub-árbol Sub-árbol

O O O O
Nodo Nodo Nodo Nodo
NIVEL 1
NIVEL 0 RAIZ

7.3. - Resolución de problemas aplicando la Técnica de diseño modular.
1. Determinar el objetivo o problema.

(Deberá especificarse por el maestro, es el problema en sí).
- Diseñar un programa que solicite los siguientes datos de un empleado: Ficha, nombre,
puesto, antigüedad, sueldo diario, días trabajados; que calcule y muestre el sueldo total neto
a pagar, así como las cuotas por pagar por el patrón por sus prestaciones sobre su sueldo
total bruto: un 3 % del Seguro Social, 1 % de Apoyo a la Educación, 5 % de Infonavit, 2 %
de I.S.P.T. (Impuesto Sobre Productos del Trabajo; y 3 % del SAR (Sistema de Ahorro para
el Retiro. Sí el empleado tiene 5 años o más de antigüedad, se le dará un bono del 5 % sobre
su sueldo total bruto.
2. Analizar el problema, describiendo de manera general los pasos para resolverlo, cada
uno de los cuales será un módulo de primer nivel.
1. Solicitar los datos del empleado.

2. Calcular el salario total a pagar.
3. Calcular las cuotas por pagar.
5. Mostrar los importes del sueldo total neto a pagar, sus prestaciones.
3. Dividir sucesivamente los módulos, hasta que no se puedan dividir más.
NIVEL 0
MÓDULO PRINCIPAL
Cálculo del sueldo total neto a pagar a un empleado, así como las cuotas por pagar.
NIVEL 1
1. Solicitar Datos del Empleado.

2. Calcular Salario Total a Pagar.
3. Calcular Cuotas por pagar.
5. Mostrar Resultados.
NIVEL 2
1. Solicitar Datos del Empleado.

1.1. Etiquetas de Solicitud de Datos.
1.2. Captura de Datos.
2. Calcular Salario Total a Pagar.
3. Calcular Cuotas por pagar.
3.1. Calcular Cuota del IMSS.
3.2. Calcular Cuota de Apoyo a la Educación.

3.3. Calcular Cuota del Infonavit.
3.4. Calcular ISPT.
3.5. Calcular SAR.
3.6. Calcular el Bono por antigüedad.
5. Mostrar Resultados.
4. Desarrollar un diagrama de árbol, en el cual se indicarán los módulos definidos

previamente.
NIVEL 0 Cálculo del sueldo total neto a pagar a un

empleado, así como sus cuotas y retenciones.
NIVEL 1
Solicitar Datos Calcular Salario Calcular Cuotas y Calcular el Mostrar
del Empleado. Total a Pagar. Retenciones. Total Neto Resultados.
a Pagar.
Etiquetas de
Calcular Cuota del IMSS.
Solicitud de Datos.
Calcular Cuota de Apoyo a la

Captura de Datos.
Educación.
NIVEL 2 Calcular Cuota del Infonavit.
Calcular ISPT.
Calcular SAR.
Calcular el Bono por

antigüedad.

5. Resolver los módulos de los niveles más bajos hacia los más altos aplicando cualquier
técnica de programación, en un orden conveniente.
NIVEL 2
PROCEDIMIENTO Etiquetas de Solicitud de Datos.
INICIO
Desplegar "Dame los siguientes datos:"
Desplegar "Nombre:"
Desplegar "Puesto:"
Desplegar "Antigüedad:"
Desplegar "Salario Diario:"
Desplegar "Días Trabajados:"
RETORNO
PROCEDIMIENTO Captura de Datos.
INICIO
Introducir cNombre
Introducir cPuesto
Introducir nAntig
Introducir nSalDia
Introducir nDiasTrab
RETORNO
PROCEDIMIENTO Calcular Cuota del IMSS.
INICIO
nImss = nSalTotAPag * 0.03
RETORNO
PROCEDIMIENTO Calcular Cuota de Apoyo a la Educación.
INICIO
nApEduc = nSalTotAPag * 0.01
RETORNO
PROCEDIMIENTO Calcular Cuota del Infonavit.
INICIO
nInfonavit = nSalTotAPag * 0.05
RETORNO

PROCEDIMIENTO Calcular ISPT.
INICIO
nIspt = nSalTotAPag * 0.02
RETORNO
PROCEDIMIENTO Calcular SAR.
INICIO
nSar = nSalTotAPag * 0.03
RETORNO
PROCEDIMIENTO Calcular el Bono por antigüedad.
INICIO
Sí nAntig >= 5 entonces
nBono = nSalTotAPag * 0.05
sino
nBono = 0
fin sí
RETORNO
NIVEL 1
PROCEDIMIENTO Solicitar Datos del Empleado.
INICIO
Etiquetas de Solicitud de Datos.
Captura de Datos.
RETORNO
PROCEDIMIENTO Calcular Salario Total a Pagar.
INICIO
RETORNO
PROCEDIMIENTO Calcular Cuotas Por Pagar.
INICIO
Calcular Cuota del IMSS.
Calcular Cuota de Apoyo a la Educación.
Calcular Cuota del Infonavit.
Calcular ISPT.
Calcular SAR.
Calcular el Bono por antigüedad.
RETORNO

PROCEDIMIENTO Calcular Total Neto a Pagar
INICIO
RETORNO
PROCEDIMIENTO Mostrar Resultados.
INICIO
Desplegar “Resultados:”;
Desplegar “IMSS:”; nImss
Desplegar “ISPT:”; nIspt
Desplegar “SAR:”; nSar
Desplegar “Ap. Educ.:”; nApEduc
Desplegar “Infonavit:”; nInfonavit
Desplegar “BONO:”; nBono
Desplegar “Sal. Total a Pagar:”; nSalTotAPag
Desplegar “Tot. Neto a Pagar:”; nTotNetoAPagar
RETORNAR
NIVEL 0
PROGRAMA Principal. (Cálculo del sueldo total neto a pagar a un empleado, así como
las cuotas por pagar).
INICIO
Inicializar variables.
Solicitar Datos del Empleado.
Calcular Salario Total a Pagar.
Calcular Cuotas por pagar.
Calcular el Total Neto a Pagar.
Mostrar Resultados.
FIN
6. Agrupar los módulos de acuerdo a cada rama del diagrama en el árbol, codificarlos e
integrarlos en un solo programa, o bien, a través de “encadenamientos”.

Lenguaje Basic.
10 REM Programa EJEMGBAS.BAS

20 REM Método de Diseño Modular.
30 '**************************************************************************
40 'Programa Principal. NIVEL 0.
50 '**************************************************************************
60 CLS 'Borra la pantalla.
70 'Inicializar variables.
80 CNOMBRE$ = "": CPUESTO$ = "": NANTIG = 0: NSALDIA = 0: NDIASTRAB = 0
90 NSALTOTAPAG = 0: NIMSS = 0: NAPEDUC = 0: NINFONAVIT = 0: NSAR = 0
100 NISPT = 0: NBONO = 0: NTOTNETOAPAGAR = 0
110 GOSUB 230 'Llamada a la subrutina: Solicitar Datos del Empleado.
120 GOSUB 290 'Llamada a la subrutina: Calcular Salario Total a Pagar.
130 GOSUB 340 'Llamada a la subrutina: Calcular Cuotas Por Pagar.
140 GOSUB 440 'Llamada a la subrutina: Calcular el Total Neto a Pagar.
150 GOSUB 490 'Llamada a la subrutina: Mostrar Resultados.
160 END 'FIN DEL PROGRAMA PRINCIPAL.
170 '
180 '
190 '
200 '**************************************************************************
210 'Procedimientos de NIVEL 1.
220 '**************************************************************************
230 'SUBRUTINA: Solicitar Datos del Empleado.
240 '
250 GOSUB 680 'Llamada a la subrutina: Desplegar Mensajes de Solicitud de Datos.
260 GOSUB 790 'Llamada a la subrutina: Captura de Datos.
270 RETURN
280 '**************************************************************************
290 'SUBRUTINA: Calcular Salario Total a Pagar.
300 '
320 RETURN
330 '**************************************************************************
340 'SUBRUTINA: Calcular Cuotas Por Pagar.
350 '
360 GOSUB 880 'Llamada a la subrutina: Calcular Cuota del IMSS.
370 GOSUB 930 'Llamada a la subrutina: Calcular Cuota de Apoyo a la Educación.
380 GOSUB 980 'Llamada a la subrutina: Calcular Cuota del Infonavit.
390 GOSUB 1030 'Llamada a la subrutina: Calcular ISPT.
400 GOSUB 1080 'Llamada a la subrutina: Calcular SAR.
410 GOSUB 1130 'Llamada a la subrutina: Calcular el Bono por Antigüedad.
420 RETURN
430 '**************************************************************************
440 'SUBRUTINA: Calcular Total Neto a Pagar.
450 '
470 RETURN
480 '**************************************************************************
490 'SUBRUTINA: Mostrar Resultados.
500 '
520 LOCATE 3, 10: PRINT "Resultados:"
530 LOCATE 4, 10: PRINT "IMSS: "; NIMSS
540 LOCATE 5, 10: PRINT "ISPT: "; NISPT
550 LOCATE 6, 10: PRINT "SAR: "; NSAR
560 LOCATE 7, 10: PRINT "Apoyo a la Educación: "; NAPEDUC
570 LOCATE 8, 10: PRINT "INFONAVIT: "; NINFONAVIT
580 LOCATE 9, 10: PRINT "Bono: "; NBONO
590 LOCATE 10, 10: PRINT "Salario Total a Pagar: "; NSALTOTAPAG

600 LOCATE 11, 10: PRINT "Total Neto a Pagar: "; NTOTNETOAPAGAR
610 RETURN
620 '
630 '
640 '
650 '**************************************************************************
660 'Procedimientos de NIVEL 2.
670 '**************************************************************************
680 'SUBRUTINA: Desplegar Mensajes de Solicitud de Datos.
690 '
710 LOCATE 3, 10: PRINT "Dame los siguientes datos:"
720 LOCATE 4, 10: PRINT "Nombre:";
730 LOCATE 5, 10: PRINT "Puesto:";
740 LOCATE 6, 10: PRINT "Antigüedad:";
750 LOCATE 7, 10: PRINT "Salario Diario:";
760 LOCATE 8, 10: PRINT "Dias Trabajados:";
770 RETURN
780 '**************************************************************************
790 'SUBRUTINA: Captura de Datos.
800 '
810 LOCATE 4, 30: INPUT CNOMBRE$
820 LOCATE 5, 30: INPUT CPUESTO$
830 LOCATE 6, 30: INPUT NANTIG
840 LOCATE 7, 30: INPUT NSALDIA
850 LOCATE 8, 30: INPUT NDIASTRAB
860 RETURN
870 '**************************************************************************
880 'SUBRUTINA: Calcular Cuota del IMSS.
890 '
910 RETURN
920 '**************************************************************************
930 'SUBRUTINA: Calcular Cuota de Apoyo a la Educación.
940 '
960 RETURN
970 '**************************************************************************
980 'SUBRUTINA: Calcular Cuota de Infonavit.
990 '
1010 RETURN
1020 '**************************************************************************
1030 'SUBRUTINA: Calcular ISPT.
1040 '
1060 RETURN
1070 '**************************************************************************
1080 'SUBRUTINA: Calcular SAR.
1090 '
1110 RETURN
1120 '**************************************************************************
1130 'SUBRUTINA: Calcular el Bono por Antigüedad.
1140 '
1150 IF NANTIG >= 5 THEN NBONO = NSALTOTAPAG * .05 ELSE NBONO = 0
1160 RETURN
1170 '**************************************************************************
1180 'FIN DEL CODIGO DEL PROGRAMA.
Lenguaje Quick Basic.
REM Programa EJEMQBAS.BAS

REM Método de Diseño Modular.
'Declaración de PROCEDIMIENTOS (Módulos).
'Módulos de NIVEL 2.
DECLARE SUB DesplegarMensajesDeSolicitudDeDatos ()

DECLARE SUB CapturaDeDatos (nAntig, nSalDia, nDiasTrab)
DECLARE SUB CalcularCuotaDelIMSS (nImss AS SINGLE, nSalTotAPag AS SINGLE)
DECLARE SUB CalcularCuotaDeApoyoALaEducacion (nApEduc AS SINGLE, nSalTotAPag AS
SINGLE)
DECLARE SUB CalcularCuotaDelInfonavit (nInfonavit AS SINGLE, nSalTotAPag AS SINGLE)
DECLARE SUB CalcularISPT (nIspt AS SINGLE, nSalTotAPag AS SINGLE)
DECLARE SUB CalcularSAR (nSar AS SINGLE, nSalTotAPag AS SINGLE)
DECLARE SUB CalcularElBonoPorAntiguedad (nAntig AS SINGLE, nBono AS SINGLE,
nSalTotAPag AS SINGLE)
'Módulos de NIVEL 1.
'El módulo INICIALIZAR VARIABLES, por ser muy sencillo se codifica
'directamente en el PROGRAMA PRINCIPAL (NIVEL 0).
DECLARE SUB SolicitarDatosDelEmpleado (nAntig, nSalDia, nDiasTrab)

DECLARE SUB CalcularSalarioTotalAPagar (nSalTotAPag, nDiasTrab, nSalDia)
DECLARE SUB CalcularCuotasPorPagar (nImss AS SINGLE, nApEduc AS SINGLE, nInfonavit
AS SINGLE, nIspt AS SINGLE, nSar AS SINGLE, nAntig AS SINGLE, nBono AS SINGLE,
DECLARE SUB CalcularElTotalNetoAPagar (nTotNetoAPagar AS SINGLE, nSalTotAPag AS
SINGLE, nBono AS SINGLE)
DECLARE SUB MostrarResultados (nImss AS SINGLE, nIspt AS SINGLE, nSar AS SINGLE,
nApEduc AS SINGLE, nInfonavit AS SINGLE, nBono AS SINGLE, nSalTotAPag AS SINGLE,
nTotNetoAPagar AS SINGLE)
'PROGRAMA PRINCIPAL. NIVEL 0.
'Inicio del programa.
'Inicializar variables.

nSalTotAPag = 0: nImss = 0: nApEduc = 0: nInfonavit = 0: nSar = 0: nIspt= 0
'Llamadas a los procedimientos
CALL SolicitarDatosDelEmpleado(nAntig, nSalDia, nDiasTrab)

CALL CalcularSalarioTotalAPagar(nSalTotAPag, nSalDia, nDiasTrab)
CALL CalcularCuotasPorPagar(nImss, nApEduc, nInfonavit, nIspt, nSar,
nAntig, nBono, nSalTotAPag)
CALL CalcularElTotalNetoAPagar(nTotNetoAPagar, nSalTotAPag, nBono)
CALL MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono,
nSalTotAPag, nTotNetoAPagar)
END 'Fin del programa.
'Módulo de NIVEL 2.
SUB CalcularCuotaDeApoyoALaEducacion (nApEduc AS SINGLE, nSalTotAPag AS SINGLE)

END SUB
SUB CalcularCuotaDelIMSS (nImss AS SINGLE, nSalTotAPag AS SINGLE)
END SUB
SUB CalcularCuotaDelInfonavit (nInfonavit AS SINGLE, nSalTotAPag AS SINGLE)
END SUB
SUB CalcularCuotasPorPagar (nImss AS SINGLE, nApEduc AS SINGLE, nInfonavit AS
SINGLE, nIspt AS SINGLE, nSar AS SINGLE, nAntig AS SINGLE, nBono AS SINGLE,
CALL CalcularCuotaDelIMSS(nImss, nSalTotAPag)

CALL CalcularCuotaDeApoyoALaEducacion(nApEduc, nSalTotAPag)
CALL CalcularCuotaDelInfonavit(nInfonavit, nSalTotAPag)
CALL CalcularISPT(nIspt, nSalTotAPag)
CALL CalcularSAR(nSar, nSalTotAPag)
CALL CalcularElBonoPorAntiguedad(nAntig, nBono, nSalTotAPag)
END SUB
SUB CalcularElBonoPorAntiguedad (nAntig AS SINGLE, nBono AS SINGLE, nSalTotAPag AS
SINGLE)
IF nAntig >= 5 THEN

ELSE
nBono = 0
END IF
END SUB
SUB CalcularElTotalNetoAPagar (nTotNetoAPagar AS SINGLE, nSalTotAPag AS SINGLE,
nBono AS SINGLE)
END SUB
SUB CalcularISPT (nIspt AS SINGLE, nSalTotAPag AS SINGLE)
END SUB
SUB CalcularSalarioTotalAPagar (nSalTotAPag AS SINGLE, nDiasTrab AS SINGLE, nSalDia
AS SINGLE)

END SUB
SUB CalcularSAR (nSar AS SINGLE, nSalTotAPag AS SINGLE)
END SUB
SUB CapturaDeDatos (nAntig AS SINGLE, nSalDia AS SINGLE, nDiasTrab AS SINGLE)
LOCATE 4, 30: INPUT cNombre$

LOCATE 5, 30: INPUT cPuesto$
LOCATE 6, 30: INPUT nAntig
LOCATE 7, 30: INPUT nSalDia
LOCATE 8, 30: INPUT nDiasTrab
END SUB
SUB DesplegarMensajesDeSolicitudDeDatos

LOCATE 3, 10: PRINT "Dame los siguientes datos:"
LOCATE 4, 10: PRINT "Nombre:";
LOCATE 5, 10: PRINT "Puesto:";
LOCATE 6, 10: PRINT "Antigüedad:";
LOCATE 7, 10: PRINT "Salario Diario:";
LOCATE 8, 10: PRINT "Días Trabajados:";
END SUB
SUB MostrarResultados (nImss AS SINGLE, nIspt AS SINGLE, nSar AS SINGLE, nApEduc AS
SINGLE, nInfonavit AS SINGLE, nBono AS SINGLE, nSalTotAPag AS SINGLE,

LOCATE 3, 10: PRINT "Resultados:"
LOCATE 4, 10: PRINT "IMSS: "; nImss
LOCATE 5, 10: PRINT "ISPT: "; nIspt
LOCATE 6, 10: PRINT "SAR: "; nSar
LOCATE 7, 10: PRINT "Apoyo a la Educación: "; nApEduc
LOCATE 8, 10: PRINT "INFONAVIT: "; nInfonavit
LOCATE 9, 10: PRINT "Bono: "; nBono
LOCATE 10, 10: PRINT "Salario Total a Pagar: "; nSalTotAPag
LOCATE 11, 10: PRINT "Total Neto a Pagar: "; nTotNetoAPagar
END SUB
SUB SolicitarDatosDelEmpleado (nAntig AS SINGLE, nSalDia AS SINGLE, nDiasTrab AS
SINGLE)
CALL DesplegarMensajesDeSolicitudDeDatos
CALL CapturaDeDatos(nAntig, nSalDia, nDiasTrab)
END SUB

‘ Fin del código del programa.

Lenguaje Pascal.
PROGRAM Ejemplo;
(* Programa EJEMPASC.PAS *)
(* Método de Diseño Modular. *)
USES CRT;
VAR nAntig,
nSalDia,
nDiasTrab,
nSalTotAPag,
nImss,
nApEduc,
nInfonavit,
nSar,
nIspt,
nBono,
(* Módulo de NIVEL 2 *)
PROCEDURE DesplegarMensajesDeSolicitudDeDatos;
BEGIN
GOTOXY(10,3); WRITELN('Dame los siguientes datos:');

GOTOXY(10,4); WRITE('Nombre: ');
GOTOXY(10,5); WRITE('Puesto: ');
GOTOXY(10,6); WRITE('Antigüedad: ');
GOTOXY(10,7); WRITE('Salario Diario: ');
GOTOXY(10,8); WRITE('Días Trabajados: ');
END;
PROCEDURE CapturaDeDatos(VAR nAntig, nSalDia, nDiasTrab: REAL);

BEGIN
GOTOXY(30,4); READLN(cNombre);
GOTOXY(30,5); READLN(cPuesto);
GOTOXY(30,6); READLN(nAntig);
GOTOXY(30,7); READLN(nSalDia);
GOTOXY(30,8); READLN(nDiasTrab);
END;

PROCEDURE CalcularCuotaDelIMSS(VAR nImss: REAL; nSalTotAPag: REAL);
BEGIN
END;
PROCEDURE CalcularCuotaDeApoyoALaEducacion(VAR nApEduc: REAL; nSalTotAPag: REAL);
BEGIN
END;
PROCEDURE CalcularCuotaDelInfonavit(VAR nInfonavit: REAL; nSalTotAPag: REAL);
BEGIN
END;
PROCEDURE CalcularISPT(VAR nIspt: REAL; nSalTotAPag: REAL);
BEGIN
END;
PROCEDURE CalcularSAR(VAR nSar: REAL; nSalTotAPag: REAL);
BEGIN
END;
PROCEDURE CalcularElBonoPorAntiguedad(VAR nBono: REAL; nAntig, nSalTotAPag: REAL);
BEGIN
IF nAntig >= 5 THEN

ELSE
nBono = 0;
END;
PROCEDURE SolicitarDatosDelEmpleado(VAR nAntig, SalDia, DiasTrab: REAL);

BEGIN
DesplegarMensajesDeSolicitudDeDatos;
CapturaDeDatos(nAntig, nSalDia, nDiasTrab);
END;
PROCEDURE CalcularSalarioTotalAPagar(VAR nSalTotAPag: REAL; nDiasTrab, nSalDia:

REAL);
BEGIN
END;
PROCEDURE CalcularCuotasPorPagar(VAR nImss, nApEduc, nInfonavit, nIspt, nSar,

nBono: REAL; nSalTotAPag, nAntig: REAL);
BEGIN
CalcularCuotaDelIMSS(nImss, nSalTotAPag);
CalcularCuotaDeApoyoALaEducacion(nApEduc, nSalTotAPag);
CalcularCuotaDelInfonavit(nInfonavit, nSalTotAPag);
CalcularISPT(nIspt, nSalTotAPag);
CalcularSAR(nSar, nSalTotAPag);
CalcularElBonoPorAntiguedad(nBono, nAntig, nSalTotAPag);
END;
PROCEDURE CalcularElTotalNetoAPagar(VAR nTotNetoAPagar: REAL; nSalTotAPag, nBono:

REAL);
BEGIN

END;
PROCEDURE MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono,

nSalTotAPag, nTotNetoAPagar: REAL);
BEGIN
CLRSCR;
GOTOXY(10,3);WRITELN('Resultados:');
GOTOXY(10,4);WRITELN('IMSS: ', nImss:6:2);
GOTOXY(10,5);WRITELN('ISPT: ', nIspt:6:2);
GOTOXY(10,6);WRITELN('SAR: ', nSar:6:2);
GOTOXY(10,7);WRITELN('Apoyo a la Educación: ', nApEduc:6:2);
GOTOXY(10,8);WRITELN('INFONAVIT: ', nInfonavit:6:2);
GOTOXY(10,9);WRITELN('Bono: ', nBono:6:2);
GOTOXY(10,10);WRITELN('Salario Total a Pagar: ', nSalTotAPag:6:2);
GOTOXY(10,11);WRITELN('Total Neto a Pagar: ', nTotNetoAPagar:6:2);
END;

(* INICIA PROGRAMA PRINCIPAL NIVEL 0 *)
BEGIN (* Inicio *)
(* Inicializar Variables *)
nAntig := 0;
nSalDia := 0;
nDiasTrab := 0;
nSalTotAPag := 0;
nImss := 0;
nApEduc := 0;
nInfonavit := 0;
nSar := 0;
nIspt := 0;
nBono := 0;
SolicitarDatosDelEmpleado(nAntig, nSalDia, nDiasTrab);

CalcularSalarioTotalAPagar(nSalTotAPag, nDiasTrab, nSalDia);
CalcularCuotasPorPagar(nImss, nApEduc,nInfonavit, nIspt, nSar, nBono,
nSalTotAPag, nAntig);
CalcularElTotalNetoAPagar(nTotNetoAPagar, nSalTotAPag, nBono);
MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono,
nSalTotAPag, nTotNetoAPagar);
END. (* FIN DEL PROGRAMA *)

Lenguaje Clipper.
* Programa EJEMCLIP.PRG
* Método de Diseño Modular.
* PROGRAMA PRINCIPAL. NIVEL 0.
Ejemplo()
FUNCTION Ejemplo()
/* Declarando variables */
LOCAL nAntig, nSalDia, nDiasTrab, nSalTotAPag, nImss, nApEduc,;
nInfonavit, nSar, nIspt, nBono, nTotNetoAPagar
/* Inicializando variables */
nAntig := 0
nSalDia := 0
nDiasTrab := 0
nSalTotAPag := 0
nImss := 0
nApEduc := 0
nInfonavit := 0
nSar := 0
nIspt := 0
nBono := 0
nTotNetoAPagar := 0

SolicitarDatosDelEmpleado(@nAntig, @nSalDia, @nDiasTrab)
CalcularSalarioTotalAPagar(@nSalTotAPag, nDiasTrab, nSalDia)
CalcularCuotasPorPagar(@nImss, @nApEduc, @nInfonavit, @nIspt, @nSar,;
@nBono, nSalTotAPag, nAntig)
CalcularElTotalNetoAPagar(@nTotNetoAPagar, nSalTotAPag, nBono)
MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono,;
RETURN
* Módulos de NIVEL 1.
FUNCTION SolicitarDatosDelEmpleado(nAntig, nSalDia, nDiasTrab)
DesplegarMensajesDeSolicitudDeDatos()
CapturaDeDatos(@nAntig, @nSalDia, @nDiasTrab)
RETURN
FUNCTION CalcularSalarioTotalAPagar(nSalTotAPag, nDiasTrab, nSalDia)
RETURN
FUNCTION CalcularCuotasPorPagar(nImss, nApEduc, nInfonavit, nIspt, nSar,;

nBono, nSalTotAPag, nAntig)
CuotaDelIMSS(@nImss, nSalTotAPag)
CuotaDeApoyoALaEducacion(@nApEduc, nSalTotAPag)
CuotaDelInfonavit(@nInfonavit, nSalTotAPag)

CuotaISPT(@nIspt, nSalTotAPag)
CuotaSAR(@nSar, nSalTotAPag)
CuotaBonoPorAntiguedad(@nBono, nAntig, nSalTotAPag)
RETURN
FUNCTION CalcularElTotalNetoAPagar(nTotNetoAPagar, nSalTotAPag, nBono)
RETURN
FUNCTION MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono,;


@ 9,10 SAY "IMSS: "
@ 9,35 SAY nImss
@ 10,10 SAY "ISPT: "
@ 10,35 SAY nIspt
@ 11,10 SAY "SAR: "
@ 11,35 SAY nSar
@ 12,35 SAY nApEduc
@ 14,10 SAY "Bono: "
@ 14,35 SAY nBono
RETURN
* Módulos de NIVEL 2.
FUNCTION DesplegarMensajesDeSolicitudDeDatos;

RETURN
FUNCTION CapturaDeDatos(nAntig, nSalDia, nDiasTrab);
LOCAL cNombre := ' ', cPuesto := ' '
@ 2,30 GET cNombre

@ 3,30 GET cPuesto
@ 4,30 GET nAntig PICT '9999999.99'
@ 5,30 GET nSalDia PICT '9999999.99'
@ 6,30 GET nDiasTrab PICT '9999999.99'
READ
RETURN
FUNCTION CuotaDelIMSS(nImss, nSalTotAPag)

nImss := nSalTotAPag * 0.03
RETURN
FUNCTION CuotaDeApoyoALaEducacion(nApEduc, nSalTotAPag)
nApEduc := nSalTotAPag * 0.01
RETURN
FUNCTION CuotaDelInfonavit(nInfonavit, nSalTotAPag)
nInfonavit := nSalTotAPag * 0.05

RETURN
FUNCTION CuotaISPT(nIspt, nSalTotAPag)
nIspt := nSalTotAPag * 0.02
RETURN
FUNCTION CuotaSAR(nSar, nSalTotAPag)
nSar := nSalTotAPag * 0.03
RETURN
FUNCTION CuotaBonoPorAntiguedad(nBono, nAntig, nSalTotAPag)
IF nAntig >= 5
ELSE
nBono := 0
END IF
RETURN
* Fin del código del programa.

Lenguaje C++.
/* Programa EJEMMC.C */
/* Método de Diseño Modular. */
#include <stdio.h>
/* Módulos de NIVEL 2 */
/* Declaración de funciones */
void DesplegarMensajesDeSolicitudDeDatos(void);
void CapturaDeDatos(float *, float *, float *);
void CuotaDelIMSS(float *, float);
void CuotaDeApoyoALaEducacion(float *, float);
void CuotaDelInfonavit(float *, float);
void CuotaISPT(float *, float);
void CuotaSAR(float *, float);
void CuotaBonoPorAntiguedad(float *, float, float);
void SolicitarDatosDelEmpleado(float *, float *, float *);

void CalcularSalarioTotalAPagar(float *, float, float);
void CalcularCuotasPorPagar(float *, float *, float *, float *, float *,
float *, float, float);
void CalcularElTotalNetoAPagar(float *, float, float);
void MostrarResultados(float, float, float, float, float, float, float,
float);
/* Programa Principal. NIVEL 0 */

void main () /* Inicio del programa principal */
{
/* Declaración e inicialización de variables */
float nAntig = 0;
float nSalDia = 0;
float nImss = 0;
float nApEduc = 0;
float nIspt = 0;
float nSar = 0;
float nBono = 0;
clrscr(); /* Borra la pantalla */

SolicitarDatosDelEmpleado(&nAntig, &nSalDia, &nDiasTrab);
CalcularSalarioTotalAPagar(&nSalTotAPag, nDiasTrab, nSalDia);
CalcularCuotasPorPagar(&nImss, &nApEduc, &nInfonavit, &nIspt, &nSar,
&nBono, nSalTotAPag, nAntig);
CalcularElTotalNetoAPagar(&nTotNetoAPagar, nSalTotAPag, nBono);
}
void DesplegarMensajesDeSolicitudDeDatos(void)
{
gotoxy(10,1); printf("Dame los siguientes datos:");

gotoxy(10,2); printf("Nombre:");
gotoxy(10,3); printf("Puesto:");
gotoxy(10,4); printf("Antigüedad:");
gotoxy(10,5); printf("Salario Diario:");
gotoxy(10,6); printf("Días Trabajados:");
}
void CapturaDeDatos(float *nAnt, float *nSal, float *nDias)
{
/* Declaración de variables locales */
char cNombre[10];
char cPuesto[10];
float nA, nS, nD; /* Variables auxiliares para el
paso de parámetros */
gotoxy(30,2); scanf("%s",&cNombre);
gotoxy(30,3); scanf("%s",&cPuesto);
gotoxy(30,4); scanf("%f",&nA);
gotoxy(30,5); scanf("%f",&nS);
gotoxy(30,6); scanf("%f",&nD);
/* Asignación de valores a las variables que son parámetro por

referencia o variable */
*nAnt = nA;
*nSal = nS;
*nDias = nD;
}
void CuotaDelIMSS(float *nIm, float nSalTotAPag)
{
*nIm = nSalTotAPag * 0.03;
}
void CuotaDeApoyoALaEducacion(float *nApEd, float nSalTotAPag)
{
*nApEd = nSalTotAPag * 0.01;
}
void CuotaDelInfonavit(float *nInfo, float nSalTotAPag)
{
*nInfo = nSalTotAPag * 0.05;
}
void CuotaISPT(float *nIs, float nSalTotAPag)
{
*nIs = nSalTotAPag * 0.02;
}
void CuotaSAR(float *nSa, float nSalTotAPag)
{
*nSa = nSalTotAPag * 0.03;
}
void CuotaBonoPorAntiguedad(float *nBon, float nAntig, float nSalTotAPag)
{
if(nAntig >= 5)

*nBon = nSalTotAPag * 0.05;
else
*nBon = 0;
}
/* Módulos de Nivel 1 */
void SolicitarDatosDelEmpleado(float *nAntig, float *nSalDia, float *nDiasTrab)
{
/* Declaración de variables auxiliares para el paso de parámetros */
float nAnt,nSal,nDias;
DesplegarMensajesDeSolicitudDeDatos();
CapturaDeDatos(&nAnt, &nSal, &nDias);
/* Asignación de valores a las variables que son par metro por

*nAntig = nAnt;
*nSalDia = nSal;
*nDiasTrab = nDias;
}
void CalcularSalarioTotalAPagar(float *nSalTotAPag, float nDiasTrab, float nSalDia)
{
*nSalTotAPag = nDiasTrab * nSalDia;
}
void CalcularCuotasPorPagar(float *nImss, float *nApEduc, float *nInfonavit,

float *nIspt, float *nSar, float *nBono,
float nSalTotAPag, float nAntig)
{
float nIm, nApEd, nInfo, nIs, nSa, nBon;
CuotaDelIMSS(&nIm, nSalTotAPag);
CuotaDeApoyoALaEducacion(&nApEd, nSalTotAPag);
CuotaDelInfonavit(&nInfo, nSalTotAPag);
CuotaISPT(&nIs, nSalTotAPag);
CuotaSAR(&nSa, nSalTotAPag);
CuotaBonoPorAntiguedad(&nBon, nAntig, nSalTotAPag);

*nImss = nIm;
*nApEduc = nApEd;
*nInfonavit = nInfo;
*nIspt = nIs;
*nSar = nSa;
*nBono = nBon;
void CalcularElTotalNetoAPagar(float *nTotNetoAPagar, float nSalTotAPag,

float nBono)
{
*nTotNetoAPagar = nSalTotAPag + nBono;
}
void MostrarResultados(float nImss, float nIspt, float nSar, float nApEduc,

float nInfonavit, float nBono, float nSalTotAPag,
float nTotNetoAPagar)
{
gotoxy(10,10); printf("Salario Total a Pagar: %f",nSalTotAPag);
gotoxy(10,11); printf("Cuota IMSS: %f",nImss);
gotoxy(10,12); printf("Cuota de Apoyo a la Educación: %f",nApEduc);
gotoxy(10,13); printf("Cuota del Infonavit: %f",nInfonavit);
gotoxy(10,14); printf("Cuota del SAR: %f",nSar);
gotoxy(10,15); printf("Bono por antigüedad: %f",nBono);
gotoxy(10,16); printf("Total Neto a Pagar: %f",nTotNetoAPagar);
}
/* Fin del código del programa*/

8. - Técnica de diseño descendente.
Esta técnica, como la anterior, es recomendable para el desarrollo de aplicaciones complejas y
de gran tamaño; una de sus características principales es que evita la repetición de bloques de
instrucciones, economizando con esto tiempo de programación y captura de la codificación.
TECNICA DE DISEÑO DESCENDENTE
Esta técnica, también conocida como "top-down", nos permite usar una aproximación
del " divide y vencerás " (no debe confundirse con Diseño Modular, que es similar). En otras
palabras, un problema se divide en sub-problemas que sean manejables. Después de resolver
todos los sub-problemas tendremos una solución del problema global.
Lo que hacemos en el diseño descendente es ir de lo abstracto (nuestra descripción o
especificación del problema) a lo particular (nuestro código en lenguaje de programación).
Si la descripción del problema es una descripción en palabras vagamente establecida,
entonces el primer paso es crear una descripción funcional del problema. Es decir, una
descripción que establezca claramente lo que el programa ha de hacer. En muchos casos, esto
significa un dialogo entre la persona que tiene el problema y el programador.
Para resolver los problemas, comenzaremos subdividiendo el problema en un conjunto

de sub-problemas. Luego, cada sub-problema se divide a su vez en sub-problemas. Este proceso
continúa hasta que no se puede dividir más cada sub-problema. Estamos creando una estructura
jerárquica, también conocida como estructura en árbol, de problemas y sub-problemas llamados
módulos funcionales. Los módulos de un nivel pueden llamar a los módulos del nivel inferior.
Estos módulos son los bloques básicos nuestros programas.
Dividiendo nuestro problema en sub-problemas, o segmentos, podemos resolver cada
uno independientemente de los otros.
Nuestro árbol de diseño contiene sucesivos niveles de refinamiento (ver figura). En la
cabeza, o nivel 0, esta nuestra descripción funcional del problema, los niveles inferiores son
nuestros sucesivos refinamientos.
Concretamente; las fases o pasos para la resolución de problemas de esta técnica son:
¾Analizar el problema.
¾Escribir el módulo principal.
¾Escribir los módulos restantes.
¾Re-ordenar y revisar lo que sea necesario.
A continuación se describen detalladamente los pasos anteriores:
1. Analizar el problema.
- Comprender el problema. Comprender lo que se da (ENTRADA) y lo que se

pide (SALIDA). Especificar los formatos de ENTRADA / SALIDA.
- Pensar. ¿ Cómo se resolvería el problema a mano ? Establecer las estructuras de

datos necesarias (sí las hay).
- Desarrollar un algoritmo global o plan general de ataque.
- Listar las suposiciones (sí las hay).
2. Escribir el módulo principal.
- Utilizar el castellano o pseudo código para establecer el problema en el módulo

principal. Usar nombres de módulos para dividir el problema en áreas
funcionales. Si éste módulo es demasiado largo (mas de 10 o 15 sentencias), esta
en un nivel demasiado bajo de detalle. Introducir en este punto cualquier
estructura de control que se necesite (tal como iteración o selección). Revisar la
lógica, sí se necesita. Posponer los detalles a niveles inferiores. El módulo
principal puede cambiar en futuros refinamientos.
- No preocuparse si no se sabe como resolver un módulo que no este escrito en
este momento. Suponga que tiene un "amigo inteligente" que conoce la respuesta
y pospóngala hasta que se hagan mas refinamientos. Todo lo que tiene que hacer
en el módulo principal es dar los nombres de los módulos del nivel inferior que
suministren ciertas funciones.
- Utilizar nombres con significado para los módulos.
3. Escribir los módulos restantes.
- No hay un número fijo de niveles. Los módulos de un nivel pueden especificar

mas módulos del nivel inferior.
- Cada módulo debe estar completo, aunque los módulos que él refiere estén sin
escribir.
- Hacer sucesivos refinamientos en cada módulo hasta que cada sentencia pueda
traducirse directamente en una sentencia en lenguaje de programación.
4. Re-ordenar y revisar lo que sea necesario.
- Planificar un cambio.
- No preocuparse por comenzar de nuevo. Pueden ser necesarios varios intentos y
refinamientos.
- Volver atrás en las decisiones de diseño inapropiadas.
- Tratar de mantener la claridad.
- Expresarse simple y directamente.
PERFIL DEL DISEÑO DESCENDENTE
- DESCRIPCION DE LA ENTRADA.
- DESCRIPCION DE LA SALIDA.
- ESTRUCTURAS DE DATOS.
- SUPOSICIONES (SÍ LAS HAY)
- MÓDULO PRINCIPAL.
- MÓDULOS RESTANTES POR NIVELES.

El producto final del diseño es el programa. El programa debe reflejar la estructura del
diseño descendente realizado. El módulo principal debe ser el programa principal.
8.2. - Resolución de problemas aplicando la Técnica de diseño descendente.
- Diseñar un programa que solicite los siguientes datos de un empleado: Ficha, nombre,
puesto, antigüedad, sueldo diario, días trabajados; que calcule y muestre el sueldo total neto
a pagar, así como las cuotas por pagar por el patrón por sus prestaciones sobre su sueldo
total bruto: un 3 % del Seguro Social, 1 % de Apoyo a la Educación, 5 % de Infonavit, 2 %
de I.S.P.T. (Impuesto Sobre Productos del Trabajo; y 3 % del SAR (Sistema de Ahorro para
el Retiro. Sí el empleado tiene 5 años o más de antigüedad, se le dará un bono del 5 % sobre
su sueldo total bruto.
1. Analizar el problema.
El programa deberá pedir los datos del empleado y posteriormente sobre la base de
éstos, deberá calcular las cuotas por pagar por el patrón, así como el bono por antigüedad, en
caso de que tenga 5 años o más de antigüedad; todo con base en su sueldo total bruto.
DESCRIPCIÓN DE LA ENTRADA.
Los datos de entrada son:
DATO TIPO
Nombre Alfanumérico (Carácter)
Puesto Alfanumérico (Carácter)
Antigüedad Numérico
Salario Diario Numérico
Días Trabajados Numérico
DESCRIPCIÓN DE LA SALIDA.
Los datos de salida son:
DATO TIPO
Cuota del IMSS Numérico
Cuota del ISPT Numérico
Cuota del SAR Numérico
Cuota de Apoyo a la Educación Numérico
Cuota del Infonavit Numérico
Bono por antigüedad Numérico
Salario Total a Pagar Numérico
Total Neto a Pagar Numérico

ESTRUCTURAS DE DATOS.
VARIABLE IDENTIFICADOR TIPO

(NOMBRE DE VARIABLE)
Nombre cNombre Alfanumérico (Carácter)
Puesto cPuesto Alfanumérico (Carácter)
Antigüedad nAntig Numérico
Sueldo Diario nSalDia Numérico
Días trabajados nDiasTrab Numérico
Cuota del IMSS nImss Numérico
Cuota del ISPT nIspt Numérico
Cuota del SAR nSar Numérico
Cuota de Apoyo a la Educación nApEduc Numérico
Cuota del Infonavit nInfonavit Numérico
Bono por antigüedad nBono Numérico
Salario Total a Pagar nSalTotAPag Numérico
Total Neto a Pagar nTotNetoAPagar Numérico
SUPOSICIONES (SI LAS HAY).
En este caso supondremos que no habrá ningún error en la captura, y por lo tanto no
habrá días trabajados, antigüedades, y sueldos diarios; negativos. Ni tampoco habrá otros
tipos de errores por parte del usuario.
NOTA: En el primer caso es obvio que no debe haber valores negativos, sin embargo,
cuando se hace un programa más profesional, se deben considerar todos los valores que
podría tomar una variable, pues nunca sabremos que es lo que puede pensar y/o hacer el
usuario con nuestro programa. Para el segundo caso, en el que supondremos que no habrá
otro tipo de error por parte del usuario, durante la captura; es para evitar confundirlo y
además, el crearnos una rutina de procesamiento de errores; que en la vida real es
conveniente desarrollar para procesar todos aquellos errores que podamos imaginarnos que
se podrían generar en nuestros programas, e inclusive aquellos errores impredecibles, para
darles una salida sencilla y elegante a nuestros programas.
2. Escribir el módulo principal.
NIVEL 0
Módulo Principal.
Calcular el Salario Total a Pagar, el Total Neto a Pagar y las cuotas por pagar.

3. Escribir los módulos restantes.
NIVEL 1
a. Inicializar variables.
b. Solicitar datos del empleado.
c. Calcular el salario total a pagar.
d. Calcular las cuotas por pagar.
e. Mostrar resultados.
NIVEL 2
a.1. cNombre = “ “
a.2. cPuesto = “ “
a.3. nAntig = 0
a.4. nSalDia = 0
a.5. nDiasTrab = 0
a.6. nImss = 0
a.7. nIspt = 0
a.8. nSar = 0
a.9. nApEduc = 0
a.10. nInfonavit = 0
a.11. nBono = 0
a.12. nSalTotAPag = 0
a.13. nTotNetoAPagar = 0
b.1. Etiquetas de Solicitud de datos.

b.2. Captura de datos.
c.1. Salario Total a Pagar = Salario Diario * Días Trabajados
d.1. Cuota del Imss = Salario Total a Pagar * 0.03

d.2. Cuota de Apoyo a la Educación = Salario Total a Pagar * 0.01
d.3. Cuota del Infonavit = Salario Total a Pagar * 0.05
d.4. Cuota del ISPT = Salario Total a Pagar * 0.02
d.5. Cuota del SAR = Salario Total a Pagar * 0.03
d.6. Sí Antigüedad >= 5 entonces Bono por Antigüedad = Salario Total a Pagar * 0.05
e.1. Desplegar “Resultados:”;

e.2. Desplegar “IMSS:”; nImss
e.3. Desplegar “ISPT:”; nIspt
e.4. Desplegar “SAR:”; nSar
e.5. Desplegar “Ap. Educ.:”; nApEduc
e.6. Desplegar “Infonavit:”; nInfonavit
e.7. Desplegar “BONO:”; nBono
e.8. Desplegar “Sal. Total a Pagar:”; nSalTotAPag

e.9. Desplegar “Tot. Neto a Pagar:”; nTotNetoAPagar
NIVEL 3
a.1. cNombre = “ “
a.2. cPuesto = “ “
a.3. nAntig = 0
a.4. nSalDia = 0
a.5. nDiasTrab = 0
a.6. nImss = 0
a.7. nIspt = 0
a.8. nSar = 0
a.9. nApEduc = 0
a.10. nInfonavit = 0
a.11. nBono = 0
a.12. nSalTotAPag = 0
a.13. nTotNetoAPagar = 0
b.1.1. Desplegar "Dame los siguientes datos:"

b.1.2. Desplegar "Nombre:"
b.1.3. Desplegar "Puesto:"
b.1.4. Desplegar "Antigüedad:"
b.1.5. Desplegar "Salario Diario:"
b.1.6. Desplegar "Días Trabajados:"
b.2.1. Introducir cNombre

b.2.2. Introducir cPuesto
b.2.3. Introducir nAntig
b.2.4. Introducir nSalDia
b.2.5. Introducir nDiasTrab
c.1. Salario Total a Pagar = Salario Diario * Días Trabajados
d.1. Cuota del Imss = Salario Total a Pagar * 0.03

d.2. Cuota de Apoyo a la Educación = Salario Total a Pagar * 0.01
d.3. Cuota del Infonavit = Salario Total a Pagar * 0.05
d.4. Cuota del ISPT = Salario Total a Pagar * 0.02
d.5. Cuota del SAR = Salario Total a Pagar * 0.03
d.6. Sí Antigüedad >= 5 entonces Bono por Antigüedad = Salario Total a Pagar * 0.05 sino
Bono = 0
e.1. Desplegar “Resultados:”;

e.2. Desplegar “IMSS:”; nImss
e.3. Desplegar “ISPT:”; nIspt
e.4. Desplegar “SAR:”; nSar
e.5. Desplegar “Ap. Educ.:”; nApEduc
e.6. Desplegar “Infonavit:”; nInfonavit

e.7. Desplegar “BONO:”; nBono
e.8. Desplegar “Sal. Total a Pagar:”; nSalTotAPag
e.9. Desplegar “Tot. Neto a Pagar:”; nTotNetoAPagar
4. Reordenar y revisar lo que sea necesario.
Como se puede observar, ésta técnica es similar a la de diseño modular. Sin embargo,
aquí no es necesario crear el diagrama de árbol, y esto resulta ser optativo.
También es de notar que al final obtenemos el algoritmo totalmente detallado como en el
caso de la técnica de diseño elemental, pero con la diferencia de que cada segmento está
plenamente identificado, y por lo tanto, si el algoritmo resulta ser demasiado extenso,
podemos crear procedimientos, como en el diseño modular, lo cual acortaría el código del
programa principal y lo haría mas legible.
Y por supuesto, ya teniendo el algoritmo en el nivel más bajo, lo único que queda es
codificarlo, aunque bien podíamos haberlo hecho desde otros niveles superiores, pero como
lo que se pretende es enseñar a programar y no a codificar en algún lenguaje especifico, por
tal razón se muestra simplemente el algoritmo hasta su mínimo detalle.
Queda para el programador principiante, a su gusto, cuando llegue a niveles muy bajos,
el codificar directamente cuando ya domine un lenguaje de programación.
Puesto que el código, para este ejemplo resulta ser muy pequeño, bien podríamos
obtener un código como el del diseño elemental, o como el del diseño modular; y ¿por qué
no?, una mezcla de ambos como se muestra más adelante; todo dependerá de los gustos y
estilos de cada programador.
Lenguaje Basic.
10 REM Programa EJEMDBAS.BAS

20 REM Método de Diseño Descendente.
30 '**************************************************************************
40 'Programa Ejemplo.
50 '**************************************************************************
70 '
80 'Inicializar variables.
90 '
100 CNOMBRE$ = "": CPUESTO$ = "": NANTIG = 0: NSALDIA = 0: NDIASTRAB = 0
110 NSALTOTAPAG = 0: NIMSS = 0: NAPEDUC = 0: NINFONAVIT = 0: NSAR = 0
120 NISPT = 0: NBONO = 0: NTOTNETOAPAGAR = 0
130 '
140 GOSUB 390 'Llamada a la subrutina: Solicitar Datos del Empleado.
150 '
160 'Calcular Salario Total a Pagar.
170 '
190 '
200 'Calcular Cuotas Por Pagar.
210 '
270 IF NANTIG >= 5 THEN NBONO = NSALTOTAPAG * .05
280 '

290 'Calcular el Total Neto a Pagar.
300 '
320 '
330 GOSUB 450 'Llamada a la subrutina: Mostrar Resultados.
340 '
350 END 'FIN DEL PROGRAMA PRINCIPAL.
360 '
370 '
380 '**************************************************************************
390 'SUBRUTINA: Solicitar Datos del Empleado.
400 '
410 GOSUB 600 'Llamada a la subrutina: Desplegar Mensajes de Solicitud de Datos.
420 GOSUB 710 'Llamada a la subrutina: Captura de Datos.
430 RETURN
440 '**************************************************************************
450 'SUBRUTINA: Mostrar Resultados.
460 '
480 LOCATE 3, 10: PRINT "Resultados:"
490 LOCATE 4, 10: PRINT "IMSS: "; NIMSS
500 LOCATE 5, 10: PRINT "ISPT: "; NISPT
510 LOCATE 6, 10: PRINT "SAR: "; NSAR
520 LOCATE 7, 10: PRINT "Apoyo a la Educación: "; NAPEDUC
530 LOCATE 8, 10: PRINT "INFONAVIT: "; NINFONAVIT
540 LOCATE 9, 10: PRINT "Bono: "; NBONO
550 LOCATE 10, 10: PRINT "Salario Total a Pagar: "; NSALTOTAPAG
560 LOCATE 11, 10: PRINT "Total Neto a Pagar: "; NTOTNETOAPAGAR
570 RETURN
580 '
590 '**************************************************************************
600 'SUBRUTINA: Desplegar Mensajes de Solicitud de Datos.
610 '
630 LOCATE 3, 10: PRINT "Dame los siguientes datos:"
640 LOCATE 4, 10: PRINT "Nombre:";
650 LOCATE 5, 10: PRINT "Puesto:";
660 LOCATE 6, 10: PRINT "Antigüedad:";
670 LOCATE 7, 10: PRINT "Salario Diario:";
680 LOCATE 8, 10: PRINT "Dias Trabajados:";
690 RETURN
700 '**************************************************************************
710 'SUBRUTINA: Captura de Datos.
720 '
730 LOCATE 4, 30: INPUT CNOMBRE$
740 LOCATE 5, 30: INPUT CPUESTO$
750 LOCATE 6, 30: INPUT NANTIG
760 LOCATE 7, 30: INPUT NSALDIA
770 LOCATE 8, 30: INPUT NDIASTRAB
780 RETURN
790 '**************************************************************************
800 'FIN DEL CODIGO DEL PROGRAMA.
810 '**************************************************************************

Lenguaje Quick Basic.
REM Programa EJEDQBAS.BAS

REM Método de Diseño Descendente.
'Declaración de PROCEDIMIENTOS.
DECLARE SUB DesplegarMensajesDeSolicitudDeDatos ()

DECLARE SUB CapturaDeDatos (nAntig, nSalDia, nDiasTrab)
DECLARE SUB SolicitarDatosDelEmpleado (nAntig, nSalDia, nDiasTrab)
DECLARE SUB MostrarResultados (nImss AS SINGLE, nIspt AS SINGLE, nSar AS SINGLE,
nApEduc AS SINGLE, nInfonavit AS SINGLE, nBono AS SINGLE, nSalTotAPag AS SINGLE,
'PROGRAMA Ejemplo.
'Inicio del programa.
'Inicializar variables.

nSalTotAPag = 0: nImss = 0: nApEduc = 0: nInfonavit = 0: nSar = 0: nIspt= 0
'Llamadas a los procedimientos
CALL SolicitarDatosDelEmpleado(nAntig, nSalDia, nDiasTrab)
'Calcular Salario Total a Pagar
'Calcular Cuotas Por Pagar

IF nAntig >= 5 THEN
ELSE
nBono = 0
END IF
'
'Calcular El Total Neto a Pagar
'
CALL MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono,
END 'Fin del programa.
SUB CapturaDeDatos (nAntig AS SINGLE, nSalDia AS SINGLE, nDiasTrab AS SINGLE)
LOCATE 4, 30: INPUT cNombre$

LOCATE 5, 30: INPUT cPuesto$
LOCATE 6, 30: INPUT nAntig
LOCATE 7, 30: INPUT nSalDia
LOCATE 8, 30: INPUT nDiasTrab

END SUB
SUB DesplegarMensajesDeSolicitudDeDatos

LOCATE 3, 10: PRINT "Dame los siguientes datos:"
LOCATE 4, 10: PRINT "Nombre:";
LOCATE 5, 10: PRINT "Puesto:";
LOCATE 6, 10: PRINT "Antigüedad:";
LOCATE 7, 10: PRINT "Salario Diario:";
LOCATE 8, 10: PRINT "Días Trabajados:";
END SUB
SUB MostrarResultados (nImss AS SINGLE, nIspt AS SINGLE, nSar AS SINGLE, nApEduc AS

SINGLE, nInfonavit AS SINGLE, nBono AS SINGLE, nSalTotAPag AS SINGLE,

LOCATE 3, 10: PRINT "Resultados:"
LOCATE 4, 10: PRINT "IMSS: "; nImss
LOCATE 5, 10: PRINT "ISPT: "; nIspt
LOCATE 6, 10: PRINT "SAR: "; nSar
LOCATE 7, 10: PRINT "Apoyo a la Educación: "; nApEduc
LOCATE 8, 10: PRINT "INFONAVIT: "; nInfonavit
LOCATE 9, 10: PRINT "Bono: "; nBono
LOCATE 10, 10: PRINT "Salario Total a Pagar: "; nSalTotAPag
LOCATE 11, 10: PRINT "Total Neto a Pagar: "; nTotNetoAPagar
END SUB
SUB SolicitarDatosDelEmpleado (nAntig AS SINGLE, nSalDia AS SINGLE, nDiasTrab AS

SINGLE)
CALL DesplegarMensajesDeSolicitudDeDatos
CALL CapturaDeDatos(nAntig, nSalDia, nDiasTrab)
END SUB
‘Fin del código del programa.

Lenguaje Pascal.
PROGRAM Ejemplo;
(* Programa EJEDPASC.PAS *)
(* Método de Diseño Descendente. *)
USES CRT;
VAR nAntig,
nSalDia,
nDiasTrab,
nSalTotAPag,
nImss,
nApEduc,
nInfonavit,
nSar,
nIspt,
nBono,
PROCEDURE DesplegarMensajesDeSolicitudDeDatos;
BEGIN
GOTOXY(10,3); WRITELN('Dame los siguientes datos:');

GOTOXY(10,4); WRITE('Nombre: ');
GOTOXY(10,5); WRITE('Puesto: ');
GOTOXY(10,6); WRITE('Antigüedad: ');
GOTOXY(10,7); WRITE('Salario Diario: ');
GOTOXY(10,8); WRITE('Días Trabajados: ');
END;
PROCEDURE CapturaDeDatos(VAR nAntig, nSalDia, nDiasTrab: REAL);

BEGIN
GOTOXY(30,4); READLN(cNombre);
GOTOXY(30,5); READLN(cPuesto);
GOTOXY(30,6); READLN(nAntig);
GOTOXY(30,7); READLN(nSalDia);
GOTOXY(30,8); READLN(nDiasTrab);
END;
PROCEDURE SolicitarDatosDelEmpleado(VAR nAntig, SalDia, DiasTrab: REAL);
BEGIN
DesplegarMensajesDeSolicitudDeDatos;
CapturaDeDatos(nAntig, nSalDia, nDiasTrab);

END;
PROCEDURE MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono,

nSalTotAPag, nTotNetoAPagar: REAL);
BEGIN
CLRSCR;
GOTOXY(10,3);WRITELN('Resultados:');
GOTOXY(10,4);WRITELN('IMSS: ', nImss:6:2);
GOTOXY(10,5);WRITELN('ISPT: ', nIspt:6:2);
GOTOXY(10,6);WRITELN('SAR: ', nSar:6:2);
GOTOXY(10,7);WRITELN('Apoyo a la Educación: ', nApEduc:6:2);
GOTOXY(10,8);WRITELN('INFONAVIT: ', nInfonavit:6:2);
GOTOXY(10,9);WRITELN('Bono: ', nBono:6:2);
GOTOXY(10,10);WRITELN('Salario Total a Pagar: ', nSalTotAPag:6:2);
GOTOXY(10,11);WRITELN('Total Neto a Pagar: ', nTotNetoAPagar:6:2);
END;
(* INICIA PROGRAMA PRINCIPAL Ejemplo *)
BEGIN (* Inicio *)
(* Inicializar Variables *)
nAntig := 0;
nSalDia := 0;
nDiasTrab := 0;
nSalTotAPag := 0;
nImss := 0;
nApEduc := 0;
nInfonavit := 0;
nSar := 0;
nIspt := 0;
nBono := 0;
SolicitarDatosDelEmpleado(nAntig, nSalDia, nDiasTrab);
(* Calcular Salario Total a Pagar *)

(* Calcular Cuotas Por Pagar *)

IF nAntig >= 5 THEN
ELSE
nBono := 0;
(* Calcular El Total Neto a Pagar *)


END. (* FIN DEL PROGRAMA *)

Lenguaje Clipper.

* Programa EJEDCLIP.PRG
* Método de Diseño Descendente.
* PROGRAMA PRINCIPAL. NIVEL 0.
Ejemplo()
FUNCTION Ejemplo()
/* Declarando variables */
LOCAL nAntig, nSalDia, nDiasTrab, nSalTotAPag, nImss, nApEduc,;
nInfonavit, nSar, nIspt, nBono, nTotNetoAPagar
/* Inicializando variables */
nAntig := 0
nSalDia := 0
nDiasTrab := 0
nSalTotAPag := 0
nImss := 0
nApEduc := 0
nInfonavit := 0
nSar := 0
nIspt := 0
nBono := 0
nTotNetoAPagar := 0

SolicitarDatosDelEmpleado(@nAntig, @nSalDia, @nDiasTrab)
* Calcular Salario Total a Pagar
* Calcular Cuotas Por Pagar
nImss := nSalTotAPag * 0.03

nApEduc := nSalTotAPag * 0.01
nInfonavit := nSalTotAPag * 0.05
nIspt := nSalTotAPag * 0.02
nSar := nSalTotAPag * 0.03
IF nAntig >= 5
ELSE
nBono := 0
END IF
* Calcular El Total Neto a Pagar
MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono,;

RETURN
FUNCTION SolicitarDatosDelEmpleado(nAntig, nSalDia, nDiasTrab)
DesplegarMensajesDeSolicitudDeDatos()
CapturaDeDatos(@nAntig, @nSalDia, @nDiasTrab)

RETURN
FUNCTION MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono,;


@ 9,10 SAY "IMSS: "
@ 9,35 SAY nImss
@ 10,10 SAY "ISPT: "
@ 10,35 SAY nIspt
@ 11,10 SAY "SAR: "
@ 11,35 SAY nSar
@ 12,35 SAY nApEduc
@ 14,10 SAY "Bono: "
@ 14,35 SAY nBono
RETURN
FUNCTION DesplegarMensajesDeSolicitudDeDatos;

RETURN
FUNCTION CapturaDeDatos(nAntig, nSalDia, nDiasTrab);
LOCAL cNombre := ' ', cPuesto := ' '
@ 2,30 GET cNombre

@ 3,30 GET cPuesto
@ 4,30 GET nAntig PICT '9999999.99'
@ 5,30 GET nSalDia PICT '9999999.99'
@ 6,30 GET nDiasTrab PICT '9999999.99'
READ
RETURN
* Fin del código del programa.

Lenguaje C++.
/* Programa EJEMDC.C */
/* Método de Diseño Descendente. */
#include <stdio.h>
void DesplegarMensajesDeSolicitudDeDatos(void);
void CapturaDeDatos(float *, float *, float *);
void SolicitarDatosDelEmpleado(float *, float *, float *);

void MostrarResultados(float, float, float, float, float, float, float, float);
void main () /* Inicio del programa principal Ejemplo */
{
/* Declaración e inicialización de variables */
float nAntig = 0;
float nSalDia = 0;
float nImss = 0;
float nApEduc = 0;
float nIspt = 0;
float nSar = 0;
float nBono = 0;
clrscr(); /* Borra la pantalla */

SolicitarDatosDelEmpleado(&nAntig, &nSalDia, &nDiasTrab);
/* Calcular Salario Total a Pagar */
nSalTotAPag = nDiasTrab * nSalDia;
/* Calcular Cuotas Por Pagar */
nImss = nSalTotAPag * 0.03;

nApEduc = nSalTotAPag * 0.01;
nInfonavit = nSalTotAPag * 0.05;
nIspt = nSalTotAPag * 0.02;
nSar = nSalTotAPag * 0.03;
if(nAntig >= 5)
nBono = nSalTotAPag * 0.05;
else
nBono = 0;
/* Calcular El Total Neto a Pagar */
nTotNetoAPagar = nSalTotAPag + nBono;

}
/* Fin del programa principal */

/* Inician las funciones */
void DesplegarMensajesDeSolicitudDeDatos(void)
{
gotoxy(10,1); printf("Dame los siguientes datos:");
gotoxy(10,2); printf("Nombre:");
gotoxy(10,3); printf("Puesto:");
gotoxy(10,4); printf("Antigüedad:");
gotoxy(10,5); printf("Salario Diario:");
gotoxy(10,6); printf("Días Trabajados:");
}
void CapturaDeDatos(float *nAnt, float *nSal, float *nDias)
{
/* Declaración de variables locales */
char cNombre[10];
char cPuesto[10];
float nA, nS, nD; /* Variables auxiliares para el
paso de parámetros */
gotoxy(30,2); scanf("%s",&cNombre);
gotoxy(30,3); scanf("%s",&cPuesto);
gotoxy(30,4); scanf("%f",&nA);
gotoxy(30,5); scanf("%f",&nS);
gotoxy(30,6); scanf("%f",&nD);

*nAnt = nA;
*nSal = nS;
*nDias = nD;
}
void SolicitarDatosDelEmpleado(float *nAntig, float *nSalDia, float *nDiasTrab)
{
float nAnt,nSal,nDias;
DesplegarMensajesDeSolicitudDeDatos();
CapturaDeDatos(&nAnt, &nSal, &nDias);

*nAntig = nAnt;
*nSalDia = nSal;
*nDiasTrab = nDias;
}
void MostrarResultados(float nImss, float nIspt, float nSar, float nApEduc,

float nInfonavit, float nBono, float nSalTotAPag,
float nTotNetoAPagar)
{
gotoxy(10,10); printf("Salario Total a Pagar: %f",nSalTotAPag);
gotoxy(10,11); printf("Cuota IMSS: %f",nImss);
gotoxy(10,12); printf("Cuota de Apoyo a la Educación: %f",nApEduc);
gotoxy(10,13); printf("Cuota del Infonavit: %f",nInfonavit);
gotoxy(10,14); printf("Cuota del SAR: %f",nSar);
gotoxy(10,15); printf("Bono por antigüedad: %f",nBono);
gotoxy(10,16); printf("Total Neto a Pagar: %f",nTotNetoAPagar);

}
/* Fin del código del programa*/

9. – Introducción a la programación para gestión de archivos.
9.1. - Conceptos básicos.
En el mundo de la informática existen muchas vertientes para la programación, algunas

son los programas para gráficos, programas de paquete o paqueterías (p. e. Hojas de cálculo,
procesadores de texto, manejadores de bases de datos, etc.), programas utilitarios o utilerías
(antivirus, mantenimiento de discos, diagnostico de hardware, etc.), programas administrativos
(contabilidad, inventarios, nóminas, etc.) e inclusive sistemas operativos y traductores de
lenguajes de programación.
Y, aunque existen en el mercado un sinnúmero de programas desarrollados por infinidad
de empresas de software; siempre es necesario que, para ciertos usuarios se desarrollen
programas especificos de gestión de información, que manipulen dicha información con la
ayuda de archivos de datos, equiparables y equivalentes a los archivos físicos documentales,
para la agilización de sus procesos administrativos. De ahí que resulta imprescindible para todo
programador, el conocimiento básico de las operaciones elementales para la gestión de
información almacenada en archivos. A continuación se verán los conceptos básicos.
9.1.1. - Archivo.
Es un conjunto de información relacionada entre sí.
Normalmente, en informática representamos un archivo como si fuera una tabla

compuesta de columnas y filas. También reciben el nombre de ficheros.
Por ejemplo:
Toda la información relacionada con estudiantes de una institución educativa

(Nombre, dirección, teléfono, nivel o grado escolar, edad, calificaciones, etc.).
9.1.2. - Campo.
Es un grupo de datos del mismo tipo, pertenecientes a un mismo archivo, y que

se relacionan con sus respectivos elementos.
Generalmente representamos los campos de un archivo como las columnas de

una tabla.
Por ejemplo:
Los nombres de cada uno de los estudiantes de una institución educativa.
9.1.3. - Registro.
Son un conjunto de campos relacionados entre sí, los cuales contienen

información sobre un elemento particular.

Comúnmente se representan los registros de un archivo como filas de una tabla.
Por ejemplo:
El registro de inscripción de un alumno, el cual contiene los siguientes

campos:
Número de control, nombre, grupo, grado o nivel escolar.
Representación de un Archivo de Alumnos.
Campo 1 Campo 2 Campo 3 Campo 4 Campo 5
Nombre
del Campo Número de Nombre Grupo Turno Grado
Control
990701001 Francisco Fernández 990701 Vespertino 1
Jiménez
Registro 990602058 Julieta Campos 990602 Matutino 2
Enríquez
990503047 Armando Gutiérrez Armas 990503 Matutino 4
980402109 Edith Mijangos Lagos 980402 Vespertino 3
9.1.4. - Base de datos.
Una base de datos es un conjunto de información. En sentido amplio, el término

puede aplicarse a cualquier agregado de datos aunque éste no sea tratado de modo
informático. Por tanto, en dicho sentido amplio, son ejemplos de bases de datos nuestra
agenda, la guía telefónica, un archivo (o fichero) con recetas de cocina, una biblioteca y,
en general, cualquier cosa que podamos designar con el apelativo de conjunto de
información. No obstante, cuando usamos el término base de datos desde una óptica
informática estamos dándole un significado algo más restrictivo. Desde este nuevo punto
de vista podemos definir una base de datos como un sistema de mantenimiento de
registros basado en computadoras, es decir, un sistema cuyo propósito general es
registrar y mantener información16.
Como se ha visto anteriormente, los archivos son el recipiente informático que
contiene la información. Muchas veces se confunde el término base de datos con el
término archivo (o fichero). Realmente son dos cosas distintas. En general, una base de
datos es una colección de archivos, con alguna relación interna entre ellos. Bien es
cierto que pueden existir bases de datos que estén compuestas de un único archivo, pero
esto no es lo más frecuente y, además, en lo que a nuestra definición respecta, esto no
modificaría las cosas.
16
Usamos la definición de C. J. Date, una de las máximas autoridades mundiales en esta materia, en su obra Introducción a
los sistemas de bases de datos, publicada en nuestro idioma por Addison-Wesley Iberoamericana, México, 1986.

9.2. - Tipos de Archivos y accesos.
Aunque en la actualidad se ha optado por el manejo masivo de las bases de datos,

(que en conjunto con los sistemas gestores de bases de datos -SGBD- y los lenguajes con
la estructura necesaria, nos brindan grandes facilidades y prestaciones); siempre es
necesario conocer los tipos de archivos y sus modos de acceso.
9.2.1. - Archivos secuenciales
Son archivos cuyos registros son almacenados consecutivamente, es decir, uno

tras otro.
En estos archivos, sus registros solo pueden ser accesados de manera secuencial,
es decir, empezando por el primero, y siguiendo de uno en uno hasta el final del archivo.
9.2.2. - Archivos directos.
En este tipo de archivo, la información también se almacena de manera

secuencial, sin embargo, a cada registro se le asigna interna y automáticamente un
número al cual llamamos, número de registro; de tal manera que, para accesar la
información de cualquier registro, simplemente se hace referencia al número de registro
para acceder a él.
Por lo tanto, los registros del archivo pueden ser accesados secuencialmente, o
bien, directamente por su número de registro.
9.2.3. – Archivos indexados.
Los archivos indexados, podríamos decir que son similares a los archivos
directos, con la diferencia de que, siempre van acompañado de uno o más archivos que
contienen los datos del campo clave de búsqueda, es decir, su índice.
Dicho de otra manera, los archivos indexados tienen las mismas características
que los archivos directos, es decir, los registros se almacenan de manera secuencial, y a
cada uno se le asigna interna y automáticamente un número de registro, pero
paralelamente a éstos se pueden crear uno o más índices. Podemos comparar estos
índices con los índices que traen los libros, donde si se observa, por un lado se tiene el
nombre del tema en un orden lógico (p. e. alfabético o temático) y por el otro el número
de página donde se encuentra ubicado, y al consultar este índice nos resulta más rápido y
fácil localizar el tema que nos interesa. De tal manera, imaginemos los índices como una
tabla con dos campos donde se almacenan los datos del campo clave para su búsqueda y
el número de registro donde se localiza.
Obviamente, para acceder a los registros de un archivo indexado o mejor dicho
indizado (que sería lo correcto pues en español es índice –indizado- y no índex del
inglés –indexado-), tenemos tres tipos de acceso que son: secuencia, directo e indizado.

9.2.4. – Otros tipos de archivos.
Así como los archivos anteriormente vistos, existen muchos más tipos de
archivos, que tienen relación al tipo de software que se utilice para crearlos y
modificarlos. Algunos de los más comunes son los archivos de gráficos, los de texto, de
hoja de cálculo, de presentaciones, de datos comprimidos, etc.
Desde luego que la manera (o formato) en que se almacena la información en un
archivo depende del software que se este utilizando, aunque sean del mismo tipo, y se
pueden identificar por la extensión del mismo.
Ejemplos:
De archivos de gráficos las extensiones más comunes son JPG, GIF, PCX y BMP
entre otras. De archivos de texto, lo son; DOC, TXT, WPS.
9.3. – Bases de datos.
En este punto, se tratara con mayor profundidad todo lo relacionado a las Bases de
datos, pues se han difundido tanto debido a su las necesidades de los usuarios y programadores,
que se tienen muchas opciones en el mercado para usar o crear un Sistema para la Gestión de
Bases de Datos (SGBD). Pero…
9.3.1. - ¿ Qué es un SGBD ?
SGBD son las siglas de Sistema para la Gestión de Bases de Datos. Esta frase
proviene de traducir al español Data Base Management System (DBMS). En general,
podemos decir que todo aquello a lo que en informática llamamos vulgarmente base de
datos, no es tal sino un SGBD. En sentido estricto el término base de datos hace
referencia sólo al lugar donde está depositada la información (hablando desde la
perspectiva del hardware como del software). En cambio, con SGBD hacemos referencia
a la herramienta informática que usamos para manejar dicha información. Gráficamente
podemos representar un SGBD como vemos en la figura.
BASE DE DATOS
Vista 1 Usuario A
Usuario B
Vista 3
Usuario X
Vista 4
Usuario Y
Usuario Z
Vista 5

Lo que el gráfico nos indica es que el conjunto de información contenida en la
base de datos tiene la peculiaridad de hallarse integrado bajo un mismo sistema gestor,
pero que, además, dichos datos son accedidos de forma independiente por usuarios y
aplicaciones, sólo en la medida en que son necesarios para dichos usuarios y dichas
aplicaciones. Es decir, el Usuario A necesita sólo la porción de datos designada como
Vista 1; por tanto la base de datos revestirá ante dicho usuario la peculiaridad de parecer
que sólo contiene el trozo de información manejado desde dicha vista. La aplicación Y
trabaja sólo con los datos contenidos en la Vista 4, por tanto, en ningún momento
alcanzará esta aplicación a manejar datos situados fuera de esa vista.
9.3.2. – La independencia de los datos.
Podemos preguntarnos qué ventajas presenta la implantación de un SGBD frente

a la más convencional gestión de archivos que podemos realizar desde cualquier
lenguaje de programación. La respuesta a esta pregunta es múltiple, ya que múltiples son
las ventajas que un método de trabajo posee sobre otro:
a) En general un SGBD nos permite tener un control centralizado de toda la

información que poseemos, independientemente de que cada aplicación gestione un
solo segmento de dicha información.
b) Los archivos gestionados por diversas aplicaciones y no agrupados bajo una filosofía
de una base de datos tienden a la redundancia, ya que en la construcción de cada
programa tendemos a diseñarnos la estructura de datos necesarios para el mismo sin
tener demasiado en cuenta los requerimientos de otras aplicaciones. De esta forma,
cuando queremos darnos cuenta, tenemos un mismo dato repetido en diversos
archivos, claves multiplicadas, etc.
c) La existencia de un SGBD nos permite crear un sistema global y único de seguridad,
tanto para controlar los accesos al sistema, como para garantizar la salvaguarda de la
información ante posibles deterioros de la misma.
En general, podemos decir que aquello que diferencia a un SGBD de un sistema

de archivos controlados de forma autónoma por diversas aplicaciones es que con el
primero debemos garantizar la independencia de los datos. En general, las aplicaciones
que construimos son dependientes de la información que manejan. Esto quiere decir que
la aplicación debe estar al tanto del sistema de almacenamiento empleado, de las claves
de acceso a la información, etc. Un cambio en la ubicación de ciertos datos o en la
estructura de índices no puede llevarse a cabo sin modificar igualmente las aplicaciones
que gestionan los datos afectados por dichos cambios.
No obstante, la independencia de los datos es, aún, un objetivo a cubrir por los
SGBD más que una realidad, ya que la mayor parte de los sistemas gestores de bases de
datos no han conseguido todavía garantizar en su totalidad esta independencia.

9.3.3. – Lenguajes y Bases de Datos.
Cada SGBD debe poseer la necesaria estructura de lenguajes que permita

efectuar tanto las labores de diseño de la base de datos, como las de actualización,
consulta y mantenimiento de la misma.
En general, las labores de desarrollo de aplicaciones que realizan los

programadores sobre el soporte de un SGBD, son efectuadas en uno o más lenguajes
anfitriones (host) de la base de datos. Estos son lenguajes convencionales como
COBOL, C, PL/1, DBASE, CLIPPER, FOX BASE, VISUAL BASIC, VISUAL FOX
PRO, VISUAL C++, etc. No obstante, estas herramientas deben poseer un sub-lenguaje
de datos adecuado para tratar los objetos propios de la base de datos. De dicho sub-
lenguaje se dice que está inmerso en el lenguaje anfitrión. En el sub-lenguaje de datos
(DSL –Data Sublanguage-) hemos de distinguir dos partes: El lenguaje para la
definición de datos (DDL –Data Definition Language-) y el lenguaje para la
manipulación de datos (DML –Data Manipulation Language-).
Anfitrión
Lenguajes Lenguaje para la
en un SGBD definición de datos
Sublenguaje
de datos
Lenguaje para la
manipulación de
datos
Lenguajes de un SGBD.
9.3.4. – Los tres enfoques.
Los sistemas gestores de bases de datos se dividen según el tipo de estructura de

datos soportado por cada uno de ellos. En la actualidad los tres enfoques más difundidos
son el jerárquico, el de red y el relacional.
9.3.4.1. – Enfoque jerárquico.
Se parte de que la estructura de datos necesaria es un conjunto de

registros diferentes, guardados en un único archivo, y jerarquizados entre sí
mediante ligas. Supongamos el siguiente modelo para comprender mejor este
enfoque:
La empresa X posee una base de datos que contiene información de sus

empleados y de los departamentos a los que están adscritos. De cada
departamento se guarda su código, al que denominaremos COD y su nombre, al
que denominaremos NOMBRE. De cada empleado se guarda su código, al que

denominaremos COD_EMP, su nombre, al que denominaremos NOM_EMP y
su ciudad, a la que denominaremos CIUDAD.
De este modo, el formato de los dos registros existentes será:

Departamento: COD NOMBRE
Empleados: COD_E NOM_EMP CIUDAD

Supongamos ahora que nuestra empresa ficticia posee tres departamentos
y ocho empleados. Estos datos se verían en un archivo jerárquico del siguiente
modo:
DEP PRODUCCION
01 JUAN BERMUDEZ CADIZ

02 LUISA ALCAZAR CORDOBA
03 JOSE PRIETO LOGROÑO
04 ANTONIO GARCIA MADRID
DEP ADMINISTRACION
05 LUCIA CASTILLO MURCIA

06 ROBERTO GIMBERNAT BARCELONA
07 MARIA CIFUENTES GUADALAJARA
DEP VENTAS
3
08 LUIS GARCIA MADRID
Como vemos hay dos formatos de registro distintos, uno para los
departamentos y otro para los empleados. El conjunto de registro de los
empleados de un departamento se encuentra ligado jerárquicamente al registro
correspondiente a dicho departamento. No obstante, ambos registros se
encuentran contenidos en un mismo archivo.
Este es un ejemplo muy simple de estructura jerárquica. No obstante, el
árbol de ligas establecido entre los datos puede crecer mucho más. Supongamos
que definimos otra porción de nuestro archivo donde anotamos los pagos
mensuales que la empresa X da a sus empleados. El registro que definamos para

contener esta información estaría ligado al registro de empleado definido
previamente.
Las bases de datos jerárquicas están muy difundidas en el mercado, sobre

todo en grandes equipos. No obstante, dada la gran complejidad que presenta su
manejo van siendo sustituidas cada vez más por bases de datos tipo relacional.
Incluso muchos sistemas concebidos desde el enfoque jerárquico son gestionados
hoy de modo semirrelacional.
9.3.4.2. – Enfoque de red (Codasyl).
El enfoque de red es muy similar al jerárquico. Partimos también de las

nociones de registro y enlace. La diferencia radica en que un elemento de inferior
jerarquía puede tener varios elementos situados a un nivel superior del mismo.
Esto no sucedía así en las bases de datos jerárquicas donde la estructura de árbol
impone que un elemento padre puede tener varios elementos hijo, pero no a la
inversa.
En las bases de datos gestionadas bajo el enfoque de red existen lo que se

denominan registros conectores que son estructuras de datos que sirven para
asociar otras dos diferentes estructuras dentro de un archivo. Siguiendo nuestro
ejemplo anterior, supongamos que el pago de nómina a los empleados se realiza
a través de los departamentos. Supongamos también que el registro donde
guardamos el importe de la nómina hace las funciones de uno de estos registros
conectores y que en él registramos solamente el importe del pago que realiza el
departamento a cada empleado.
La red de los pagos efectuados por DEP1 se vería según el gráfico de la

figura siguiente:
DEP1
150 187 362 521
01 02 03 04
La estructura de registros en una Base de Datos Codasyl.
Al igual que decíamos con el enfoque jerárquico, el ejemplo aquí

propuesto es el más simple posible. Podemos comprender fácilmente la gran
cantidad de tiempo que los diseñadores de bases de datos, según el enfoque de
red, han de perder en construir la estructura de conectores y ligas necesarios para
el buen manejo de los datos. Esta gran cantidad de tiempo, junto con la que se ha
de gastar cuando han de hacerse modificaciones en el diseño de los registros, son
los principales problemas que presentan este tipo de bases de datos.
9.3.4.3. – Enfoque relacional.
Aunque es posible que todavía el enfoque relacional no sea el más

difundido en el mercado, sí está claro que es el más aceptado a un nivel teórico,
siendo también, casi sin duda, el modelo hacia el que caminan los SGBD. Bien
es cierto que resulta muy difícil asegurar que un SGBD sea relacional al ciento
por ciento, no obstante esto no es un obstáculo para que las bases de datos
gestionadas según este enfoque sean las que más fuerte pisan actualmente en el
mundo de la informática.
El enfoque relacional se caracteriza porque la presentación de los datos al
usuario se produce en forma de tablas. En dichas tablas las filas o registros
siempre deben tener un formato fijo y una idéntica estructura. El enfoque
relacional en bases de datos parte del modelo relacional en matemáticas y, por
tanto, son susceptibles de aplicar al mismo todas las formulaciones teóricas que
este último presenta. Veamos a continuación una tabla de equivalencias entre tres
conceptos sinónimos y las diferentes maneras con que cada uno de ellos en su
dominio nombra las realidades sobre las que trata.
RELACION ARCHIVO TABLA

Tupla Registro Fila
Atributo Campo Columna
Cardinalidad No. de Registro No. de Fila
Grado No. de Campo No. de Columna
Es muy importante reseñar que en el enfoque relacional no existe ningún

otro componente que no sean tablas, contrariamente a lo que sucedía en las bases
de datos de tipo jerárquico o de red donde hemos encontrado otros componentes:
ligas y conectores. Un principio científico ampliamente aceptado es que un
sistema que puede explicar los mismos hechos con menos componentes es más
plausible que otro que lo haga con más. Esto da ya algunas ventajas al enfoque
relacional.
La siguiente figura muestra el aspecto que presentará nuestra base de

datos de ejemplo siguiendo una notación de tipo relacional.

EMPLEADOS
COD_EMP NOM_EMP CIUDAD COD
01 JUAN BERMUDEZ CADIZ DEP1
02 LUISA ALCAZAR CORDOBA DEP1
03 JOSE PRIETO LOGROÑO DEP1
04 ANTONIO GARCIA MADRID DEP1
05 LUCIA CASTILLO MURCIA DEP2
06 ROBERTO BARCELONA DEP2
GIMBERNAT
07 MARIA CIFUENTES GUADALAJA DEP2
RA
08 LUIS GARCIA MADRID DEP2
DEPARTAMENTOS
COD NOMBRE
DEP1 PRODUCCION
DEP2 ADMINISTRACION
DEP2 VENTAS
NOMINAS
MES COD_EMP IMPORTE
11 01 1,500.00
11 02 1,875.00
11 03 3,623.00
11 04 5,213.00
12 07 8,253.00
07 08 10,215.00
Nuestra Base de Datos de ejemplo según el Modelo Relacional.
Como podemos observar, las tres tablas anteriores contienen la misma

información que hemos manejado en el capítulo anterior para explicar los
enfoques jerárquicos y de red. La información contenida en estas tablas está
plenamente normalizada; esto quiere decir que no hay ambigüedad en las
definiciones de las columnas y que, además, no existe ningún tipo de registro de
longitud variable.
Piénsese lo que sucedería si se intentase guardar el importe de la nómina

en el archivo de empleados. Si reservamos un campo para introducir este dato,
sólo podremos guardar un importe, con lo que perderemos la riqueza de la
información que nos supondría almacenar todos los pagos que se produjeran. Por
otro lado, si tratamos de definir el registro de cada empleado con diversos
campos para guardar cada uno de los pagos: IMPORTE1, IMPORTE2,
IMPORTE3, etc. Difícilmente podríamos prever de antemano el número de

pagos posibles a realizar a cada empleado, por lo que la definición de la
estructura de columnas de nuestra base de datos quedaría incompleta. Otra
solución crearía una gran redundancia de información, ya que en cada registro
grabado quedarían duplicados COD_EMP, NOM_EMP, CIUDAD y COD.
Las tres tablas de nuestro ejemplo salvan estos escollos usando archivos
independientes para cada parcela de la información que pueda ser susceptible de
un tratamiento individualizado. Si posteriormente quisiéramos obtener datos,
producto de cruzar dos o más tablas, bastaría con relacionarlas por el campo
común que poseen: EMPLEADOS puede ser relacionada con
DEPARTAMENTOS a través del campo COD; NOMINA puede relacionarse
con EMPLEADOS a través del campo COD_EMP.
Esto lo podemos ver en la siguiente figura:
DEPARTAMENTOS EMPLEADOS NOMINAS
COD COD_EMP MES

NOMBRE NOM_EMP COD_EMP
CIUDAD IMPORTE
COD
Relaciones entre archivos de la base de datos de ejemplo.
Supongamos que, llegado un momento, necesitásemos saber los pagos

realizados a los empleados del departamento DEP2. Relacionando NOMINAS
con EMPLEADOS a través de COD_EMP podemos ver fácilmente que el único
empleado de DEP2 que tiene un registro de NOMINAS es el que posee un
COD_EMP=07, siendo el importe del único pago efectuado $8,253.
9.3.5. – Diseño de Bases de Datos.
La labor primera y fundamental con la que nos encontramos ante una base de
datos es la de su diseño. Este parte de la observación de la parcela del mundo real que
deseamos informatizar para abstraer de ella el modelo de datos que necesitamos para
formalizar el sistema de información que deseemos realizar. Para realizar esta labor de
modelización se dispone de varias técnicas. Nosotros vamos a explicar brevemente aquí
dos de las más usadas. El modelo entidad-relación y el proceso de normalización.
Antes de llevar a efecto la explicación de estas dos técnicas conviene que

definamos algunos conceptos nuevos:
ENTIDAD Es cada elemento u objeto del mundo real que debe pasar a formar
parte del sistema de información que abordamos. Por ejemplo, los
clientes, las facturas, etc. El Instituto Americano de
Normalización ANSI/SPARC define a la entidad como una
persona, lugar, cosa, concepto o suceso, real o abstracto, de

interés para la empresa. Las entidades suelen corresponderse
con los nombres de una oración.
ATRIBUTO Es cada una de las características de que consta una entidad y que
son de utilidad para el proceso de informatización. Así, un cliente
tiene como atributos su código, su nombre, el total facturado, el
porcentaje de descuento que le hacemos habitualmente, etc.
VALOR Es un caso concreto de un atributo. Así, por ejemplo, el valor

0017 para el atributo CODIGO DE CLIENTE, el valor
28/1287162 para el atributo NÚMERO DE SEGURIDAD
SOCIAL.
El diseño de una base de datos es un proceso de abstracción sucesiva de modo

que partiendo del mundo real lleguemos a un diseño físico pasando por un modelo de
datos y un diseño lógico de los mismos.
9.3.6. – El modelo Entidad-Relación..
Este modelo engloba una serie de técnicas para llevar adelante el proceso de
diseño de una base de datos. Con él realizamos el paso que va desde la determinación de
las entidades del mundo real hasta la formalización del modelo de datos y una primera
aproximación al diseño lógico de la base de datos resultante. El método empleado tiene
dos fases claramente diferenciadas:
1) Consiste en representar, mediante un determinado conjunto de símbolos, las

entidades, los atributos de las mismas y las interrelaciones que entre ellas
existen. Con ello tenemos lo que venimos denominando modelo de datos.
2) Consiste en determinar el diseño de la base de datos basándonos en el
modelo de datos hallado en el proceso anterior.
Los símbolos empleados pueden verse en las siguientes figuras.
ENTIDAD
RELACION
ATRIBUTO
Los símbolos del modelo entidad-relación.

En general, con ellos poseemos una buena herramienta para efectuar el diseño de
una base de datos. La primera labor a efectuar para ello es tomar papel y lápiz (o alguna
herramienta informática, si la poseemos) y tratar de representar todas las entidades que
descubramos en la parcela del mundo real que debamos formalizar. A continuación
deberemos determinar las relaciones entre estas entidades y las restricciones que llevan
consigo.
Lo veremos mejor con un problema práctico. Veamos el siguiente enunciado de

aplicación:
La empresa X desea gestionar la información relativa a sus empleados y

departamentos. Un departamento normalmente consta de varios empleados y éstos
siempre están adscritos a un solo departamento. Se desea mantener información sobre
los datos de identificación básicos de los empleados: código identificador, nombre,
domicilio, fecha de ingreso y salario anual, así como el nombre literal de cada
departamento y la planta en que se ubica en la empresa.
Con este enunciado ya tenemos claramente diferenciadas dos entidades:

EMPLEADO y DEPARTAMENTO. Entre ambas existe una relación: Los empleados
pertenecen a los departamentos. Así, pues, a las don entidades hemos de añadirle una
relación, a la cual denominaremos Pertenece_a. Veamos ahora las restricciones de esta
relación.
• Un empleado pertenece como mínimo y como máximo a un departamento.

• Un departamento lo forman como mínimo 0 empleados y como máximo N
empleados.
Con estos dos enunciados anteriores hemos descubierto lo que denominaremos la

Cardinalidad en el modelo entidad-relación. Esta se representa en el primer caso como
(1,1) y en el segundo como (0,N). Cuando la N aparece sólo asociada a una de las dos
entidades relacionadas decimos que el grado de la relación es de 1 a N. Esto se
representa 1:N. Si la N hubiera aparecido en ambas entidades, la relación sería N:M; lo
que querría decir que para 1 ocurrencia de la primera entidad habría N ocurrencias de la
segunda y viceversa. Cuando la N no aparece en ninguna de las dos entidades la relación
es 1:1. Así pues, ya tenemos los tres tipos posibles de grado en una relación.
1:1 Para un elemento de una entidad existe 1 elemento de la otra y viceversa.
1:N Para un elemento de una entidad existen N elementos de la otra.
N:M Para N elementos de una entidad existen M elementos de la otra y

viceversa.
La representación gráfica final del modelo de datos de nuestra aplicación puede

verse en la siguiente figura.

EMPLEADO Pertenece_a DEPARTAMENTO
CODIGO CODIGO
NOMBRE NOMBRE
DOMICILIO UBICACION
F. INGRESO
SALARIO
El modelo de datos de la aplicación propuesta.
El siguiente paso consiste en formar las tablas que necesitamos construir para
gestionar la aplicación que se nos demanda. Las reglas son:
• Una entidad se corresponde con una tabla.

• En las relaciones 1:N la entidad de la N ocurrencias hereda la clave de la
entidad de la ocurrencia única. (Este es nuestro caso. La regla a lo que nos
lleva es a que la clave identificadora del departamento –el código-, hayamos
de llevarlo a la tabla del empleado, de modo que podamos relacionar a ambos
a través de él).
• Las relaciones N:M se convierten en una tabla cuyos atributos son como
mínimo las claves de las dos entidades relacionadas. Piénsese por ejemplo en
la relación entre las entidades AULA y PROFESOR. Un profesor puede dar
clase simultáneamente en varias aulas y un aula puede esta ocupada a lo largo
del día por varios profesores. Esta es una relación N:M que se resuelve con
una tabla donde guardamos las aulas, otra donde guardamos los profesores y
una tercera (la proveniente de la relación N:M donde guardamos la clave del
aula, la del profesor así como cualquier otro atributo de interés para la
relación, como por ejemplo, el día y la hora en que se da una clase).

Pues bien, usando estas reglas podemos tener ya la composición de las tablas con
las que nuestra aplicación debe trabajar:
EMPLEADO DEPARTAMENTO
CODIGO EMPLEADO CODIGO DEPARTAMENTO
NOMBRE EMPLEADO NOMBRE DEPARTAMENTO
CODIGO DEPARTAMENTO UBICACIÓN FISICA
CALLE Y NÚMERO
CODIGO POSTAL
CIUDAD
TELEFONO
FECHA INGRESO
SALARIO ANUAL
Con esto hemos visto, de manera excesivamente resumida, el uso del modelo
entidad-relación para diseñar una base de datos. Piénsese lo complejo de esta labor en
bases de datos con centenas de entidades y relaciones. Discúlpenos el lector novicio en
bases de datos por el excesivo tecnicismo y el experimentado por resumir con tanta
brevedad los conceptos. Como casi siempre, es difícil hallar el justo término medio.
9.3.7. – Normalización.
Lo habitual es que el modelo entidad-relación sea la primera aproximación que el

analista hace al diseño de una base de datos. Tras este primer acercamiento siempre ha
de venir otro más profundo que sirve para depurar la estructura de datos definida y
revisar posibles errores del modelo. Es lo que denominamos normalización. Antes de
entrar en detalle con ella permítasenos realizar algunas definiciones previas:
DEPENDENCIA FUNCIONAL.
Dado un archivo, sean CAMPO1 y CAMPO2 dos campos de ese archivo.

Diremos que CAMPO2 tiene dependencia funcional de CAMPO1 cuando dado un valor
de CAMPO! Se obtiene un valor único de CAMPO2, o que a cada valor de CAMPO2 le
corresponde un único valor de CAMPO1.
DEPENDENCIA FUNCIONAL COMPLETA.
Si en un archivo, CAMPO1 es un conjunto de campos, entonces diremos que

CAMPO2 tiene una dependencia funcional completa de CAMPO1 cuando CAMPO2
tiene dependencia funcional de todo el conjunto de CAMPO1 y no tiene dependencia
funcional de un subconjunto de CAMPO1. Cuando CAMPO1 consta de un único
atributo entonces coincide la dependencia funcional y la dependencia funcional
completa.

CANDIDATO A CLAVE.
Candidato a clave es un atributo o conjunto de atributos que identifica de forma

unívoca un registro. Uno de los candidatos a clave es utilizado como clave principal o
primaria.
ATRIBUTO NO CLAVE.
Es aquel que no forma parte de la clave o de un candidato a clave.
DETERMINANTE.
Es un atributo o un conjunto de atributos del que dependen otros atributos.
Decimos que una relación está normalizada cuando para cada fila de una
determinada columna sólo existe un valor individualizado y no un conjunto de valores.
En nuestro ejemplo anterior vemos que en el fichero EMPLEADOS sólo podemos
asignar un valor a la columna CIUDAD para cada fila, es decir, para cada registro de un
empleado distinto. La normalización nos permite estructurar los datos en relaciones y
además evita que los archivos de las bases de datos tengan redundancias, incoherencias
o inconsistencias.
9.3.7.1. – Formas normales.
NO NORMALIZADO.
Decimos que una relación o archivo no está normalizada cuando sus

diferentes atributos se encuentran en un formato ambiguo, sin distinción
funcional y con longitud variable. Por ejemplo, si en una base de datos bancaria
guardamos en el mismo registro los datos del titular de la cuenta y todos los
movimientos asociados.
1ª. FORMA NORMAL (1NF).
Una relación esta en 1NF si y sólo si sus atributos son no

descomponibles, es decir, si dentro de un mismo campo guardamos información
que no puede ser susceptible de una ulterior subdivisión.
Una relación esta en 2NF cuando está en 1NF y cada atributo no clave
tiene Dependencia Funcional Completa de la clave primaria. Una relación que
esté en 1NF puede descomponerse en un conjunto de relaciones que estén en
2NF.

Una relación está en 3NF cuando está en 2NF y cada atributo no clave
tiene dependencia no transitiva de la clave principal. O dicho de otra manera,
cada atributo tiene dependencia únicamente de la clave, no existiendo
dependencias entre atributos no clave.
Veamos un ejemplo17:
Tenemos una empresa con una lista de proveedores con los siguientes datos:
CODIGO Código del proveedor.
NOMBRE Nombre del proveedor.
ESTADO Coeficiente numérico que se asigna a cada proveedor en función

del volumen de negocio con éste.
CIUDAD Ciudad donde vive el proveedor.
PEDIDO Pedido que se hace al proveedor (sólo uno por cada pieza).
PIEZA Pieza que se le pide al proveedor.
NOMPIEZ Nombre de la pieza.
COLOR Color de la pieza.
PESO Peso de la pieza.
CIUPED Ciudad a la que se envía la pieza.
17
Los archivos del ejemplo están tomados de la obra citada: C.J. Date. Op. Cit.

El formato de la ficha que recoge esta información sería el siguiente:
Código: S1
Proveedor: Francisco Hernández y Fernández
Estado: 20
Ciudad: Londres
Pedidos:
Pieza Cantidad Nombre Color Peso Ciudad

P1 300 N1 Rojo 12 París
P2 150 N2 Verde 20 Madrid
P3 200 N3 Azul 14 Madrid
. . . . . .
. . . . . .
. . . . . .
La relación estaría formada por:
CODIGO NOMBRE ESTADO CIUDAD PIEZA CANTIDAD NOMPIEZ COLOR PESO CIUPED
PEDIDO
Uno de los problemas que puede traer esta estructura de relación es que al
dar de ALTA a un proveedor, forzosamente tendremos que dar de alta a un
pedido, de la misma manera que si damos de baja a un pedido corremos el riesgo
de perder la información relativa a un proveedor, si éste tiene un solo pedido.
Además el atributo PEDIDO puede repetirse si un proveedor tiene más de
un pedido, con lo que tendríamos que utilizar registros de longitud variable.
No está en 1NF (1ª Forma Normal) porque tiene el atributo PEDIDO que
es descomponible.
La falta de normalización de esta estructura puede corregirse usando el

siguiente método:
REL 1A
CODIGO NOMBRE ESTADO CIUDAD
REL 1B
CODIGO PIEZA CANT NOMPIEZ COLOR PESO CIUPED
La clave de REL 1A es CODIGO y la de REL 1B es CODIGO+PIEZA.
Estas dos relaciones ya están en 1NF con lo que eliminamos los

problemas anteriores, aunque todavía posee otros no menos serios.

Cuando damos de ALTA a una pieza, también tenemos que dar de alta a
un pedido. Esto nos obliga a rellenar en blanco los atributos CODIGO, CANT,
CIUPED. Al igual que si damos de baja un pedido perderemos la información
relativa a esa pieza. A la hora de la modificación de los datos de una pieza nos
vemos en la obligación de modificarlo tantas veces como pedidos de ésta existan.
REL 2A
CODIGO NOMBRE ESTADO CIUDAD
REL 2B
CODIGO PIEZA CANT CIUPED
REL 2C
PIEZA NOMPIEZ COLOR PESO
La clave de REL 2A es CODIGO, la de REL 2B es CODIGO+PIEZA, y

la de REL 2C es PIEZA.
La relación REL 2ª ya estaba en 2NF porque no tenía clave compuesta.

Las otras dos relaciones han surgido de la REL 1B que sí tenía clave compuesta y
sin embargo no todos sus atributos dependían totalmente de ella. Los que sólo
dependían de PIEZA, y no de CODIGO, han dado lugar a la relación REL 2C.
Las tres relaciones están también en 3NF pues no hay dependencias de

atributos no clave entre sí. Todos dependen únicamente de su clave principal.
Las relaciones resultantes son sin duda mucho más óptimas para el
movimiento de datos. La potencia de un Gestor de Bases de Datos Relaciónales
estriba en la posibilidad de relacionar de forma automática los diferentes
archivos que sean producto de situar en Tercera Forma Normal una estructura de
información no normalizada.
9.3.8. – Índices y ordenaciones.
La información que se guarda en los archivos de una base de datos se almacena

de forma secuencial en los diferentes archivos de la misma, es decir, que cada registro se
escribe físicamente en un lugar posterior al último escrito.
Si nuestra base de datos es muy grande, la localización de un caso particular

puede ser larga y tediosa, ya que tendríamos que recorrernos desde el principio todos los
registros de la misma hasta localizar aquel que estamos buscando. Los índices están
pensados para solucionar este problema. Cada índice suele guardarse en una tabla
auxiliar donde se guarda el número de registro correspondiente a cada caso y el valor del
índice para ese caso. Para comprender esto mejor veamos un ejemplo:

EMPLEADOS
No. COD_EMP NOM_EMP CIUDAD COD
Reg.
1 01 JUAN BERMUDEZ CADIZ DEP1
2 02 LUISA ALCAZAR CORDOBA DEP1
3 03 JOSE PRIETO LOGROÑO DEP1
4 04 ANTONIO GARCIA MADRID DEP1
5 05 LUCIA CASTILLO MURCIA DEP2
6 06 ROBERTO BARCELONA DEP2
GIMBERNAT
7 07 MARIA CIFUENTES GUADALAJA DEP2
RA
8 08 LUIS GARCIA MADRID DEP2
INDICE POR NOMBRE

NOM_EMP No. Reg.
ANTONIO GARCIA 4
JOSE PRIETO 3
JUAN BERMUDEZ 1
LUCIA CASTILLO 5
LUISA ALCAZAR 2
LUIS GARCIA 8
MARIA CIFUENTES 7
ROBERTO 6
GIMBERNAT
ORDENACION POR INDICES
En la figura anterior se nos muestra el archivo de empleados que ya hemos visto

con anterioridad. Como puede verse, este archivo está ordenado por el código de cada
empleado. Para una mayor claridad, hemos anotado en él también el número de registro
correspondiente a cada caso. Si nos interesara hacer búsquedas alfabéticas por el nombre
de cada empleado tendríamos alguna dificultad, ya que no existe una ordenación por este
campo.
En la figura podemos ver también qué aspecto tendría un índice por nombre.
Como podemos observar, este índice lo concebimos como un archivo independiente
donde guardamos solamente el valor de cada nombre y el número del registro que cada
uno de ellos tiene en el archivo principal. Al estar alfabetizado el índice las búsquedas
son muy rápidas y si queremos acceder al caso completo bastará con dirigirnos al
archivo principal por el número de registro contenido en la tabla índice.
Los índices deben mantenerse de forma automática por el SGBD o mediante las
instrucciones pertinentes del sub-lenguaje de datos. Es decir, cada vez que actualicemos
la información de la tabla principal debe existir algún sistema para que se produzca una

actualización de la tabla índice.
Existen también otro tipo de ordenaciones provisionales que se realizan sobre
archivos de trabajo, pero que no son mantenidas por el sistema sino que se realizan en el
momento en que han de ser usadas sin ninguna implicación posterior. Supongamos que
la ordenación alfabética descrita no es frecuentemente usada por la aplicación que
gestiona los archivos ya vistos. No obstante, en un determinado momento necesitamos
obtener un listado alfabético de todos los empleados de la empresa, dicho listado
difícilmente volverá a ser necesario. En este caso habría que proceder a una de estas
ordenaciones temporales que quedaría destruida una vez emitido el correspondiente
listado.
Una de las labores preeminentes a la hora de realizar el diseño de una base de
datos relacional es fijar por qué campos habrán de ser indexados los archivos. Un
archivo índice nos garantiza una enorme rapidez en el acceso a la información, por ello
parece que podría ser interesante que todos los campos de nuestros archivos fueran
índices. Sin embargo los índices ocupan también espacio en disco y han de ser
controlados por el sistema como un archivo más, esto puede crear ciertas limitaciones.
Por ello han de fijarse como índices sólo aquellos campos que más frecuentemente
hayan de ser accedidos por sus correspondientes valores, dejando el resto sin indexar
como campos susceptibles de ser ordenados de manera temporal por el segundo sistema
descrito.
Las ordenaciones también pueden realizarse por campos múltiples o por

expresiones que contengan valores de campos. Por ejemplo, la tabla de empleados
podría ordenarse por NOM_EMP+CIUDAD de modo que los empleados aparecieran
por orden alfabético para cada ciudad, o bien por los 20 primeros caracteres de
NOM_EMP.
9.3.9. – Lenguajes de cuarta generación (4GL).
Uno de los elementos típicos que suelen incorporar los Gestores de Bases de
Datos es lo que denominamos Lenguaje de Cuarta Generación. Estos lenguajes están
diseñados para facilitar el diseño rápido de aplicaciones y el fácil acceso a la
información contenida en las bases de datos. Un lenguaje de cuarta generación es un
lenguaje anfitrión más de entre los soportados por un SGBD, junto con los de tercera
generación: COBOL, etc. Sus características fundamentales son:
• Poseer un elevado nivel de ayudas a la programación, lo que le hace accesible

a usuarios o programadores no experimentados.
• Poseer generadores automáticos de informes, pantallas, gráficos e incluso
aplicaciones completas.
• Estar basado en las pautas de la programación estructurada.
• Poseer dos niveles de uso, uno avanzado para programadores basado en una
estructura de mandatos similar a la de cualquier lenguaje convencional y
otro, más simple, enfocado a usuarios donde la mayoría de las labores se
desarrollan por menús o por la cumplimentación de pantallas predefinidas.
• A veces es también una característica la posesión de una interfaz de lenguaje
natural para las consultas simples de los usuarios del sistema.

Como ejemplos tenemos los lenguajes llamados, Visuales, de los cuales, algunos tienen origen en los
viejos lenguajes de programación y conservan varias de sus características, tales como:
Lenguaje Visual Lenguaje Origen

Visual Basic Basic
Visual C++ C++
Delphi Pascal
Visual Fox Pro Fox Pro (o Fox Base), Dbase, Clipper
9.4. – Gestión de archivos de datos.
Antes de iniciar con el estudio de los diagramas y algoritmos para la gestión de archivos,
debes saber que las operaciones de un sistema básico de gestión de archivos (Sistema ABC) son
Altas de registros, Bajas de registros, Consultas de registros y Cambios o Modificaciones de
registros (sin olvidar la Creación del Archivo, que se verá mas adelante); siendo cada operación
un módulo del sistema. Este sistema básico (que también algunos llamamos: de mantenimiento
de registros) lo podemos representar en una estructura jerárquica como sigue:
Menu ABC
Altas Bajas Consultas Modificaciones

o
Cambios
Dependiendo de los gustos de cada programador, cada módulo puede ser independiente
y presentar su propia pantalla de despliegue de datos, o bien, englobar en un solo módulo dos o
más operaciones básicas, por ejemplo: Consultas y Cambios. O bien, presentar en una pantalla,
un listado de los registros y mediante teclas de funciones bien definidas, accesar a cada
operación básica de mantenimiento de registros; con el propio estilo del programador.
Una nota muy importante es el hecho de que existen dos tipos de Bajas de registros; una
la llamaremos Baja Lógica y la otra Baja Física18.
La Baja Lógica consiste en marcar el registro que se desea eliminar, para que el sistema
lo considere como borrado, pero sin que los datos desaparezcan o se pierdan. Esto lo puede
hacer el SGBD mediante una marca interna, o bien nosotros a través de un campo al cual
podríamos llamar STATUS o CONDICION, el cual puede contener un tipo de dato Carácter o
Lógico, según sea posible o necesario. Una de las ventajas de la Baja Lógica, es la de poder
recuperar registros que fueron borrados por error o bien aquellos que son necesarios reactivar
por necesidades propias del proceso de información, y por el contra parte tenemos que una
desventaja es el espacio en disco que ocupa.
La Baja Física, como es de esperarse, consiste en eliminar totalmente el registro, es
decir, borrar todos los datos de los campos relativos al registro deseado. La ventaja de hacer lo
18
La frase Baja Física es relativa, dado que la información en sí, se maneja como si fuera un objeto en un plano conceptual,
sin embargo, en el plano real, estos objetos al ser datos únicamente, no tienen volumen, peso o color, sino mas bien, los
describen o representan.

anterior es que economiza espacio en disco, sin embargo, una de sus peores desventajas es que
resulta prácticamente imposible recuperar la información del registro.
Normalmente en la gran mayoría de los sistemas de gestión de archivos, se consideran
los dos tipos de Bajas, y por lo general el procedimiento para dar de baja a uno o mas registros
consiste en realizar primero una Baja Lógica de aquel o aquellos registros que se desean
eliminar, y posteriormente, pasado un tiempo considerable, ejecutar un procedimiento de Baja
Física para todos aquellos registros marcados como Baja Lógica. En otras palabras, primero se
marcan los registros deseados para su borrado, y pasado un tiempo se eliminan definitivamente,
uno por uno o por lote, todos los registros marcados como borrados.
Como observación primordial, debemos tener presente que todo Sistema ABC, debe
incluir una rutina o instrucción de creación del archivo.
La operación para crear un archivo lleva aparejada tanto la acción de dar nombre al
mismo, a fin de que el sistema lo reconozca, como la de dotarlo con la necesaria estructura de
registro según nuestras conveniencias. Todo esto podemos dividirlo en las siguientes secuencias
lógicas:
1. Identificar cada archivo mediante un nombre y el camino (ruta de acceso) necesario

para su localización en el disco.
2. Indicar el nombre de cada campo.
3. Indicar el tipo de cada campo.
4. Indicar el tamaño de cada campo.
Una vez que tenemos pensado el nombre y la información que contendrá nuestro
archivo, debemos indicar cómo se va a guardar dicha información. La unión de todos estos
campos dará como resultado un registro, de tal forma que podremos decir que un registro
contiene toda la información referente a un objeto (objeto desde el punto de vista informático
puede ser una persona, una cosa, etc.).
Un campo va a estar formado por una serie de especificaciones. Estas serán:
- Nombre de Campo
- Tipo de Campo
- Ancho de Campo
- Número de decimales del Campo
Nombre de Campo Es el nombre que le daremos a cada campo. Un nombre de campo esta
limitado por las normas del traductor que usemos. Sin embargo, deberá
forzosamente empezar por una letra y podrá contener letras, números y el
carácter especial “_”. Es aconsejable que el nombre sea significativo
(descriptivo) respecto al dato que almacenará, para que así nos sea fácil
de identificar a la hora de manipularlo.
Tipo de Campo Deberemos indicar el tipo de dato que vamos a utilizar. Recordemos que
en los traductores de los lenguajes de programación se dispone por lo
menos de dos tipos de campos:

• CARÁCTER. Los campos definidos con este tipo podrán
contener todo tipo de caracteres, letras, números, caracteres especiales
y espacios en blanco.
• NUMERICO. Sólo pueden contener números, punto decimal y el

signo negativo. Pueden ser números enteros o decimales.
Sin embargo, deberemos especificar claramente los tipos de datos a

utilizar en la estructura del archivo, de tal manera que, sepamos que
formato utilizaremos para mostrar los datos. De ahí tenemos que otros
tipos de datos que debemos usar y que también son aceptados por algunos
traductores, son:
• FECHA. Acepta valores de fecha. Su longitud es normalmente de 8

caracteres. Debemos tener cuidado, para el caso de que el traductor no
reconozca este tipo de dato, de crearnos las rutinas necesarias para
que este tipo solamente acepte fechas válidas. Los formatos utilizados
generalmente son: dd/mm/aa ó mm/dd/aa, según la configuración del
traductor o bien que así lo desee el programador.
• LOGICO. Este tipo de campo tiene posibilidad de tomar dos valores,
verdadero o falso. Para verdadero se introducirá T, Y o S (True, Yes o
Si) y para falso F o N (False, Falso o No). Su longitud es de 1
carácter.
• MEMO. Se utiliza para guardar textos de longitud variable. Los
datos que introducimos en este campo, no se guardan en el archivo en
el que definimos el campo, sino en otro de igual nombre por lo
general. En el archivo donde se define el campo, se almacena una
clave que relacionará el registro con el texto correspondiente en el
archivo de texto.
Ancho de Campo En este concepto se determinará la longitud que tendrá el campo, no

pudiendo sobrepasar los límites según su tipo, de acuerdo al traductor
utilizado.
Deberemos tener en cuenta que si un campo de tipo NUMERICO tiene
decimales, al especificar el ancho, deberemos sumarle a los dígitos del
número entero, el punto decimal y el número de decimales que llevará
asociado. Supongamos que queremos guardar números de la forma
999999.9999, para ello indicaremos que el ancho de este campo será 11,
ya que tenemos 6 dígitos para la parte entera, 1 para el punto decimal y 4
dígitos como parte decimal.
Como última aclaración a la hora de especificar el ancho de los campos,

deberemos pensar siempre en el dato de mayor longitud que será
introducido en el archivo, y que no deberemos ni quedarnos cortos ni
poner mayor longitud de la prevista. Por ejemplo supongamos que
tendremos un campo Mes donde guardaremos los nombres de los
distintos meses del año, pues bien no deberemos asignar un ancho de 7

caracteres, ya que ni Septiembre, ni Noviembre, ni Diciembre quedarán
guardados completamente, y por el contrario tampoco diremos que tendrá
un ancho de 25 ya que el mes de nombre más largo, Septiembre,
solamente tiene 10 caracteres.
Decimal de Campo Indicaremos aquí los decimales que contendrá un campo de tipo
numérico.
Todas las especificaciones antes descritas podríamos anotarlas en forma de una tabla como la
que se muestra a continuación.
Nombre del Tipo Ancho Decimales

Campo
Y como nota final, siempre deberemos crear un campo clave, por medio del cual accesaremos la
información a un registro, de una manera rápida y precisa, por ejemplo: Número de Control (de
un alumno), Número de Referencia (de una cuenta contable), Número económico o Número de
placas (de una unidad de transporte), Número de modelo o de serie (de aparatos diversos),
Número de código de barras (de artículos diversos), etc.
Y por fin, después de todo este mundo de conceptos, veremos los diagramas y
algoritmos típicos para la gestión de archivos.
Para el lector que ha seguido paso a paso este manual notará que, los primeros
diagramas así como sus algoritmos, tienen un diseño “no estructurado”, es decir, no usan una
lógica lineal, la cual haría uso de bucles y no de saltos de una línea a otra.
Los segundos diagramas, como los algoritmos tienen un diseño “estructurado”, es decir,
utilizan una lógica lineal, usando las instrucciones de bucles, en lugar de saltos de una línea a
otra.
Esto se hizo así con el fin de presentar, lo más simple posible, la lógica de gestión de
archivos, desde los dos tipos de programación, para que compare las diferencias, y desde luego,
se tomen como base para iniciar la codificación de programas para la gestión de archivos,
puesto que tanto los diagramas como los algoritmos presentados a continuación, son
susceptibles de optimizaciones y adecuaciones al estilo de cada programador, aunque, la lógica
general sea básicamente la misma.
Debo recordarle amable lector que es preferible el modelo “estructurado”.

9.4.1. – Gestión de archivos secuenciales.
DISEÑO “NO ESTRUCTURADO”
Diagrama de flujo: ALTAS.
INICIO C
Inicializar NO
¿ Clave del Registro
Variables
= Clave Capturada?
SI Ir al siguiente
registro
NO Creación
¿Existe el
del “La Clave
archivo?
archivo. YA existe.”
SI D
A E
Abrir archivo A Ir al Principio
del archivo
B
Solicitar clave
y datos. ‘¿Más datos?
(S/N)’
Clave y datos Respuesta
D
SI
Respuesta=‘S’ B
¿Fin de SI Grabar el NO
Archivo? nuevo registro
Cerrar archivo
NO
E
Leer
registro. FIN

DISEÑO “ESTRUCTURADO”
INICIO C
Inicializar
¿ Clave del Registro NO
Variables
= Clave Capturada?
SI Ir al siguiente
SI registro
¿ No Existe el
archivo?
Encontrado = Verdadero
NO Creación
A del D
archivo.
“La Clave
Abrir archivo
YA existe.”
Respuesta=‘S’ A
Encontrado=Falso
F
B
NO
Respuesta=‘S’
Cerrar archivo
SI
FIN
Solicitar clave
y datos.
Clave y datos
D
F E
¿No es Fin NO ¿No fue NO Ir al

de Archivo? encontrado? Principio
del archivo
SI
SI ‘¿Más datos?
Leer (S/N)’
registro. Grabar el
nuevo registro
Respuesta
C
E B
DISEÑO “NO ESTRUCTURADO”.
Algoritmo: ALTAS.
1. Inicializar Variables.
2. Sí Existe el archivo entonces
Ir al paso 3.
Sino
Crear el archivo.
3. Abrir el archivo.
4. Desplegar solicitud de clave y datos.
5. Introducir clave y datos.
6. Sí es Fin de Archivo entonces
- Grabar el nuevo registro
- Ir al paso 11.
7. Leer registro
8. Sí Clave del Registro = Clave Capturada entonces
- Desplegar ‘La Clave YA existe.’
- Ir al paso 11.
9. Ir al siguiente registro.
10. Ir al paso 6
11. Ir al principio del archivo.
12. Desplegar ‘¿ Más datos ?’
13. Introducir Respuesta
14. Sí Respuesta=’S’ entonces
Ir al paso 4.
15. Cerrar el archivo.
16. FIN.

DISEÑO “ESTRUCTURADO”.
Algoritmo: ALTAS.
2. Sí No Existe el archivo entonces
a. Crear el archivo.
3. Fin del Sí
5. Respuesta = ‘S’
6. Encontrado = Falso
7. Mientras Respuesta = ‘S’
a. Desplegar solicitud de clave y datos.
b. Introducir clave y datos.
c. Mientras No sea Fin de archivo
i. Leer registro.
ii. Sí Clave del Registro = Clave Capturada entonces
1. Encontrado = Verdadero.
2. Desplegar ‘La Clave YA existe.’
3. Salida (del Mientras no sea Fin de archivo).
iii. Fin del Sí.
iv. Ir al siguiente registro.
d. Fin del Mientras No sea Fin de archivo.
e. Sí No fue Encontrado entonces
i. Grabar el nuevo registro.
f. Fin del Sí.
g. Ir al Principio del archivo.
h. Desplegar ‘¿Más datos? (S/N)’.
i. Introducir Respuesta.
8. Fin del Mientras Respuesta = ‘S’
9. Cerrar Archivo.
10. FIN.

Diagrama de flujo: BAJAS. (Baja Lógica).
INICIO C
Inicializar Datos del

Variables registro.
‘¿Dar de baja
el registro?’
NO Creación
¿Existe el
del
archivo? Respuesta
archivo.
SI
NO
Respuesta=‘S’ E
Abrir archivo
‘El archivo
esta vacio’
SI
B
Marcar y grabar el
Solicitar la A registro
clave.
E
Clave. Ir al Principio
del archivo
D
SI ‘El registro ‘¿Otra Baja?

¿Fin de
(S/N)’
Archivo?
NO existe’
NO
Respuesta
Leer E
registro.
SI
Respuesta=‘S’ B
¿ Clave del registro NO

NO
= Clave Capturada?
Ir al siguiente Cerrar archivo
SI registro
A
C
D FIN
INICIO C
Inicializar
Variables ¿ Clave del registro NO
= Clave Capturada?
Ir al siguiente
Creación
SI registro
¿Existe el NO
del
archivo? Encontrado = Verdadero
archivo.
SI D
Datos del
Abrir archivo ‘El archivo registro.
esta vacio’ ‘¿Dar de baja el
registro?’
Respuesta = ‘S’
Encontrado = Falso
A
B A Respuesta
NO Cerrar archivo NO
Respuesta=‘S’
Respuesta=‘S’ E
SI
SI
FIN
Solicitar la
clave. Marcar y grabar el
registro
E
Clave.
¿No fue NO
D encontrado? G
F
¿No es Fin NO
E SI
de Archivo?
‘¿Otra Baja?
‘El registro (S/N)’
SI
NO existe’
Leer G
registro. Respuesta
Ir al Principio
del archivo
Encontrado = Falso
C
Realizó: Ing. Domingo Olivares Barrios F Pág. 147
B
Algoritmo: BAJAS. (Baja Lógica).
Ir al paso 3.
Sino
- Crear el archivo
- Desplegar ‘El archivo esta vacío’
- Ir al paso 20.
4. Solicitar la Clave.
5. Introducir la Clave.
- Desplegar ‘El registro NO existe’
- Ir al paso 14.
7. Leer registro
Ir al paso 11.
10. Ir al paso 6.
11. Desplegar los datos del registro.
12. Desplegar ‘¿Dar de baja el registro?’
13. Introducir Respuesta.
14. Sí Respuesta = ‘S’ entonces
Marcar y grabar el registro.
16. Desplegar ‘¿ Otra Baja ?’
Ir al paso 4.
20. FIN.

i. Inicializar Variables.
ii. Sí Existe el archivo entonces
2. Respuesta = ‘S’
3. Encontrado = Falso
4. Mientras Respuesta = ‘S’
a. Solicitar la Clave.
b. Introducir la Clave.
c. Mientras No sea Fin de Archivo
i. Leer registro
ii. Sí Clave del Registro = Clave Capturada entonces
1. Encontrado = Verdadero.
a. Marcar y grabar el registro.
6. Fin del Sí.
7. Salir (del Mientras No sea Fin de Archivo)
iii. Fin del Sí.
iv. Ir al siguiente registro.
d. Fin del Mientras No sea Fin de Archivo.
e. Sí No fue Encontrado entonces
i. Desplegar ‘El registro NO existe.’.
f. Fin del Sí.
g. Ir al principio del archivo.
h. Desplegar ‘¿ Otra Baja ?’
i. Introducir Respuesta
j. Encontrado = Falso.
5. Fin del Mientras Respuesta = ‘S’
iii. Sino
1. Crear el archivo
2. Desplegar ‘El archivo esta vacío’
iv. Fin del Sí.
v. Cerrar el archivo.
vi. FIN.

Diagrama de flujo: CONSULTAS.
INICIO C
Inicializar NO
¿ Clave del registro
Variables
= Clave Capturada?
SI Ir al siguiente
registro
NO Creación
¿Existe el Datos del
del
archivo? registro.
archivo.
SI E D
‘El archivo Ir al Principio
Abrir archivo esta vacio’ del archivo
B
Solicitar la A ‘¿Otra consulta?
clave. (S/N)’
Capturar la Respuesta
Clave.
D SI
Respuesta=‘S’ B
SI ‘El registro
¿Fin de NO
Archivo?
NO existe’
Cerrar archivo
NO
A
Leer E
registro. FIN

INICIO C
Inicializar
= Clave Capturada?
Ir al siguiente
Creación
SI registro
¿Existe el NO
del
archivo.
SI D
Datos del
esta vacio’
E
Respuesta = ‘S’
Encontrado = Falso
A ¿No fue NO
B A encontrado? F
NO Cerrar archivo
Respuesta=‘S’ SI
‘El registro
SI
FIN NO existe’
Solicitar la
clave. F
Ir al Principio
del archivo
Clave.
D ‘¿Otra Consulta?
(S/N)’
¿No es Fin NO
de Archivo? E
Respuesta
SI
Leer Encontrado = Falso

registro.
B
C
Algoritmo: CONSULTAS.
Ir al paso 3.
Sino
- Crear el archivo
- Ir al paso 17.
- Ir al paso 12.
7. Leer registro
Ir al paso 11.
10. Ir al paso 6.
Ir al paso 4.
17. FIN.

a. Abrir el archivo.
b. Respuesta = ‘S’
c. Encontrado = Falso
d. Mientras Respuesta = ‘S’
i. Solicitar la Clave.
ii. Introducir la Clave.
iii. Mientras No sea Fin de Archivo
1. Leer registro
a. Encontrado = Verdadero.
b. Desplegar los datos del registro.
c. Salir (del Mientras No sea Fin de Archivo)
3. Fin del Sí.
iv. Fin del Mientras No sea Fin de Archivo.
v. Sí No fue Encontrado entonces
1. Desplegar ‘El registro NO existe.’.
vi. Fin del Sí.
vii. Ir al principio del archivo.
viii. Desplegar ‘¿ Otra Consulta ?’
ix. Introducir Respuesta
x. Encontrado = Falso.
e. Fin del Mientras Respuesta = ‘S’
3. Sino
a. Crear el archivo
b. Desplegar ‘El archivo esta vacío’
4. Fin del Sí.
6. FIN.

Diagrama de flujo: CAMBIOS. (Modificaciones).

INICIO C
Datos del
Inicializar registro.
Variables ‘¿Modificar el
registro?’
Respuesta
¿Existe el NO Creación
del
archivo?
archivo.
NO
Respuesta=‘S’ E
SI
‘El archivo SI
Abrir archivo esta vacio’ Solicitar los
datos del
B registro.
Solicitar la A
clave.
Datos del registro.
Grabar el registro
Capturar la
Clave. E
D Ir al Principio
del archivo
¿Fin de SI ‘El registro

Archivo?
NO existe’
‘¿Más datos?
(S/N)’
NO
Leer E
registro. Respuesta
SI
Respuesta=‘S’ B
¿ Clave del registro NO
= Clave Capturada?
NO
Ir al siguiente
SI registro Cerrar archivo
A
C
D
FIN
DISEÑO “ ESTRUCTURADO”
Diagrama de flujo: CAMBIOS. (Modificaciones).
INICIO C
Inicializar
= Clave Capturada?
Ir al siguiente
Creación
SI registro
¿Existe el NO
del
archivo.
SI D
Datos del
esta vacio’ ‘¿Modificar el
registro?’
Respuesta = ‘S’
Encontrado = Falso
A
B Respuesta
A
NO Cerrar archivo NO
Respuesta=‘S’
Respuesta=‘S’ E
SI
SI
FIN
Solicitar la
clave. Solicitar
datos del
registro.
Clave.
Grabar el registro
D
E
¿No es Fin NO
de Archivo? E ¿No fue NO
encontrado? G
SI
SI
Leer
registro.
F

F
‘El registro
NO existe’
G
Ir al Principio
del archivo
‘¿Otra modificación?
(S/N)’
Respuesta
Encontrado = Falso

Algoritmo: CAMBIOS. (Modificaciones).
Ir al paso 3.
Sino
- Crear el archivo
- Ir al paso 20.
- Ir al paso 14.
7. Leer registro
Ir al paso 11.
10. Ir al paso 6.
11. Desplegar los datos del Registro.
12. Desplegar ‘¿Modificar el registro?’
- Desplegar Solicitud de datos del registro.
- Introducir los datos del registro.
- Grabar el registro.
Ir al paso 4.
20. FIN.

Algoritmo: CAMBIOS. (Modificaciones).
c. Encontrado = Falso
d. Mientras Respuesta = ‘S’
i. Solicitar la Clave.
ii. Introducir la Clave.
iii. Mientras No sea Fin de Archivo
1. Leer registro
a. Encontrado = Verdadero.
b. Desplegar los datos del registro.
c. Desplegar ‘¿Modificar el registro?’
d. Introducir Respuesta
e. Sí Respuesta = ‘S’ entonces
i. Desplegar Solicitud de datos del registro.
ii. Introducir los datos del registro.
iii. Grabar el registro.
f. Fin del Sí.
g. Salir (del Mientras No sea Fin de Archivo)
3. Fin del Sí.
iv. Fin del Mientras No sea Fin de Archivo.
v. Sí No fue Encontrado entonces
1. Desplegar ‘El registro NO existe.’.
vi. Fin del Sí.
vii. Ir al principio del archivo.
viii. Desplegar ‘¿ Otra Modificación ?’
ix. Introducir Respuesta
x. Encontrado = Falso.
e. Fin del Mientras Respuesta = ‘S’
3. Sino
a. Crear el archivo
b. Desplegar ‘El archivo esta vacío’
4. Fin del Sí.
6. FIN.

9.4.2. – Gestión de archivos directos.

INICIO C
‘El registro
Inicializar YA esta
Variables ocupado.’
E
‘¿Más datos?
NO Creación (S/N)’
¿Existe el
del
archivo?
archivo.
SI Respuesta
A
Abrir archivo A
SI
Respuesta=‘S’ B
B
Solicitar el Número NO
de registro y datos.
Cerrar archivo
Número de
registro y datos FIN
D
Ir al registro
y leerlo.
¿Registro SI Grabar los

vacío? datos en el
registro
NO
E
C

INICIO
Inicializar
Variables
NO Creación
¿Existe el
del
archivo?
archivo.
SI
A
Abrir archivo A
Respuesta = ‘S’
C
NO
Respuesta=‘S’ Cerrar archivo
¿Registro SI Grabar los
vacío? datos en el
SI registro
FIN
Solicitar el Número NO
de registro y datos.
‘El registro E
YA esta
ocupado.’
Número de E
registro y datos
‘¿Más datos?
D (S/N)’
Ir al registro
y leerlo.
Respuesta
C B

Algoritmo: ALTAS.
Ir al paso 3.
Sino
Crear el archivo.
4. Desplegar Solicitud del Número de registro y datos.
5. Introducir Número de registro y datos.
6. Grabar el nuevo registro
7. Ir al registro y leerlo.
8. Sí el Registro está Vacío entonces
- Grabar los datos en el registro.
- Ir al paso 10.
9. Desplegar ‘El registro YA esta ocupado.’
Ir al paso 4.
14. FIN.

Algoritmo: ALTAS.
c. Mientras Respuesta = ‘S’
i. Desplegar Solicitud del Número de registro y datos.
ii. Introducir Número de registro y datos.
iii. Ir al registro y leerlo.
iv. Sí el Registro está Vacío entonces
1. Grabar los datos en el registro.
v. Sino
1. Desplegar ‘El registro YA esta ocupado.’
vi. Fín de Sí.
vii. Desplegar ‘¿ Más datos ?’
viii. Introducir Respuesta
d. Fin del Mientras.
4. FIN.

INICIO A
Inicializar Marcar y grabar el

Variables registro
B
‘¿Más datos?
¿Existe el
del
archivo?
archivo.
Respuesta
SI
Abrir archivo
‘El
archivo SI
Respuesta=‘S’ C
C
Solicitar el Número
NO
de registro.
Cerrar archivo
Número de
registro
FIN
Ir al registro
y leerlo.
Datos del
registro.
‘¿Dar de baja el
registro?’
Respuesta
SI
Respuesta=‘S’ A
NO

A
INICIO
Inicializar Datos del

Variables registro.
‘¿Dar de baja el
registro?’
NO Creación
¿Existe el Respuesta
del
archivo?
archivo.
NO
SI Respuesta=‘S’ B
Abrir archivo
‘El archivo
esta vacío.’ SI
Marcar y grabar el
registro
Respuesta = ‘S’
B
C ‘¿Más datos?
(S/N)’
NO
Respuesta=‘S’
Cerrar archivo Respuesta

SI
de registro. FIN C
Número de
registro
Ir al registro
y leerlo.

Ir al paso 3.
Sino
- Crear el archivo.
- Desplegar ‘El archivo esta vacío’.
- Ir al paso 14.
4. Desplegar Solicitud del Número de registro.
5. Introducir Número de registro.
- Marcar y grabar los datos en el registro.
Ir al paso 4.
15. FIN.

i. Desplegar Solicitud del Número de registro.
ii. Introducir Número de registro.
iv. Desplegar los datos del registro.
v. Desplegar ‘¿Dar de baja el registro?’
vi. Introducir Respuesta.
vii. Sí Respuesta = ‘S’ entonces
1. Marcar y grabar los datos en el registro.
viii. Fin del Sí
ix. Desplegar ‘¿ Más datos ?’
x. Introducir Respuesta
d. Fin del Mientras
3. Sino
b. Desplegar ‘El archivo esta vacío’.
4. Fin del Sí
6. FIN.

INICIO
Inicializar A
Variables
‘¿Mas datos?
¿Existe el
del
archivo?
archivo.
Respuesta
SI
‘El archivo
Abrir archivo esta vacío.’ SI
Respuesta=‘S’ B
B
NO
de registro.
Cerrar archivo
Número de
registro FIN
Ir al registro
y leerlo.
Datos del
registro.

INICIO
Inicializar
Variables
A
Ir al registro
del
archivo? y leerlo.
archivo.
SI
‘El archivo Datos del
Abrir archivo registro.
esta vacío.’
Respuesta = ‘S’ ‘¿Mas datos?

(S/N)’
B
NO Respuesta
Respuesta=‘S’
SI Cerrar archivo
B
de registro.
FIN
Número de
registro

Ir al paso 3.
Sino
- Crear el archivo.
- Desplegar ‘El archivo esta vacío’.
- Ir al paso 12.
4. Desplegar Solicitud del Número de registro.
5. Introducir Número de registro.
Ir al paso 4.
12. FIN.

i. Desplegar Solicitud del Número de registro.
ii. Introducir Número de registro.
iv. Desplegar los datos del registro.
v. Desplegar ‘¿ Más datos ?’
vi. Introducir Respuesta
d. Fin del Mientras.
3. Sino
b. Desplegar ‘El archivo esta vacío’.
4. Fin del Sí.
6. FIN.

Diagrama de flujo: MODIFICACIONES (Cambios).
INICIO
Inicializar A
Variables
Solicitar los
datos del
¿Existe el NO Creación registro.
del
archivo?
archivo.
SI Datos del registro.
‘El archivo
Abrir archivo esta vacío.’
Grabar el registro
B
de registro. ‘¿Mas datos?
(S/N)’
Número de
registro Respuesta
Ir al registro SI
Respuesta=‘S’ B
y leerlo.
NO
Datos del Cerrar archivo

registro.
‘¿Modificar el
registro?’
FIN
Respuesta
NO
Respuesta=‘S’ E
SI

INICIO
Inicializar A
Variables
Datos del
registro.
NO Creación ‘¿Modificar el
¿Existe el
del registro?’
archivo?
archivo.
SI
Respuesta
‘El archivo
Abrir archivo esta vacío.’ NO
Respuesta=‘S’ E
Respuesta = ‘S’ SI
Solicitar los
datos del
NO registro.
Respuesta=‘S’
SI
B Cerrar archivo Datos del registro.
de registro. Grabar el registro
FIN
E
Número de
registro ‘¿Mas datos?
(S/N)’
Ir al registro
y leerlo. Respuesta
B
A

Algoritmo: MODIFICACIONES (Cambios).
2. Sí existe el archivo entonces
a. Abrir el archivo
i. Solicitar el número de registro
ii. Introducir el número de registro
iii. Ir al registro y leerlo
iv. Desplegar los datos del registro
v. Desplegar “¿Modificar el registro?
vi. Introducir Respuesta
vii. Sí Respuesta = “S” entonces
1. Solicitar los datos del registro
2. Introducir los datos del registro
3. Grabar el registro
viii. Fin del Sí
ix. Desplegar “¿Más datos (S/N)?”
x. Introducir Respuesta
d. Fin del mientras
3. sino
a. Creación del archivo
b. Desplegar “El archivo esta vacío.”
c. Cerrar el archivo.
4. Fin del Sí
5. FIN

9.4.3. – Gestión de archivos indexados.
INICIO C
Inicializar ¿Más datos?

Variables (S/N)
NO Creación Respuesta
¿Existe el
del
archivo?
archivo.
SI
SI Respuesta=‘S B
A
A NO
Abrir archivo
Cerrar archivo
B
Solicitar clave
y datos. FIN
Capturar clave y
datos
Buscar el
registro por
la clave.
SI “El registro
¿ Se encontro
el registro ?
YA existe.”
NO
C
Grabar el
registro

Algoritmo: ALTAS.
Ir al paso 3.
Sino
Crear el archivo.
4. Solicitar clave y datos.
5. Introducir clave y datos.
6. Buscar el registro por la clave.
7. Sí Se encontró el registro entonces
Ir al Paso 8.
Sino
Desplegar ‘El registro YA existe’.
Ir al Paso 9.
8. Grabar registro.
Ir al paso 4.
13. FIN.


C
INICIO
Buscar el registro
Inicializar variables por la clave
¿Existe el NO Creación ¿Se encontro SI

archivo? el registro?
del archivo
“El registro
SI NO YA existe.”
A A
Grabar el
registro
Abrir archivo
“¿Más datos?
Respuesta = “S” (S/N)”
Respuesta
¿Respuesta NO
= “S”? Cerrar archivo
B
SI
FIN
Solicitar clave
y datos
Capturar clave
y datos

Algoritmo: ALTAS.
1. Inicializar variables
2. Sí NO existe el archivo entonces
3. sino
a. Abrir archivo
b. Respuesta =”S”
c. Mientras Respuesta = “S”
i. Solicitar clave y datos
ii. Introducir clave y datos
iii. Buscar el registro por la clave
iv. Sí NO se encontro el registro entonces
1. Grabar el registro
v. Sino
1. Desplegar “El registro YA existe”
vi. Fin del Sí
vii. Desplegar “¿Más datos (S/N)”
d. Fin del Mientras
e. Cerrar archivo
4. Fin del Sí

Diagrama de flujo: BAJAS.
INICIO
Inicializar A
Variables
Datos del
¿ Existe el NO Creación Registro.
del
archivo ?
archivo.
SI ¿Dar de baja
“El el registro?
Abrir archivo archivo
esta
vacio.”
D Respuesta
Solicitar
clave. SI
B
Respuesta=‘S
NO Marcar o
Capturar clave eliminar el
C registro.
Buscar el ¿Buscar otro

registro por registro?
la clave. C
Respuesta
¿ Se encontro SI
el registro ? A
SI
Respuesta=‘S D
NO
NO
“El registro
NO existe.”
Cerrar archivo
B
C
FIN

Algoritmo: BAJAS.
Ir al paso 3.
Sino
- Crear el archivo.
- Desplegar “El archivo esta vacío”.
- Ir al paso 15.
4. Solicitar clave.
5. Introducir clave.
Desplegar Datos del Registro.
Sino
- Desplegar ‘El registro NO existe’.
- Ir al Paso 11
Marcar o eliminar el registro
11. Desplegar ‘¿ Buscar otro registro ?’
Ir al paso 4.
15. FIN.

Diagrama de flujo: BAJAS.
INICIO A
Inicializar
Variables Datos del registro.
“¿Dar de baja el
registro? (S/N)”
archivo? del archivo
Respuesta
SI “El archivo
está vacio.”
Abrir archivo SI
¿Respuesta =
“S”?
D
Respuesta = “S”
NO Marcar o
eliminar el
C B registro
“¿Buscar otro
¿Respuesta = NO Cerrar registro?” B
“S”? archivo
SI D Respuesta
Solicitar FIN
clave.
C
Capturar clave
Buscar el registro
por la clave.
NO
¿Se encontro el “El registro
registro?
NO existe.”
SI
A B

Algoritmo: BAJAS.
b. Desplegar “El archivo está vacío”
3. sino
a. Abrir archivo
b. Respuesta = “S”
i. Solicitar clave
ii. Introducir Clave
iii. Buscar el registro por clave
iv. Sí se encontro el registro entonces
1. Desplegar datos del registro
2. Desplegar “¿Dar de baja el registro? (S/N)”
4. Sí Respuesta = “S” entonces
a. Marcar o eliminar el registro
5. Fin del Sí
v. Fin del Sí
vi. Desplegar “¿Buscar otro registro?”
vii. Introducir Respuesta
d. Fin del Mientras
e. Cerrar archivo
4. Fin del Sí
5. FIN

INICIO
Inicializar
Variables
¿ Existe el NO Creación
del
archivo ? A
archivo.
SI
“El Respuesta
Abrir archivo archivo
C esta
vacio.” SI
Solicitar Respuesta=‘S C
clave.
NO
Clave Cerrar archivo
Buscar el FIN
registro por
la clave.
¿ Se encontro NO “El registro

el registro ?
NO existe.”
SI
Datos del B
Registro.
B
¿Buscar
otro
registro?

Ir al paso 3.
Sino
- Crear el archivo.
- Desplegar “El archivo esta vacío”
- Ir al paso 12.
4. Solicitar clave.
Sino
Ir al paso 4.
12. FIN.

B
INICIO
Datos del
Inicializar Variables registro
C
“¿Otra consulta?
NO Creación (S/N)”
¿Existe el
del
archivo?
archivo
SI Respuesta
“El archivo
Abrir archivo está vacío”
D
Respuesta = “S” A
NO
¿Respuesta =
“S”? Cerrar archivo
SI A
Solicitar FIN
clave
Clave
Buscar el registro por la clave
NO
¿Se encontro el registro? “El registro
NO existe.”
SI
B C

b. Desplegar “El archivo está vacío.”
3. sino
a. Abrir archivo
i. Desplegar Solicitar Clave
iii. Buscar el registro por la Clave
1. Desplegar datos del registro
v. Sino
1. Desplegar “El registro NO existe.”
vi. Fin del Sí
vii. Desplegar “¿Otra consulta? (S/N)”
d. Fin del Mientras
e. Cerrar Archivo
4. Fin del Sí
5. FIN

INICIO
A
Inicializar
Variables SI Solicitar
Respuesta=‘S datos del
registro.
NO
NO Creación C
¿ Existe el
del
archivo ? ¿Buscar otro Capturar datos
archivo.
registro? del registro.
SI
“El
Abrir archivo archivo Grabar el
B esta Respuesta registro
vacio.”
Solicitar
clave. SI
Respuesta=‘S B C
NO
Capturar clave
Cerrar archivo
Buscar el
registro por
la clave. FIN
¿ Se encontro NO “El registro

el registro ?
NO existe.”
SI
Datos del Registro.

C
¿Modificar registro?
Respuesta

Ir al paso 3.
Sino
- Crear el archivo.
- Desplegar “El archivo esta vacío”
- Ir al paso 16.
4. Solicitar clave.
Sino
- Ir al paso 11.
8. Desplegar ‘¿Modificar registro?
10. Sí Respuesta =’S’ entonces
- Desplegar solicitud de datos del registro.
- Capturar datos del registro.
- Grabar el registro.
14. Ir al paso 4.
16. FIN.

INICIO A
Inicializar
Variables Datos del registro.
“¿Modificar el
registro? (S/N)”
archivo? del archivo
Respuesta
SI “El archivo
está vacio.”
Abrir archivo SI
¿Respuesta =
“S”?
D
Respuesta = “S”
NO Solicitar los datos
C B del registro
“¿Buscar otro
¿Respuesta = NO Cerrar registro?” Datos del
“S”? archivo registro
SI D Respuesta
Grabar el
registro
Solicitar FIN
clave.
C
B
Capturar clave
Buscar el registro
por la clave.
NO
¿Se encontro el registro? “El registro
NO existe.”
SI
A B

b. Desplegar “El archivo está vacío”
3. Sino
a. Abrir archivo
i. Desplegar Solicitar Clave
iii. Buscar el registro por la Clave
1. Desplegar Datos del registro
2. Desplegar “¿Modificar el registro? (S/N)”
a. Desplegar Solicitar Datos del registro
b. Introducir Datos del registro
c. Grabar Registro
5. Fin del Sí
v. Sino
1. Desplegar “El registro NO existe”
vi. Fin del Sí
vii. Desplegar “¿Buscar otro registro? (S/N)”
d. Fin del Mientras
e. Cerrar archivo
4. Fin del Sí
5. FIN

9.4.4. – Gestión de una base de datos relacional constituida por dos archivos.
Para las bases de datos relacionales, lo óptimo es utilizar archivos indexados y un

diseño estructurado. Otro punto importante es definir cual es el archivo principal y cual es
el complementario. Para nuestro ejemplo, el archivo principal será nombrado como A y el
complementario como B.
La lógica del sistema ABC, básicamente es la misma, la única diferencia es en el
momento de capturar o buscar los datos complementarios en un segundo archivo.
Se debe recordar que en el archivo complementario (B) se almacenan grupos de
registros relacionados a un registro del archivo principal (A), por lo tanto, los datos del
campo Clave pueden estar repetidos, no así en el archivo principal.
Algoritmo: ALTAS.
2. Sí NO Existe el archivo A entonces
a. Creación del archivo A
b. Creación del archivo B
3. Sino
a. Sí NO Existe el archivo B entonces
i. Creación del archivo B.
b. Fin del Sí
4. Fin del Sí.
5. Abrir los archivos.
6. Clave = “”
7. Mientras Clave <> “SALIR”
a. Desplegar solicitud de la Clave.
b. Introducir Clave
c. Sí Clave = “SALIR” entonces
i. Vuelta al Mientras
d. Fin del Sí
e. Buscar el registro por la Clave en el archivo A.
f. Sí se encontró el registro entonces
i. Desplegar “El registro YA existe”
g. Sino
i. Solicitar datos del archivo A
ii. Introducir datos del archivo A
iii. Desplegar “¿Los datos estan correctos? (S/N)”
iv. Introducir Respuesta
v. Sí Respuesta = “S” entonces
1. Grabar registro en archivo A
2. Mientras Respuesta = “S”
a. Solicitar datos para archivo B.
b. Introducir datos del archivo B.
c. Desplegar “¿Los datos están correctos? (S/N)?”
e. Sí Respuesta = “S” entonces

i. Grabar registro en archivo B
f. Fin del Sí
g. Desplegar “¿Más datos? (S/N)”
h. Introducir Respuesta
3. Fin del Mientras
vi. Fin del Sí
h. Fin del Sí
8. Fin del Mientras
9. Cerrar archivos
10. FIN

Algoritmo: BAJAS.
2. Sí NO Existe el archivo A entonces
c. Desplegar “Los archivos estan vacíos.”
3. Sino
i. Creación del archivo B
b. Fin del Sí
c. Abrir los archivos.
d. Clave = “”
e. Mientras Clave <> “SALIR”
i. Desplegar solicitud de la Clave
iii. Sí Clave = “SALIR” entonces
1. Vuelta al Mientras
iv. Fin del Sí
v. Buscar el registro por la Clave en el archivo A
vi. Sí NO se encontró el registro entonces
1. Desplegar “El registro NO existe”
vii. Sino
1. Desplegar los datos del archivo A
2. Encontrado = FALSO
3. Ir al principio del archivo B
4. Mientras NO sea FIN DE ARCHIVO en B
a. Localizar registro relacionado por la Clave.
b. Sí se encontro registro relacionado entonces
i. Desplegar datos del registro localizado.
ii. Encontrado = VERDADERO
c. Fin del Sí
5. Fin del Mientras
6. Sí Encontrado = FALSO entonces
a. Desplegar “La clave no tiene registros relacionados”
b. Desplegar “PUEDE BORRAR EL REGISTRO
PRINCIPAL, SI LO DESEA.”
c. Desplegar “¿Dar de baja el registro principal? (S/N)?
i. Marcar o eliminar el registro principal
f. Fin del Sí
7. Sino
a. Desplegar “NO PUEDE BORRAR EL REGISTRO
PRINCIPAL, PUES TIENE REGISTROS
RELACIONADOS. ES NECESARIO QUE PRIMERO
BORRE LOS REGISTROS DEL ARCHIVO B.”

b. Desplegar “¿Desea borrar registros relacionados del
archivo B? (S/N)”
c. Introducir Respuesta
d. Mientras Respuesta = “S”
i. Desplegar “Teclee la referencia del registro
secudario a borrar”
ii. Introducir Referencia
iii. Localizar registro a borrar del archivo B
1. Desplegar “¿Dar de baja el registro
secundario? (S/N)”
a. Marcar o eliminar el registro
secundario
4. Fin del Sí
v. Sino
1. Desplegar “No existe el registro”
vi. Fin del Sí
vii. Desplegar “¿Borrar otro registro secundario?
(S/N)”
e. Fin del Mientras
8. Fin del Sí
viii. Fin del Sí
f. Fin del Mientras
4. Fin del Sí
5. Cerrar archivos
6. FIN.

Algoritmo: CONSULTAS
2. Sí NO Existe el Archivo A entonces
c. Desplegar “Los archivos están vacíos.”
3. Sino
b. Fin del Sí
c. Abrir los archivos
d. Clave = “”
iv. Fin del Sí
v. Buscar el registro por la Clave en el archivo A
vi. Sí NO se encontró el registro entonces
vii. Sino
a. Localizar registro relacionado por la Clave
i. Desplegar datos del registro localizado
c. Fin del Sí
5. Fin del Mientras
a. Desplegar “La clave no tiene registros relacionados”
7. Fin del Sí
viii. Fin del Sí
f. Fin del Mientras
4. Fin del Sí
5. Cerrar archivos
6. FIN

Algoritmo: MODIFICACIONES.
2. Sí NO existe el archivo A entonces
c. Desplegar “Los archivos están vacíos.”
3. Sino
a. Sí NO existe el archivo B entonces
b. Fin del Sí
c. Abrir los archivos
d. Clave = “”
iv. Fin del Sí
v. Buscar el registro por la Claven en el archivo A
vi. Si NO se encontró el registro entonces
vii. Sino
2. Desplegar “¿Modificar datos del registro principal? (S/N)”
a. Mientras VERDADERO
i. Desplegar solicitud de datos del registro principal
ii. Introducir datos del registro principal
iii. Desplegar “¿Están correctos los datos? (S/N)”
v. Sí Respuesta = “S” entonces
1. Grabar los datos del registro
2. Salir del Mientras
vi. Fin del Sí
b. Fin del Mientras
5. Fin del Sí
a. Localizar registro relacionado por la Clave
i. Desplegar datos del registro localizado
iii. Desplegar “¿Modificar datos del registro secundario
encontrado? (S/N)”

v. Sí Respuestas = “S” entonces
1. Mientras VERDADERO
a. Desplegar solicitud de datos del
registro secundario encontrado.
b. Introducir datos del registro
secundario encontrado.
c. Desplegar “¿Están correctos los
datos? (S/N)”
i. Grabar los datos del registro
ii. Salir del Mientras
f. Fin del Sí
2. Fin del Mientras
vi. Fin del Sí
c. Fin del Sí
9. Fin del Mientras
a. Desplegar “La clave no tiene registros relacionados.”
11. Fin del Sí
viii. Fin del Sí
f. Fin del Mientras
4. Fin del Sí
5. Cerrar archivos
6. FIN

10. – Introducción a la Programación Dirigida por los Datos.
El término data-driven programming, en una traducción literal, puede traducirse como
programación dirigida por los datos. Mediante la programación dirigida por los datos, usted puede
ahorrar mucho tiempo en el desarrollo y mantenimiento de sus aplicaciones.
10.1. – Programación Código-Fijo (Hard-Code).
Este término puede ser nuevo para usted; no obstante, en su estilo de programación debe
intentar que sus programas sean hard-coded, es decir, que estén escritos de manera literal,
fáciles de entender y de programar.
Vea el ejemplo siguiente, escrito en lenguaje Clipper:
USE Func *** Usar o abrir el archivo Func.

DO WHILE .T. *** Bucle infinito: Hacer mientras VERDADERO.
mCodEmpl = CodEmpl *** \
mNombreEmpl = NombreEmpl *** \
mCodSet = CodSet *** \
mCodCar = CodCar *** Asignación de valores de campos a variables.
mFechaEnt = FechaEnt *** /
mSalario = Salario *** /
mGremio = Gremio *** /
** ORDENES *** Lógica de gestión del archivo.
ENDDO *** Terminación del bucle infinito.
En este ejemplo son inicializadas las variables de memoria (identificadas con la m

antepuesta) con el contenido de los campos de un archivo para utilizarlas después. Cada nombre
de campo y de variable ha sido explícitamente especificado. Si tuviéramos cinco campos,
tendríamos cinco líneas de asignación. Si tuviéramos treinta campos, serían necesarias treinta
líneas de asignación. Como norma se acepta que cada variable de memoria tenga el mismo
nombre de campo, precedido por la letra <m>.
Con este estilo de programación tiene que preocuparse con cada nombre y saber cómo se
llama exactamente cada nombre del campo del archivo para poder teclearlo.
Veamos ahora la misma tarea realizada en esta ocasión por una rutina que utiliza el
concepto <<dirigida por los datos>>.
USE Func *** Usar o abrir el archivo Func.

FOR I = 1 TO FCOUNT() /*** Bucle PARA-HASTA desde 1 hasta la
cantidad total de campos en el archivo
(FCOUNT – devuelve la cantidad de campos
en el archivo). ***/
Var = “m”+FIELDNAME(I) /*** Con la función FIELDNAME, se toma el
nombre del campo I; y se le antepone la letra
“m” para que éste sea el nombre de la variable
que se almacene en la variable Var ***/
&Var = &(FIELDNAME(I)) /*** El uso del carácter & -ampersand- antes del

nombre Var indica al Clipper que utilice el
contenido de la variable Var como nombre de
variable. Lo mismo sucede con el & antes de
la función FIELDNAME que esta entre
paréntesis, el cual toma el valor del campo I
***/
NEXT /*** Siguiente. (Terminación del bucle
PARA-HASTA) ***/
De tal manera que:
1. En el primer bucle, donde la variable I tiene el valor de 1, FIELDNAME devolverá el nombre

de dicho campo, por ejemplo; Clave, y al realizar la operación “m”+”Clave” tendremos
“mClave“, que será la cadena string que se almacenara en la variable Var.
2. Acto seguido, el carácter & -ampersand- en la función &(FIELDNAME(I)), le indica a Clipper
que devuelva el nombre del campo I, que en el primer bucle es 1, y que lo tome como si fuera
un nombre de variable o campo, siendo en nuestro caso Clave, y no como cadena de caracteres;
de la misma manera, el mismo carácter &, hace lo propio con el contenido de la variable Var,
indicándole a Clipper que tome el contenido de dicha variable, que para nuestro ejemplo es
“mClave” y lo utilice como un nombre de variable, siendo mClave, la variable.
3. De ahí tendríamos que se tomaría el valor del campo Clave, por ejemplo, la cadena, “a123x” y
se almacenará en la variable mClave.
4. Por último, para el resto de los campos, se realizará la misma operación de creación y
asignación de variables descrita en los tres puntos anteriores.
En este ejemplo se utiliza un bucle FOR NEXT (PARA-HASTA) para crear una
variable por cada campo del archivo. Observe cómo con sólo dos líneas, todas las variables de
memoria son inicializadas. Tanto si existen 5 campos o 40, estas mismas dos líneas hacen esa
función.
Inicializando las variables de esa forma no es necesario preocuparse de teclear el nombre
de los campos y de las variables, evitando de esa forma los errores cometidos al teclear
programas.
PROS Y CONTRAS.
Programación CODIGO-FIJO (HARD-CODE)
• Es más sencilla de programar.

• Es más fácil leer el programa.
• El tamaño del código aumenta con el número de elementos manipulados.
10.2. – Programación Dirigida por los Datos (Data-Driven).
• Es más difícil de programar (aparentemente).

• Es más difícil de leer.
• El tamaño del código no aumenta con el número de elementos.

• Por su estructura, está indicada para crear procedimientos y funciones.
El ejemplo expuesto utiliza los datos de una base de datos. Si la estructura del
archivo fuera modificada, en la programación dirigida por los datos no sería necesaria
ninguna modificación del código, mientras que en el estilo tradicional es necesario re-
escribir el código.
Si considera que en una aplicación puede haber varias situaciones como ésa, la
pérdida de tiempo dedicado al mantenimiento disminuye de forma considerable.
Programar en el estilo dirigido por los datos requiere siempre un estudio previo de los
elementos que serán manipulados. Exige el uso efectivo de variables de memoria,
matrices y otras estructuras de datos.
La mayor ventaja de ese estilo puede estar en la parametrización del estilo de
programación y la obtención de un código eficiente y altamente profesional. Para utilizar
ese estilo de programación es necesario que el lector conozca muy bien los recursos de
programación del lenguaje que se utilice y, obviamente, tener también una buena lógica
de programación.
Esta técnica es normalmente adoptada por los programadores expertos. Para los
programadores que empiezan es recomendable que utilicen, para comenzar, el estilo de
programación tradicional y después usar éste estilo.
NOTA: Sería conveniente invertir mucho tiempo elaborando funciones y

procedimientos que, una vez tecleados, economizan gran cantidad de tiempo en el
desarrollo de programas y sistemas. Así cada vez que se tenga que desarrollar alguna
rutina para una aplicación específica, analiza si ésta puede ser <<generalizada>>, y por
tanto, usada en otras aplicaciones. Muchas veces la respuesta es no. No obstante, otras
veces se puede realizar un magnífico procedimiento o función.
En el primer ejemplo mostrado usamos sólo el bucle FOR NEXT y la macro
sustitución (&) de Clipper. Estos dos elementos u otros similares, aparecen
constantemente en las aplicaciones dirigidas por los datos, en éste lenguaje o cualquier
otro.
Observe el programa mostrado a continuación, el cual está codificado en Clipper. Es
un programa típico de introducción de datos.
Programa CP10PR01.PRG (Hard Code).

*** Programa CP10PR01.PRG Altas.
* Estructura base de datos: PERSONAL.DBF
* Campo Nombre Campo Tipo Tamaño Dec Indice
* 1 CodEmpl Caracter 3 N
* 2 NombreEmpl Caracter 30 N
* 3 CodSet Caracter 1 N
* 4 CodCar Caracter 1 N
* 5 FechaEnt Fecha 8 N
* 6 Salario Num‚rico 9 2 N
* 7 Gremio L¢gico 1 N
* 8 Coment Memo 10 N
** Total 64
PROCEDURE Principal() // Inicio del programa
CLEAR ALL // Elimina variables en memoria y cierra cualquier archivo abierto

IF FILE("IndCodC.NTX") // S¡ existe el archivo IndCodC.NTX
USE Personal INDEX IndCodC // Abre el archivo Personal y su ¡ndice IndCodC
ELSE // Sino
USE Personal // Abre el archivo Personal

INDEX ON CodEmpl TO IndCodC // Indexa seg£n CodEmpl Al archivo IndCodC
ENDIF // Fin del S¡
WHILE .T. // Mientras VERDADERO (Bucle Infinito)
Clear // Limpia (la pantalla)
mCodEmpl = SPACE(3) // MCodEmpl = 3 espacios (en blanco)
mNombrEmpl = SPACE(30) // MNombrEmpl = 30 espacios (en blanco)
mCodSet = SPACE(1) // MCodSet = 1 espacio (en blanco)
mCodCar = SPACE(1) // MCodCar = 1 espacio (en blanco)
mFechaEnt = CTOD("") // MFechaEnt = Convierte Cadena Nula a Fecha Nula
mSalario = 0 // MSalario = 0
mGremio = .F. // MGremio = Falso
@ 1,1 SAY "Código Empleado o;
<INTRO> para salir";
GET mCodEmpl // Despliega mensaje e Introduce el valor de MCodEmpl
READ // Lee los datos del teclado despu‚s del <INTRO>
IF VAL(mCodEmpl) = 0 // S¡ el valor num‚rico de MCodEmpl = 0
EXIT // Salir del Mientras
SEEK mCodEmpl // Busca (el valor de) MCodEmpl (en el archivo)
IF FOUND() // S¡ se encontr¢
@ 23,01 SAY "Código ya;
encontrado...;
Teclee <INTRO>" // Despliega mensaje
INKEY(0) // Introducir Tecla (Detiene el programa hasta que se presiona una tecla.
LOOP // Lazo (Vuelta al Mientras)
@ 3,1 SAY "Nombre:";
GET mNombrEmpl // Despliega mensaje e Introduce el valor de MNombrEmpl
@ 4,1 SAY Sector:" GET mCodSet // Despliega mensaje e Introduce el valor de MCodSet
@ 5,1 SAY "Cargo:" GET mCodCar // Despliega mensaje e Introduce el valor de MCodCar
@ 6,1 SAY "Fecha:";
GET mFechaEnt // Despliega mensaje e Introduce el valor de MFechaEnt
@ 7,1 SAY "Salario:";
GET mSalario // Despliega mensaje e Introduce el valor de MSalario
Ok = ""
@ 8,1 SAY "¨Datos Ok? (S/N)"; // Despliega mensaje
GET Ok PICTURE "!"; // Introduce el valor de Ok y lo convierte a mayusculas
VALID Ok $ "SN" // Restringe los valores de Ok a "S" o "N"
IF Ok = "S" // S¡ Ok = "S"
APPEND BLANK // Agrega un registro vac¡o al archivo
REPLACE CodEmpl WITH mCodEmpl,; // Reemplaza (Graba el valor del campo) CodEmpl con (el valor de la variable) MCodEmpl
NombrEmpl WITH mNombrEmpl,; // (Reemplaza) NombreEmpl con mNombrEmpl
CodSet WITH mCodSet,; // (Reemplaza) CodSet con mCodSet
CodCar WITH mCodCar,; // (Reemplaza) CodCar con mCodCar
FechaEnt WITH mFechaEnt,; // (Reemplaza) FechaEnt con mFechaEnt
Salario WITH mSalario,; // (Reemplaza) Salario con mSalario
Gremio WITH mGremio // (Reemplaza) Gremio con mGremio
ENIF // Fin del S¡
END // Fin del Mientras
CLOSE ALL // Cierra todos los archivos
RETURN // Fin del programa
En el programa mostrado a continuación, se crean funciones para asignar las

variables con el contenido de los campos del archivo, para sustituir el contenido de los
campos por el contenido de las variables y para inicializar variables de memoria con el
mismo tipo de dato que el de los campos.
Programa CP10PR02.PRG (Data Driven).

*** Programa CP6PR01.PRG Altas.
* Estructura base de datos: PERSONAL.DBF
* Campo Nombre Campo Tipo Tama¤o Dec Indice
* 1 CodEmpl Caracter 3 N
* 2 NombreEmpl Caracter 30 N
* 3 CodSet Caracter 1 N
* 4 CodCar Caracter 1 N
* 5 FechaEnt Fecha 8 N
* 6 Salario Num‚rico 9 2 N
* 7 Gremio L¢gico 1 N
* 8 Coment Memo 10 N

** Total 64
PROCEDURE Principal() // Inicio del programa
CLEAR ALL // Elimina variables en memoria y cierra cualquier archivo abierto

IF FILE("IndCodC.NTX") // S¡ existe el archivo IndCodC.NTX
USE Personal INDEX IndCodC // Abre el archivo Personal y su ¡ndice IndCodC
ELSE // Sino
USE Personal // Abre el archivo Personal
INDEX ON CodEmpl TO IndCodC // Indexa seg£n CodEmpl Al archivo IndCodC
WHILE .T. // Mientras VERDADERO (Bucle Infinito)
Clear // Limpia (la pantalla)
DO Inic_Var // Llama al procedimiento de inicializaci¢n de variables
@ 1,1 SAY "Código Empleado o;
<INTRO> para salir";
GET mCodEmpl // Despliega mensaje e Introduce el valor de MCodEmpl
IF VAL(mCodEmpl) = 0 // S¡ el valor num‚rico de MCodEmpl = 0
EXIT // Salir del Mientras
SEEK mCodEmpl // Busca (el valor de) MCodEmpl (en el archivo)
IF FOUND() // S¡ se encontr¢
@ 23,01 SAY "Código ya;
encontrado...;
Teclee <INTRO>" // Despliega mensaje
INKEY(0) // Introducir Tecla (Detiene el programa hasta que se presiona una tecla.
LOOP // Lazo (Vuelta al Mientras)
@ 3,1 SAY "Nombre:";
GET mNombrEmpl // Despliega mensaje e Introduce el valor de MNombrEmpl
@ 4,1 SAY Sector:" GET mCodSet // Despliega mensaje e Introduce el valor de MCodSet
@ 5,1 SAY "Cargo:" GET mCodCar // Despliega mensaje e Introduce el valor de MCodCar
@ 6,1 SAY "Fecha:";
GET mFechaEnt // Despliega mensaje e Introduce el valor de MFechaEnt
@ 7,1 SAY "Salario:";
GET mSalario // Despliega mensaje e Introduce el valor de MSalario
Ok = ""
@ 8,1 SAY "¨Datos Ok? (S/N)"; // Despliega mensaje
GET Ok PICTURE "!"; // Introduce el valor de Ok y lo convierte a mayusculas
VALID Ok $ "SN" // Restringe los valores de Ok a "S" o "N"
IF Ok = "S" // S¡ Ok = "S"
APPEND BLANK // Agrega un registro vac¡o al archivo
DO Repl_Var // Llamada al procedimiento para grabar o reemplazar los datos en el archivo
ENIF // Fin del S¡
END // Fin del Mientras
CLOSE ALL // Cierra todos los archivos
RETURN // Fin del programa
PROCEDURE Inic_Var() // Inicio del procedimiento de inicializaci¢n de variables
FOR N = 1 TO FCOUNT() // Para I = 1 hasta Cantidad de campos

IF TYPE(FIELD(N)) <> "M" // S¡ el tipo del campo N es diferente de "M" (Memo)
NombCampo = FIELDNAME(N) // NombCampo = Nombre del campo N
NombVar = "m"+NombCampo // NombVar = "m" + Valor de NombCampo
(concatena cadenas de caracteres)
PUBLIC &NombVar // Declara como p£blico el nombre de variable contenido en la variable NombVar
DO CASE // Hacer en Caso
CASE TYPE(FIELD(I)) = "C" // Caso de que el tipo del campo = "C" (Caracter)
&NombVar = SPACE(LEN(&NombCampo)) // Variable en NombVar = Cantidad de espacios de la longitud del campo en NombCampo
CASE TYPE(FIELD(I)) = "N" // Caso de que el tipo del campo = "N" (Num‚rico)
&NombVar = 0 // Variable en NombVar = 0
CASE TYPE(FIELD(I)) = "D" // Caso de que el tipo del campo = "D" (Fecha)
&NombVar = CTOD("") // Variable en NombVar = Nulo convertido a formato de fecha
CASE TYPE(FIELD(I)) = "L" // Caso de que el tipo del campo = "L" (L¢gico)
&NombVar = .F. // Variable en NombVar = FALSO
ENDCASE // Fin del Caso
NEXT // Siguiente (I)
RETURN // Retorna a la l¡nea siguiente de donde fue llamado el procedimiento
PROCEDURE Repl_Var() // Inicio del procedimiento de grabado o reemplazo de los valores de las variables al archivo

FOR N = 1 TO FCOUNT() // Para I = 1 hasta Cantidad de campos
IF TYPE(FIELD(N)) <> "M" // S¡ el tipo del campo N es diferente de "M" (Memo)
NombCampo = FIELDNAME(N) // NombCampo = Nombre del campo N
NombVar = "m"+NombCampo // NombVar = "m" + Valor de NombCampo (concatena cadenas de caracteres)
IF TYPE("&NombVar") <> "U" // S¡ el tipo de la variable en NombVar <> "U" (Undefined - Indefinido)
REPLACE &NombCampo WITH &NombVar // Reemplaza el campo en NombCampo con la variable en NombVar
NEXT // Siguiente (I)
RETURN // Retorna a la l¡nea siguiente de donde fue llamado el procedimiento
Por lo que ya ha podido ver, esta técnica es utilizada en los procedimientos de

creación y asignación del contenido de las variables de memoria; guardar los campos
nos es de bastante ayuda. No obstante, la programación DD, también puede ser utilizada
para operaciones tradicionales, como son: la captura y despliegue de datos, generación
de menús, etc.
Para la aplicación práctica de ésta técnica, es necesario que el programador conozca
suficientemente bien, el lenguaje en el que aplicara ésta técnica DD.
10.3. – Diccionario de datos.
Puede utilizar el concepto de DD para crear un diccionario de datos que contenga toda la
información sobre los datos que serán manipulados por la aplicación.
Es posible, por ejemplo, crear un diccionario de datos con información sobre los
archivos utilizados por la aplicación de forma que permita crear procedimientos y funciones que
permitan su manipulación genérica (apertura, fechado, indexación, etc.) y mostrar pantallas,
como hemos visto anteriormente. En definitiva, crear un archivo de parámetros de uso general.
Las formas más simples de crear ese diccionario de datos son:
1. Utilizando un archivo de base de datos.

2. Utilizando matrices.
La primera opción tiene como puntos a favor el hecho de que se puedan modificar sus
datos sin que sea necesario recompilar la aplicación, que trae consigo una gran portabilidad y
facilidad de mantenimiento para su aplicación. Por otro lado, si ese archivo no dispone de algún
mecanismo de protección, cualquiera podría modificar los datos de forma indebida y dañar su
aplicación.
Analice la información dada en este capítulo y empiece a pensar en sus posibles
aplicaciones en sus próximos programas19.
10.4. – Programación de plantillas.

10.4.1. - ¿ Qué es una plantilla ?
Básicamente, una plantilla es un programa o rutina que tiene por objeto generar
programas (código fuente) basándose en un modelo o patrón. En otras palabras, una
plantilla es un generador de programas.
19
Para ampliar sus conceptos e ideas sobre ésta técnica sugiero que estudie el Capitulo 6, del libro Curso de Clipper 5.2
Avanzado, de José Antonio Ramalho; Editorial McGraw Hill.

<< Un buen programador no usa generadores de programas.>>
¿Será cierta esta afirmación?

Después de crear varios programas, comenzará a crear un modelo propio de
programación, es decir, cualquier aplicación que desarrolle tendrá algunas características
en común con todos los demás que ya ha desarrollado. Por ejemplo, siempre colocará la
fecha en la esquina superior derecha de la pantalla, sus mensajes de error aparecen
siempre en la línea 23, columna 10, y así lo demás.
Y entonces, no se resistirá a la idea de obtener una copia del programa anterior
en su editor y realizar sólo algunas modificaciones para generar un nuevo programa.
10.4.2. – Ventajas de una plantilla.
1. Ahorro de tiempo.
Una plantilla puede generar un sistema completo en menos de dos minutos;

bastará con suministrarle los datos específicos del nuevo sistema, pulsar <Intro> y
centenares de líneas de programa serán escritas en pocos minutos. Todo esto nos libra de
los detestables errores al teclear que siempre terminamos cometiendo.
2. Modelado del código fuente.
Cada programador tiene su propia forma de programar. Ahora bien, si trabaja

para una empresa que tiene su propio modelo particular para la generación de pantallas,
informes u otras rutinas, tendrá que seguir ese modelo en buena parte de su programa.
Imagínese el gasto que supone el mantenimiento de un programa de otro programador
que posee una forma de programar totalmente distinta a la suya.
3. Facilidad de modificación.
Si quiere cambiar un determinado elemento que afecta a todos los módulos del
sistema, la modificación de la plantilla realizará todos los cambios en el sistema.
10.4.3. – Cuando utilizar una plantilla.
La creación de una plantilla requiere un análisis previo del programa que desea
generar. Si va a crear una rutina que será específica de una única aplicación o que
necesitará modificaciones profundas para que sea utilizada en otro programa, ésa, con
certeza, no será la rutina del programa ideal para crear una plantilla.
Las plantillas utilizan el concepto de programación orientada o dirigida por los
datos, es decir, son rutinas que trabajarán con objetos previamente preparados generando
el código definitivo.
10.4.4. – Generadores de Código.

En el mercado, dispone de varios programas generadores de código. Los más
conocidos son el UI2 y el GENNIFER. Estos programas permiten la generación de
códigos fuente en varios dialectos Dbase, C y otros lenguajes. Esos programas
normalmente disponen de plantillas listas para ser usadas, donde usted simplemente les
debe informar de los objetos que deben actuar.
Estos programas permiten también que usted, utilizando órdenes del programa,
cree sus propias plantillas, es decir, aquellas que tengan su forma de programar.
Discutiremos cómo crear plantillas con las propias órdenes de Clipper.
Una plantilla está básicamente formada por textos literales y órdenes de
generación. En el CD que acompaña a ésta obra se presenta un generador de código
desarrollado en Clipper, el cual genera un programa, también en Clipper, para el
mantenimiento de una base de datos.

11. – Introducción a la Programación Orientada al Objeto.
11.1. – Introducción.
Hace años la programación se realizaba mediante el modelo lineal, es decir, los

programas evolucionaban línea a línea sin que la descomposición modular de los mismos
tuviese la menor importancia a la hora de estructurar el código. Esta situación fue superada por
el método de la programación estructurada donde la simple linealidad del código desaparecía
para dejar paso a la noción de estructura modular, descomposición top-down, etc. Hoy vivimos
otra nueva revolución en las técnicas de ingeniería del software. Es lo que se ha dado en llamar
la Programación Orientada a Objetos.
Pero, ¿En qué consiste esta innovación? ¿Qué es realmente un objeto?. Trataremos, con
la brevedad que una corta introducción debe aportar, de responder estas cuestiones. El diseño de
software orientado a objetos pretende ser una técnica de construcción de aplicaciones que
funcione de acorde a como lo hace la mente humana en su ubicación en la realidad. El hombre
conoce mediante un proceso de abstracción en el que de lo real vamos tomando sus aspectos
más comunes para construir formas inteligibles por nuestro pensamiento, éstas son los objetos.
Los objetos deben poseer un conjunto de propiedades que los definan y distingan, algo que les
de la individualidad necesaria como para que el conocimiento del hombre pueda tratar con ellos.
Sólo conocemos objetos.
Los objetos son la formalización de lo real que hace la mente del hombre.
Por tanto, si la noción de objeto posee tanta importancia a la hora de explicar los
mecanismos cognoscitivos del ser humano, parece lógico que una de las actividades
intelectuales del hombre, como es el diseño de software, se trate de aprovechar todo lo que esta
noción pueda dar de sí.
Deberíamos también contestar a la pregunta ¿Qué se pretende obtener con la

incorporación de la noción de objeto al universo informático? Fundamentalmente se desea
reducir los tiempos de desarrollo. Un objeto es una parte de una aplicación totalmente terminada
y transportable, de forma que pueda usarse de forma similar por otras aplicaciones. La labor de
ensamblar objetos se pretende como más reducida en cuanto a esfuerzo que la de desarrollar
programas partiendo sólo de un lenguaje de programación.
Continuar con una exposición teórica de la Programación Orientada al Objeto (OOP

abreviado en Inglés), resultaría larga, tediosa e inútil teniendo en cuenta la finalidad de este
libro. Situándonos en el justo contexto de una breve introducción, el tratamiento dado al tema
sólo puede ser eminentemente práctico, y ceñirse lo mas posible a la generalización del
concepto. Esa es la pretensión inicial de este capítulo, en el que por razones obvias de
comodidad abreviaremos las palabras “Programación Orientada al Objeto”, sustituyéndolas por
la ya conocida expresión anglosajona: OOPS.

11.2. – Vocabulario OOPS.
Cualquier tecnología, (programación, fontanería, pastelería, etc.), por regla general e

ineludible, requiere un vocabulario técnico propio, el cual cumple dos cometidos diferentes:
1º. Especificar de modo claro y conciso cada una de las peculiaridades e

implementaciones del proceso técnico en cuestión (Los profesionales se sirven de él para el
intercambio de información).
2º. Alejar a los intrusos, aficionado y otros posibles merodeadores. Como todos sabemos
las jergas profesionales complejas e ininteligibles, crean una barrera de incomprensión entre
iniciados y neófitos. Algunos profesionales (que no todos, por supuesto) tienden a refugiarse en
el oscurantismo del lenguaje para encubrir su ineficiencia.
Como era de esperar OOPS no podía resultar ajeno a esta regla universal. Eso explica el
incontrolado florecimiento de infinidad de palabrejas, a cuál más rara e inútil, cuya inmensa
mayoría son fruto de bárbaras traducciones anglosajonas. De todos modos, ya que existe ese
vocabulario (absolutamente necesario por cierto), usémoslo; pero sin renunciar a explicaciones
en lenguaje llano, que son de agradecer. La experiencia indica que existen excelentes
programadores que manifiestan su total incapacidad de entendimiento a la hora de trabajar con
objetos. En la mayoría de los casos ese aparente bloqueo es motivado por un exceso de
vocabulario inconexo y mal digerido.
11.3. – Conceptos básicos.
NOCIONES BASICAS.
En este apartado vamos a tratar de definir algunas cuestiones básicas de la programación

orientada a objetos20. Nos centraremos ya en definiciones técnicas olvidándonos de los aspectos
más filosóficos planteados anteriormente.
Objeto Un objeto es un conjunto de código asociado con los datos operados por
dicho código. Los objetos están encapsulados. Esto supone que tanto el código
como los datos que contienen son inaccesibles por otros objetos. Desde este
punto de vista, un objeto es bastante similar a una función o a una subrutina (o
procedimiento) en general. La diferencia fundamental estriba en la encapsulación
de datos. En una subrutina los datos pueden ser accedidos por otra subrutina.
Esto no puede suceder nunca en un objeto. (Es decir, podemos tomar copias de
los datos del objeto y manipular estas copias, pero nunca podremos accesar a los
datos originales).
20
Entre otra bibliografía pueden consultarse los siguientes libros:
• Rebeca Wirfs-Brocks, Brian Wilkerson y Lauren Wiener, Designing Object-Oriented, publicado por
Prentice Hall en 1990.
• Peter Coad/Edward Yourdon, Object-Oriented Analysis, publicado por Prentice Hall.
• Gordon Blair et al (editores), Object-Oriented Languages, System and Aplications, Pitman en 1991.

Mensaje Es el modo que tenemos de comunicarnos con un objeto. Los mensajes
son enviados por un objeto y recibidos por otro. Los mensajes determinan el
comportamiento de un objeto. Por ejemplo, puedo tener un objeto que gestione la
cola de impresión de mi sistema. Un mensaje para este objeto sería comienza la
impresión.(Podríamos decir que son palabras o claves que representan
instrucciones u ordenes para que se active un procedimiento o función interna
del objeto, y que con esto dicho objeto se comporte o haga lo que nosotros
deseamos).
Método Es un algoritmo que contiene los pasos necesarios que han de ejecutarse
como respuesta a un mensaje. Si ya dijimos que un objeto es similar a una
función, igualmente hemos de decir ahora que un método también lo es. Ya
dijimos que los objetos están compuestos de código y datos, pues bien, el código
no es más que un conjunto de métodos. Algo así como un grupo de
procedimientos dentro de otro principal.
Clase Una clase es un objeto que tiene como propiedad la de poder crear otros
objetos, dotándoles de una peculiar herencia. Todos los objetos de una clase
reciben de ésta sus rasgos comunes. (Se puede decir que podemos obtener copias
de un objeto y agregarle nuevos métodos y mensajes, tal y como lo hacemos
algunos programadores, con los procedimientos que creamos. Los copiamos y
les agregamos más parámetros y procedimientos internos.).
De lo anterior, y en mi, quizás, parco conocimiento del tema; podriamos decir (y

perdóneme los programadores de alto nivel), que los objetos no son otra cosa que
procedimientos o funciones que contienen otros procedimientos o funciones (llamados métodos)
los cuales podemos hacer que se comporten de la manera que necesitamos a través del paso de
ciertos parámetros (llamados mensajes); y que, además, fueron desarrollados por otros
programadores, los cuales, para proteger su código y funcionamiento nos los entregan
compilados (entiendase encapsulados), y pese a ello, podemos copiarlos y agregarles en su
entorno, nuevos procedimientos (lease métodos) propios, así como nuevos pasos de parámetros
(lease mensajes), para enriquecerlos. Es de notar que también dichos objetos nos devuelven
mensajes, lo que en mi idea llamaría parámetros de retorno.
Contrariamente a la creencia generalizada, la programación orientada al objeto es

eminentemente práctica y sencilla. El desarrollo profesional de aplicaciones, planteado como
actividad económica plenamente rentable se han visto afectado de manera muy positiva por la
aparición de OOPS. Antes de continuar, vamos a apuntar cuales son las dos líneas maestras de
esas mejoras:
1º. ENCAPSULACIÓN: La definición de variables y procedimientos Locales

(LOCAL) y Estáticos (STATIC), dentro de los lenguajes de programación (como
Clipper o Pascal), permite procesar datos de manera mucho más autónoma y
cerrada. A la hora de reutilizar código, se tiene que prestar especial atención a
posibles declaraciones duplicadas de variables Privadas o Públicas, y por
supuesto a los nombres de las funciones o procedimientos (Siempre transparente
desde cualquier parte de una aplicación). Casi siempre, se inicia la búsqueda

desesperada de nuevos “apellidos” para nuestras funciones, cuando se hacen
módulos de gran tamaño. A partir de los lenguajes de programación orientados al
objeto, se permite una mayor autonomía de datos y funciones gracias
precisamente a los dos nuevos conceptos. El calificativo de Local (LOCAL) solo
afecta a variables, sin embargo el de Estático (STATIC) se refiere a variables y
funciones (o procedimientos). Tal como se verá más adelante, OOPs apunta
claramente en la misma dirección.
2º. REUSABILIDAD: El sueño de todo programador responde a la imagen de un

personaje montando aplicaciones a base de cortar trozos de código existente,
pegándolos en el menor tiempo posible, y convirtiendo el resultado en algo
vendible (a poder ser, caro). Aunque la cruda y diaria realidad sigue alejada de
esa utopía, OOPS es sin duda el mejor camino hacia ella. De momento, las
ventajas de reutilizar código son básicamente dos:
• Un ahorro considerable de tiempo: Todos los procesos básicos se escriben

una sola vez.
• Una mayor seguridad ante posibles errores: Los módulos que se reutilizan
han sido probados y depurados con anterioridad en otras aplicaciones.
Prácticamente todo lo dicho hasta el momento, es sobradamente conocido por cualquier

programador experimentado. Llegados pues a este punto, es necesario hacer un mínimo esfuerzo
de desmitificación, ya que muchos han exagerado hasta el punto de hablar de técnicas
revolucionarias cuando citan OOPS. ¡Nada mas lejos de la realidad! Programar en un lenguaje
de programación con orientación al objeto, es dar un paso mas, no un salto al vacío, como quizá
algunos temen.
De momento, las clases que traen consigo los lenguajes orientados al objeto, nos
permiten realizar programas eficientes y en poco tiempo, a pesar de ello, los fabricantes nos han
ahorrado la molestia de estudiar sus fuentes, ya que los mismos no aparecen en ninguna
documentación. Un experto puede imaginarse cómo funcionan, pero al programador de a pie
sólo le queda el consuelo de conducirlas sin poder abrir el capó y ver el motor. Lógicamente
estas clases que se pueden llamar estándar, llaman a funciones, generalmente, indocumentadas
de algún enigmático módulo interno.
Debo reconocer, que todo esto nos ha ahorrado un mundo de trabajo a los viejos
programadores; y a los nuevos, un sinnumero de desvelos para comprender los intrincados y
torcidos caminos de la programación, en aquellos viejos lenguajes y formas de programar.21
11.4. – Clarificando conceptos.
11.4.1. - ¿ Qué es una clase ?
El concepto de CLASE es siempre abstracto. Dentro de un programa, no
21
Nota del autor.

manipulamos clases, utilizamos objetos derivados de ellas. Se hubiesen podido llamar
familias o especies, pero como no hemos sido invitados al bautizo, es inútil perder el
tiempo discutiendo sobre el acierto del nombre. Usándolas tales como fueron
presentadas al mundo, es decir sin posibilidad de manipulación posterior, debemos tener
bien claro lo siguiente: todos los objetos de una misma clase tienen los mismos métodos,
y por consiguiente responden de manera similar a los mismos requerimientos. Se
diferencian por el contenido de sus variables de instancia, es decir de sus datos.
11.4.2. - ¿ Qué es un objeto ?
Un objeto es un conjunto de datos y métodos. Se da el caso de algunas clases de

objetos que excepcionalmente no tienen métodos (la clase error por ejemplo, solo
contiene datos). Debemos aclarar que los datos de un objeto han sido bautizados como
variables de instancia exportadas (Ver Guías Norton de Clipper 5.01 en castellano).
Este no nos parece un nombre excesivamente acertado, pero no tenemos más remedio
que usarlo a fin de compatibilizar conceptos.
Las variables de instancia pueden ser de tres tipos:
• Lectura – Escritura. En este caso estarían los campos que pueden ser leídos y
asignados.
• Solo lectura. Son variables internas como por ejemplo en este caso el número
de registro, que sólo puede ser leída por nosotros, y cambia su estado en
función de los desplazamientos del puntero a través de la base de datos.
• Ocultas (de uso interno). Son todas aquellas que no vemos, y que el objeto
utiliza para sus procesos internos. Este sería el caso del número de
manipulador de archivos(handle) que el Sistema Operativo asigna al área en
curso, el array que contiene los nombres de los campos, etc.
Los métodos, tal como ha quedado dicho, determinan los procesos propios de su
clase.
11.4.3.- El concepto de herencia.
Las clases serían muy poca cosa, si se limitaran a lo visto. Ahora por fin, vamos
a ver no solo algo nuevo, sino lo mejor y mas interesante de OOPS: la herencia. Gracias
a ella, podemos tomar una clase y derivar hacia otra que hereda sistemáticamente sus
datos y métodos. La nueva clase puede añadir nuevos datos y métodos a la existente, o
sencillamente sustituir los actuales por otros.
Un simil de esto, es cuando creamos una función para mostrar datos en pantalla,
y creamos una nueva función en donde llamamos la función primaria, a la cual le
agregamos nuevas características funcionales.
11.4.4.- El concepto de jerarquía.
Si hemos comprendido la herencia como relación PADRE<->HIJO, poco costará

entender la posibilidad de ampliar esta estructura a más de dos niveles. En la práctica se

puede crear una estructura jerárquica de clases, donde unas heredan de otras que ya han
heredado.
11.5. – Conclusiones.
11.5.1. – Lo mejor.
Esta técnica de programación nos permite agilizar nuestro trabajo, partiendo de

clases y objetos hechos por otros programadores, lo cual nos permite ahorrar mucho
tiempo de programación, y con esto se incrementa nuestra productividad. Y aunque no
resuelve todas nuestras expectativas, de crear soluciones rápidas y eficientes; sin
embargo nos abre un poco los ojos sobre la infinita capacidad de esta nueva técnica. La
herencia nos permite ir complicando las cosas hasta alcanzar clases muy completas
partiendo de otras llamadas básicas. Una buena estructura jerárquica es una potentísima
herramienta de desarrollo.
11.5.2. – Lo peor.
Puesto que, cualquier implementación seria, basada en herencias múltiples,

requiere infinidad de punteros, y consume grandes recursos de hardware (velocidad y
memoria). Quienes han intentado desarrollar aplicaciones completas totalmente basadas
en OOPs, han debido desistir ante la evidencia de un fracaso anunciado. Los constantes
Swapps a disco y memoria enlentecen considerablemente los módulos, y además
lentitud y consumo de memoria son enemigos mortales de las redes, etc. Sin embargo,
los grandes avances tecnológicos en el hardware y algunos de software, nos estan
permitiendo salvar de una manera o de otra estos problemas.
11.5.3. – Posibles soluciones.
La mayoría de las desilusiones de los seres humanos son debidas a sus

exageradas expectativas. La programación orientada al objeto, es lo que es, y no tiene la
culpa de que muchos de nosotros hayamos sido lo suficientemente insensatos como para
elevarla al rango de panacea universal. El único camino para rentabilizarla pasa por un
profundo conocimiento de su potencia y de sus debilidades. Partiendo de una base
sólida, y armándonos de paciencia, podremos optimizar nuestro trabajo mezclando
programación convencional y OOPS, lo que sin duda nos permitirá estar preparados para
lo que se nos viene encima.

12. - Introducción a la Programación dirigida por eventos.
Nadie duda ya a estas alturas, que hacerle la vida más fácil al usuario ha dejado de ser un
capricho del programador para ser una exigencia de aquél. Nuestros programas han de tener, dentro de
lo posible, una interfaz de usuario agradable a la vista, intuitivo y sencillo de manejar. Una de esas
cosas que hacen la vida más fácil al usuario es el RATON (MOUSE –en inglés-). Generalmente se
utilizan, una serie de funciones que llaman a algunos de los servicios de la interrupción 33H22,
encargada del control del ratón. Con ellas podemos saber que está ocurriendo con ese animalejo que
tenemos encima de la mesa pillado por el rabo, y actuar en consecuencia. Afortunadamente, en la
actualidad, dichas funciones ya estan provistas en los presentes sistemas operativos, lo cual nos facilita
la vida como programadores, teniendo solo que preocuparnos de activar o desactivar y programar las
acciones que se deben realizar cuando se mueva el ratón o se pulse alguno de sus botones.
El término <<programación conducida por eventos>> será algo frecuente cuando

programemos en Microsoft –Windows- u otro sistema operativo visual23. En la programación
conducida por eventos, es el usuario quien decide cómo será ejecutado el programa; este tipo de
programación difiere de la programación por lotes, donde un programa es ejecutado desde arriba hacia
abajo.
¿Qué beneficios nos ofrece la programación conducida por eventos como desarrollador y como
suministrador de soluciones? Primero, hace que las aplicaciones sean más fáciles de crear y depurar,
porque sólo desarrollamos pequeñas porciones. En segundo lugar, ofrece consistencia, porque se utiliza
en todos los entornos de programación Windows o visuales, especialmente en aplicaciones VBA
(Visual Basic para Aplicaciones). A lo largo de todo este capitulo, presentaremos ejemplos que siguen
el acercamiento a la programación conducida por eventos (el mejor acercamiento para crear
aplicaciones basadas en Windows, que es lo más común).
Para poder entender la diferencia entre la programación por lotes y la programación conducida
por eventos, pensemos en una aplicación como si se tratase del menú de un restaurante. El
acercamiento a la programación por lotes nos sirve cada elemento en cada página del menú en una
secuencia, uno a uno, hasta que se nos haya servido toda la lista del menú. La programación conducida
por eventos nos permite elegir únicamente los <<elementos de menú>> que queramos –es decir, sólo se
ejecutarán las partes de programa que queramos-. Este tipo de acercamiento habitualmente se presenta
al usuario con una selección de botones de órdenes, elementos de menú y botones de barra de
herramientas.
En la programación conducida por eventos, nuestra aplicación responde únicamente a las

acciones del usuario. Más adelante en este tema, cuando empecemos a estudiar los objetos más
comunes (por ejemplo, formularios e informes) en los lenguajes visuales, veremos varios eventos para
cada objeto. Cada uno de los eventos para un objeto concreto cubrirá casi cualquier acción del usuario
que se pueda aplicar a ese objeto. Por ejemplo, en el entorno Windows el usuario podrá ejecutar
22
Se les llama interrupción, a algunos procedimientos que realiza el microprocesador al activarse algun bit dentro de una
región especifica de memoria, tal como la 33H, en hexadecimal.
23
Comúnmente, se les llama Visuales, a todos aquellos sistemas operativos, lenguajes de programación, o programas, que
nos dan una presentación gráfica de la información. Tales como los productos de Microsoft, cuyo ejemplo ineludible es, su
ahora, sistema operativo Windows.

múltiples eventos utilizando únicamente el ratón, como se muestra en la siguiente tabla.

Evento de Ratón Acción del usuario
Click El usuario pulsa el botón izquierdo del ratón una sola vez.
DoubleClick El usuario pulsa el botón izquierdo del ratón dos veces en una rápida sucesión.
MouseMove El usuario mueve el ratón mientas que éste está sobre un objeto.
MouseDown y El usuario pulsa o libera un botón del ratón. Un programa en lenguaje visual puede
MouseUp atrapar esto para el botón izquierdo o para el botón derecho (contexto secundario)
del ratón.
NOTA: El ratón esta habitualmente configurado para ser operado con la mano derecha. En esta
configuración, el botón de la izquierda es el botón de selección y el botón de la derecha es el botón de
contexto secundario. Podremos cambiar la orientación del botón utilizando el Panel de Control, para el
caso de Microsoft Windows. Los lenguajes visuales y los programas desarrollados en estos, reciben las
propiedades de ratón de Windows. Como resultado, no se necesita ninguna codificación especial de los
eventos de ratón para usuarios diestros o zurdos.
La mayoría de los usuarios en un entorno Windows utilizan el ratón para ejecutar la mayoría de
las acciones. Pero para acomodarse a aquellos que prefieran utilizar el teclado, Microsoft en sus
diversos productos de programación y paqueterías, nos permite reconocer, o atrapar, eventos de
teclado. La siguiente tabla lista algunos de los eventos de teclado más comunes.
Evento de teclado Acción del usuario

KeyPress El usuario pulsa una tecla del teclado y un
programa en lenguaje visual puede determinar qué
tecla ha sido pulsada. El evento KeyPress
capturará únicamente los caracteres ANSI
estándar, tales como letras del alfabeto inglés.
KeyDown y KeyUp El usuario pulsa o libera una tecla sobre el teclado.
Estos eventos de teclado pueden atrapar las
pulsaciones de teclado no capturadas por el evento
KeyPress, tales como las teclas de función y las de
navegación.
Observe que los nombres de los eventos de ratón y teclado son simples y realmente descriptivos
del evento. Esta intuitividad hace que la programación en el entorno de programación conducida por
eventos de los lenguajes visuales resulte lógica y fácil. El desafío consiste en anticipar qué eventos
estará ejecutando el usuario sobre un objeto concreto.
En el entorno de los lenguajes visuales, estaremos escribiendo la mayor parte de nuestro código
orientado a eventos para los formularios y para los controles que estos contengan. El evento Click es el
más comúnmente usado por el objeto botón de orden, pero no sería el único permitido. Algunos de los
eventos disponibles para el objeto botón de orden, en los diversos lenguajes visuales, podremos
encontrar los que se listan a continuación.

Eventos.
1. Al entrar
2. Al salir
3. Al recibir el enfoque
4. Al perder el enfoque
5. Al hacer click
6. Al hacer doble click
7. Al bajar el mouse
8. Al mover el mouse
9. Al subir el mouse
10. Al bajar una tecla
11. Al subir una tecla
12. Al presionar una tecla
Ahora es cuando comienza el desafío. Desde esta lista de ejemplo, ¿qué eventos utilizaremos? Por
ejemplo, la ilustración anterior lista los eventos para un objeto Botón de orden, de un lenguaje visual. Si
escribiésemos código para el evento DoubleClick de un Botón de orden, puede que el usuario jamás
active el evento, debido a que el procedimiento convencional de un Botón de orden es siempre una
única pulsación.
¿Y cómo escribiremos código para múltiples eventos? Tendremos que conocer el orden en el que se
producen estos eventos. Por ejemplo, si tenemos código en el evento Click y en el evento DoubleClick,
cuando el usuario pulse dos veces sobre el Botón de orden, el evento Click siempre se producirá antes
que el evento DoubleClick, debido a que la primera pulsación de un doble click se detecta como una
sola pulsación o como un evento Click. ¿Qué ocurrirá entonces si escribimos código adicional para los
eventos MouseUp y MouseDown del Botón de orden? ¿Qué evento se activaría primero? Conocer el
orden de los eventos es algo crucial en la programación conducida por eventos. Si no conocemos el
orden en el que se producen los eventos, nuestro código nos podrá devolver unos resultados
impredecibles.
Una forma de obtener una lista completa con explicaciones sobre el funcionamiento o el orden de
los eventos, es consulta el tem <<Orden de eventos>> en la Ayuda interactiva del lenguaje visual, por
ejemplo VBA24 (Visual Basic para Aplicaciones).
Por ahora, creo que es todo lo que podemos tratar, a manera de una simple introducción. Si usted
querido lector desea profundizar en esta técnica de programación que, por cierto, actualmente es muy
popular y está ampliamente difundida, le recomiendo, iniciarse con Microsoft Access; que si bien, no es
un lenguaje de programación, si es un potente gestor de bases de datos, que incluye el VBA, que le
permite realizar aplicaciones altamente profesionales.
24
El lenguaje Visual Basic para Aplicaciones, normalmente es suministrado por Microsoft en sus productos, tales como
MS Office.

13. - Documentación de programas.
Generalmente, un programa es parte de un proyecto mucho más grande, al cual normalmente se
le conoce como sistema de información, o simplemente sistema.
Aunque es esencial la creación de diagramas de flujo para la planeación de un sistema o
programa, solo es parte de la documentación que se requiere en una compañía. En cada compañía
existen estándares propios para la documentación y las formas que se emplean varían hasta cierto punto
de una compañía a otra. No importa cual sea el formato, el concepto fundamental es el deseo de
comunicar información acerca de un programa o de todo un sistema en la forma mas completa y
eficiente posible.
Dentro de una organización los programadores y analistas de sistemas cambian de puesto o lo
abandonan, pero los proyectos en que trabajan permanecen como parte del sistema de procesamiento de
datos de la compañía. Conforme se realizan modificaciones dentro de la compañía, estos sistemas y
programas requieren revisión. Si el programa o sistema no se ha documentado, entonces las
modificaciones necesitaran una cantidad excesiva de tiempo. Este tiempo extra se necesita para
localizar y seguir todos los detalles del proyecto.
Dentro de la documentación básica de un sistema o programa, se deben elaborar tres tipos de
manuales:
a) Manual del sistema. Dirigido al lider del proyecto de sistematización.
b) Manual del programa. Dirigido al programador.
c) Manual del usuario. Dirigido, como su nombre lo indica, al usuario final.
13.1.- Manual del Sistema.
El manual de un sistema siempre se desarrolla, mucho antes que los manuales de los
programas, dado que para el desarrollo u optimización de un sistema, se requiere un trabajo
previo llamado Análisis y Diseño del Sistema. Dicho trabajo normalmente es realizado por los
llamados, propiamente, analistas de sistemas; quienes desarrollan el o los manuales del sistema
y de los programas.
De tal manera que se utilizan los manuales del sistema como apoyo y los manuales de
programas para entregarlos a los programadores como cuadernos de carga, en los cuales se
describen detalladamente los programas que se deberán desarrollar.
Invariablemente los manuales de los programas, también llamados cuadernos de carga,
serán complementados con información que anexará el programador.
Dependiendo de la técnica de análisis utilizada, se tendrá la estructura del o los
manuales del sistema. Una de estás técnicas, por ejemplo, incluye lo que serían tres capitulos
dentro del manual del sistema, como son:
1. Análisis Previo.
2. Análisis Funcional.
3. Análisis Orgánico.
Sin embargo, el Análisis y Diseño de Sistemas, será otra materia interesante y digna de
estudio por parte del lector25.
25
Sistemas de Información Gerencial. Autor: Ing. Domingo Olivares Barrios.

13.2. - Manual del programa.
Los elementos más comunes de documentación son:
1. Nombres de los archivos de datos, y los programas que los usan.
2. Descripción de los registros de los archivos de datos.
3. Tablas de impresión.
4. Narrativa del programa.
5. Hoja de corrida.
Cuando un programa se ha completado (escrito y probado), se separa un paquete de

documentación. Se preparan versiones finales de los elementos antes mencionados y se agregan
los que siguen:
1. Una tabla del contenido del paquete de documentación.
2. Diagrama de flujo.
3. Un listado de programa fuente (listado del programa, según lo codifico el

programador, producido por la "máquina"). Esta es la versión final del
programa fuente después de que se han corregido todos los errores y el
programa ha producido la salida correcta.
4. Muestras de los informes impresos producidos por el programa y, en

particular, cualesquiera formas especiales previamente impresas que puedan
utilizarse al producir la salida.
5. Un diagrama de flujo del sistema puede incluirse para mostrar a que parte del
sistema corresponde este programa.
13.3. - Manual del usuario.
En este caso se desarrolla un manual explicando el funcionamiento del programa, y

como deberá usarlo el usuario. Las explicaciones deberán ser claras y sencillas, de tal manera
que sea fácil de entender, inclusive por cualquier persona que no tenga un gran conocimiento de
computación, o definitivamente desconozca el manejo de un equipo de computo.
Los manuales individuales de los programas, se integraran en un único manual del
usuario, es decir, el manual del sistema.
Este manual del usuario o guía del usuario, como le llaman algunos, debe tratar de por lo
menos algunos de los siguientes puntos:
• Prefacio.
Con una explicación general del objetivo del sistema o programa, sus

requerimientos de hardware y software, así como las convenciones establecidas
en cuanto a los tipos de letra utilizados en el manual para hacerlo más explicito.
Por ejemplo, en un manual se podría establecer lo siguiente para el usuario:
Convención Significado
Negrita En los procedimientos, indica el texto que usted escribe
Cursiva Índica un término del glosario.
Así mismo, deberá contener información acerca del lugar o persona de contacto
para obtener soporte técnico.
• Introducción (o bienvenida).
Con una breve descripción acerca de las facilidades del programa o sistema, o
bien, de las innovaciones, si es que es una versión actualizada.
• Capitulos de las opciones (uno para cada opción principal del programa).
Por lo menos se deberá dedicar un capitulo a cada una de las principales
opciones del programa o sistema. Dichos capitulos y el número de éstos se
desarrollarán a criterio del equipo de trabajo que desarrolla los manuales del
sistema o programa.
• Apéndices (si son necesarios).

Que contendrán información adicional acerca de temas o información
indirectamente relacionados al programa o sistema.
• Glosario.
Con definiciones de términos técnicos y conceptos.
• Índice (temático o alfabético).

Obviamente con los números de página en donde se encuentra la información
que requiera el usuario.

SOLUCIONES
Como habrá podido observar, estimado lector, los capítulos previos a éste, son bastante
extensos; así que por razones de espacio y con la idea de permitir que practique en el desarrollo de
soluciones o programas, aquí solo se plantean las soluciones a desarrollar, sin embargo, el desarrollo de
cada una de ellas, así como los códigos fuente de los programas y algunos lenguajes de programación,
se encuentran en el CD que acompaña a esta obra.
Por lo que respecta a los compiladores e interpretes de los lenguajes de programación incluidos,
es conveniente y recomendable que se documente con bibliografía relativa a aquel que vaya a utilizar, y
que incluya una relación descriptiva y estructurada de los comandos e instrucciones del lenguaje.
Las versiones de los lenguajes proporcionados, tal vez ya no sean tan populares ni utilizadas, sin
embargo, se prestan perfectamente para iniciar una buena trayectoria a un nuevo programador.
Las soluciones propuestas para desarrollar, van incrementando su grado de dificultad y están
enfocadas para que el lector aplique algunas de las herramientas de programación aprendidas, y así
mejore su comprensión al respecto.
LINEALES
1. Diseñar un programa que calcule el área de un triángulo.
2. ¿Cual es el costo por metro cuadrado de mi parcela?, si el precio es de $ 20,000.00. Las medidas
son: Largo = 100 pies, Ancho = 80 pies, 1 pie = 0.305 mts.
3. Diseñar un programa que sume dos quebrados, y muestre el resultado en forma de quebrados.
4. Diseñar un programa que calcule el promedio final del nivel, el cual consta de tres materias:
Introducción a la computación, Sistema Operativo y Lenguajes Algorítmicos.
5. Encontrar la media ponderada de tres puntuaciones de exámenes. Los pesos asociados son: 30 %,
30 % y 40 %.
6. Calcular la edad de una persona, en una fecha determinada.
TOMAS DE DECISION
7. Diseñar un programa que diga cual de dos personas es la mayor.
8. Muchas universidades hacen que a los estudiantes del primer curso que están a punto de suspender
una asignatura se les dé un aviso. Usted ha de calcular media de las puntuaciones de tres exámenes
e imprimir el número de control del estudiante, la media y si el estudiante ha pasado o no. Para
pasar se necesita una media de 60 puntos como mínimo. Si el estudiante ha pasado, pero con
menos de 70 de media, indicar que el o ella esta dudoso.
9. Diseñar un programa que acepte 3 números diferentes por teclado y despliegue el número mayor. Si
en la entrada algún número es igual entre sí deberá ser rechazado.

10. Hacer un programa que pida tres números enteros. Si el primero es negativo, desplegar el producto
de los tres. Si no desplegar la suma de los tres.
11. Diseñar un programa que diga cual es el mayor de tres números.
a) Suponiendo que los tres números son iguales.
b) Suponiendo que dos o los tres pueden ser diferentes.
12. Hacer un programa que pida la temperatura y despliegue el deporte que es apropiado hacer a esa
temperatura usando la siguiente tabla:
DEPORTE TEMPERATURA (GRADOS FAHRENHEIT)
Natación Temperatura > 85

Tenis 70 < Temperatura <= 85
Golf 32 < Temperatura <= 70
Esquí 10 < Temperatura <= 32
Damas chinas Temperatura <= 10
13. Diseñar un programa que calcule el pago por consumo de energía eléctrica, según la siguiente tabla:
CONSUMO (KW/H) CUOTA POR KW/H
HASTA 15 $ 1.50
LOS SIGUIENTES 60 $ 2.00
MAS DE 75 $ 2.50
14. Calcular la hora de llegada a su destino de los siguientes vuelos:
VUELOS TIEMPO
Veracruz – México 35 min.

Veracruz - Mérida 1 hr. 20 min.
Veracruz – Xalapa 10 min.
Veracruz – Monterrey 2 hr. 18 min.
Veracruz – Guadalajara 4 hr. 48 min.
Veracruz - Salina Cruz 2 hr. 25 min.
Veracruz – Montreal 5 hr. 30 min.
Veracruz – Tokio 8 hr. 40 min.
Veracruz – Washington 4 hr.
CONTADOR O BUCLE FOR, WHILE O REPEAT
15. Realizar un programa que efectúe la suma de 15 números dados por teclado y despliegue el
resultado.

TOMAS DE DECISION Y CONTADORES
16. Diseñar un programa que genere y despliegue los números del 1 al 100.
17. Diseñar un programa que simule el juego de ROCA - PAPEL - TIJERA. Para dos jugadores, a
ganar tres juegos; los empates no cuentan.
18. Diseñar un programa que nos dé el total de votos obtenidos por cada partido en las elecciones para
presidente, y cual fue el partido ganador. Los partidos participantes son: PRI, PAN y PRD.
19. Diseñar un programa que lea los resultados de los exámenes de veinticinco alumnos y nos diga
cuantos obtuvieron las siguientes calificaciones:
ACIERTOS CALIFICACION
95 – 100 A: EXCELENTE
85 – 94 B: MUY BUENO
75 – 84 C: BUENO
65 – 74 D: REGULAR
0 – 64 E: MALO, REPROBADO
20. Diseñar un programa que clasifique a las personas, según su edad y sexo, y nos diga cuantas
integran cada grupo según la siguiente tabla:
EDAD GRUPO
0 – 13 niños
14 – 18 adolescentes
19 – 25 jóvenes
26 – 35 adultos jóvenes
36 – 55 personas maduras
56 en adelante personas mayores
21. Diseñar un programa que haga un examen de 10 preguntas y dé el número de buenas, el número de
malas y la calificación obtenida según una escala de 0 a 100.
22. Diseñar un programa que simule un cajero automático, dando cambio en las siguientes
denominaciones:
BILLETES MONEDAS
$ 100 $ 2.00
$ 50 $ 1.00
$ 20 $ 0.50
$ 10 $ 0.20
$5 $ 0.10

TOMAS DE DECISION Y ACUMULADOR
23. Diseñar un programa que calcule el promedio de las ventas mensuales de un empleado (seis meses),
para que de acuerdo a la siguiente tabla se pueda calcular su comisión correspondiente:
PROMEDIO <= $ 5,000 COMISION: 3 %

PROMEDIO > $ 5,000 COMISION: 5 %
PROMEDIO > $ 10,000 COMISION: 8 %
24. Diseñar un programa que nos permita simular un sistema de apartado de ropa, dejando un 15 % de
su costo total y a pagar en un mes.
BANDERA
25. Dada una serie de números cualesquiera, encontrar el número mayor.
BANDERA, ACUMULADOR, Y CONTADOR
26. Diseñar un programa que pida la temperatura de cada hora del día, y que encuentre la temperatura
promedio y las temperaturas más alta y más baja del día.
SALIDA POR OPCION
27. El Instituto México desea que se capturen los siguientes datos de los alumnos: Matricula, nombre,
calificación 1, calificación 2.
Para calcular y desplegar sus promedios. Se debe considerar la opción de continuar.
SALIDA POR CENTINELA
28. Realice un programa para simular el proceso que realiza una caja registradora.
El supermercado " Las Américas " hace un descuento del 10% a los artículos marcados con
la clave " AL79 " y un 15% a los artículos que tienen la clave " AM80 ". Desplegar el total de la
compra y aplicar centinela para finalizar.
OPERACIONES CON MATRICES
29. Diseñar un programa que solicite valores y los almacene en una matriz.
30. Diseñar un programa que solicite valores numéricos, los almacene en una matriz cuadrada, y
obtenga la suma de los elementos de la diagonal principal.

APENDICE A
LIBRERIAS
NECESIDAD DE LAS LIBRERIAS.
El uso de las librerías es absolutamente necesario en la construcción de aplicaciones de gestión.

El motivo fundamental es el importante ahorro de espacio de disco y de memoria que esto conlleva en
la mayoría de los casos. Otro aspecto a tener en cuenta es el tiempo de programación que se gana si
cada tarea que se repita, al menos una vez, a lo largo de una aplicación, se guarda en una librería y se la
llama cada vez que la necesitemos, en vez de reprogramarla.
Muchas veces nos encontramos con la necesidad de realizar alguna tarea determinada y no
disponemos de ninguna función en las librerías del compilador que la realice. Si se prevé esta tarea más
veces, se compila, se añade a una de nuestras librerías y cada vez que la necesitemos, enlazamos
nuestros programas con ella, sin preocuparnos de nada más. El enlazador se encargará de buscarla
dentro de la librería y añadirla al ejecutable dejando las que no necesite para otra ocasión.
Si poseemos un conjunto de rutinas compiladas con las que enlazamos nuestros programas de
forma habitual, estaremos añadiendo espacio innecesario a los ejecutables, a no ser que las utilicemos
todas. El enlazador añade al ejecutable todo el código de los módulos compilados, los use o no,
mientras que con las librerías sólo añade la parte del código que necesita.
Si poseyéramos todas nuestras rutinas compiladas por separado en módulos objeto y tuviésemos
la precaución de enlazarlas una por una con nuestro programa cuando éste las necesite, estaríamos
haciendo exactamente la misma función que hace el enlazador con una librería.
CONSTRUCCION DE LIBRERIAS.
Existen varios (programas) utilitarios en el mercado para la construcción de librerías, por

ejemplo el programa LIB.EXE que viene junto a varios productos de Microsoft, o el TLIB de Borland
que viene junto a Turbo C. El uso de éstos y las técnicas a seguir para la construcción de librerías son
relativamente simples.
Código fuente Compilador Código objeto Constructor de librerías
Librería
REGLAS BÁSICAS.
Para diseñar una librería no basta con conocer bien la mecánica de funcionamiento del programa
constructor de librerías. Hace falta también seguir una serie de normas que optimicen el uso que más
tarde se hará de nuestro programa. Algunas de estas normas básicas a observar son:

• Hemos de procurar que las funciones estén bien documentadas, sobre todo en lo que al
funcionamiento se refiere, para que cualquiera que utilice la librería no tenga dudas a la hora de
usarlas.
• Hay que intentar planificar bien los módulos de manera que al enlazarlos con el resto de la
aplicación no ocupen espacio de más. Llevando esto a una situación extrema, lo mejor es que cada
función sea un módulo objeto distinto. Sin embargo, esta técnica hace crecer el tamaño de la librería
y deja un gran número de objetos desperdigados por el disco duro, por lo que a veces es mejor
pensar en módulos que agrupen a varias funciones. Esto último es adecuado:
- Cuando hay un grupo de funciones que se supone que si se utiliza una, se

utilizarán las demás. Por ejemplo, si usamos funciones para controlar el ratón, está claro que al
emplear una que detecte la pulsación del botón derecho también usaremos otra para detectar la
pulsación del botón izquierdo.
- Cuando el código de un grupo de funciones sea muy pequeño y suponga

un aumento despreciable de nuestro ejecutable.
• En caso de agrupar funciones en un mismo módulo objeto es aconsejable que traten de un mismo
tema para mayor facilidad a la hora de localizarlas.
• No utilizar variables PRIVADAS o PUBLICAS, o sin declarar previamente, para optimizar espacio
de ejecutable y memoria, y no interferir en las variables que declaren en sus aplicaciones los
programadores que la usen.
• Declarar ESTATICAS las funciones auxiliares internas de la librería que no se usen para el resto de
los programas.
• Hemos de procurar también que las funciones de nuestras librerías estén bien depuradas y pasen
pruebas completamente rigurosas.
• Establecer un código de error que devuelvan las funciones cuando algo no vaya bien, por ejemplo –
1. Este código no tiene por que ser el mismo para todas, pero sí tiene que ser (dentro de lo posible)
del mismo tipo de dato que el que devuelve cuando su ejecución es normal.
LAS LIBRERIAS Y LOS GRUPOS DE TRABAJO.
Cuando trabajamos en equipo, y esto suele ser lo habitual, es lógico que cada programador no
tenga que repetir el trabajo realizado por los otros. Por ello es bueno que exista para la empresa, el
grupo de trabajo, el proyecto o al nivel que nos parezca oportuno, una librería común donde vayan a
parar todas las rutinas de utilidad comunes. Es muy importante que la creación y el mantenimiento de
esta librería se haga de un modo reglamentado para facilitar su buen uso y funcionamiento. Pensemos
en una empresa cualquiera (Chapuzas, S. A.) que se dedica al desarrollo de aplicaciones en Clipper.
Cuenta con 8 desarrolladores distribuidos en 3 proyectos. Existe un responsable cada proyecto así como
uno de todo el grupo (Director Técnico). Un modelo de la organización para la gestión de una librería
común podría regirse por las siguientes normas:
1. Debe haber una librería común CHAPUZAS.LIB para todos los desarrollos que la empresa lleve
adelante. La responsabilidad última del uso y mantenimiento de esa librería es del Director
Técnico. No obstante, deberá existir una Comisión de Control de Calidad encargada de la decisión
de incorporación de funciones ya desarrolladas y del planteamiento de la necesidad de nuevas

funciones. Esta comisión se reunirá con carácter semanal. Uno de sus miembros ha de ser el
desarrollador encargado de mantener físicamente la librería. En sus manos estará no solo la
documentación de las funciones desarrolladas por otros sino también la de la creación de nuevas
funciones a petición de la Comisión de Control de Calidad.
2. Cualquier función que se incorpore a la librería debe estar documentada y probada. La
documentación debe constar de:
• Nombre de la función.
• Fecha de creación.
• Nombre del creador.
• Fecha de cada modificación.
• Nombre de cada modificador.
• Parámetros que usa con explicación detallada de los tipos, valores y funciones de cada uno de
ellos.
• Lo devuelto en caso de error.
• Si maneja bases de datos, relación de las estructuras e índices.
• Si llama a otras funciones de la misma u otras librerías complementarias, la especificación de la
misma.
• Breve descripción de la funcionalidad que realiza.
• Al menos un ejemplo de su uso.
3. Cuando cualquier equipo de trabajo necesite una rutina que considere necesaria para su aplicación
y que tenga el carácter genérico como para ser incorporada a la librería, y no pueda esperar a la
reunión de control de calidad, podrá desarrollarla por sí mismo e incorporarla a su código como un
módulo OBJ. La comisión decidirá más tarde si:
• La función se incorpora a CHAPUZAS.LIB.

• La función no tiene interés general y, por tanto, no se incorpora a la librería aunque puede seguir
formando parte de la aplicación.
• La función puede sustituirse por otra de la librería y, por tanto, el grupo de trabajo que la maneja
debe modificar su código para eliminar la función por ellos desarrollada y adoptar la que
corresponda de la librería.

APENDICE B
PROGRAMACION SEGMENTADA
Overlays estáticos y dinámicos
En el pasado, el mayor problema con el que nos podíamos encontrar, cuando estábamos
realizando una aplicación, es que ésta no nos cupiera físicamente en la memoria de trabajo de nuestro
ordenador. El único modo que teníamos de solucionar este problema era proceder a los que
denominamos segmentación, programación por capas, solapes y overlays. Generalmente los overlays
eran de carácter estático. Es decir, el programador los diseñaba en el momento de programar la
aplicación y, de forma independiente al sistema en que la aplicación se implantara, los overlays
quedaban dimensionados hasta que el programa se reenlazaba bajo otros criterios. Actualmente muchos
lenguajes solucionan este problema mediante la técnica de overlays dinámicos. Con estos el
programador se olvida de seguir ningún criterio especial, siendo el propio sistema quien decide que
parte del código se posiciona en el área de memoria principal y qué parte en el área de overlay.
Dado que los lenguajes actuales solucionan de forma automática el problema, quizá nunca tenga
que usar la técnica de overlays estáticos. Sin embargo, aún algunos lenguajes y enlazadores también lo
permiten, además de la estándar dinámica. En ocasiones, para integrar los módulos objetos de código
de diferentes lenguajes o para solucionar enrevesadas situaciones de gestión de memoria, quizá use
overlays estáticos. Algunos enlazadores sólo gestionan overlays dinámicos para ciertos lenguajes, por
ello será muy necesario que en aplicaciones grandes donde usted integre rutinas entre lenguajes
diferentes, diseñe áreas de overlays estáticos para facilitar la ubicación de las mismas. Por todo ello
vamos a explicar a continuación como trabajar con este tipo de overlays.
Cuando programamos usando esta técnica, lo que hacemos es dividir nuestra memoria RAM en
dos o más áreas de trabajo. En la primera de ellas (área principal) se carga el módulo ejecutable y en las
áreas de solape se cargan y descargan, conforme se van usando, los diferentes módulos overlay que
hayamos definido.
Los overlays estáticos permiten diversas configuraciones. La más básica es aquella que divide la
memoria de trabajo en un área principal y un área de solape. Una segunda forma es la que la divide en
un área principal y varias de solape. La tercera, y última forma, es la que trabaja con un área principal y
varias de solape, teniendo alguna de éstas otros segmentos anidados. Para comprenderlo mejor
supongamos que una aplicación que posee la siguiente estructura de módulos:
PROGPRIN MODULO1
MODULO2
MODULO3 SUBMOD1
SUBMOD2

PRIMERA FORMA SEGUNDA FORMA
AREA PRINCIPAL AREA PRINCIPAL
PROGPRIN PROGPRIN
AREA DE OVERLAY AREA DE OVERLAY 1
MODULO1 o MODULO1 o
MODULO2 o MODULO2
MODULO3
AREA DE OVERLAY 2
MODULO3
TERCERA FORMA
AREA PRINCIPAL
PROGPRIN
AREA DE OVERLAY 1
MODULO1 o
MODULO2 o
MODULO3 con
SUBMOD1 o
SUBMOD2

APENDICE C
VARIABLES DINÁMICAS.
Hasta ahora hemos manejado muchas variables, sin embargo, independientemente del tipo de
datos que contengan, éstas pueden ser estáticas o dinámicas.
Una variable estática, que es la más común, existe mientras se esté ejecutando la parte del
programa en la que está declarada (bloque). Esto significa que aquellas variables declaradas en el
programa principal están siempre allí (durante la ejecución). Las variables declaradas en los
procedimientos y funciones existen desde que se llama el procedimiento hasta que se devuelve el
control a la rutina que hizo la llamada.
Muchos lenguajes, tal como Pascal y C, tienen un mecanismo para crear variables dinámicas.
Esto significa que se puede definir un tipo en tiempo de compilación, pero realmente no crear una
variable de ese tipo hasta el tiempo de ejecución.
Estas variables dinámicas pueden crearse o destruirse en cualquier momento durante la
ejecución del programa. Pueden definirse de cualquier tipo simple o estructurado.
Referenciamos a una variable dinámica no por su nombre sino mediante un puntero. Un puntero
es una variable que contiene la dirección (posición) de memoria de la variable dinámica a la que
referencia. Cada nueva variable dinámica creada tiene un puntero asociado para referenciarla
(seleccionarla).
¿Cuándo son necesarias las variables dinámicas? Cuando necesitamos almacenar datos en una
variable de tipo arreglo, pero con la incertidumbre del número de elementos a manejar; por ejemplo, si
deseamos almacenar una lista de alumnos en un arreglo, sería complicado definir un arreglo estático, si
consideramos que la cantidad de alumnos por grupo es variable.
¿Qué podemos hacer si no sabemos cuántas componentes necesitaremos? Podemos siempre dar
una longitud y preveer en el programa que pueda ocurrir un error al tratar de almacenar datos cuando el
arreglo está lleno. ¿Qué hacemos si queremos que una lista de componentes esté almacenada de una
forma ordenada? Haremos algoritmos para ordenar arreglos. ¿Cómo insertar o suprimir una
componente? La inserción o supresión de componentes de una arreglo supone el desplazar parte del
arreglo una componente en una u otra dirección. Si la lista (arreglo) es muy larga, la inserción o
supresión de componentes necesitará una cantidad significativa de tiempo.
Podemos usar variables dinámicas para evitar estos problemas de las variables estáticas tales
como el arreglo. Podemos crear nuevas componentes para nuestra lista sólo cuando se necesiten,
usando variables dinámicas como componentes. Haciendo que cada componente contenga el enlace o
puntero a la siguiente componente de la lista, podemos crear una estructura de datos dinámica que se
expande o contrae conforme se ejecuta el programa.

No tenemos que saber de entrada cómo de grande será la lista. Ahora la única limitación es la cantidad
de memoria disponible. Podemos cambiar fácilmente el orden de los componentes cambiando sólo los
valores de los punteros.
La inserción y supresión de componentes son más fáciles y más rápidas; simplemente hay que
cambiar uno o dos valores de los punteros.
Podemos usar variables dinámicas y punteros para crear listas y estructuras de datos más
complejas que pueden expandirse y contraerse durante la ejecución del programa. Estas estructuras de
datos son extremadamente flexibles, permitiendo una más fácil inserción y supresión de las
componentes.
ORDENACION
INSERCION
SUPRESION
MANIPULACIÓN DE UNA ESTRUCTURA DE DATOS DINAMICA

PUNTEROS Y LISTAS ENLAZADAS.
PUNTEROS
Las variables dinámicas no son referenciadas mediante el nombre sino mediante un puntero. El
tipo puntero (pointer) es un tipo de datos predefinido en algunos lenguajes de programación.
Una variable referenciada, es una variable accedida no por su nombre sino por una variable
puntero; una variable dinámica.
Para crear una variable referenciada se usa, en Pascal por ejemplo, el procedimiento estándar
NEW.
NEW(P) – Crea una variable del tipo referenciado por el puntero P y almacena un puntero a la nueva
variable P.
Las sentencias
NEW(Ptr1);
NEW(Ptr2);
NEW(Ptr3);
dejan en Ptr1, Ptr2 y Ptr3 las direcciones a cada una de las variables referenciadas creadas.
¿Cómo accedemos a las nuevas variables creadas? Las variables punteros seguidas de ^, para el
caso del Pascal, nos dan la variable a la que apunta. Para las variables referenciadas creadas antes, son
válidas estas asignaciones, en el caso del Pascal:
Ptr1^:= 18;
Ptr2^:=ROJO;
Ptr3^:=TRUE
El valor de un puntero es un entero en la mayoría de las computadoras, ya que las posiciones de

memoria son direcciones en el rango de cero hasta el tamaño de la memoria. Sin embargo, un tipo
puntero no es un tipo entero. Es de notar que el Pascal es un lenguaje fuertemente tipeado. No podemos
asignar un valor entero a un puntero. Ni siquiera podemos asignar Ptr1, Ptr2 y Ptr3 unos a otros, puesto
que no apuntan a variables del mismo tipo. (Podemos asignar punteros del mismo tipo unos a otros.)
No está previsto imprimir un valor puntero.
Ptr1 Ptr1
18 18
Ptr2 Ptr2
ROJO ROJO
Ptr3 Ptr3
TRUE TRUE

La siguiente figura muestra un puntero y la variable referenciada por él.
La variable puntero Ptr1

contiene la dirección de
Ptr1^ (la variable 1432
referenciada)
18
1432 es la dirección de memoria

de la variable referenciada Ptr1^
Los punteros son importantes para crear estructuras de datos dinámicas. Puesto que debemos tener
alguna forma de enlazar cada componente con la siguiente de la estructura, cada componente debe
contener un enlace o puntero que apunte a la siguiente componente de la estructura. El registro es ideal
como componente de una estructura de datos dinámica. Puede contener campos de diferentes tipos con
el puntero siendo uno de ellos. Por ejemplo, en Pascal tendríamos:
TYPE TipoPtr = ^Persona; (* Un puntero a un registro del tipo persona *)

Persona = RECORD
Nombre : PACKED ARRAY[1..20] OF CHAR;
Siguiente : TipoPtr (* Un puntero al siguiente elemento de la lista *)
END; (* RECORD *)
Para definir una variable dinámica se describe lo que esa variable puede ser en la sección de
declaración de tipos de datos del lenguaje. En la sección de declaración de variables se declara una
variable del tipo puntero a una variable de ese tipo. Cuando se necesite una de las variables
referenciadas, se usa el procedimiento de creación de variables puntero (NEW para Pascal), en la
sección de declaración de variables.
Observe que la definición de TipoPtr incluye al identificador Persona el cual aún no está
definido. En la definición de un tipo puntero debe usarse un identificador de tipo. Este identificador de
tipo es una excepción en la regla general de que los identificadores deben declararse antes de que se
usen. Esto nos permite definir un puntero a un objeto (variable referenciada) antes de definir el propio
objeto.
No existe ninguna variable del tipo Persona antes del cuerpo del programa. Para obtener una
variable del tipo Persona, se llama al procedimiento (NEW) de creación de punteros, durante el tiempo
de ejecución. Al volver de dicho procedimiento, se ha creado una variable registro del tipo Persona. La
información sobre dónde está posicionada la variable se deja en la variable puntero Ptr. Observe que
los campos de esta nueva variable están indefinidos.
Ptr Variable del tipo PERSONA
Nombre

Esto se llama asignación dinámica de memoria porque las variables del tipo Persona se crean
cuando se necesitan en el programa.
El uso repetido del procedimiento (NEW) de creación de punteros nos permite generar variables
adicionales de este tipo. Entre estas llamadas a dicho procedimiento, enlazamos la variable que hemos
obtenido en la llamada anterior para formar una estructura de datos dinámica.
MEMORIA
Ptr
Los punteros siempre referencian a variables sin nombre. Los propios punteros pueden tener
nombre o no. Es decir, podemos crear una cadena de punteros sin nombre dinámicamente, con cada uno
apuntando al que le sigue. Sin embargo, tal cadena debe tener al menos una variable puntero con
nombre apuntando al primer elemento de la cadena o no tendremos ninguna forma de acceder a ella. Es
parecido a esos juegos de las fiestas en los que las gentes tienen que seguir una cadena de pistas, cada
pista dice dónde se encuentra la siguiente y así hasta que se encuentra un premio. Si no se da la
posición de la primera pista entonces no hay forma de empezar la cadena. Si la posición dada
corresponde a una pista de la mitad de la cadena, no hay forma de encontrar las pistas anteriores.
Cuando una variable dinámica tal como Ptr no se necesita más, el procedimiento de liberación
de memoria (DISPOSE par Pascal) la devolverá, de forma que la memoria ocupada por ella pueda
asignarse más adelante si se necesita. Esto se llama devolución a la memoria disponible.
Cualquier operación que sea válida sobre una variable con nombre de un cierto tipo lo es sobre
una variable dinámica de este tipo. Sin embargo, sólo las asignaciones y las comparaciones para ver si
son iguales, son operaciones válidas con las variables punteros. Por ejemplo, dadas estas operaciones en
Pascal:
TYPE Rango = 1..25;

VAR PtrA, PtrB : ^Rango;
Podemos hacer las siguientes operaciones:
NEW(PtrA); (* Crea una variable dinámica *)

NEW(PtrB); (* Crea una variable dinámica *)
READ(PtrA^, PtrB^); (* Almacena valores capturados en estas variables dinámicas *)
WRITELN(‘La suma de ‘, PtrA^:1, ‘ Y ‘, (* Despliega la suma de *)
PtrB^:1, ‘ ES ‘, PtrA^+ PtrB^:1) (* estas variables dinámicas *)
Observe que PtrA^ + PtrB^ es válido porque hemos añadido los contenidos de las dos variables
del tipo Rango apuntadas por PtrA y PtrB. PtrA + PtrB no sería válido porque no se pueden sumar
variables punteros. Podemos sólo asignar punteros del mismo tipo o compararlos para ver si son iguales

o desiguales. En otras palabras, podemos hacer que dos punteros referencien a la misma variable o
podemos comparar dos punteros para ver si apuntan o no a la misma variable. En la siguiente figura
comparamos las direcciones contenidas en las variables punteros, no los contenidos de estas direcciones
de memoria.
(B)
(A)
PtrA PtrB
15 15
28 28
PtrA = PtrB evalúa a FALSO Resultado de la asignación PtrA := PtrB

PtrA <> PtrB evalua a VERDADERO Ahora PtrA = PtrB evalúa a VERDADERO
PtrA <> PtrB evalúa a FALSO
Usaremos la asignación y comparación de punteros en la creación y uso de estructuras de datos

dinámicas.
LISTAS ENLAZADAS
Una de las estructuras de datos que podemos construir usando variables dinámicas y punteros se
conoce como lista enlazada. De hecho, es la estructura enlazada que hemos descrito en la primera parte
de este apéndice.
Puesto que sólo podemos acceder a las variables dinámicas mediante un puntero (^), ¿tenemos
que tener tantas variables punteros como variables dinámicas haya (componentes) en la lista? ¿Cuál es
la ventaja de esto? Ninguna, si la usamos así. Sin embargo, lo que podemos hacer es formar una cadena
de estas variables. Apuntamos a la primera de la lista y luego almacenamos dentro de cada una un
puntero a la siguiente. Es decir, cada variable dinámica será un registro con un campo conteniendo un
puntero al siguiente.
El siguiente segmento de código en Pascal, crea una lista de cinco variables del tipo
AlgunRegistro, todas enlazadas juntas.
TYPE Puntero = ^AlgunRegistro;

AlgunRegistro = RECORD
(* Otros campos *)
Siguiente : Puntero
END; (* RECORD *)
VAR List, (* El puntero a la primera componente de la lista *)

Ptr1, (* El puntero a la última compnente de la lista *)
Ptr2 : Puntero; (* El puntero a la componente más nueva *)
Vcb : Integer;

BEGIN
NEW(List);
Ptr1 := List;
For Vcb := 1 TO 4 DO
BEGIN
NEW(Ptr2);
Ptr1^.Siguiente := Ptr2;
Ptr1 := Ptr2
END;
Ptr1^.Siguiente := NIL
END.
List Ptr1 Ptr2
LISTA ENLAZADA
¿Cómo crea este código una lista? ¿Por qué necesitamos tres punteros? Hagamos un recorrido lógico
del código y veamos como funciona este algoritmo.
NEW(List);
Se crea una variable del tipo AlgunRegistro. El puntero se deja en List. List permanecerá sin
cambiar como el puntero al primero. List se llama el puntero externo a la lista.
List
Ptr1 := List;
Nuestro algoritmo obtiene una nueva variable y almacena su puntero en el campo Siguiente de
la última componente de la lista. Por tanto, necesitamos guardar la última componente para poder
asignarle a su campo puntero la variable que se cree.
List Ptr1

For Vcb := 1 TO 4 DO
Se utiliza un bucle controlado por contador para sumar las 4 últimas componentes de la lista.
BEGIN
NEW(Ptr2);
Se crea otra variable del tipo AlgunRegistro con Ptr2 apuntando a ella.
Ptr1^.Siguiente := Ptr2;
El puntero a la variable creada se almacena en el campo Siguiente de la última componente de la

lista.
Ptr1 := Ptr2
Ptr1 está de nuevo apuntando a la última componente de la lista.

Primera vuelta del bucle FOR.
La secuencia de diagramas siguiente, muestra cómo se añade una componente a la lista (es
decir, lo que sucede en el cuerpo del bucle FOR).
Y así sucesivamente, hasta crear 4 elementos en la lista. Y al salir del bucle se ejecutará lo siguiente:
END;
Ptr1^.Siguiente := NIL

Al campo Siguiente de la última componente de la lista se le asigna el valor especial NIL
(Nulo).
Observe que asignamos el valor NIL al último puntero de la lista. NIL es una palabra reservada
que puede asignarse a cualquier variable puntero. Significa que el puntero no apunta a nada. Su
importancia está ligada con el hecho de que podemos comparar el campo enlace de cada componente de
la lista con NIL para ver cuándo se alcanza el final de la lista. Esta técnica se usa cuando se busca en
(se recorre) la lista.

IMPRESIÓN DE UNA LISTA ENLAZADA
Para imprimir (o acceder en orden secuencial) a los elementos de una lista enlazada, comenzaremos
imprimiendo los valores del primer elemento, luego los del segundo, luego los del tercero y así hasta
que alcancemos el final de la lista. Esto nos sugiere algún tipo de bucle en el que la expresión sea
“mientras no sea el final de la lista”. Lo que tenemos que hacer es usar un puntero como la variable de
control del bucle. Para incrementarlo en cada paso, pondremos el campo Siguiente del registro actual.
El final de la condición del bucle será que el puntero sea igual a NIL.
PROCEDURE Imprimir(List: Puntero); (* List es el puntero externo *)
VAR P: Puntero;
BEGIN
P := List;
WHILE P <> NIL DO
BEGIN
WRITE(P^.Info);
P := P^.Siguiente
END
END;
Este procedimiento funcionará incluso para una lista vacía (Lista = NIL).

INSERCIÓN EN UNA LISTA ENLAZADA.
Un procedimiento que inserte en una lista enlazada debe tener dos parámetros: una lista
enlazada y el elemento que va a insertarse. “En” una lista enlazada es ambiguo. Podría significar
insertar un elemento como el primer elemento de la lista o insertar un elemento en su lugar de acuerdo
con alguna ordenación (alfabética o numérica). Examinemos estas dos situaciones separadamente.
Para insertar un elemento como el primero de una lista enlazada hay que hacer dos pasos: crear
el nuevo elemento y ponerlo como el primero.

PROCEDURE Meter(VAR List: Puntero; Elemento: Integer);
(* Procedimiento para insertar un elemento en la cabeza de la lista *)
VAR P: Puntero;
BEGIN
NEW(P);
P^.Info := Elemento; (* asigna el valor de Elemento al nuevo elemento *)
P^.Siguiente := List; (* enlaza al anterior primer elemento *)
List := P (* el puntero externo apunta al nuevo elemento *)
END;
Observe que antes de llamar a Meter la primera vez, deberá haberse puesto Lista a NIL.
Para insertar un elemento en su lugar se necesita del paso adicional de encontrar su lugar.
Tendremos que ir recorriendo todos los nodos (elementos de la lista) hasta que encontremos uno cuyo
campo Info sea mayor que el valor que quermos insertar. (Esto supone mantener una lista ordenada en
orden creciente). El siguiente fragmento hará esta búsqueda.
Ptr := List;
WHILE (Ptr^.Info < Elemento) DO
Ptr := Ptr^.Siguiente;
Si el nodo referenciado por Ptr es el que tiene un valor mayor que el que queremos insertar,
entonces el nuevo elemento debe insertarse delante de ese nodo. Esto causa un problema; necesitamos
conocer el nodo anterior de la lista para poder cambiar su campo puntero y que apunte al nuevo
elemento. Tendremos que mantener dos punteros conforme recorremos la lista: el puntero al nodo
actual y el puntero al nodo anterior. El siguiente fragmento hará esto.
Ptr := List;
WHILE (Ptr^.Info < Elemento DO
BEGIN
Anterior := Ptr;
Ptr := Ptr^.Siguiente
END

Esto tiene en cuenta el caso en el que el elemento va en la mitad de la lista. ¿Qué sucede en los
dos casos extremos, cuando el nuevo elemento debe insertarse por el principio o al final? Si el nuevo
elemento es el primero, podemos usar el mismo algoritmo que acabamos de escribir. Si es el último
tendremos problemas, porque la comparación
Ptr^.Info < Elemento
Causa un error al final de la lista. El tratar de acceder a Ptr^ cuando Ptr es NIL causará un error
en tiempo de ejecución.
Nuestro bucle tendrá que tener dos condiciones. Nuestra primera idea podría ser usar
(Ptr <> NIL) AND (Ptr^.Info < Elemento)
pero esto no funcionará. La mayoría de los compiladores de Pascal evaluarán ambas comparaciones de
la expresión incluso si la evaluación del primero da FALSE. Esto es, el que Ptr sea NIL no hará que se
deje de evaluar Ptr^.Info. Tendremos que usar nuestra vieja amiga la variable Booleana Encontrado. La
inicializaremos a FALSE y la cambiaremos a TRUE cuando encontremos el lugar en el que hay que
insertar el elemento.
(Ptr <> NIL) AND NOT Insertar
Esto tiene en cuenta los tres casos: la inserción por el principio, por la mitad y al final. El siguiente
procedimiento representa nuestro algoritmo de inserción general.
PROCEDURE Insertar (VAR List: Puntero; Elemento: INTEGER);

(* Procedimiento para insertar un elemento en una lista manteniéndola ordenada *)
VAR Encontrado: BOOLEAN;

P, Ptr, Anterior: Puntero; (* puntero local *)
BEGIN
NEW(P);
P^.Info := Elemento; (* obtiene un nuevo nodo *)
Anterior := NIL;
Ptr := List;
Encontrado := False;
WHILE (Ptr <> NIL) AND NOT Encontrado DO

IF Ptr^.Info > Elemento
THEN
Encontrado := TRUE
ELSE
BEGIN
Anterior := Ptr;
Ptr := Ptr^.Siguiente
END;
P^.Siguiente := Ptr;
IF Anterior = NIL
THEN
List := P
ELSE
Anterior^. Siguiente := P
END;
Observe dos cosas en este procedimiento. La primera es que el parámetro List tiene que ser un
parámetro VAR (por variable) para el caso en el que el nuevo elemento se inserta como el primer
elemento. La segunda cosa es que funcionará para campos Info de cualquier tipo escalar sin más que
cambiar el tipo de Elemento.

SUPRESIÓN EN UNA LISTA ENLAZADA
Para suprimir un nodo de una lista enlazada, debemos conocer qué nodo se va a suprimir. Esto
puede especificarse como el i-ésimo nodo o buscando un nodo con un cierto campo Info.
Examinaremos las dos supresiones: la supresión del primer nodo y la supresión de un nodo con un
campo Info determinado.
El quitar el primer nodo es simétrico a insertar un elemento como el primer nodo. El valor del
campo Info del primer nodo quitado de una lista se devolverá como un parámetro de salida.

PROCEDURE Sacar (VAR List: Puntero; VAR Elemento: INTEGER);
(* Procedimiento para quitar el primer elemento de una lista*)
VAR P: Puntero;
BEGIN
P := List; (* guarda List para devolverlo a la memoria disponible *)
Elemento := List^.Info;
List := List^.Siguiente;
DISPOSE(P) (* envia P^para que pueda usarse de nuevo *)
END;
Para suprimir un nodo cuyo campo Info tiene un cierto valor se hace de una forma muy similar al
procedimiento Insertar. La diferencia es que aquí buscamos un valor igual al nuestro, no un valor
mayor que el de nuestro elemento.

PROCEDURE Suprimir (VAR List: Puntero; Elemento: INTEGER);
VAR P, Ptr: Puntero;
BEGIN
IF Elemento = List^.Info
THEN
List := List^.Siguiente (* se suprime el primer elemento *)
ELSE
BEGIN
Ptr := List;
WHILE Ptr^.Siguiente^.Info <> Elemento DO
Ptr := Ptr^.Siguiente;
P := Ptr^.Siguiente;
Ptr^.Siguiente := Ptr^.Siguiente^.Siguiente;
DISPOSE(P) (* devuelve P^ a la memoria disponible *)
END
END;
Observe que este procedimiento evita tener que llevar un puntero atrasado usando
Ptr^.Siguiente^.Info y Ptr^.Siguiente^.Siguiente. Esto funciona inclusive si P^. Siguiente^.Siguiente es
NIL. Sin embargo, si no se encuentra un elemento igual, se producirá un error en tiempo de ejecución
cuando P^.Siguiente es NIL.
Las expresiones con punteros pueden ser muy complejas. Veamos ahora algunas expresiones
con punteros.
P, Q y R apuntan a los nodos de una lista. Para accedere a los campos de los nodos, se usa P, Q
y R. Compruebe que las siguientes equivalencias son verdad.
P^.Siguiente = Q
P^.Siguiente^= Q^
P^.Siguiente^.Siguiente = R
P^.Siguiente^.Siguiente^= R^
Q^.Siguiente = R
Q^.Siguiente^ = R^
Recuerde la semántica de la sentencia de asignación:
P := Q asigna el valor del puntero Q al puntero P.

P^ := Q^ asigna el valor de la variable referenciada por Q a la variable referenciada por P.

Para estas variables
La asignación
P^ := Q^
Da
Ahora los dos punteros P y Q apuntan cada uno a una variable diferente que contiene un GATO. Sin
embargo, la asignación
P := Q
Daria como resultado
La variable que contiene Perro está aún allí pero P no apunta a ella. De hecho, a menos que el pobre
viejo Perro pueda ser accedido de otra forma –otro puntero que le apunte- está perdido para siempre.
Sigue estando en memoria, pero no hay forma de alcanzarlo, para usarlo o para mandarlo a la memoria
disponible y que pueda usarse de nuevo.

PILAS, COLAS, COLAS DOBLES, ÁRBOLES BINARIOS.
Además de las listas enlazadas hay otras muchas estructuras de datos dinámicas que se pueden
construir. Puesto que esto no es un texto sobre estructuras de datos, describire brevemente algunas de
ellas sin usarlas en programas muestras.
PILAS
¿Ha reparado en los divertidos nombres de procedimientos Meter (Push) y Sacar (Pop) de la
sección sobre manejo de listas enlazadas? Esos nombres se utilizan en la terminología sobre pilas.
Una pila se define como una estructura de datos dinámica en la que se accede sólo por un
extremo. Se puede insertar un elemento como el primero (Meter) y suprimir el primero (Sacar).
Esta estructura de datos modela muchas cosas de la vida real. Se le suele llamar LIFO (Last-In-
First-Out) que significa que el último en entrar es el primero en salir. Una pila de datos o bandejas en
una cafetería o panadería tienen esta propiedad. Usted puede tomar sólo el plato de encima. Cuando lo
hace, el que estaba debajo queda encima y la siguiente persona puede tomarlo.
Las latas de conservas en el estante de su supermercado tiene esta propiedad. Cuando usted
toma la primera lata de una fila, está tomando la última lata que se puso en esa fila.
El conjunto de diagramas de la figura que se muestra a continuación ilustra lo que sucede
cuando se mete un elemento en una determinada pila y luego se saca de la pila. Por razones obvias, el
puntero que apunta a la cabeza o tope de la pila se llama frecuentemente Tope.

Las pilas son extremadamente útiles en informática. Si se quiere imprimir una línea de
caracteres en orden inverso se podría hacer lo siguiente:
Tope := NIL;
WHILE NOT EOLN DO
BEGIN
READ(Ch);
Meter(Tope, Ch)
END;
WHILE Tope <> NIL DO
BEGIN
Sacar(Tope,Ch);
WRITE(Ch)
END
El último carácter leído debe ser el primer carácter que se imprima.
COLAS y COLAS DOBLES
Una cola es una estructura de datos dinámica en la que los elementos se introducen por un
extremo y se suprimen o sacan por el otro. Se le suele llamar a esto FIFO (First-In-First-Out)
significando que el primero en entrar es el primero en salir. Esto se parece a una cola de espera en un
banco o supermercado. Por ello, las colas se utilizan para simular este tipo de situación.
Mientras que la terminología usada en la literatura anglosajona para referirse a la inserción y
supresión en pilas es estándar (Push, Pop), no existe tal estandarización con las colas. La operación de
insertar por el final tiene muchos nombres en la literatura: Insert (Insertar), Enter (Introducir) y Enq
(Intc) son tres nombres muy utilizados. Correspondientemente la operación de suprimir del frente o
cabeza se le llama Delete (Suprimir), Remove (Quitar) y Deq (Supc). Para llamar a nuestros
procedimientos elegimos Intc y Supc. Puesto que se accederá por los dos extremos, necesitaremos dos
punteros externos: Frente y Final.
Para insertar un elemento por el Final debemos considerar dos casos: cuando la cola esta vacía y
cuando tiene al menos un elemento. Si la cola está vacia (Final = NIL) entonces debemos poner los
dos punteros Final y Frente apuntando al elemento que se ha introducido en la cola. Si existe ya al
menos un elemento en la cola, debemos insertar el nuevo elemento a continuación de Final^ y redefinir
Final para que apunte al nuevo elemento.
Para los dos procedimientos siguientes usaremos las siguientes declaraciones.
TYPE PtrNodo = ^TipoNodo;

TipoNodo = RECORD
Elemento: INTEGER;
Siguiente: PtrNodo
END; (* RECORD *)
VAR Nodo: TipoNodo;

Frente, Final: PtrNodo;
Num: Integer;
PROCEDURE Intc(VAR Frente, Final: PtrNodo; Num: INTEGER);

(* Procedimiento para insertar un elemento al final de una cola *)
VAR Ptr: PtrNodo;
BEGIN
NEW(Ptr);
Ptr^.Elemento := Num;
Ptr^.Siguiente := NIL;
IF Final = NIL
THEN
BEGIN
Final := Ptr;
Frente := Ptr
END
ELSE
BEGIN
Final^.Siguiente := Ptr;
Final := Ptr
END
END;
El suprimir un elemento del frente o cabeza es realmente igual que sacar de una pila. De hecho,
podemos usar el procedimiento Sacar. La única cosa adicional que hay que hacer es comprobar si la
cola queda vacía después de quitar el elemento. Si queda vacía, debe ponerse Final a NIL.
PROCEDURE Supc(VAR Frente, Final: PtrNodo;

VAR Elemento: Integer);
(* Procedimiento para quitar un elemento del frente de una cola *)
BEGIN
Sacar(Frente, Elemento);
IF Frente = NIL
THEN Final := NIL
END;

Hay otras formas de implementar las pilas y las colas, pero puesto que estas estructuras varían
en tamaño durante el tiempo de ejecución, se implementan frecuentemente como listas enlazadas tal
como lo he descrito aquí.
Para el caso de las colas dobles, la lógica a aplicar es la de Insertar o Suprimir por ambos lados
de la lista enlazada. Es decir, el frente y final pueden ser intercambiados, de tal manera que cambia el
sentido de la cola, y el frente pasa a ser final y el final a ser el frente. Para ello se requiere que la
estructura elemento cuente con dos punteros.

ARBOLES BINARIOS
El concepto de lista enlazada puede extenderse a estructuras que contienen nodos con más de un
campo puntero. Una de estas estructuras se conoce como árbol. El diagrama mostrado a continuación se
llama arbol binario, cada nodo tiene como máximo dos descendientes.
El árbol se referencia mediante un puntero externo al nodo especial llamado raíz. La raíz tiene
dos punteros: uno a su hijo izquierdo y otro a su hijo derecho. Cada hijo tiene a su vez dos punteros:
uno a su hijo izquierdo y otro a su hijo derecho.
Los árboles binarios de búsqueda son árboles que tienen la propiedad de que la información de
cualquier nodo es mayor que la información de cualquier nodo de su hijo izquierdo y de cualquier nodo
de sus hijos, y menor que la información de su hijo derecho y cualquier nodo de sus hijos.
El árbol anterior es un ejemplo de árbol binario de búsqueda. La razón de su utilidad está en que
si se busca un cierto número, se puede saber después de una comparación en qué mitad del árbol está.
Con otra comparación se puede saber en qué mitad de esa mitad estaría. Así se continúa hasta que se
encuentre el elemento, o se sepa que no está en el árbol.
Probemos con el número 50.

Veamos ahora para el 18, un número que no está en el árbol.
El hijo izquierdo de 19 es NIL por lo que el 18 no está en el árbol. No sólo sabemos que no está
allí, sino que si queremos insertarlo, estamos en el lugar en el que se insertaría.

BIBLIOGRAFIA
Curso de Programación en Clipper 5.

Grupo EIDOS. Vladimir Algara, Francisco Marín, Antonio Quirós, Antonio Torres, Helio Yago.
De la edición RA-MA. Editorial Adison-Wesley Iberoamericana.
Librerías en Clipper 5.
Grupo EIDOS. Francisco Marín Quirós, Antonio Quirós Casado, Antonio Torres Lozano.
Curso de Clipper 5.2 Avanzado

José Antonio Ramalho.
Editorial McGraw Hill.
Clipper Summer ‘87

Editorial RAMA.
Microsoft Access 97. Desarrollo de Soluciones. Manual del Programador.

Timothy M. O’Brien, Steven J. Pogge, Geoffrey E. White.
Microsoft Press. Editorial McGraw Hill.
PASCAL.
Nell Dale, David Orschalic.
Editorial McGraw Hill.
QBasic.
(Un libro muy bueno que tenía, sin embargo lo perdí).
Y algunos más, que me prestaron momentáneamente, o que preste y nunca me devolvieron, razón
por la cual no tengo las bibliografías.

Lenguajes Algoritmicos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Lenguajes Algoritmicos

Cargado por

Copyright:

Formatos disponibles

LENGUAJES ALGORITMICOS

Realizó: Ing. Domingo Olivares Barrios Pág. 1

Realizó: Ing. Domingo Olivares Barrios Pág. 2

Realizó: Ing. Domingo Olivares Barrios Pág. 3

Realizó: Ing. Domingo Olivares Barrios Pág. 4

El desarrollo de nuestra lógica y habilidades de programación es similar a la construcción de

Este libro está dirigido a quienes quieren convertirse en diseñadores de soluciones

Realizó: Ing. Domingo Olivares Barrios Pág. 5

En este libro aprenderá a convertirse en un hábil diseñador de soluciones y aprovechará las

Realizó: Ing. Domingo Olivares Barrios Pág. 6

Realizó: Ing. Domingo Olivares Barrios Pág. 7

En el mundo de la computación, uno de los aspectos más importantes es la resolución de

A continuación y para entendernos mejor, se dan algunos conceptos básicos utilizados en la

Un lenguaje es un medio de comunicación, que hace uso de símbolos, caracteres y

Es la actividad de desarrollar programas, que serán suministrados a la computadora.

Es un conjunto de instrucciones, escritas en una secuencia lógica, en un lenguaje de

Realizó: Ing. Domingo Olivares Barrios Pág. 8

Es el conjunto de caracteres y reglas de utilización, aplicadas para desarrollar programas

1.4.1. Lenguaje Máquina.

Es el “idioma” de la computadora, y lógicamente, solo entendible por ella. Este

1.4.2. Lenguajes de Alto Nivel.

Es un lenguaje de programación que utilizamos para comunicarnos con la

En computación, se define como traductor, a un programa cuya función es la de

Un intérprete, es un programa traductor, el cual debe permanecer en la

Un compilador, es un programa traductor, el cual realiza la traducción del

Realizó: Ing. Domingo Olivares Barrios Pág. 9

1.4.4. – Palabras reservadas.

Son aquellas palabras propias de un lenguaje de programación, las cuales no

Desde el punto de vista informático, el Código, son las instrucciones de un

1.4.5.1. - Código fuente.

Son las instrucciones de un programa, escritas en un lenguaje de

1.4.5.2. – Código objeto.

Son las instrucciones de un programa, escritas en un formato intermedio

1.4.5.3. – Código ejecutable.

Son las instrucciones de un programa, escritas en lenguaje máquina, por

Es el proceso de traducción del código fuente a un formato intermedio de

Realizó: Ing. Domingo Olivares Barrios Pág. 10

Es el proceso de traducción del código objeto a código ejecutable, por medio de

Código Compilador Código Enlazador Código

Una librería de funciones es un archivo, normalmente con extensión.LIB, que

1.4.8.1. – Librerías preenlazadas.

Son aquellas librerías que contienen módulos objeto previamente

Realizó: Ing. Domingo Olivares Barrios Pág. 11

1.5. - Sistema informático o aplicación.

Es la persona que desarrolla programas para computadoras.

1.7. - Técnicas de programación.

Conjunto de reglas o normas utilizadas para el desarrollo de programas.

Es cualquier persona que hace uso de una computadora.

Realizó: Ing. Domingo Olivares Barrios Pág. 12

2.2. - Tipos de datos.

2.2.1. - Datos numéricos.

Un tipo numérico es el conjunto de valores numéricos, con los cuales podemos

- Tipo numérico entero (integer).

Ejemplos de tipos numéricos enteros: 5, 3, 8, 23, …

Normalmente en las computadoras, los números reales se representan en formato

2.2.2. - Datos tipo carácter.

El tipo carácter es el conjunto finito (limitado) y ordenado de caracteres que la

- Caracteres alfabéticos (A, B, C,..., Z, a, b, c,..., z).

Realizó: Ing. Domingo Olivares Barrios Pág. 13

Una cadena (string) de caracteres es una sucesión de caracteres que se encuentran

2.2.4. - Datos lógicos (booleanos).

CIERTO o VERDADERO (true) y FALSO (false)

2.3. - Constantes, variables y funciones.