Programación Estructurada

Capítulo 2

Programación Estructurada

2.1. Paradigmas de Programación

Las computadoras electrónicas digitales se inventaron en los años 1940s y, desde entonces, han evolucionado mejorando su desempeño. Conforme los problemas a resolver se han vuelto de mayor complejidad, y conforme las computadoras mejoran su rapidez de procesamiento y su capacidad de almacenamiento, los modelos o paradigmas de programación han evolucionado, pasando de la programación ad-hoc u orientada a procedimientos a la programación estructurada y, de esta, a la programación orientada a objetos. Al mismo tiempo, los lenguajes de programación han evolucionado para soportar dichos paradigmas de programación, pasando de la programación en lenguaje de máquina y en lenguaje ensamblador, a la programación en Fortran, en Pascal y en C (que soportan la programación estructurada), y de estos a la programación en Java y en C++ (que soportan la programación orientada a objetos), entre otros.

El modelo de programación estructurada consiste en idear un procedimiento top-down (de arriba abajo) modular; es decir, en producir una descripción funcional de un sistema, estructurado mediante módulos funcionales relacionados. El modelado del sistema (programa) se inicia con un módulo principal de entrada general y luego se refina mediante módulos funcionales de detalle hasta lograr una implementación que realiza la tarea requerida. Las estructuras de datos, así como las estructuras de los archivos, se proponen después y se evalúan de manera que soporten adecuadamente al modelo funcional.

La Programación Orientada a Objetos (POO), en cambio, es un modelo de programación que consiste en identificar primero los ítems de datos (objetos) que representan entidades en el dominio de la aplicación. Un objeto encapsula tanto los datos (atributos), como las operaciones sobre los datos, formando una entidad auto-contenida. La interacción con un objeto puede realizarse entonces invocando las operaciones propias de dicho objeto. Después, se especifican las relaciones entre objetos, es decir, el comportamiento del sistema en su conjunto, mediante la descripción del procedimiento correspondiente a la interacción (envío de mensajes) entre los ítems de datos u objetos.

2.2. El Método del Proyecto de Ingeniería y la Programación Estructurada

La programación estructurada se utiliza como técnica para  modelar sistemas de información (programas), durante el ciclo de anteproyecto, particularmente en la etapa de opciones de solución del problema, como se muestra esquemáticamente en la Figura 2-1.

[pic 1]

2.3. Fundamentos de la Programación Estructurada

Los fundamentos de la programación estructurada, son^[1]:

1. La Programación Descendente (top-down)
2. La Programación Modular
3. El Teorema de Estructura (de Control de Programa)

2.3.1. Programación Descendente (Top-Down)

Conforme al método de la programación descendente o top-down o “en-capas”, un programa entero (o sistema) se considera primero como un solo módulo independiente “invocable” (y, ciertamente, a menudo trabaja de ésta manera), es decir, cualquier programa de aplicación es “llamado” usualmente como subrutina por un sistema operativo, y retorna al sistema operativo cuando termina o se aborta, como se muestra en la Figura 2-2a. En la siguiente etapa del diseño, el programa del nivel original (nivel-0) se subdivide en módulos subordinados, de nivel-1; éstos se descomponen entonces en sub-módulos, de nivel-2; y el proceso de descomposición continúa hasta que el diseñador se queda con bloques de construcción que son suficientemente pequeños para codificarlos fácilmente, como se muestra en la Figura 2-2b.

[pic 2]

Inicio

Fin

Inicio

Fin

Para probar todo el programa, es importante estar en posibilidad de definir el comportamiento de los sub-módulos en el nivel k-ésimo, independientemente del contexto en el que ocurre. Esto nos permite probar si los módulos en el nivel (k+1)-ésimo son correctos, independientemente de su contexto en el paso k-ésimo. Esto nos sugiere que, a su vez, cada sub-módulo deberá diseñarse con un solo punto de entrada y uno solo de salida; a su vez, todo el programa puede describirse como un conjunto de módulos anidados, como se muestra en la Figura 2-2b, cada uno de los cuales tienen una entrada y una salida.

El programa de la Figura 2-2b trabaja entonces como sigue: primero, el programa inicia en el módulo principal, el cual es invocado desde el Sistema Operativo, ejecutándose secuencialmente las primeras instrucciones del módulo principal; segundo, en alguna parte del programa principal hay una instrucción que invoca o llama a un sub-módulo, el cual se ejecuta y al finalizar su ejecución retorna al módulo principal para continuar la secuencia principal de ejecución de instrucciones; y así, sucesivamente, hasta que el módulo principal retorna el control al sistema operativo.

2.3.2. Teorema de Estructura (de Control de Programa)

Antes de que la programación estructurada se inventara, los programadores utilizaban la denominada programación ad-hoc, es decir, los programas eran una solución estrechamente adaptada al problema y, por lo mismo, no se podía reutilizar en todo o sus partes para resolver otro problema.

El problema principal de la programación ad-hoc se presenta al utilizar extensivamente la estructura de control de programa go-to (Ir-a), como se ilustra en el programa ficticio de la Figura 2-3, el cual consta solamente de 10 instrucciones. La instrucción goto tiene como argumento una etiqueta que le dice a la máquina a qué instrucción saltar. Por la forma que toma el programa se le llama críticamente plato de espagueti.

[pic 3]

Aun cuando los programas resultado de la programación ad-hoc son eficaces, eficientes y rápidos, presentan los problemas siguientes:

• Difícultad para leerlos (entender su funcionamiento)
• Difícultad para probarlos y depurarlos (corregir errores)
• No se pueden usar para otro problema, ni en parte ni el todo
• Difícultad para el trabajo en grupo
• Baja productividad de los programadores

Durante la segunda parte de los años 1960’s y principios de los 1970’s, se desarrolló un movimiento en el ambiente computacional, con la participación destacada del entonces profesor Edsger W. Dijkstra, de la Universidad de Eindhoven, Holanda, que culminó con la creación de lo que se conoce como programación estructurada. En el año 1965 el profesor Dijkstra propuso en un congreso de expertos en computación, que el GO-TO podría ser eliminado de los lenguajes de programación.

Los objetivos de la programación han sido siempre mayor legibilidad y claridad del programa, mayor productividad del programador y menores problemas con las pruebas y la depuración. Los experimentos que entonces se practicaron con la programación estructurada resultaron altamente exitosos.

En un artículo clásico de Böhm y Jacopini^[2] se demuestra que un programa, por pequeño o grande, simple o complejo que sea, puede realizarse utilizando sólo tres estructuras de control básicas: secuencia, selección e iteración; asimismo, se demuestra que un programa  escrito con cualesquiera estructuras de control de programa, puede rescribirse utilizando solamente las tres estructuras básicas anteriores. El concepto presentado en el artículo de Böhm-Jacopini, a veces referido como el “teorema de estructura” es de importancia fundamental en la programación estructurada.

Conforme a Böhm y Jacopini, se necesitan solo tres bloques de construcción básicos para construir un programa:

1. Una caja o secuencia de cajas de proceso (Estructura de Secuencia)
2. Un mecanismo de decisión-binaria (Estructura de Selección)
3. Un mecanismo generalizado de iteración (Estructura de Iteración)

La caja de proceso, mostrada esquemáticamente en la Figura 2-4, conforme a los símbolos de los diagramas de flujo (ver Anexo B), puede pensarse como un solo enunciado computacional (o una instrucción en un lenguaje de programación) o como cualquier otra secuencia computacional con  una sola entrada y una sola salida.

[pic 4]

El mecanismo de decisión binaria se muestra esquemáticamente en la Figura 2-5a; por razones obvias, se le refiere como un mecanismo IF-THEN-ELSE (SI-ENTONCES-OTRO). Esta estructura de selección (if [condición] then [secuencia 1] else [secuencia 2]) opera de la manera siguiente: al entrar a la estructura se verifica si una condición se cumple o no; si la condición resulta ser cierta, entonces se ejecuta la Secuencia de Instrucciones 1; de otro modo (es decir, si la condición no se cumple) entonces se ejecuta la Secuencia de Instrucciones 2. De ahí su nombre de Estructura de Selección, pues se elige uno u otro camino, dependiendo de si la condición se cumple o no.

...