LENGUAJES ALGORITMICOS ÍNDICE

1. - Introducción y conceptos básicos. ................................................ 8
1.1. - Lenguaje................................................ 8 1.2. - Programación. ...................................... 8 1.3. - Programa. ............................................. 8 1.4. - Lenguaje de programación. .................. 9 1.4.1. Lenguaje Máquina................................ 9 1.4.10. – Semántica. ..................................... 12 1.4.2. Lenguajes de Alto Nivel........................ 9 1.4.3. – Traductores. ...................................... 9 1.4.3.1. – Intérpretes. ...................................... 9 1.4.3.2. – Compiladores. ................................ 9 1.4.4. – Palabras reservadas........................ 10 1.4.5. – Código. ............................................ 10 1.4.5.1. - Código fuente............................... 10 1.4.5.2. – Código objeto. .............................. 10 1.4.5.3. – Código ejecutable. ........................ 10 1.4.6. – Compilación. ................................... 10 1.4.7. – Enlazado.......................................... 11 1.4.8. – Librerías. ......................................... 11 1.4.8.1. – Librerías preenlazadas. ................. 11 1.4.9. – Sintaxis. ........................................... 11 1.5. - Sistema informático o aplicación........ 12 1.6. - Programador....................................... 12 1.7. - Técnicas de programación.................. 12 1.8. - Usuario. .............................................. 12

11. – Introducción a la Programación Orientada al Objeto. ...............................................205
11.1. – Introducción. ...................................205 11.2. – Vocabulario OOPS..........................206 11.3. – Conceptos básicos. ..........................206 11.4. – Clarificando conceptos. ..................208 11.4.1. - ¿ Qué es una clase ? .....................208 11.4.2. - ¿ Qué es un objeto ? .....................209 11.4.3.- El concepto de herencia.................209 11.4.4.- El concepto de jerarquía................209 11.5. – Conclusiones. ..................................210 11.5.1. – Lo mejor. ......................................210 11.5.2. – Lo peor. ........................................210 11.5.3. – Posibles soluciones. .....................210

12. - Introducción a la Programación dirigida por eventos. .............................................211 13. - Documentación de programas......................................215
13.1.- Manual del Sistema...........................215 13.2. - Manual del programa. .....................216 13.3. - Manual del usuario. .........................216

10. – Introducción a la Programación Dirigida por los Datos......................................... 197
10.1. – Programación Código-Fijo (HardCode). ..................................................... 197 10.2. – Programación Dirigida por los Datos (Data-Driven). ........................................ 198 10.3. – Diccionario de datos. ..................... 202 10.4. – Programación de plantillas............ 202 10.4.1. - ¿ Qué es una plantilla ? ............... 202 10.4.2. – Ventajas de una plantilla............. 203 10.4.3. – Cuando utilizar una plantilla. ..... 203 10.4.4. – Generadores de Código............... 203 Realizó: Ing. Domingo Olivares Barrios

2. - Tipos y estructuras básicas de datos. ........................13
2.1. - Dato. ....................................................13 2.2. - Tipos de datos. .....................................13 2.2.1. - Datos numéricos. ..............................13 2.2.2. - Datos tipo carácter. ..........................13 2.2.3. - Datos alfanuméricos, de cadena o string. ........................................................14 2.2.4. - Datos lógicos (booleanos). ...............14 2.3. - Constantes, variables y funciones........14 2.4. - Expresiones. .........................................14 2.4.1. - Expresiones aritméticas. ...................15 2.4.2. - Expresiones alfanuméricas. ..............16 Pág. 1

2.4.3. - Expresiones lógicas (booleanas)...... 16 2.4.3.1. - Operadores de relación.................. 16 2.4.3.2. - Operadores lógicos........................ 17 2.4.4. – Reglas globales de prioridad o precedencia. ............................................. 18 2.5. - Arreglos (arrays)................................. 18 2.5.1. - Arreglos unidimensionales............... 18 2.5.2. - Arreglos bidimensionales................. 19 2.5.3. - Arreglos multidimensionales. .......... 19

5.3.4. - Estructura de " para hasta ". ............51 5.3.5. - Estructura de " hacer mientras ". .....53 5.3.6. - Estructura de " hacer hasta ". (repetir hasta).........................................................54

6. - Herramientas de programación. ..............................56
6.1. - El contador. .........................................56 6.2. - El acumulador o sumador....................56 6.3. - La bandera o indicador. ......................57 6.4. - Salida de un programa por opción. .....58 6.5. - Salida de un programa por centinela. .59 6.6. – Subrutinas, procedimientos y funciones. ...................................................................59 6.6.1.- Subrutinas. .........................................59 6.6.2.- Procedimientos...................................63 6.6.3.- Funciones. ..........................................63 6.6.3.1.- Funciones Implícitas. ......................64 6.6.3.2.- Funciones de Usuario......................64 6.6.4.- Parámetros en procedimientos y funciones. ..................................................64 6.6.4.1.- Parámetros por valor. ......................64 6.6.4.2.- Parámetros por referencia (por variable).....................................................66 6.6.5.- Variables en procedimientos y funciones. ..................................................67 6.6.5.1.- Variables Globales. .........................67 6.6.5.2.- Variables Locales............................67 6.6.5.3.- Reglas de ámbito.............................67 6.6.5.4.- Efectos laterales. .............................69 6.6.6.- Recursividad. .....................................71 6.7. - Encadenamiento de programas. ..........74

3. - Técnicas de Programación. ............................ 20
3.1. - Importancia......................................... 20 3.2. - Objetivo............................................... 20 3.3. - Estilos de programación. .................... 20 3.4. La Notación Húngara y otras convenciones. ........................................... 21

4. - Técnica de diseño general o elemental. ................................... 27
4.1. - Fases de resolución de problemas. ..... 27 4.2. - Simbología de diagramas de bloques o diagramas de flujo de sistemas. ............... 33 4.3. - Simbología de diagramas de flujo. ..... 34 4.4. - Recomendaciones para el desarrollo de diagramas................................................. 35 4.4.1. - Diagramas de bloques o diagramas de flujo de sistemas. ...................................... 35 4.4.2. - Diagramas de flujo. ......................... 35 4.5. - Resolución de problemas aplicando la Técnica de diseño general o elemental. ... 36

5. - Diagramas de flujo. ........... 48 5.1. - Tipos de diagramas de flujo................ 48 5.1.1. - Diagramas de flujo lineales. ............ 48 5.1.2. - Diagramas de flujo cíclicos. ............ 48 5.2. - Estructuras de diagramas de flujo lineales. .................................................... 48 5.2.1. - Estructura de secuencia. .................. 48 5.2.2. - Estructura de decisión. .................... 49 5.2.3. - Ramificaciones. ................................ 49 5.3. - Estructuras de diagramas de flujo cíclicos...................................................... 50 5.3.1. - Creación de ciclos, iteraciones o bucles........................................................ 50 5.3.2. - Pasos de un ciclo o bucle................. 50 5.3.3. - Ciclos o bucles anidados. ................ 51
Realizó: Ing. Domingo Olivares Barrios

7. - Técnica de diseño modular. ............................................75
7.1. - Fases de resolución de problemas.......75 7.2. - Estructuras jerárquicas o en árbol. .....75 7.3. - Resolución de problemas aplicando la Técnica de diseño modular........................78

8. - Técnica de diseño descendente. .................................100
8.1. - Fases de resolución de problemas.....100 8.2. - Resolución de problemas aplicando la Técnica de diseño descendente. ..............102

Pág. 2

9. – Introducción a la programación para gestión de archivos. .................................. 117
9.1. - Conceptos básicos............................. 117 9.1.1. - Archivo. .......................................... 117 9.1.2. - Campo. ........................................... 117 9.1.3. - Registro. ......................................... 117 9.1.4. - Base de datos. ................................ 118 9.2. - Tipos de Archivos y accesos.............. 119 9.2.1. - Archivos secuenciales .................... 119 9.2.2. - Archivos directos............................ 119 9.2.3. – Archivos indexados........................ 119 9.2.4. – Otros tipos de archivos. ................ 120 9.3. – Bases de datos. ................................. 120 9.3.1. - ¿ Qué es un SGBD ? ...................... 120 9.3.2. – La independencia de los datos. ..... 121 9.3.3. – Lenguajes y Bases de Datos. ......... 122 9.3.4. – Los tres enfoques. .......................... 122 9.3.4.1. – Enfoque jerárquico. .................... 122 9.3.4.2. – Enfoque de red (Codasyl). .......... 124 9.3.4.3. – Enfoque relacional...................... 125 9.3.5. – Diseño de Bases de Datos. ............ 127 9.3.6. – El modelo Entidad-Relación.. ....... 128 9.3.7. – Normalización. .............................. 131 9.3.7.1. – Formas normales. ....................... 132 9.3.8. – Índices y ordenaciones. ................. 135 9.3.9. – Lenguajes de cuarta generación (4GL). ................................................................ 137 9.4. – Gestión de archivos de datos............ 138 9.4.1. – Gestión de archivos secuenciales.. 142

9.4.2. – Gestión de archivos directos. .........159 9.4.3. – Gestión de archivos indexados.......174 9.4.4. – Gestión de una base de datos relacional constituida por dos archivos..190

APENDICE A.............................222 APENDICE B.............................225 APENDICE C.............................227 BIBLIOGRAFIA.....................252
IMPRESIÓN DE UNA LISTA ENLAZADA ........................................237 INSERCIÓN EN UNA LISTA ENLAZADA. .......................................238 LIBRERIAS ...........................................222

OBJETIVOS. ..........................................7
PILAS, COLAS, COLAS DOBLES, ÁRBOLES BINARIOS. .................246
PREFACIO......................................................5

PROGRAMACION SEGMENTADA
.................................................................225 PRÓLOGO ......................................................4

PUNTEROS Y LISTAS ENLAZADAS. ...................................229
S O L U C I O N E S ...................................218

SUPRESIÓN EN UNA LISTA ENLAZADA ........................................242 VARIABLES DINÁMICAS. ............227

Realizó: Ing. Domingo Olivares Barrios

Pág. 3

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 2

Como venía haciéndolo –aunque sin una estructura claramente definida-. 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 4

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 Realizó: Ing. Domingo Olivares Barrios Pág. 5

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 6

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 7

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.

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).

4

Realizó: Ing. Domingo Olivares Barrios

Pág. 8

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
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.
5

Realizó: Ing. Domingo Olivares Barrios

Pág. 9

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 10

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 fuente
Compilador

Código objeto

Enlazador

Código 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 11

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 12

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 (!, ", $, %, &, /, ...).

Realizó: Ing. Domingo Olivares Barrios

Pág. 13

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 14

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 5 DIV 2 5 MOD 2 4+6/2 (4+6)/2 ((3+5)/2^2)+1 4*2/4 2^2/4

OPERACIONES División entera Módulo o residuo 4+3 10/2 (8/2^2)+1 = (8/4)+1 = 2+1 8/4 4/4

RESULTADO 2 1 7 5 3 2 1

Realizó: Ing. Domingo Olivares Barrios

Pág. 15

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 5<3 3<5 8>2 2>8 3=3 3=2 3 <= 5 6 <= 5 3 >= 5 6 >= 5 3 <> 3 3 <> 2 RESULTADO FALSO VERDADERO VERDADERO FALSO VERDADERO FALSO VERDADERO FALSO FALSO VERDADERO FALSO VERDADERO

Realizó: Ing. Domingo Olivares Barrios

Pág. 16

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 Verdadera Falsa AND Falsa Resultados Expresión Verdadera Verdadera Falsa Falsa Falsa Lógica 1 Resultados Expresión Lógica 2 Verdadera Falsa OR Expresión Verdadera Verdadera Verdadera Resultados Falsa Verdadera Falsa Lógica 1 Resultados Resultado NOT Falsa Expresión Verdadera Falsa Verdadera Lógica 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. Expresión Lógica 2 Verdadera Falsa XOR Verdadera Resultados Expresión Verdadera Falsa Falsa Verdadera Falsa Lógica 1 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 17

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 18

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 5 2 3 4

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 19

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. AddisonWesley, 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 20

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 Realizó: Ing. Domingo Olivares Barrios Pág. 21

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
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.
7

Realizó: Ing. Domingo Olivares Barrios

Pág. 22

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 Realizó: Ing. Domingo Olivares Barrios Pág. 23

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 Realizó: Ing. Domingo Olivares Barrios Pág. 24

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
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. 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.
9 8

Realizó: Ing. Domingo Olivares Barrios

Pág. 25

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 kktPrueba vnt -> Ventana 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 26

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. 1. - Determinar el objetivo o problema. 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. 2. - Análisis del problema: A) Determinar los datos de salida solicitados, y los datos de entrada necesarios. 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 Realizó: Ing. Domingo Olivares Barrios Pág. 27

partiremos". B) Determinar los pasos para resolver el problema. 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. C) Comprender y detallar los pasos para resolver el problema. 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. 6. - Codificar el programa. 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 28

Lenguaje Basic Lenguaje Pascal Print Write (imprimir) (escribir) Input Read (introducir) (leer) If-Then-Else If-Then -Else-; (Si-Entonces-Sino) (Sí-Entonces-Sino) En caso On-goto Case Of (Según-ir a) (Caso de) Para-Hasta-Siguiente For-To-Next For-To-; (Para-Hasta-Siguiente) (Para-Hasta-;) Hacer Mientras While-Wend While-Do-; (Mientras-FinMientras) (Mientras-Hacer-;) Hacer Hasta Do-Until (Hacer-Hasta)

Lenguaje Común Desplegar (en pantalla) Introducir (por teclado) Sí-Entonces-Sino

Lenguaje Clipper Say (decir) Get-Read (tomar-leer) If-Else-EndIf (Sí—Sino-FinSí) Do Case (Hacer en caso) For-To-Next
(Para-Hasta-Siguiente)

Lenguaje C Printf (imprimir) Scanf (examinar) If-Else-; (Sí—Sino-;) Switch-Case
(Interruptor-Caso)

Do While-EndDo
(Hacer-Mientras-FinHacer)

For(){}; (Para()-{}-;) While-; (Mientras-;) Do-while-;
(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. 7. - Capturar la codificación. 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

Realizó: Ing. Domingo Olivares Barrios

Pág. 29

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. 8. - Prueba y detección de errores. 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. Realizó: Ing. Domingo Olivares Barrios Pág. 30

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). 9. - Depuración del programa. 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 Realizó: Ing. Domingo Olivares Barrios Pág. 31

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. 10. - Ejecución y puesta en operación del programa. 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.

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.

10

Realizó: Ing. Domingo Olivares Barrios

Pág. 32

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)

Almacenamiento en medio magnético (disco duro o fijo)

Almacenamiento en medio magnético (cinta magnética) Entrada/Salida general de información Salida de información, reporte por impresora

Realizó: Ing. Domingo Olivares Barrios

Pág. 33

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 34

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 35

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 1. - Determinar el objetivo o problema. (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. 2. - Análisis del problema: A) Determinar los datos de salida solicitados, y los datos de entrada necesarios. 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. B) Determinar los pasos para resolver el problema. 1. 2. 3. 4. 5. Solicitar los datos del empleado. Calcular el salario total a pagar. Calcular las cuotas por pagar. Calcular el Total Neto a Pagar. Mostrar los importes del sueldo total neto a pagar, sus prestaciones y deducciones.

C) Comprender y detallar los pasos para resolver el problema. 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 Realizó: Ing. Domingo Olivares Barrios Pág. 36

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 Empleado Calculo del Sueldo
Calculo de las deducciones y prestaciones Total de deducciones, prestaciones y Total a Pagar

Realizó: Ing. Domingo Olivares Barrios

Pág. 37

2. Diseñar el diagrama de flujo. INICIO 1 2

INICIALIZAR VARIABLES

“Salario Diario:”

nInfonavit = nSalTotAPag * 0.05

“Dame los siguientes datos:”

nSalDia

nSar = nSalTotAPag * 0.03

“Nombre:”

“Días Trabajados:”

nIspt = nSalTotAPag * 0.02

cNombre

nDiasTrab ¿ nAntig >= 5 ?

NO

3

“Puesto:”

nSalTotAPag = nDiasTrab * nSalDia

SI
nBono = nSalTotAPag * 0.05

cPuesto
nImss = nSalTotAPag * 0.03 “Antigüedad:” nApEduc = nSalTotAPag * 0.01

3
nTotNetoAPagar = nSalTotAPag + nBono

nAntig

1

2

“Resultados:”, “IMSS:”; nImss, “ISPT:”; nIspt, “SAR:”; nSar, “Ap. Educ.:”; nApEduc, “Infonavit:”; nInfonavit, “Bono:”; nBono, “Sal. Total a Pagar:”; nSalTotAPag, “Tot. Neto a Pagar:”; nTotNetoAPagar

FIN

Realizó: Ing. Domingo Olivares Barrios

Pág. 38

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. 1. Inicializar variables. 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. 6. - Codificar el programa. 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. Realizó: Ing. Domingo Olivares Barrios Pág. 39

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 40

Lenguaje Quick Basic. (Podríamos considerar éste, como un dialecto del Basic).
REM REM REM REM Programa EJEGQBAS.BAS Método de Diseño General o Elemental. Programa Principal. 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 PRINT INPUT PRINT INPUT PRINT INPUT PRINT INPUT PRINT INPUT "Dame los siguientes datos:" "Nombre:"; cNombre$ "Puesto:"; cPuesto$ "Antigüedad:"; nAntig "Salario Diario:"; nSalDia "Días Trabajados:"; 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 PRINT PRINT PRINT PRINT PRINT PRINT PRINT PRINT END "Resultados:" "IMSS: "; nImss "ISPT: "; nIspt "SAR: "; nSar "Apoyo a la Educación: "; nApEduc "INFONAVIT: "; nInfonavit "Bono: "; nBono "Salario Total a Pagar: "; nSalTotAPag "Total Neto a Pagar: "; nTotNetoAPagar

Realizó: Ing. Domingo Olivares Barrios

Pág. 41

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 cPuesto nAntig nSalDia nDiasTrab nSalTotAPag nImss nApEduc nInfonavit nSar nIspt nBono nTotNetoAPagar BEGIN (* Inicio *) (* Inicializando variables. *) nAntig nSalDia nDiasTrab nSalTotAPag nImss nApEduc nInfonavit nSar nIspt nBono nTotNetoAPagar := := := := := := := := := := := 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; : : : : : : : : : : : : : STRING[10]; STRING[10]; REAL; REAL; REAL; REAL; REAL; REAL; REAL; REAL; REAL; REAL; REAL;

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. *)

Realizó: Ing. Domingo Olivares Barrios

Pág. 42

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 43

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 @ 2,10 @ 2,30 @ 3,10 @ 3,30 @ 4,10 @ 4,30 @ 5,10 @ 5,30 @ 6,10 @ 6,30 READ SAY SAY GET SAY GET SAY GET SAY GET SAY GET "Dame los siguientes datos:" "Nombre:" cNombre "Puesto:" cPuesto "Antigüedad:" nAntig "Salario Diario:" nSalDia "Días Trabajados:" nDiasTrab

* 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: " 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
12

Realizó: Ing. Domingo Olivares Barrios

Pág. 44

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ RETURN

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 45

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);

Realizó: Ing. Domingo Olivares Barrios

Pág. 46

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. */

7. - Capturar la codificación. 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. 8. - Prueba y detección de errores. Se realiza esta actividad, tras terminar la captura del programa. 9. - Depuración del programa. Es la corrección de los errores detectados durante las pruebas efectuadas en la actividad anterior. 10. - Ejecución y puesta en operación del programa. 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 47

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 48

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 Realizó: Ing. Domingo Olivares Barrios Pág. 49

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 Realizó: Ing. Domingo Olivares Barrios Pág. 50

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
V > F

VERDADERO

SALIDA
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).

Realizó: Ing. Domingo Olivares Barrios

Pág. 51

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
FALSO

SALIDA

PROCESO

INC

A 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 Entrada PARA V = I HASTA F INCREMENTO INC PROCESO SIGUIENTE Salida INGLÉS Entrada FOR V = I TO F STEP INC PROCESO NEXT 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 52

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

A 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. El algoritmo se escribiría de la siguiente manera: ESPAÑOL Entrada HACER MIENTRAS Condición=Verdadera PROCESO FIN MIENTRAS Salida INGLÉS Entrada DO WHILE Condición=Verdadera PROCESO END WHILE 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 53

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

CONDICION

NO

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. El algoritmo se escribiría de la siguiente manera: ESPAÑOL Entrada REPETIR PROCESO HASTA Condición=Verdadera Salida Otra forma podría ser: ESPAÑOL Entrada HACER PROCESO INGLÉS Entrada DO PROCESO INGLÉS Entrada REPEAT PROCESO UNTIL Condición=Verdadera Salida

Realizó: Ing. Domingo Olivares Barrios

Pág. 54

VUELTA HASTA Condición=Verdadera Salida

LOOP UNTIL Condición=Verdadera 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 HACER PROCESO MIENTRAS Condición=Falsa Salida Que también podría quedar como: Entrada HACER PROCESO MIENTRAS Condición<>Verdadero Salida Entrada DO PROCESO WHILE Condición<>Verdadero Salida Entrada DO PROCESO WHILE Condición=Falsa 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 55

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 56

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 Operador lógico Valor lógico 2

NO ó SI

PROCESO B

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 57

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 A

PROCESO

“¿ Desea Continuar (S/N) ?

cRespuesta

cRespuesta = “S”

SI A

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).

Realizó: Ing. Domingo Olivares Barrios

Pág. 58

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 A

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 Realizó: Ing. Domingo Olivares Barrios Pág. 59

programa que llama a una subrutina. ENTRADA

PROCESO

SUBRUTINA A

SUBRUTINA A PROCESO DE LA SUBRUTINA RETORNO

PROCESO

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 60

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. … … … … … … CONTINUA CODIGO DEL PROGRAMA. … … LLAMADA A LA SUBRUTINA … … … FIN DEL 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 Realizó: Ing. Domingo Olivares Barrios Pág. 61

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. CONTINUA CODIGO DEL PROGRAMA. … … LLAMADA A LA SUBRUTINA … … … FIN DEL CODIGO DEL PROGRAMA.

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. … … CONTINUA CODIGO DEL PROGRAMA. … … LLAMADA A LA SUBRUTINA … … … FIN DEL CODIGO 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 Realizó: Ing. Domingo Olivares Barrios Pág. 62

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 63

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:

Realizó: Ing. Domingo Olivares Barrios

Pág. 64

Inicio del Código del Programa Principal. … … … VariableOrigen = 5 LlamadaAlProcedimientoA(VariableOrigen) Desplegar Variable Origen … … Parámetro Actual … Fin del Código del Programa Principal.

VariableOrigen

5

Este cuadro representa el área de memoria donde se almacena el valor de VariableOrigen.

Cabecera del Procedimiento o Función

Parámetro Formal Este cuadro representa el área de memoria donde se almacena el valor de ParámetroPorValor. El cual es una copia del original. Como puedes observar, la modificación del valor se realiza en el área de memoria donde se almaceno la copia del valor, y no en el área de memoria donde tenemos el valor original. Esto es útil cuando no queremos que se modifique el valor original o inicial.

LlamadaAlProcedimiento(ParámetroPorValor) Inicio del Código de un Procedimiento o Función. … … ParametroPorValor = ParametroPorValor+2 … … Fin del Código de LlamadaAlProcedimiento Retorno (RETURN) al Programa Principal.

5
ParámetroPorValor

7
ParámetroPorValor

Realizó: Ing. Domingo Olivares Barrios

Pág. 65

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. … … … VariableOrigen = 5 LlamadaAlProcedimientoA(VariableOrigen) Desplegar Variable Origen … … Parámetro Actual … Fin del Código del Programa Principal.

Este cuadro representa el área de memoria donde se almacena el valor de la VariableOrigen.

VariableOrigen

VariableOrigen

5
ParámetroPorVariable

7
ParámetroPorVariable

Cabecera del Procedimiento o Función

Parámetro Formal

LlamadaAlProcedimiento(ParámetroPorVariable) Inicio del Código de un Procedimiento o Función. … … ParametroPorVariable = ParametroPorVariable+2 … … Fin del Código de LlamadaAlProcedimiento Retorno (RETURN) al Programa Principal.

Este cuadro representa el área de memoria donde se almacena el valor del ParámetroPorValor. El cual es una copia del original.

Como puedes observar, los dos nombres de variables hacen referencia a la misma posición de 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 66

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 67

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”.

Realizó: Ing. Domingo Olivares Barrios

Pág. 68

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 Y Otros procedimientos Efectos Laterales Lista de parámetros Interface de comunicación Otros módulos

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 Realizó: Ing. Domingo Olivares Barrios Pág. 69

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) LATERAL(A,B) (cuando se llama) X=X+Y A=X+1 LATERAL = X + A

0 0 1 2 2

1 1 1 1 1

? 0 1 2 2

? 1 1 1 1

? ? ? ? 4

Lo que se imprime

LATERAL(A,B) (cuando se llama) X=X+Y A=X+1 LATERAL = X + A

2 3 4 4

1 1 1 1

2 3 4 4

1 1 1 1

? ? ? 8

Lo que se imprime

Realizó: Ing. Domingo Olivares Barrios

Pág. 70

LATERAL(A,B) (cuando se llama) X=X+Y A=X+1 LATERAL = X + A

4 4 6 6

1 5 5 5

1 5 5 5

4 4 6 6

? ? ? 11

Lo que se imprime

LATERAL(A,B) (cuando se llama) X=X+Y A=X+1 LATERAL = X + A

6 5 5 6 6 11 11 6 12 11 11 12 12 11 11 12

? ? ? 23

Lo que se 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 Realizó: Ing. Domingo Olivares Barrios Pág. 71

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 72

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

2
Llamada a POTENCIA(2,2)

3
El valor devuelto es 4

FUNCION Potencia nX nN

2
Llamada a POTENCIA(2,1)

2

El valor devuelto es 2

FUNCION Potencia nX nN

2

1

Realizó: Ing. Domingo Olivares Barrios

Pág. 73

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 74

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. 7.1. - Fases de resolución de problemas. 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

Realizó: Ing. Domingo Olivares Barrios

Pág. 75

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 15

Métodos de clasificación y búsqueda. Árboles sintácticos para representar las expresiones o producciones posibles de un lenguaje.

Realizó: Ing. Domingo Olivares Barrios

Pág. 76

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

NIVEL 1 Sub-árbol O Nodo Sub-árbol O Nodo Sub-árbol O Nodo Sub-árbol O Nodo

NIVEL 2

Sub-árbol O Nodo

Sub-árbol O Nodo

Sub-árbol O Nodo

Sub-árbol O Nodo

Sub-árbol O Nodo

ESPEJO
Sub-árbol O Nodo Sub-árbol O Nodo Sub-árbol O Nodo Sub-árbol O Nodo Sub-árbol O Nodo

NIVEL 2

Sub-árbol O Nodo NIVEL 1

Sub-árbol O Nodo

Sub-árbol O Nodo

Sub-árbol O Nodo

NIVEL 0

RAIZ

Realizó: Ing. Domingo Olivares Barrios

Pág. 77

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. 2. 3. 4. 5. Solicitar los datos del empleado. Calcular el salario total a pagar. Calcular las cuotas por pagar. Calcular el Total Neto a Pagar. 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. 2. 3. 4. 5. Solicitar Datos del Empleado. Calcular Salario Total a Pagar. Calcular Cuotas por pagar. Calcular el Total Neto a Pagar. 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. Realizó: Ing. Domingo Olivares Barrios Pág. 78

3.3. Calcular Cuota del Infonavit. 3.4. Calcular ISPT. 3.5. Calcular SAR. 3.6. Calcular el Bono por antigüedad. 4. Calcular el Total Neto a Pagar. 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 del Empleado.

Calcular Salario Total a Pagar.

Calcular Cuotas y Retenciones.

Calcular el Total Neto a Pagar.

Mostrar Resultados.

Etiquetas de Solicitud de Datos. Captura de Datos.

Calcular Cuota del IMSS. Calcular Cuota de Apoyo a la Educación. Calcular Cuota del Infonavit. Calcular ISPT. Calcular SAR.

NIVEL 2

Calcular el Bono por antigüedad.

Realizó: Ing. Domingo Olivares Barrios

Pág. 79

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 80

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 nSalTotAPag = nDiasTrab * nSalDia 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 Realizó: Ing. Domingo Olivares Barrios Pág. 81

PROCEDIMIENTO Calcular Total Neto a Pagar INICIO nTotNetoAPagar = nSalTotAPag + nBono 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”.

Realizó: Ing. Domingo Olivares Barrios

Pág. 82

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 ' 310 NSALTOTAPAG = NDIASTRAB * NSALDIA 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 ' 460 NTOTNETOAPAGAR = NSALTOTAPAG + NBONO 470 RETURN 480 '************************************************************************** 490 'SUBRUTINA: Mostrar Resultados. 500 ' 510 CLS 'Borra la pantalla. 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

Realizó: Ing. Domingo Olivares Barrios

Pág. 83

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 ' 700 CLS 'Borra la pantalla. 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 ' 900 NIMSS = NSALTOTAPAG * .03 910 RETURN 920 '************************************************************************** 930 'SUBRUTINA: Calcular Cuota de Apoyo a la Educación. 940 ' 950 NAPEDUC = NSALTOTAPAG * .01 960 RETURN 970 '************************************************************************** 980 'SUBRUTINA: Calcular Cuota de Infonavit. 990 ' 1000 NINFONAVIT = NSALTOTAPAG * .05 1010 RETURN 1020 '************************************************************************** 1030 'SUBRUTINA: Calcular ISPT. 1040 ' 1050 NISPT = NSALTOTAPAG * .02 1060 RETURN 1070 '************************************************************************** 1080 'SUBRUTINA: Calcular SAR. 1090 ' 1100 NSAR = NSALTOTAPAG * .03 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

Realizó: Ing. Domingo Olivares Barrios

Pág. 84

REM Método de Diseño Modular. 'Declaración de PROCEDIMIENTOS (Módulos). 'Módulos de NIVEL 2. DECLARE SUB DECLARE SUB DECLARE SUB DECLARE SUB SINGLE) DECLARE SUB DECLARE SUB DECLARE SUB DECLARE SUB nSalTotAPag DesplegarMensajesDeSolicitudDeDatos () CapturaDeDatos (nAntig, nSalDia, nDiasTrab) CalcularCuotaDelIMSS (nImss AS SINGLE, nSalTotAPag AS SINGLE) CalcularCuotaDeApoyoALaEducacion (nApEduc AS SINGLE, nSalTotAPag AS CalcularCuotaDelInfonavit (nInfonavit AS SINGLE, nSalTotAPag AS SINGLE) CalcularISPT (nIspt AS SINGLE, nSalTotAPag AS SINGLE) CalcularSAR (nSar AS SINGLE, nSalTotAPag AS SINGLE) CalcularElBonoPorAntiguedad (nAntig AS SINGLE, nBono AS SINGLE, 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, nSalTotAPag 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. 'Inicio del programa. CLS 'Borra la pantalla. 'Inicializar 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 '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) nApEduc = nSalTotAPag * .01 NIVEL 0.

Realizó: Ing. Domingo Olivares Barrios

Pág. 85

END SUB 'Módulo de NIVEL 2. SUB CalcularCuotaDelIMSS (nImss AS SINGLE, nSalTotAPag AS SINGLE) nImss = nSalTotAPag * .03 END SUB 'Módulo de NIVEL 2. SUB CalcularCuotaDelInfonavit (nInfonavit AS SINGLE, nSalTotAPag AS SINGLE) nInfonavit = nSalTotAPag * .05 END SUB 'Módulo de NIVEL 1. SUB CalcularCuotasPorPagar (nImss AS SINGLE, nApEduc AS SINGLE, nInfonavit AS SINGLE, nIspt AS SINGLE, nSar AS SINGLE, nAntig AS SINGLE, nBono AS SINGLE, nSalTotAPag AS SINGLE) CALL CALL CALL CALL CALL CALL END SUB 'Módulo de NIVEL 2. SUB CalcularElBonoPorAntiguedad (nAntig AS SINGLE, nBono AS SINGLE, nSalTotAPag AS SINGLE) IF nAntig >= 5 THEN nBono = nSalTotAPag * .05 ELSE nBono = 0 END IF END SUB 'Módulo de NIVEL 1. SUB CalcularElTotalNetoAPagar (nTotNetoAPagar AS SINGLE, nSalTotAPag AS SINGLE, nBono AS SINGLE) nTotNetoAPagar = nSalTotAPag + nBono END SUB 'Módulo de NIVEL 2. SUB CalcularISPT (nIspt AS SINGLE, nSalTotAPag AS SINGLE) nIspt = nSalTotAPag * .02 END SUB 'Módulo de NIVEL 1. SUB CalcularSalarioTotalAPagar (nSalTotAPag AS SINGLE, nDiasTrab AS SINGLE, nSalDia AS SINGLE) nSalTotAPag = nDiasTrab * nSalDia CalcularCuotaDelIMSS(nImss, nSalTotAPag) CalcularCuotaDeApoyoALaEducacion(nApEduc, nSalTotAPag) CalcularCuotaDelInfonavit(nInfonavit, nSalTotAPag) CalcularISPT(nIspt, nSalTotAPag) CalcularSAR(nSar, nSalTotAPag) CalcularElBonoPorAntiguedad(nAntig, nBono, nSalTotAPag)

Realizó: Ing. Domingo Olivares Barrios

Pág. 86

END SUB 'Módulo de NIVEL 2. SUB CalcularSAR (nSar AS SINGLE, nSalTotAPag AS SINGLE) nSar = nSalTotAPag * .03 END SUB 'Módulo de NIVEL 2. SUB CapturaDeDatos (nAntig AS SINGLE, nSalDia AS SINGLE, nDiasTrab AS SINGLE) LOCATE LOCATE LOCATE LOCATE LOCATE END SUB 'Módulo de NIVEL 2. SUB DesplegarMensajesDeSolicitudDeDatos CLS 'Borra la LOCATE 3, 10: LOCATE 4, 10: LOCATE 5, 10: LOCATE 6, 10: LOCATE 7, 10: LOCATE 8, 10: END SUB 'Módulo de NIVEL 1. 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) CLS 'Borra la pantalla. 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 pantalla. PRINT "Dame los siguientes datos:" PRINT "Nombre:"; PRINT "Puesto:"; PRINT "Antigüedad:"; PRINT "Salario Diario:"; PRINT "Días Trabajados:"; 4, 5, 6, 7, 8, 30: 30: 30: 30: 30: INPUT INPUT INPUT INPUT INPUT cNombre$ cPuesto$ nAntig nSalDia nDiasTrab

'Módulo de NIVEL 1. SUB SolicitarDatosDelEmpleado (nAntig AS SINGLE, nSalDia AS SINGLE, nDiasTrab AS SINGLE) CALL DesplegarMensajesDeSolicitudDeDatos CALL CapturaDeDatos(nAntig, nSalDia, nDiasTrab) END SUB

Realizó: Ing. Domingo Olivares Barrios

Pág. 87

‘ Fin del código del programa.

Realizó: Ing. Domingo Olivares Barrios

Pág. 88

Lenguaje Pascal.
PROGRAM Ejemplo; (* Programa EJEMPASC.PAS *) (* Método de Diseño Modular. *) (* Especificación del dispositivo o unidad de salida *) USES CRT; (* Declarando variables. *) VAR nAntig, nSalDia, nDiasTrab, nSalTotAPag, nImss, nApEduc, nInfonavit, nSar, nIspt, nBono, nTotNetoAPagar : REAL; (* Módulo de NIVEL 2 *) PROCEDURE DesplegarMensajesDeSolicitudDeDatos; BEGIN CLRSCR; (* Borra la pantalla *) GOTOXY(10,3); GOTOXY(10,4); GOTOXY(10,5); GOTOXY(10,6); GOTOXY(10,7); GOTOXY(10,8); END; (* Módulo de NIVEL 2 *) PROCEDURE CapturaDeDatos(VAR nAntig, nSalDia, nDiasTrab: REAL); VAR cNombre cPuesto BEGIN GOTOXY(30,4); GOTOXY(30,5); GOTOXY(30,6); GOTOXY(30,7); GOTOXY(30,8); END; (* Módulo de NIVEL 2 *) READLN(cNombre); READLN(cPuesto); READLN(nAntig); READLN(nSalDia); READLN(nDiasTrab); : STRING[10]; : STRING[10]; WRITELN('Dame los siguientes datos:'); WRITE('Nombre: '); WRITE('Puesto: '); WRITE('Antigüedad: '); WRITE('Salario Diario: '); WRITE('Días Trabajados: ');

Realizó: Ing. Domingo Olivares Barrios

Pág. 89

PROCEDURE CalcularCuotaDelIMSS(VAR nImss: REAL; nSalTotAPag: REAL); BEGIN nImss := nSalTotAPag * 0.03; END; (* Módulo de NIVEL 2 *) PROCEDURE CalcularCuotaDeApoyoALaEducacion(VAR nApEduc: REAL; nSalTotAPag: REAL); BEGIN nApEduc := nSalTotAPag * 0.01; END; (* Módulo de NIVEL 2 *) PROCEDURE CalcularCuotaDelInfonavit(VAR nInfonavit: REAL; nSalTotAPag: REAL); BEGIN nInfonavit := nSalTotAPag * 0.05; END; (* Módulo de NIVEL 2 *) PROCEDURE CalcularISPT(VAR nIspt: REAL; nSalTotAPag: REAL); BEGIN nIspt := nSalTotAPag * 0.02; END; (* Módulo de NIVEL 2 *) PROCEDURE CalcularSAR(VAR nSar: REAL; nSalTotAPag: REAL); BEGIN nSar := nSalTotAPag * 0.03; END; (* Módulo de NIVEL 2 *) PROCEDURE CalcularElBonoPorAntiguedad(VAR nBono: REAL; nAntig, nSalTotAPag: REAL); BEGIN IF nAntig >= 5 THEN nBono := nSalTotAPag * 0.05 ELSE nBono = 0; END; (* Módulo de NIVEL 1 *) PROCEDURE SolicitarDatosDelEmpleado(VAR nAntig, SalDia, DiasTrab: REAL);

Realizó: Ing. Domingo Olivares Barrios

Pág. 90

BEGIN DesplegarMensajesDeSolicitudDeDatos; CapturaDeDatos(nAntig, nSalDia, nDiasTrab); END; (* Módulo de NIVEL 1 *) PROCEDURE CalcularSalarioTotalAPagar(VAR nSalTotAPag: REAL; nDiasTrab, nSalDia: REAL); BEGIN nSalTotAPag := nDiasTrab * nSalDia; END; (* Módulo de NIVEL 1 *) 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; (* Módulo de NIVEL 1 *) PROCEDURE CalcularElTotalNetoAPagar(VAR nTotNetoAPagar: REAL; nSalTotAPag, nBono: REAL); BEGIN nTotNetoAPagar := nSalTotAPag + nBono; END; (* Módulo de NIVEL 1 *) 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;

Realizó: Ing. Domingo Olivares Barrios

Pág. 91

(* INICIA PROGRAMA PRINCIPAL NIVEL 0 *) BEGIN (* Inicio *) (* Inicializar nAntig nSalDia nDiasTrab nSalTotAPag nImss nApEduc nInfonavit nSar nIspt nBono nTotNetoAPagar Variables *) := 0; := 0; := 0; := 0; := 0; := 0; := 0; := 0; := 0; := 0; := 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 *)

Realizó: Ing. Domingo Olivares Barrios

Pág. 92

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 CLS //Borra la pantalla. 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) RETURN * Módulos de NIVEL 1. FUNCTION SolicitarDatosDelEmpleado(nAntig, nSalDia, nDiasTrab) DesplegarMensajesDeSolicitudDeDatos() CapturaDeDatos(@nAntig, @nSalDia, @nDiasTrab) RETURN FUNCTION CalcularSalarioTotalAPagar(nSalTotAPag, nDiasTrab, nSalDia) nSalTotAPag := nDiasTrab * nSalDia RETURN FUNCTION CalcularCuotasPorPagar(nImss, nApEduc, nInfonavit, nIspt, nSar,; nBono, nSalTotAPag, nAntig) CuotaDelIMSS(@nImss, nSalTotAPag) CuotaDeApoyoALaEducacion(@nApEduc, nSalTotAPag) CuotaDelInfonavit(@nInfonavit, nSalTotAPag)

Realizó: Ing. Domingo Olivares Barrios

Pág. 93

CuotaISPT(@nIspt, nSalTotAPag) CuotaSAR(@nSar, nSalTotAPag) CuotaBonoPorAntiguedad(@nBono, nAntig, nSalTotAPag) RETURN FUNCTION CalcularElTotalNetoAPagar(nTotNetoAPagar, nSalTotAPag, nBono) nTotNetoAPagar := nSalTotAPag + nBono RETURN FUNCTION MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono,; nSalTotAPag, nTotNetoAPagar) @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ RETURN * Módulos de NIVEL 2. FUNCTION DesplegarMensajesDeSolicitudDeDatos; @ @ @ @ @ @ RETURN FUNCTION CapturaDeDatos(nAntig, nSalDia, nDiasTrab); LOCAL cNombre := ' @ 2,30 @ 3,30 @ 4,30 @ 5,30 @ 6,30 READ RETURN FUNCTION CuotaDelIMSS(nImss, nSalTotAPag) GET GET GET GET GET ', cPuesto := ' ' 1,10 2,10 3,10 4,10 5,10 6,10 SAY SAY SAY SAY SAY SAY "Dame los siguientes datos:" "Nombre:" "Puesto:" "Antigüedad:" "Salario Diario:" "Días Trabajados:" 8,10 SAY "Resultados:" 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,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

cNombre cPuesto nAntig PICT '9999999.99' nSalDia PICT '9999999.99' nDiasTrab PICT '9999999.99'

Realizó: Ing. Domingo Olivares Barrios

Pág. 94

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 nBono := nSalTotAPag * 0.05 ELSE nBono := 0 END IF RETURN

* Fin del código del programa.

Realizó: Ing. Domingo Olivares Barrios

Pág. 95

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

/* Módulos de NIVEL 1 */ /* Declaración de funciones */ 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 nDiasTrab = 0; float nSalTotAPag = 0; float nImss = 0; float nApEduc = 0; float nInfonavit = 0; float nIspt = 0; float nSar = 0; float nBono = 0; float nTotNetoAPagar = 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); MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono, nSalTotAPag, nTotNetoAPagar); } /* Módulos de NIVEL 2 */ void DesplegarMensajesDeSolicitudDeDatos(void) { gotoxy(10,1); printf("Dame los siguientes datos:");

Realizó: Ing. Domingo Olivares Barrios

Pág. 96

gotoxy(10,2); gotoxy(10,3); gotoxy(10,4); gotoxy(10,5); gotoxy(10,6); }

printf("Nombre:"); printf("Puesto:"); printf("Antigüedad:"); printf("Salario Diario:"); 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); gotoxy(30,3); gotoxy(30,4); gotoxy(30,5); gotoxy(30,6); scanf("%s",&cNombre); scanf("%s",&cPuesto); scanf("%f",&nA); scanf("%f",&nS); 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)

Realizó: Ing. Domingo Olivares Barrios

Pág. 97

*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 referencia o variable */ *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) { /* Declaración de variables auxiliares para el paso de parámetros */ 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); /* Asignación de valores a las variables que son par metro por referencia o variable */ *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,

Realizó: Ing. Domingo Olivares Barrios

Pág. 98

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

/* Fin del código del programa*/

Realizó: Ing. Domingo Olivares Barrios

Pág. 99

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. 8.1. - Fases de resolución de problemas. 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

Realizó: Ing. Domingo Olivares Barrios

Pág. 100

-

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 101

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 Nombre Puesto Antigüedad Salario Diario Días Trabajados TIPO Alfanumérico (Carácter) Alfanumérico (Carácter) Numérico Numérico Numérico

DESCRIPCIÓN DE LA SALIDA. Los datos de salida son: DATO Cuota del IMSS Cuota del ISPT Cuota del SAR Cuota de Apoyo a la Educación Cuota del Infonavit Bono por antigüedad Salario Total a Pagar Total Neto a Pagar TIPO Numérico Numérico Numérico Numérico Numérico Numérico Numérico Numérico

Realizó: Ing. Domingo Olivares Barrios

Pág. 102

ESTRUCTURAS DE DATOS. VARIABLE Nombre Puesto Antigüedad Sueldo Diario Días trabajados Cuota del IMSS Cuota del ISPT Cuota del SAR Cuota de Apoyo a la Educación Cuota del Infonavit Bono por antigüedad Salario Total a Pagar Total Neto a Pagar IDENTIFICADOR (NOMBRE DE VARIABLE) cNombre cPuesto nAntig nSalDia nDiasTrab nImss nIspt nSar nApEduc nInfonavit nBono nSalTotAPag nTotNetoAPagar TIPO Alfanumérico (Carácter) Alfanumérico (Carácter) Numérico Numérico Numérico Numérico Numérico Numérico Numérico Numérico Numérico Numérico 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 103

3. Escribir los módulos restantes. NIVEL 1 a. b. c. d. e. Inicializar variables. Solicitar datos del empleado. Calcular el salario total a pagar. Calcular las cuotas por pagar. 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 Realizó: Ing. Domingo Olivares Barrios Pág. 104

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 Realizó: Ing. Domingo Olivares Barrios Pág. 105

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 '************************************************************************** 60 CLS 'Borra la pantalla. 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 ' 180 NSALTOTAPAG = NDIASTRAB * NSALDIA 190 ' 200 'Calcular Cuotas Por Pagar. 210 ' 220 NIMSS = NSALTOTAPAG * .03 230 NAPEDUC = NSALTOTAPAG * .01 240 NINFONAVIT = NSALTOTAPAG * .05 250 NISPT = NSALTOTAPAG * .02 260 NSAR = NSALTOTAPAG * .03 270 IF NANTIG >= 5 THEN NBONO = NSALTOTAPAG * .05 280 '

Realizó: Ing. Domingo Olivares Barrios

Pág. 106

290 300 310 320 330 340 350 360 370 380 390 400 410 420 430 440 450 460 470 480 490 500 510 520 530 540 550 560 570 580 590 600 610 620 630 640 650 660 670 680 690 700 710 720 730 740 750 760 770 780 790 800 810

'Calcular el Total Neto a Pagar. ' NTOTNETOAPAGAR = NSALTOTAPAG + NBONO ' GOSUB 450 'Llamada a la subrutina: Mostrar Resultados. ' END 'FIN DEL PROGRAMA PRINCIPAL. ' ' '************************************************************************** 'SUBRUTINA: Solicitar Datos del Empleado. ' GOSUB 600 'Llamada a la subrutina: Desplegar Mensajes de Solicitud de Datos. GOSUB 710 'Llamada a la subrutina: Captura de Datos. RETURN '************************************************************************** 'SUBRUTINA: Mostrar Resultados. ' CLS 'Borra la pantalla. 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 RETURN ' '************************************************************************** 'SUBRUTINA: Desplegar Mensajes de Solicitud de Datos. ' CLS 'Borra la pantalla. 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 "Dias Trabajados:"; RETURN '************************************************************************** 'SUBRUTINA: Captura de Datos. ' 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 RETURN '************************************************************************** 'FIN DEL CODIGO DEL PROGRAMA. '**************************************************************************

Realizó: Ing. Domingo Olivares Barrios

Pág. 107

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, nTotNetoAPagar AS SINGLE) 'PROGRAMA Ejemplo. 'Inicio del programa. CLS 'Borra la pantalla. 'Inicializar 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 'Llamadas a los procedimientos CALL SolicitarDatosDelEmpleado(nAntig, nSalDia, nDiasTrab) 'Calcular Salario Total a Pagar nSalTotAPag = nDiasTrab * nSalDia 'Calcular Cuotas Por Pagar nImss = nSalTotAPag * .03 nApEduc = nSalTotAPag * .01 nInfonavit = nSalTotAPag * .05 nIspt = nSalTotAPag * .02 nSar = nSalTotAPag * .03 IF nAntig >= 5 THEN nBono = nSalTotAPag * .05 ELSE nBono = 0 END IF ' 'Calcular El Total Neto a Pagar ' nTotNetoAPagar = nSalTotAPag + nBono CALL MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono, nSalTotAPag, nTotNetoAPagar) END 'Fin del programa. SUB CapturaDeDatos (nAntig AS SINGLE, nSalDia AS SINGLE, nDiasTrab AS SINGLE) LOCATE LOCATE LOCATE LOCATE LOCATE 4, 5, 6, 7, 8, 30: 30: 30: 30: 30: INPUT INPUT INPUT INPUT INPUT cNombre$ cPuesto$ nAntig nSalDia nDiasTrab

Realizó: Ing. Domingo Olivares Barrios

Pág. 108

END SUB SUB DesplegarMensajesDeSolicitudDeDatos CLS 'Borra la LOCATE 3, 10: LOCATE 4, 10: LOCATE 5, 10: LOCATE 6, 10: LOCATE 7, 10: LOCATE 8, 10: 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, nTotNetoAPagar AS SINGLE) CLS 'Borra la pantalla. 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 pantalla. PRINT "Dame los siguientes datos:" PRINT "Nombre:"; PRINT "Puesto:"; PRINT "Antigüedad:"; PRINT "Salario Diario:"; PRINT "Días Trabajados:";

‘Fin del código del programa.

Realizó: Ing. Domingo Olivares Barrios

Pág. 109

Lenguaje Pascal.
PROGRAM Ejemplo; (* Programa EJEDPASC.PAS *) (* Método de Diseño Descendente. *) (* Especificación del dispositivo o unidad de salida *) USES CRT; (* Declarando variables. *) VAR nAntig, nSalDia, nDiasTrab, nSalTotAPag, nImss, nApEduc, nInfonavit, nSar, nIspt, nBono, nTotNetoAPagar : REAL; PROCEDURE DesplegarMensajesDeSolicitudDeDatos; BEGIN CLRSCR; (* Borra la pantalla *) GOTOXY(10,3); GOTOXY(10,4); GOTOXY(10,5); GOTOXY(10,6); GOTOXY(10,7); GOTOXY(10,8); END; PROCEDURE CapturaDeDatos(VAR nAntig, nSalDia, nDiasTrab: REAL); VAR cNombre cPuesto BEGIN GOTOXY(30,4); GOTOXY(30,5); GOTOXY(30,6); GOTOXY(30,7); GOTOXY(30,8); END; PROCEDURE SolicitarDatosDelEmpleado(VAR nAntig, SalDia, DiasTrab: REAL); BEGIN DesplegarMensajesDeSolicitudDeDatos; CapturaDeDatos(nAntig, nSalDia, nDiasTrab); READLN(cNombre); READLN(cPuesto); READLN(nAntig); READLN(nSalDia); READLN(nDiasTrab); : STRING[10]; : STRING[10]; WRITELN('Dame los siguientes datos:'); WRITE('Nombre: '); WRITE('Puesto: '); WRITE('Antigüedad: '); WRITE('Salario Diario: '); WRITE('Días Trabajados: ');

Realizó: Ing. Domingo Olivares Barrios

Pág. 110

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 nAntig nSalDia nDiasTrab nSalTotAPag nImss nApEduc nInfonavit nSar nIspt nBono nTotNetoAPagar Variables *) := 0; := 0; := 0; := 0; := 0; := 0; := 0; := 0; := 0; := 0; := 0;

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 THEN nBono := nSalTotAPag * 0.05 ELSE nBono := 0; (* Calcular El Total Neto a Pagar *) nTotNetoAPagar := nSalTotAPag + nBono; MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono, nSalTotAPag, nTotNetoAPagar); END. (* FIN DEL PROGRAMA *)

Lenguaje Clipper.

Realizó: Ing. Domingo Olivares Barrios

Pág. 111

* 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 CLS //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 END IF * Calcular El Total Neto a Pagar nTotNetoAPagar := nSalTotAPag + nBono MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono,; nSalTotAPag, nTotNetoAPagar) RETURN

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 112

RETURN FUNCTION MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono,; nSalTotAPag, nTotNetoAPagar) @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ RETURN FUNCTION DesplegarMensajesDeSolicitudDeDatos; @ @ @ @ @ @ RETURN FUNCTION CapturaDeDatos(nAntig, nSalDia, nDiasTrab); LOCAL cNombre := ' @ 2,30 @ 3,30 @ 4,30 @ 5,30 @ 6,30 READ RETURN * Fin del código del programa. GET GET GET GET GET ', cPuesto := ' ' 1,10 2,10 3,10 4,10 5,10 6,10 SAY SAY SAY SAY SAY SAY "Dame los siguientes datos:" "Nombre:" "Puesto:" "Antigüedad:" "Salario Diario:" "Días Trabajados:" 8,10 SAY "Resultados:" 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,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

cNombre cPuesto nAntig PICT '9999999.99' nSalDia PICT '9999999.99' nDiasTrab PICT '9999999.99'

Realizó: Ing. Domingo Olivares Barrios

Pág. 113

Lenguaje C++.
/* Programa EJEMDC.C */ /* Método de Diseño Descendente. */ #include <stdio.h> /* Declaración de funciones */ 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 nDiasTrab = 0; float nSalTotAPag = 0; float nImss = 0; float nApEduc = 0; float nInfonavit = 0; float nIspt = 0; float nSar = 0; float nBono = 0; float nTotNetoAPagar = 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; MostrarResultados(nImss, nIspt, nSar, nApEduc, nInfonavit, nBono, nSalTotAPag, nTotNetoAPagar); } /* Fin del programa principal */

Realizó: Ing. Domingo Olivares Barrios

Pág. 114

/* Inician las funciones */ void DesplegarMensajesDeSolicitudDeDatos(void) { gotoxy(10,1); gotoxy(10,2); gotoxy(10,3); gotoxy(10,4); gotoxy(10,5); gotoxy(10,6); } 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); gotoxy(30,3); gotoxy(30,4); gotoxy(30,5); gotoxy(30,6); scanf("%s",&cNombre); scanf("%s",&cPuesto); scanf("%f",&nA); scanf("%f",&nS); scanf("%f",&nD); printf("Dame los siguientes datos:"); printf("Nombre:"); printf("Puesto:"); printf("Antigüedad:"); printf("Salario Diario:"); printf("Días Trabajados:");

/* Asignación de valores a las variables que son par metro por referencia o variable */ *nAnt = nA; *nSal = nS; *nDias = nD; } 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 referencia o variable */ *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); gotoxy(10,11); gotoxy(10,12); gotoxy(10,13); gotoxy(10,14); gotoxy(10,15); gotoxy(10,16); printf("Salario Total a Pagar: %f",nSalTotAPag); printf("Cuota IMSS: %f",nImss); printf("Cuota de Apoyo a la Educación: %f",nApEduc); printf("Cuota del Infonavit: %f",nInfonavit); printf("Cuota del SAR: %f",nSar); printf("Bono por antigüedad: %f",nBono); printf("Total Neto a Pagar: %f",nTotNetoAPagar);

Realizó: Ing. Domingo Olivares Barrios

Pág. 115

}

/* Fin del código del programa*/

Realizó: Ing. Domingo Olivares Barrios

Pág. 116

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 117

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 Control 990701001 990602058 990503047 980402109

Nombre Francisco Fernández Jiménez Julieta Campos Enríquez Armando Gutiérrez Armas Edith Mijangos Lagos

Grupo 990701 990602 990503 980402

Turno Vespertino Matutino Matutino Vespertino

Grado 1 2 4 3

Registro

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.

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.

16

Realizó: Ing. Domingo Olivares Barrios

Pág. 118

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 119

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 Vista 3

Usuario A Usuario B

Usuario X Vista 4 Usuario Y Usuario Z

Vista 5

Realizó: Ing. Domingo Olivares Barrios

Pág. 120

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 121

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 sublenguaje 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 en un SGBD
Sublenguaje de datos

Lenguaje para la definición 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 Realizó: Ing. Domingo Olivares Barrios Pág. 122

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: Empleados: COD COD_E NOMBRE 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 02 03 LUISA ALCAZAR JOSE PRIETO 04 DEP

CADIZ CORDOBA LOGROÑO MADRID

ANTONIO GARCIA

ADMINISTRACION

05 06

LUCIA CASTILLO ROBERTO GIMBERNAT 07 MARIA CIFUENTES

MURCIA BARCELONA GUADALAJARA

DEP 3 08

VENTAS

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 Realizó: Ing. Domingo Olivares Barrios Pág. 123

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í Realizó: Ing. Domingo Olivares Barrios Pág. 124

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 125

EMPLEADOS COD_EMP NOM_EMP 01 JUAN BERMUDEZ 02 LUISA ALCAZAR 03 JOSE PRIETO 04 ANTONIO GARCIA 05 LUCIA CASTILLO 06 ROBERTO GIMBERNAT 07 MARIA CIFUENTES 08 LUIS GARCIA

CIUDAD CADIZ CORDOBA LOGROÑO MADRID MURCIA BARCELONA GUADALAJA RA MADRID

COD DEP1 DEP1 DEP1 DEP1 DEP2 DEP2 DEP2 DEP2

DEPARTAMENTOS COD NOMBRE DEP1 PRODUCCION DEP2 ADMINISTRACION DEP2 VENTAS NOMINAS MES 11 11 11 11 12 07

COD_EMP 01 02 03 04 07 08

IMPORTE 1,500.00 1,875.00 3,623.00 5,213.00 8,253.00 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

Realizó: Ing. Domingo Olivares Barrios

Pág. 126

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 NOMBRE

COD_EMP NOM_EMP CIUDAD COD

MES COD_EMP IMPORTE

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 Pág. 127

Realizó: Ing. Domingo Olivares Barrios

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. Realizó: Ing. Domingo Olivares Barrios Pág. 128

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 1:N N:M Para un elemento de una entidad existe 1 elemento de la otra y viceversa. Para un elemento de una entidad existen N elementos de la otra. 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 129

EMPLEADO

Pertenece_a

DEPARTAMENTO

CODIGO NOMBRE DOMICILIO F. INGRESO

CODIGO NOMBRE UBICACION

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).

Realizó: Ing. Domingo Olivares Barrios

Pág. 130

Pues bien, usando estas reglas podemos tener ya la composición de las tablas con las que nuestra aplicación debe trabajar: EMPLEADO
CODIGO EMPLEADO NOMBRE EMPLEADO CODIGO DEPARTAMENTO

DEPARTAMENTO
CODIGO DEPARTAMENTO NOMBRE 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 131

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. 2ª. FORMA NORMAL (2NF). 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 132

3ª. FORMA NORMAL (3NF). 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 NOMBRE ESTADO Código del proveedor. Nombre del proveedor. Coeficiente numérico que se asigna a cada proveedor en función del volumen de negocio con éste. Ciudad donde vive el proveedor. Pedido que se hace al proveedor (sólo uno por cada pieza). Pieza que se le pide al proveedor. Nombre de la pieza. Color de la pieza. Peso de la pieza. Ciudad a la que se envía la pieza.

CIUDAD PEDIDO PIEZA NOMPIEZ COLOR PESO CIUPED

17

Los archivos del ejemplo están tomados de la obra citada: C.J. Date. Op. Cit.

Realizó: Ing. Domingo Olivares Barrios

Pág. 133

El formato de la ficha que recoge esta información sería el siguiente: Código: Proveedor: Estado: Ciudad: Pedidos: Pieza P1 P2 P3 . . . Cantidad 300 150 200 . . . Nombre N1 N2 N3 . . . Color Rojo Verde Azul . . . Peso 12 20 14 . . . Ciudad París Madrid Madrid . . . S1 Francisco Hernández y Fernández 20 Londres

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 134

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:

Realizó: Ing. Domingo Olivares Barrios

Pág. 135

EMPLEADOS No. COD_EMP NOM_EMP Reg. 1 01 JUAN BERMUDEZ 2 02 LUISA ALCAZAR 3 03 JOSE PRIETO 4 04 ANTONIO GARCIA 5 05 LUCIA CASTILLO 6 06 ROBERTO GIMBERNAT 7 07 MARIA CIFUENTES 8 08 LUIS GARCIA INDICE POR NOMBRE NOM_EMP ANTONIO GARCIA JOSE PRIETO JUAN BERMUDEZ LUCIA CASTILLO LUISA ALCAZAR LUIS GARCIA MARIA CIFUENTES ROBERTO GIMBERNAT

CIUDAD CADIZ CORDOBA LOGROÑO MADRID MURCIA BARCELONA GUADALAJA RA MADRID

COD DEP1 DEP1 DEP1 DEP1 DEP2 DEP2 DEP2 DEP2

No. Reg. 4 3 1 5 2 8 7 6

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 Realizó: Ing. Domingo Olivares Barrios Pág. 136

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. Pág. 137

Realizó: Ing. Domingo Olivares Barrios

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 Visual Basic Visual C++ Delphi Visual Fox Pro Lenguaje Origen Basic C++ Pascal 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
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.
18

Realizó: Ing. Domingo Olivares Barrios

Pág. 138

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:

Realizó: Ing. Domingo Olivares Barrios

Pág. 139

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 140

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 Campo Tipo Ancho Decimales

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”.

Realizó: Ing. Domingo Olivares Barrios

Pág. 141

9.4.1. – Gestión de archivos secuenciales. DISEÑO “NO ESTRUCTURADO” Diagrama de flujo:
INICIO

ALTAS. C

Inicializar Variables

¿ Clave del Registro = Clave Capturada?

NO

SI
¿Existe el archivo?

Ir al siguiente registro

NO

Creación del archivo.

“La Clave YA existe.”

A

SI
Abrir archivo

E A
Ir al Principio del archivo

D

B
Solicitar clave y datos. ‘¿Más datos? (S/N)’

Clave y datos

Respuesta

D
Respuesta=‘S’ ¿Fin de Archivo?

SI

B

SI

Grabar el nuevo registro

NO
Cerrar archivo

NO E
Leer registro.

FIN

C

Realizó: Ing. Domingo Olivares Barrios

Pág. 142

DISEÑO “ESTRUCTURADO”
INICIO

C

Inicializar Variables

¿ Clave del Registro = Clave Capturada?

NO

SI
¿ No Existe el archivo?

SI
Encontrado = Verdadero

Ir al siguiente registro

A

NO
Abrir archivo

Creación del archivo.

D
“La Clave YA existe.”

Respuesta=‘S’ Encontrado=Falso

A F NO
Cerrar archivo

B
Respuesta=‘S’

SI
FIN Solicitar clave y datos.

Clave y datos

D
¿No es Fin de Archivo?

F NO
¿No fue encontrado?

E NO
Ir al Principio del archivo ‘¿Más datos? (S/N)’

SI SI
Leer registro. Grabar el nuevo registro Respuesta

C E Realizó: Ing. Domingo Olivares Barrios B Pág. 143

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 144

DISEÑO “ESTRUCTURADO”. Algoritmo: ALTAS. 1. Inicializar Variables. 2. Sí No Existe el archivo entonces a. Crear el archivo. 3. Fin del Sí 4. Abrir el archivo. 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 145

DISEÑO “NO ESTRUCTURADO” Diagrama de flujo:
INICIO

BAJAS. (Baja Lógica). C

Inicializar Variables

Datos del registro. ‘¿Dar de baja el registro?’

¿Existe el archivo?

NO

Creación del archivo.

Respuesta

SI
Respuesta=‘S’ Abrir archivo

NO

E

‘El archivo esta vacio’

SI
Marcar y grabar el registro

B
Solicitar la clave.

A E

Clave.

Ir al Principio del archivo

D
¿Fin de Archivo?

SI

‘El registro NO existe’

‘¿Otra Baja? (S/N)’

NO
Respuesta Leer registro.

E
Respuesta=‘S’

SI

B

¿ Clave del registro = Clave Capturada?

NO
Ir al siguiente registro

NO
Cerrar archivo

SI C

A D
FIN

Realizó: Ing. Domingo Olivares Barrios

Pág. 146

DISEÑO “ESTRUCTURADO” Diagrama de flujo:
INICIO

BAJAS. (Baja Lógica). C

Inicializar Variables

¿ Clave del registro = Clave Capturada?

NO
Ir al siguiente registro

¿Existe el archivo?

NO

Creación del archivo.

SI
Encontrado = Verdadero

SI
Abrir archivo ‘El archivo esta vacio’ Datos del registro. ‘¿Dar de baja el registro?’

D

Respuesta = ‘S’ Encontrado = Falso

A A
Respuesta Cerrar archivo

B
Respuesta=‘S’

NO

Respuesta=‘S’

NO

E

SI
FIN Solicitar la clave.

SI
Marcar y grabar el registro

E
Clave. ¿No fue encontrado? ¿No es Fin de Archivo?

D NO

NO F

G

E

SI
‘El registro NO existe’ ‘¿Otra Baja? (S/N)’

SI
Leer registro.

G
Ir al Principio del archivo

Respuesta

Encontrado = Falso

C Realizó: Ing. Domingo Olivares Barrios F B Pág. 147

DISEÑO “NO ESTRUCTURADO” Algoritmo: BAJAS. (Baja Lógica). 1. Inicializar Variables. 2. Sí Existe el archivo entonces Ir al paso 3. Sino - Crear el archivo - Desplegar ‘El archivo esta vacío’ - Ir al paso 20. 3. Abrir el archivo. 4. Solicitar la Clave. 5. Introducir la Clave. 6. Sí es Fin de Archivo entonces - Desplegar ‘El registro NO existe’ - Ir al paso 14. 7. Leer registro 8. Sí Clave del Registro = Clave Capturada entonces Ir al paso 11. 9. Ir al siguiente registro. 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. 15. Ir al principio del archivo. 16. Desplegar ‘¿ Otra Baja ?’ 17. Introducir Respuesta 18. Sí Respuesta=’S’ entonces Ir al paso 4. 19. Cerrar el archivo. 20. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 148

DISEÑO “ESTRUCTURADO” Algoritmo: BAJAS. (Baja Lógica). i. Inicializar Variables. ii. Sí Existe el archivo entonces 1. Abrir el archivo. 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. 2. Desplegar los datos del registro. 3. Desplegar ‘¿Dar de baja el registro?’ 4. Introducir Respuesta 5. Sí Respuesta = ‘S’ entonces 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 149

DISEÑO “NO ESTRUCTURADO” Diagrama de flujo:
INICIO

CONSULTAS. C

Inicializar Variables

¿ Clave del registro = Clave Capturada?

NO

SI
¿Existe el archivo?

Ir al siguiente registro

NO

Creación del archivo.

Datos del registro.

SI
Abrir archivo ‘El archivo esta vacio’

E
Ir al Principio del archivo

D

B
Solicitar la clave.

A

‘¿Otra consulta? (S/N)’

Capturar la Clave.

Respuesta

D
Respuesta=‘S’ ¿Fin de Archivo?

SI

B

SI

‘El registro NO existe’

NO
Cerrar archivo

NO Leer registro. E A

FIN

C

Realizó: Ing. Domingo Olivares Barrios

Pág. 150

DISEÑO “ESTRUCTURADO” Diagrama de flujo: INICIO CONSULTAS. C

Inicializar Variables

¿ Clave del registro = Clave Capturada?

NO
Ir al siguiente registro

¿Existe el archivo?

NO

Creación del archivo.

SI
Encontrado = Verdadero

SI
Abrir archivo ‘El archivo esta vacio’ Datos del registro.

D

E
Respuesta = ‘S’ Encontrado = Falso

A A NO

B
Respuesta=‘S’

¿No fue encontrado?

NO

F

Cerrar archivo

SI
‘El registro

SI
FIN Solicitar la clave.

NO existe’

F
Ir al Principio del archivo

Clave.

D
¿No es Fin de Archivo?

‘¿Otra Consulta? (S/N)’

NO

E
Respuesta

SI
Leer registro. Encontrado = Falso

B C Realizó: Ing. Domingo Olivares Barrios Pág. 151

DISEÑO “NO ESTRUCTURADO” Algoritmo: CONSULTAS. 1. Inicializar Variables. 2. Sí Existe el archivo entonces Ir al paso 3. Sino - Crear el archivo - Desplegar ‘El archivo esta vacío’ - Ir al paso 17. 3. Abrir el archivo. 4. Solicitar la Clave. 5. Introducir la Clave. 6. Sí es Fin de Archivo entonces - Desplegar ‘El registro NO existe’ - Ir al paso 12. 7. Leer registro 8. Sí Clave del Registro = Clave Capturada entonces Ir al paso 11. 9. Ir al siguiente registro. 10. Ir al paso 6. 11. Desplegar los datos del registro. 12. Ir al principio del archivo. 13. Desplegar ‘¿ Más datos ?’ 14. Introducir Respuesta 15. Sí Respuesta=’S’ entonces Ir al paso 4. 16. Cerrar el archivo. 17. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 152

DISEÑO “ESTRUCTURADO” Algoritmo: CONSULTAS. 1. Inicializar Variables. 2. Sí Existe el archivo entonces 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 2. Sí Clave del Registro = Clave Capturada entonces a. Encontrado = Verdadero. b. Desplegar los datos del registro. c. Salir (del Mientras No sea Fin de Archivo) 3. Fin del Sí. 4. Ir al siguiente registro. 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í. 5. Cerrar el archivo. 6. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 153

DISEÑO “NO ESTRUCTURADO”

Diagrama de flujo:
INICIO

CAMBIOS. (Modificaciones). C
Datos del registro. ‘¿Modificar el registro?’

Inicializar Variables

¿Existe el archivo?

NO

Creación del archivo.

Respuesta

Respuesta=‘S’

NO

E

SI
Abrir archivo ‘El archivo esta vacio’

SI
Solicitar los datos del registro.

B
Solicitar la clave.

A
Datos del registro.

Capturar la Clave.

Grabar el registro

E
Ir al Principio del archivo

D
¿Fin de Archivo?

SI

‘El registro NO existe’ ‘¿Más datos? (S/N)’

NO
Leer registro.

E
Respuesta

¿ Clave del registro = Clave Capturada?

NO
Ir al siguiente registro

Respuesta=‘S’

SI

B

NO
Cerrar archivo

SI C

A D
FIN

Realizó: Ing. Domingo Olivares Barrios

Pág. 154

DISEÑO “ ESTRUCTURADO”

Diagrama de flujo:
INICIO

CAMBIOS. (Modificaciones). C

Inicializar Variables

¿ Clave del registro = Clave Capturada?

NO
Ir al siguiente registro

¿Existe el archivo?

NO

Creación del archivo.

SI
Encontrado = Verdadero

SI
Abrir archivo ‘El archivo esta vacio’ Datos del registro. ‘¿Modificar el registro?’

D

Respuesta = ‘S’ Encontrado = Falso

B
Respuesta=‘S’

A A NO
Cerrar archivo Respuesta

Respuesta=‘S’

NO

E

SI
FIN Solicitar la clave.

SI
Solicitar datos del registro.

Clave.

D E
¿No es Fin de Archivo?

Grabar el registro

NO

E

¿No fue encontrado?

NO G

SI
Leer registro.

SI F

C Realizó: Ing. Domingo Olivares Barrios Pág. 155

F

‘El registro NO existe’

G
Ir al Principio del archivo

‘¿Otra modificación? (S/N)’

Respuesta

Encontrado = Falso

B

Realizó: Ing. Domingo Olivares Barrios

Pág. 156

DISEÑO “NO ESTRUCTURADO” Algoritmo: CAMBIOS. (Modificaciones). 1. Inicializar Variables. 2. Sí Existe el archivo entonces Ir al paso 3. Sino - Crear el archivo - Desplegar ‘El archivo esta vacío’ - Ir al paso 20. 3. Abrir el archivo. 4. Solicitar la Clave. 5. Introducir la Clave. 6. Sí es Fin de Archivo entonces - Desplegar ‘El registro NO existe’ - Ir al paso 14. 7. Leer registro 8. Sí Clave del Registro = Clave Capturada entonces Ir al paso 11. 9. Ir al siguiente registro. 10. Ir al paso 6. 11. Desplegar los datos del Registro. 12. Desplegar ‘¿Modificar el registro?’ 13. Introducir Respuesta. 14. Sí Respuesta = ‘S’ entonces - Desplegar Solicitud de datos del registro. - Introducir los datos del registro. - Grabar el registro. 15. Ir al principio del archivo. 16. Desplegar ‘¿ Más datos ?’ 17. Introducir Respuesta 18. Sí Respuesta=’S’ entonces Ir al paso 4. 19. Cerrar el archivo. 20. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 157

DISEÑO “ESTRUCTURADO” Algoritmo: CAMBIOS. (Modificaciones). 1. Inicializar Variables. 2. Sí Existe el archivo entonces 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 2. Sí Clave del Registro = Clave Capturada entonces 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í. 4. Ir al siguiente registro. 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í. 5. Cerrar el archivo. 6. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 158

9.4.2. – Gestión de archivos directos. DISEÑO “NO ESTRUCTURADO” Diagrama de flujo: ALTAS. INICIO C

Inicializar Variables

‘El registro YA esta ocupado.’

E NO
Creación del archivo. ‘¿Más datos? (S/N)’

¿Existe el archivo?

A

SI
Abrir archivo

Respuesta

A
Respuesta=‘S’

SI

B
Solicitar el Número de registro y datos.

B

NO
Cerrar archivo

Número de registro y datos

FIN

D
Ir al registro y leerlo.

¿Registro vacío?

SI

Grabar los datos en el registro

NO C E

Realizó: Ing. Domingo Olivares Barrios

Pág. 159

DISEÑO “ESTRUCTURADO” Diagrama de flujo: ALTAS. INICIO

Inicializar Variables

¿Existe el archivo?

NO

Creación del archivo.

A

SI
Abrir archivo

A

B Respuesta = ‘S’ C NO

Respuesta=‘S’

Cerrar archivo ¿Registro vacío? FIN

SI

SI
Solicitar el Número de registro y datos.

Grabar los datos en el registro

NO
‘El registro YA esta ocupado.’

E

Número de registro y datos

E
‘¿Más datos? (S/N)’

D
Ir al registro y leerlo.

Respuesta

C

B

Realizó: Ing. Domingo Olivares Barrios

Pág. 160

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 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.’ 10. Desplegar ‘¿ Más datos ?’ 11. Introducir Respuesta 12. Sí Respuesta=’S’ entonces Ir al paso 4. 13. Cerrar el archivo. 14. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 161

DISEÑO “ESTRUCTURADO” Algoritmo: ALTAS. 1. Inicializar Variables. 2. Sí Existe el archivo entonces a. Abrir el archivo. b. Respuesta = ‘S’ 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. 3. Cerrar el archivo. 4. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 162

DISEÑO “NO ESTRUCTURADO” Diagrama de flujo: BAJAS. (Baja Lógica).
INICIO

A

Inicializar Variables

Marcar y grabar el registro

B NO
Creación del archivo. ‘¿Más datos? (S/N)’

¿Existe el archivo?

SI
Abrir archivo

Respuesta

‘El archivo

Respuesta=‘S’

SI C

C
Solicitar el Número de registro.

NO
Cerrar archivo

Número de registro

FIN

Ir al registro y leerlo.

Datos del registro. ‘¿Dar de baja el registro?’

Respuesta

Respuesta=‘S’

SI

A

NO B Realizó: Ing. Domingo Olivares Barrios Pág. 163

DISEÑO “ESTRUCTURADO” Diagrama de flujo: BAJAS. (Baja Lógica).
INICIO

A

Inicializar Variables

Datos del registro. ‘¿Dar de baja el registro?’

¿Existe el archivo?

NO

Creación del archivo.

Respuesta

SI
Abrir archivo

NO
Respuesta=‘S’

B

‘El archivo esta vacío.’

SI
Marcar y grabar el registro

Respuesta = ‘S’ B C
Respuesta=‘S’

‘¿Más datos? (S/N)’

NO
Cerrar archivo Respuesta

SI
Solicitar el Número de registro. FIN

C

Número de registro

Ir al registro y leerlo.

A

Realizó: Ing. Domingo Olivares Barrios

Pág. 164

DISEÑO “NO ESTRUCTURADO” Algoritmo: BAJAS. (Baja Lógica). 1. Inicializar Variables. 2. Sí Existe el archivo entonces Ir al paso 3. Sino - Crear el archivo. - Desplegar ‘El archivo esta vacío’. - Ir al paso 14. 3. Abrir el archivo. 4. Desplegar Solicitud del Número de registro. 5. Introducir Número de registro. 6. Ir al registro y leerlo. 7. Desplegar los datos del registro. 8. Desplegar ‘¿Dar de baja el registro?’ 9. Introducir Respuesta. 10. Sí Respuesta = ‘S’ entonces - Marcar y grabar los datos en el registro. 11. Desplegar ‘¿ Más datos ?’ 12. Introducir Respuesta 13. Sí Respuesta=’S’ entonces Ir al paso 4. 14. Cerrar el archivo. 15. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 165

DISEÑO “ESTRUCTURADO” Algoritmo: BAJAS. (Baja Lógica). 1. Inicializar Variables. 2. Sí Existe el archivo entonces a. Abrir el archivo. b. Respuesta = ‘S’ c. Mientras Respuesta = ‘S’ i. Desplegar Solicitud del Número de registro. ii. Introducir Número de registro. iii. Ir al registro y leerlo. 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 a. Crear el archivo. b. Desplegar ‘El archivo esta vacío’. 4. Fin del Sí 5. Cerrar el archivo. 6. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 166

DISEÑO “NO ESTRUCTURADO” Diagrama de flujo: CONSULTAS.
INICIO

Inicializar Variables

A

¿Existe el archivo?

NO

Creación del archivo.

‘¿Mas datos? (S/N)’

SI
Abrir archivo ‘El archivo esta vacío.’

Respuesta

Respuesta=‘S’

SI B

B
Solicitar el Número de registro.

NO
Cerrar archivo

Número de registro

FIN

Ir al registro y leerlo.

Datos del registro.

A

Realizó: Ing. Domingo Olivares Barrios

Pág. 167

DISEÑO “ESTRUCTURADO” Diagrama de flujo: CONSULTAS.
INICIO

Inicializar Variables

A

¿Existe el archivo?

NO

Creación del archivo.

Ir al registro y leerlo.

SI
Abrir archivo ‘El archivo esta vacío.’ Datos del registro.

Respuesta = ‘S’ B
Respuesta=‘S’

‘¿Mas datos? (S/N)’

NO
Cerrar archivo

Respuesta

SI
Solicitar el Número de registro.

B

FIN

Número de registro

A

Realizó: Ing. Domingo Olivares Barrios

Pág. 168

DISEÑO “NO ESTRUCTURADO” Algoritmo: CONSULTAS. 1. Inicializar Variables. 2. Sí Existe el archivo entonces Ir al paso 3. Sino - Crear el archivo. - Desplegar ‘El archivo esta vacío’. - Ir al paso 12. 3. Abrir el archivo. 4. Desplegar Solicitud del Número de registro. 5. Introducir Número de registro. 6. Ir al registro y leerlo. 7. Desplegar los datos del registro. 8. Desplegar ‘¿ Más datos ?’ 9. Introducir Respuesta 10. Sí Respuesta=’S’ entonces Ir al paso 4. 11. Cerrar el archivo. 12. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 169

DISEÑO “ESTRUCTURADO” Algoritmo: CONSULTAS. 1. Inicializar Variables. 2. Sí Existe el archivo entonces a. Abrir el archivo. b. Respuesta = ‘S’ c. Mientras Respuesta = ‘S’ i. Desplegar Solicitud del Número de registro. ii. Introducir Número de registro. iii. Ir al registro y leerlo. iv. Desplegar los datos del registro. v. Desplegar ‘¿ Más datos ?’ vi. Introducir Respuesta d. Fin del Mientras. 3. Sino a. Crear el archivo. b. Desplegar ‘El archivo esta vacío’. 4. Fin del Sí. 5. Cerrar el archivo. 6. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 170

DISEÑO “NO ESTRUCTURADO” Diagrama de flujo: MODIFICACIONES (Cambios).
INICIO

Inicializar Variables

A

¿Existe el archivo?

NO

Creación del archivo.

Solicitar los datos del registro.

SI
Abrir archivo ‘El archivo esta vacío.’

Datos del registro.

Grabar el registro

B
Solicitar el Número de registro. ‘¿Mas datos? (S/N)’

Número de registro

Respuesta

Ir al registro y leerlo.

Respuesta=‘S’

SI B

NO
Datos del registro. ‘¿Modificar el registro?’ Cerrar archivo

FIN Respuesta

NO
Respuesta=‘S’

E

SI A

Realizó: Ing. Domingo Olivares Barrios

Pág. 171

DISEÑO “ESTRUCTURADO” Diagrama de flujo: MODIFICACIONES (Cambios).
INICIO

Inicializar Variables

A

¿Existe el archivo?

NO

Creación del archivo.

Datos del registro. ‘¿Modificar el registro?’

SI
Abrir archivo ‘El archivo esta vacío.’

Respuesta

NO
Respuesta=‘S’

E

Respuesta = ‘S’

SI
Solicitar los datos del registro.

Respuesta=‘S’

NO

SI B
Solicitar el Número de registro. Cerrar archivo Datos del registro.

FIN

Grabar el registro

E
Número de registro ‘¿Mas datos? (S/N)’

Ir al registro y leerlo.

Respuesta

B A

Realizó: Ing. Domingo Olivares Barrios

Pág. 172

DISEÑO “ESTRUCTURADO” Algoritmo: MODIFICACIONES (Cambios). 1. Inicializar variables. 2. Sí existe el archivo entonces a. Abrir el archivo b. Respuesta = ‘S’ c. Mientras Respuesta = ‘S’ 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

Realizó: Ing. Domingo Olivares Barrios

Pág. 173

9.4.3. – Gestión de archivos indexados. DISEÑO “NO ESTRUCTURADO” Diagrama de flujo:
INICIO

ALTAS. C

Inicializar Variables

¿Más datos? (S/N)

¿Existe el archivo?

NO

Creación del archivo.

Respuesta

SI A SI A
Abrir archivo Cerrar archivo Respuesta=‘S

B

NO

B
Solicitar clave y datos. FIN

Capturar clave y datos

Buscar el registro por la clave.

¿ Se encontro el registro ?

SI

“El registro YA existe.”

NO C
Grabar el registro

C

Realizó: Ing. Domingo Olivares Barrios

Pág. 174

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. 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. 9. Desplegar ‘¿ Más datos ?’ 10. Introducir Respuesta 11. Sí Respuesta=’S’ entonces Ir al paso 4. 12. Cerrar el archivo. 13. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 175

DISEÑO “ESTRUCTURADO” Diagrama de flujo: INICIO ALTAS. C

Inicializar variables

Buscar el registro por la clave

¿Existe el archivo?

NO

Creación del archivo

¿Se encontro el registro?

SI “El registro YA existe.”

SI A A

NO Grabar el registro

Abrir archivo “¿Más datos? (S/N)”

Respuesta = “S” B

Respuesta ¿Respuesta = “S”? NO Cerrar archivo B SI FIN Solicitar clave y datos

Capturar clave y datos

C

Realizó: Ing. Domingo Olivares Barrios

Pág. 176

DISEÑO “ESTRUCTURADO” Algoritmo: ALTAS. 1. Inicializar variables 2. Sí NO existe el archivo entonces a. Creación del archivo 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)” viii. Introducir Respuesta d. Fin del Mientras e. Cerrar archivo 4. Fin del Sí

Realizó: Ing. Domingo Olivares Barrios

Pág. 177

DISEÑO “NO ESTRUCTURADO” Diagrama de flujo: BAJAS.
INICIO

Inicializar Variables

A

¿ Existe el archivo ?

NO

Creación del archivo.

Datos del Registro.

SI
Abrir archivo “El archivo esta vacio.”

¿Dar de baja el registro?

D
Solicitar clave.

Respuesta

B

SI
Respuesta=‘S

NO
Capturar clave

C
¿Buscar otro registro?

Marcar o eliminar el registro.

Buscar el registro por la clave.

C

¿ Se encontro el registro ?

SI

Respuesta

A SI
Respuesta=‘S

D

NO NO
“El registro NO existe.” Cerrar archivo

C

B
FIN

Realizó: Ing. Domingo Olivares Barrios

Pág. 178

DISEÑO “NO ESTRUCTURADO” Algoritmo: BAJAS. 1. Inicializar Variables. 2. Sí Existe el archivo entonces Ir al paso 3. Sino - Crear el archivo. - Desplegar “El archivo esta vacío”. - Ir al paso 15. 3. Abrir el archivo. 4. Solicitar clave. 5. Introducir clave. 6. Buscar el registro por la clave. 7. Sí Se encontró el registro entonces Desplegar Datos del Registro. Sino - Desplegar ‘El registro NO existe’. - Ir al Paso 11 8. Desplegar ‘¿Dar de baja el registro?’ 9. Introducir Respuesta 10. Sí Respuesta=’S’ entonces Marcar o eliminar el registro 11. Desplegar ‘¿ Buscar otro registro ?’ 12. Introducir Respuesta 13. Sí Respuesta=’S’ entonces Ir al paso 4. 14. Cerrar el archivo. 15. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 179

DISEÑO “ESTRUCTURADO” Diagrama de flujo: BAJAS. INICIO A

Inicializar Variables

Datos del registro. “¿Dar de baja el registro? (S/N)” NO Creación del archivo “El archivo está vacio.” ¿Respuesta = “S”? NO B “¿Buscar otro registro?” SI

¿Existe el archivo?

Respuesta

SI Abrir archivo

D Respuesta = “S” C

Marcar o eliminar el registro

¿Respuesta = “S”? SI
Solicitar clave.

NO D

Cerrar archivo

B

Respuesta FIN C

Capturar clave

Buscar el registro por la clave.

¿Se encontro el registro?

NO

“El registro NO existe.”

SI A B

Realizó: Ing. Domingo Olivares Barrios

Pág. 180

DISEÑO “ESTRUCTURADO” Algoritmo: BAJAS. 1. Inicializar variables 2. Sí NO existe el archivo entonces a. Creación del archivo b. Desplegar “El archivo está vacío” 3. sino a. Abrir archivo b. Respuesta = “S” c. Mientras 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)” 3. Introducir Respuesta 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

Realizó: Ing. Domingo Olivares Barrios

Pág. 181

DISEÑO “NO ESTRUCTURADO” Diagrama de flujo: CONSULTAS.
INICIO

Inicializar Variables

¿ Existe el archivo ?

NO

Creación del archivo.

A

SI
Abrir archivo

C
Solicitar clave.

“El archivo esta vacio.”

Respuesta

SI
Respuesta=‘S

C

NO
Clave Cerrar archivo

Buscar el registro por la clave.

FIN

¿ Se encontro el registro ?

NO

“El registro NO existe.”

SI Datos del Registro. B ¿Buscar otro registro? A Realizó: Ing. Domingo Olivares Barrios Pág. 182 B

DISEÑO “NO ESTRUCTURADO” Algoritmo: CONSULTAS. 1. Inicializar Variables. 2. Sí Existe el archivo entonces Ir al paso 3. Sino - Crear el archivo. - Desplegar “El archivo esta vacío” - Ir al paso 12. 3. Abrir el archivo. 4. Solicitar clave. 5. Introducir clave. 6. Buscar el registro por la clave. 7. Sí Se encontró el registro entonces Desplegar Datos del Registro. Sino - Desplegar ‘El registro NO existe’. 8. Desplegar ‘¿ Buscar otro registro ?’ 9. Introducir Respuesta 10. Sí Respuesta=’S’ entonces Ir al paso 4. 11. Cerrar el archivo. 12. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 183

DISEÑO “ESTRUCTURADO” Diagrama de flujo: CONSULTAS. INICIO B

Inicializar Variables C NO

Datos del registro

¿Existe el archivo? SI Abrir archivo

Creación del archivo

“¿Otra consulta? (S/N)”

Respuesta “El archivo está vacío” D

Respuesta = “S” D NO
¿Respuesta = “S”?

A

Cerrar archivo A FIN

SI Solicitar clave

Clave
Buscar el registro por la clave

NO
¿Se encontro el registro?

“El registro NO existe.”

SI B C

Realizó: Ing. Domingo Olivares Barrios

Pág. 184

DISEÑO “ESTRUCTURADO” Algoritmo: CONSULTAS. 1. Inicializar variables 2. Sí NO existe el archivo entonces a. Creación del archivo b. Desplegar “El archivo está vacío.” 3. sino a. Abrir archivo b. Respuesta = “S” c. Mientras Respuesta = “S” i. Desplegar Solicitar Clave ii. Introducir Clave iii. Buscar el registro por la Clave iv. Sí se encontro el registro entonces 1. Desplegar datos del registro v. Sino 1. Desplegar “El registro NO existe.” vi. Fin del Sí vii. Desplegar “¿Otra consulta? (S/N)” viii. Introducir Respuesta d. Fin del Mientras e. Cerrar Archivo 4. Fin del Sí 5. FIN

Realizó: Ing. Domingo Olivares Barrios

Pág. 185

DISEÑO “NO ESTRUCTURADO” Diagrama de flujo: MODIFICACIONES (Cambios).
INICIO

A SI
Respuesta=‘S Solicitar datos del registro.

Inicializar Variables

¿ Existe el archivo ?

NO

Creación del archivo.

C

NO
¿Buscar otro registro? Capturar datos del registro.

SI
Abrir archivo

B
Solicitar clave.

“El archivo esta vacio.”

Respuesta

Grabar el registro

SI
Respuesta=‘S

B

C

NO
Capturar clave Cerrar archivo

Buscar el registro por la clave.

FIN

¿ Se encontro el registro ?

NO

“El registro NO existe.”

SI
Datos del Registro.

C

¿Modificar registro?

Respuesta

A

Realizó: Ing. Domingo Olivares Barrios

Pág. 186

DISEÑO “NO ESTRUCTURADO” Algoritmo: MODIFICACIONES (Cambios). 1. Inicializar Variables. 2. Sí Existe el archivo entonces Ir al paso 3. Sino - Crear el archivo. - Desplegar “El archivo esta vacío” - Ir al paso 16. 3. Abrir el archivo. 4. Solicitar clave. 5. Introducir clave. 6. Buscar el registro por la clave. 7. Sí Se encontró el registro entonces Desplegar Datos del Registro. Sino - Desplegar ‘El registro NO existe’. - Ir al paso 11. 8. Desplegar ‘¿Modificar registro? 9. Introducir Respuesta 10. Sí Respuesta =’S’ entonces - Desplegar solicitud de datos del registro. - Capturar datos del registro. - Grabar el registro. 11. Desplegar ‘¿ Buscar otro registro ?’ 12. Introducir Respuesta 13. Sí Respuesta=’S’ entonces 14. Ir al paso 4. 15. Cerrar el archivo. 16. FIN.

Realizó: Ing. Domingo Olivares Barrios

Pág. 187

DISEÑO “ESTRUCTURADO” Diagrama de flujo: MODIFICACIONES (Cambios). INICIO A

Inicializar Variables

Datos del registro. “¿Modificar el registro? (S/N)” NO Creación del archivo “El archivo está vacio.” ¿Respuesta = “S”? NO B “¿Buscar otro registro?” SI

¿Existe el archivo?

Respuesta

SI Abrir archivo

D Respuesta = “S” C

Solicitar los datos del registro

¿Respuesta = “S”? SI
Solicitar clave.

NO D

Cerrar archivo

Datos del registro

Respuesta
Grabar el registro

FIN C B

Capturar clave

Buscar el registro por la clave.

NO
¿Se encontro el registro?

“El registro NO existe.”

SI A B

Realizó: Ing. Domingo Olivares Barrios

Pág. 188

DISEÑO “ESTRUCTURADO” Algoritmo: MODIFICACIONES (Cambios). 1. Inicializar variables 2. Sí NO existe el archivo entonces a. Creación del archivo b. Desplegar “El archivo está vacío” 3. Sino a. Abrir archivo b. Respuesta = “S” c. Mientras Respuesta = “S” i. Desplegar Solicitar Clave ii. Introducir Clave iii. Buscar el registro por la Clave iv. Sí se encontro el registro entonces 1. Desplegar Datos del registro 2. Desplegar “¿Modificar el registro? (S/N)” 3. Introducir Respuesta 4. Sí Respuesta = “S” entonces 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)” viii. Introducir Respuesta d. Fin del Mientras e. Cerrar archivo 4. Fin del Sí 5. FIN

Realizó: Ing. Domingo Olivares Barrios

Pág. 189

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. 1. Inicializar variables. 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)?” d. Introducir Respuesta e. Sí Respuesta = “S” entonces Realizó: Ing. Domingo Olivares Barrios Pág. 190

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 191

Algoritmo: BAJAS. 1. Inicializar variables. 2. Sí NO Existe el archivo A entonces a. Creación del archivo A b. Creación del archivo B c. Desplegar “Los archivos estan vacíos.” 3. Sino a. Sí NO Existe el archivo B entonces 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 ii. Introducir 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)? d. Introducir Respuesta e. Sí Respuesta = “S” entonces 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.” Realizó: Ing. Domingo Olivares Barrios Pág. 192

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 iv. Sí se encontro el registro entonces 1. Desplegar “¿Dar de baja el registro secundario? (S/N)” 2. Introducir Respuesta 3. Sí Respuesta = “S” entonces 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)” viii. Introducir Respuesta 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 193

Algoritmo: CONSULTAS 1. Inicializar variables. 2. Sí NO Existe el Archivo A entonces a. Creación del archivo A b. Creación del archivo B c. Desplegar “Los archivos están vacíos.” 3. Sino a. Sí NO Existe el archivo B entonces 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 ii. Introducir 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” 7. Fin del Sí viii. Fin del Sí f. Fin del Mientras 4. Fin del Sí 5. Cerrar archivos 6. FIN

Realizó: Ing. Domingo Olivares Barrios

Pág. 194

Algoritmo: MODIFICACIONES. 1. Inicializar variables 2. Sí NO existe el archivo A entonces a. Creación del archivo A b. Creación del archivo B c. Desplegar “Los archivos están vacíos.” 3. Sino a. Sí NO existe el archivo B entonces 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 ii. Introducir Clave iii. Sí Clave = “SALIR” entonces 1. Vuelta al Mientras iv. Fin del Sí v. Buscar el registro por la Claven en el archivo A vi. Si NO se encontró el registro entonces 1. Desplegar “El registro NO existe.” vii. Sino 1. Desplegar los datos del archivo A 2. Desplegar “¿Modificar datos del registro principal? (S/N)” 3. Introducir Respuesta 4. Sí Respuesta = “S” entonces 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)” iv. Introducir Respuesta 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í 6. Encontrado = FALSO 7. Ir al principio del archivo B 8. 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 iii. Desplegar “¿Modificar datos del registro secundario encontrado? (S/N)” Realizó: Ing. Domingo Olivares Barrios Pág. 195

iv. Introducir Respuesta 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)” d. Introducir Respuesta e. Sí Respuesta = “S” entonces 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 10. Sí Encontrado = FALSO entonces 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

Realizó: Ing. Domingo Olivares Barrios

Pág. 196

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 DO WHILE .T. mCodEmpl = CodEmpl mNombreEmpl = NombreEmpl mCodSet = CodSet mCodCar = CodCar mFechaEnt = FechaEnt mSalario = Salario mGremio = Gremio ** ORDENES ENDDO *** Usar o abrir el archivo Func. *** Bucle infinito: Hacer mientras VERDADERO. *** \ *** \ *** \ *** Asignación de valores de campos a variables. *** / *** / *** / *** Lógica de gestión del archivo. *** 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 FOR I = 1 TO FCOUNT() *** Usar o abrir el archivo Func. /*** 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 Pág. 197

Realizó: Ing. Domingo Olivares Barrios

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 198

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 reescribir 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 * 1 CodEmpl Caracter 3 * 2 NombreEmpl Caracter 30 * 3 CodSet Caracter 1 * 4 CodCar Caracter 1 * 5 FechaEnt Fecha 8 * 6 Salario Num‚rico 9 * 7 Gremio L¢gico 1 * 8 Coment Memo 10 ** Total 64 PROCEDURE Principal() CLEAR ALL IF FILE("IndCodC.NTX") USE Personal INDEX IndCodC ELSE USE Personal

Dec

2

Indice N N N N N N N N

// Inicio del programa
// Elimina variables en memoria y cierra cualquier archivo abierto

// S¡ existe el archivo IndCodC.NTX // Abre el archivo Personal y su ¡ndice IndCodC // Sino // Abre el archivo Personal

Realizó: Ing. Domingo Olivares Barrios

Pág. 199

INDEX ON CodEmpl TO IndCodC // ENDIF // WHILE .T. // Clear // mCodEmpl = SPACE(3) // mNombrEmpl = SPACE(30) // mCodSet = SPACE(1) // mCodCar = SPACE(1) // mFechaEnt = CTOD("") // mSalario = 0 // mGremio = .F. // @ 1,1 SAY "Código Empleado o; <INTRO> para salir"; GET mCodEmpl // READ // IF VAL(mCodEmpl) = 0 // EXIT // ENDIF // SEEK mCodEmpl // IF FOUND() // @ 23,01 SAY "Código ya; encontrado...; Teclee <INTRO>" // INKEY(0) // LOOP // ENDIF // @ 3,1 SAY "Nombre:"; GET mNombrEmpl // @ 4,1 SAY Sector:" GET mCodSet // @ 5,1 SAY "Cargo:" GET mCodCar // @ 6,1 SAY "Fecha:"; // GET mFechaEnt @ 7,1 SAY "Salario:"; GET mSalario // READ // Ok = "" @ 8,1 SAY "¨Datos Ok? (S/N)"; // GET Ok PICTURE "!"; // VALID Ok $ "SN" // READ // IF Ok = "S" // APPEND BLANK // REPLACE CodEmpl WITH mCodEmpl,; // NombrEmpl WITH mNombrEmpl,; // CodSet WITH mCodSet,; // CodCar WITH mCodCar,; // FechaEnt WITH mFechaEnt,; // Salario WITH mSalario,; // Gremio WITH mGremio // ENIF // END // CLOSE ALL // RETURN

Indexa seg£n CodEmpl Al archivo IndCodC Fin del S¡ Mientras VERDADERO (Bucle Infinito) Limpia (la pantalla) MCodEmpl = 3 espacios (en blanco) MNombrEmpl = 30 espacios (en blanco) MCodSet = 1 espacio (en blanco) MCodCar = 1 espacio (en blanco) MFechaEnt = Convierte Cadena Nula a Fecha Nula MSalario = 0 MGremio = Falso

Despliega mensaje e Introduce el valor de MCodEmpl

Lee los datos del teclado despu‚s del <INTRO> S¡ el valor num‚rico de MCodEmpl = 0 Salir del Mientras Fin del S¡ Busca (el valor de) MCodEmpl (en el archivo) S¡ se encontr¢ Despliega mensaje
Introducir Tecla (Detiene el programa hasta que se presiona una tecla.

Lazo (Vuelta al Mientras) Fin del S¡
Despliega mensaje e Introduce el valor de MNombrEmpl

Despliega mensaje e Introduce el valor de MCodSet Despliega mensaje e Introduce el valor de MCodCar
Despliega mensaje e Introduce el valor de MFechaEnt
Despliega mensaje e Introduce el valor de MSalario

Lee los datos del teclado despu‚s del <INTRO> Despliega mensaje
Introduce el valor de Ok y lo convierte a mayusculas

Restringe los valores de Ok a "S" o "N" Lee los datos del teclado despu‚s del <INTRO> S¡ Ok = "S" Agrega un registro vac¡o al archivo
Reemplaza (Graba el valor del campo) CodEmpl con (el valor de la variable) MCodEmpl

(Reemplaza) NombreEmpl (Reemplaza) CodSet (Reemplaza) CodCar (Reemplaza) FechaEnt (Reemplaza) Salario (Reemplaza) Gremio Fin del S¡ Fin del Mientras Cierra todos los archivos

con con con con con con

mNombrEmpl mCodSet mCodCar mFechaEnt mSalario mGremio

// 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 * 1 CodEmpl Caracter 3 * 2 NombreEmpl Caracter 30 * 3 CodSet Caracter 1 * 4 CodCar Caracter 1 * 5 FechaEnt Fecha 8 * 6 Salario Num‚rico 9 * 7 Gremio L¢gico 1 * 8 Coment Memo 10

Dec

2

Indice N N N N N N N N

Realizó: Ing. Domingo Olivares Barrios

Pág. 200

** Total PROCEDURE Principal() CLEAR ALL IF FILE("IndCodC.NTX") USE Personal INDEX IndCodC ELSE USE Personal INDEX ON CodEmpl TO IndCodC ENDIF WHILE .T. Clear DO Inic_Var @ 1,1 SAY "Código Empleado o; <INTRO> para salir"; GET mCodEmpl READ IF VAL(mCodEmpl) = 0 EXIT ENDIF SEEK mCodEmpl IF FOUND() @ 23,01 SAY "Código ya; encontrado...; Teclee <INTRO>" INKEY(0) LOOP ENDIF @ 3,1 SAY "Nombre:"; GET mNombrEmpl @ 4,1 SAY Sector:" GET mCodSet @ 5,1 SAY "Cargo:" GET mCodCar @ 6,1 SAY "Fecha:"; GET mFechaEnt @ 7,1 SAY "Salario:"; GET mSalario READ Ok = "" @ 8,1 SAY "¨Datos Ok? (S/N)"; GET Ok PICTURE "!"; VALID Ok $ "SN" READ IF Ok = "S" APPEND BLANK DO Repl_Var ENIF END CLOSE ALL RETURN PROCEDURE Inic_Var()

64 // Inicio del programa
// Elimina variables en memoria y cierra cualquier archivo abierto

// // // // // // // //
//

S¡ existe el archivo IndCodC.NTX Abre el archivo Personal y su ¡ndice IndCodC Sino Abre el archivo Personal Indexa seg£n CodEmpl Al archivo IndCodC Fin del S¡ Mientras VERDADERO (Bucle Infinito) Limpia (la pantalla)
Llama al procedimiento de inicializaci¢n de variables

//

Despliega mensaje e Introduce el valor de MCodEmpl

// // // // // // // // //
//

Lee los datos del teclado despu‚s del <INTRO> S¡ el valor num‚rico de MCodEmpl = 0 Salir del Mientras Fin del S¡ Busca (el valor de) MCodEmpl (en el archivo) S¡ se encontr¢ Despliega mensaje Lazo (Vuelta al Mientras) Fin del S¡
Despliega mensaje e Introduce el valor de MNombrEmpl

// Introducir Tecla (Detiene el programa hasta que se presiona una tecla.

//
// // //

Despliega mensaje e Introduce el valor de MCodSet
Despliega mensaje e Introduce el valor de MCodCar Despliega mensaje e Introduce el valor de MFechaEnt Despliega mensaje e Introduce el valor de MSalario

// //
//

Lee los datos del teclado despu‚s del <INTRO> Despliega mensaje
Introduce el valor de Ok y lo convierte a mayusculas

// // // //

Restringe los valores de Ok a "S" o "N" Lee los datos del teclado despu‚s del <INTRO> S¡ Ok = "S" Agrega un registro vac¡o al archivo

// Llamada al procedimiento para grabar o reemplazar los datos en el archivo

// Fin del S¡ // Fin del Mientras // Cierra todos los archivos // Fin del programa
// Inicio del procedimiento de inicializaci¢n de variables

FOR N = 1 TO FCOUNT() IF TYPE(FIELD(N)) <> "M" NombCampo = FIELDNAME(N) NombVar = "m"+NombCampo (concatena cadenas de caracteres) PUBLIC &NombVar DO CASE CASE TYPE(FIELD(I)) = "C" &NombVar = SPACE(LEN(&NombCampo)) CASE TYPE(FIELD(I)) = "N" &NombVar = 0 CASE TYPE(FIELD(I)) = "D" &NombVar = CTOD("") CASE TYPE(FIELD(I)) = "L" &NombVar = .F. ENDCASE ENDIF NEXT RETURN PROCEDURE Repl_Var()

// Para I = 1 hasta Cantidad de campos
// S¡ el tipo del campo N es diferente de "M" (Memo)

// //
//

NombCampo = Nombre del campo N NombVar = "m" + Valor de NombCampo
Declara como p£blico el nombre de variable contenido en la variable NombVar

//
// //

Hacer en Caso
Caso de que el tipo del campo = "C" (Caracter) Variable en NombVar = Cantidad de espacios de la longitud del campo en NombCampo

//

Caso de que el tipo del campo = "N" (Num‚rico)

//
// // //

Variable en NombVar = 0
Caso de que el tipo del campo = "D" (Fecha) Variable en NombVar = Nulo convertido a formato de fecha Caso de que el tipo del campo = "L" (L¢gico)

// Variable en NombVar = FALSO // Fin del Caso // Fin del S¡ // Siguiente (I)
// Retorna a la l¡nea siguiente de donde fue llamado el procedimiento
// Inicio del procedimiento de grabado o reemplazo de los valores de las variables al archivo

Realizó: Ing. Domingo Olivares Barrios

Pág. 201

FOR N = 1 TO FCOUNT() IF TYPE(FIELD(N)) <> "M" NombCampo = FIELDNAME(N) NombVar = "m"+NombCampo IF TYPE("&NombVar") <> "U" REPLACE &NombCampo WITH &NombVar ENDIF ENDIF NEXT RETURN

// Para I = 1 hasta Cantidad de campos
// S¡ el tipo del campo N es diferente de "M" (Memo)

//
// NombVar //

NombCampo = Nombre del campo N
= "m" + Valor de NombCampo (concatena cadenas de caracteres) Reemplaza el campo en NombCampo con la variable en NombVar

// S¡ el tipo de la variable en NombVar <> "U" (Undefined - Indefinido)

// Fin del S¡ // Fin del S¡ // Siguiente (I)
// 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.

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.

19

Realizó: Ing. Domingo Olivares Barrios

Pág. 202

<< 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 203

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 204

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 205

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 206

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). 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. 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.).

Método

Clase

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 Pág. 207

Realizó: Ing. Domingo Olivares Barrios

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 208

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 Realizó: Ing. Domingo Olivares Barrios Pág. 209

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 210

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
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.
22

Realizó: Ing. Domingo Olivares Barrios

Pág. 211

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 212

Evento de Ratón Click DoubleClick MouseMove MouseDown y MouseUp

Acción del usuario El usuario pulsa el botón izquierdo del ratón una sola vez. El usuario pulsa el botón izquierdo del ratón dos veces en una rápida sucesión. El usuario mueve el ratón mientas que éste está sobre un objeto. El usuario pulsa o libera un botón del ratón. Un programa en lenguaje visual puede 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 KeyPress Acción del usuario 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. 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.

KeyDown y KeyUp

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 213

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.

El lenguaje Visual Basic para Aplicaciones, normalmente es suministrado por Microsoft en sus productos, tales como MS Office.

24

Realizó: Ing. Domingo Olivares Barrios

Pág. 214

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 215

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 Realizó: Ing. Domingo Olivares Barrios Pág. 216

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 Negrita Cursiva Significado En los procedimientos, indica el texto que usted escribe Í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.

• •

Realizó: Ing. Domingo Olivares Barrios

Pág. 217

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 218

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 Natación Tenis Golf Esquí Damas chinas TEMPERATURA (GRADOS FAHRENHEIT) Temperatura > 85 70 < Temperatura <= 85 32 < Temperatura <= 70 10 < Temperatura <= 32 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) HASTA 15 LOS SIGUIENTES 60 MAS DE 75 CUOTA POR KW/H $ 1.50 $ 2.00 $ 2.50

14. Calcular la hora de llegada a su destino de los siguientes vuelos: VUELOS Veracruz – México Veracruz - Mérida Veracruz – Xalapa Veracruz – Monterrey Veracruz – Guadalajara Veracruz - Salina Cruz Veracruz – Montreal Veracruz – Tokio Veracruz – Washington TIEMPO 35 min. 1 hr. 20 min. 10 min. 2 hr. 18 min. 4 hr. 48 min. 2 hr. 25 min. 5 hr. 30 min. 8 hr. 40 min. 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 219

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 95 – 100 85 – 94 75 – 84 65 – 74 0 – 64 CALIFICACION A: EXCELENTE B: MUY BUENO C: BUENO D: REGULAR 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 0 – 13 14 – 18 19 – 25 26 – 35 36 – 55 56 en adelante GRUPO niños adolescentes jóvenes adultos jóvenes personas maduras 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 $ 100 $ 50 $ 20 $ 10 $5 MONEDAS $ 2.00 $ 1.00 $ 0.50 $ 0.20 $ 0.10

Realizó: Ing. Domingo Olivares Barrios

Pág. 220

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 PROMEDIO > $ 5,000 PROMEDIO > $ 10,000 COMISION: 3 % COMISION: 5 % 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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 221

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:

Realizó: Ing. Domingo Olivares Barrios

Pág. 222

• •

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 Realizó: Ing. Domingo Olivares Barrios Pág. 223

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 224

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 225

PRIMERA FORMA AREA PRINCIPAL PROGPRIN

SEGUNDA FORMA AREA PRINCIPAL PROGPRIN

AREA DE OVERLAY MODULO1 o MODULO2 o MODULO3

AREA DE OVERLAY MODULO1 o MODULO2

1

AREA DE OVERLAY 2 MODULO3

TERCERA FORMA AREA PRINCIPAL PROGPRIN

AREA DE OVERLAY 1 MODULO1 o MODULO2 o MODULO3 con SUBMOD1 o SUBMOD2

Realizó: Ing. Domingo Olivares Barrios

Pág. 226

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 227

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 228

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 18 Ptr2 ROJO Ptr3 TRUE Ptr3 TRUE Ptr2 ROJO Ptr1 18

Realizó: Ing. Domingo Olivares Barrios

Pág. 229

La siguiente figura muestra un puntero y la variable referenciada por él. La variable puntero Ptr1 contiene la dirección de Ptr1^ (la variable referenciada)

1432

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 Realizó: Ing. Domingo Olivares Barrios Pág. 230

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 Realizó: Ing. Domingo Olivares Barrios Pág. 231

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. (A) PtrA 15 PtrB 15 (B)

28

28

PtrA = PtrB evalúa a FALSO PtrA <> PtrB evalua a VERDADERO

Resultado de la asignación PtrA := PtrB 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, Ptr1, Ptr2 : Puntero; Vcb : Integer; (* El puntero a la primera componente de la lista *) (* El puntero a la última compnente de la lista *) (* El puntero a la componente más nueva *)

Realizó: Ing. Domingo Olivares Barrios

Pág. 232

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 233

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 234

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 235

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 236

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); VAR P: Puntero; BEGIN P := List; WHILE P <> NIL DO BEGIN WRITE(P^.Info); P := P^.Siguiente END END; (* List es el puntero externo *)

Este procedimiento funcionará incluso para una lista vacía (Lista = NIL).

Realizó: Ing. Domingo Olivares Barrios

Pág. 237

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 238

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

Realizó: Ing. Domingo Olivares Barrios

Pág. 239

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 Realizó: Ing. Domingo Olivares Barrios Pág. 240

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 241

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 242

PROCEDURE Sacar (VAR List: Puntero; VAR Elemento: INTEGER); (* Procedimiento para quitar el primer elemento de una lista*) VAR P: Puntero; BEGIN P := List; Elemento := List^.Info; List := List^.Siguiente; DISPOSE(P) END;

(* guarda List para devolverlo a la memoria disponible *)

(* envia P^para que pueda usarse de nuevo *)

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 243

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 P^ := Q^ asigna el valor del puntero Q al puntero P. asigna el valor de la variable referenciada por Q a la variable referenciada por P.

Realizó: Ing. Domingo Olivares Barrios

Pág. 244

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 245

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-InFirst-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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 246

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; Realizó: Ing. Domingo Olivares Barrios Pág. 247

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;

Realizó: Ing. Domingo Olivares Barrios

Pág. 248

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 249

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 250

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 251

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.

Realizó: Ing. Domingo Olivares Barrios

Pág. 252

Sign up to vote on this title
UsefulNot useful