Su estudio puede dividirse en dos partes bien diferenciadas:

• Por una parte, el estudio conceptual se centra en ver qué se entiende por «programa estructurado» para estudiar con detalle sus características fundamentales.

• Por otra parte, dentro del enfoque práctico se presentará una metodología que permite construir programas estructurados paso a paso, detallando cada vez más las instrucciones que lo componen.

Las ideas que dieron lugar a la programación estructurada ya fueron expuestas por E. W. Dijkstra en 1965, aunque el fundamento teórico está basado en los trabajos de Böhm y Jacopini publicados en 1966.

La programación estructurada surge como respuesta a los problemas que aparecen cuando se programa sin una disciplina y unos límites que marquen la creación de programas claros y correctos.

Un programador disciplinado crearía programas fáciles de leer en los que resulta relativamente fácil demostrar su corrección.

Por ejemplo, el siguiente programa que calcula el producto de dos números resulta sencillo de entender:

Si un programa se escribe de cualquier manera, aunque funcione correctamente, puede resultar engorroso, críptico, ilegible, casi imposible de modificar y de comprobar su corrección.

Por tanto, lo que hay que hacer es impedir que el programador pueda escribir programas de cualquier manera, y para ello hay que restringir sus opciones a la hora de construir programas, de forma que el programa resultante sea fácil de leer, entender, mantener y verificar.

Ese programa, una vez terminado, debe estar construido combinando sólo unos pocos tipos de componentes y cumpliendo una serie de restricciones.

Este es un ejemplo de un programa que no es propio porque no tiene una única salida:

Agrupando las salidas se obtiene un programa propio:

Las estructuras de control son estructuras que permiten regular el flujo de control del programa, y constituyen los componentes constructivos básicos de cualquier programa estructurado.

Por tanto, un programa estructurado se crea combinando entre sí varias estructuras de control.

Sintácticamente, una estructura de control es una unidad compuesta por varias sentencias que actúan como una sola.

Toda estructura de control, por tanto, representa una sentencia compuesta que actúa como un miniprograma propio (y, por tanto, con un único punto de entrada y un único punto de salida) que puede formar parte de otro programa mayor.

Cada una de las sentencias que aparecen en una estructura de control (las indicadas anteriormente como A y B) pueden ser, a su vez, otras estructuras de control.

• Esto es así porque una estructura de control también es una sentencia (en este caso, sería una sentencia compuesta y no una sentencia simple).

• Por tanto, una estructura de control puede aparecer en cualquier lugar donde se espere una sentencia.

Resumiendo, en un programa podemos tener dos tipos de sentencias:

• Sentencias simples.

• Estructuras de control, que son sentencias compuestas formadas a su vez por otras sentencias (que podrán ser, a su vez, simples o compuestas, y así recursivamente).

Por consiguiente, todo programa puede verse como una única sentencia, simple o compuesta por otras.

Esto tiene una consecuencia más profunda: si un programa es una sentencia, también puede decirse que cada sentencia es como un programa en sí mismo.

Como las estructuras de control también son sentencias, cada estructura de control es como un miniprograma dentro del programa.

Ese miniprograma debe cumplir las propiedades de los programas propios (los programas que no son propios no nos interesan).

Por eso, las estructuras de control:

1. Siempre tienen un único punto de entrada y un único punto de salida.

2. Tienen un camino desde la entrada a cada sentencia de la estructura, y un camino desde cada una de ellas hasta la salida.

3. No debe tener bucles infinitos.

Esos dos programas son equivalentes, lo que significa que producen el mismo resultado y los mismos efectos ante los mismos datos de entrada, aunque lo hacen de distinta forma:

• El primer programa se compone de saltos contínuos y líneas que se cruzan, lo que lo hace mucho más complicado de seguir.

• En cambio, el segundo programa es mucho más fácil de leer y modificar que el primero, aunque los dos resuelvan el mismo problema.

Todo programa estructurado presenta una descomposición arborescente en la que cada nodo se corresponde directamente con una sentencia simple o compuesta.

Cualquier sentencia compuesta puede ser sustituida por su descomposición arborescente y viceversa.

Esta propiedad simplifica el razonamiento sobre el programa al hacerlo mucho más legible, además de facilitar su mantenimiento, ya que lo más probable es que sólo haya que realizar modificaciones en subárboles de la estructura general.

No todos los programas estructurados son programas propios, ya que podemos escribir programas estructurados que tengan varias salidas o bucles infinitos.

Lo que demuestra el teorema es que, si tenemos un programa propio, lo podemos reescribir como programa estructurado.

Por tanto, todo programa propio se puede estructurar, pero no todos los programas estructurados son propios.

Pero es evidente que los programas estructurados que nos interesan son, precisamente, los que también son propios.

Ejemplo:

x = 1
y = 2
f = lambda a, b: a + b
z = f(x * y)

Estas cuatro sentencias, al estar todas consecutivas en el mismo nivel de indentación, actúan como una sola sentencia en bloque (forman una estructura secuencial) y se ejecutan en orden de arriba abajo.

A partir de ahora, tenemos que una sentencia puede ser simple o compuesta (es decir, una estructura), y esa sentencia compuesta puede ser una secuencia:

La estructura alternativa está formada por una sucesión de cláusulas que asocian una condición con una sentencia.

Las cláusulas van marcadas con if, elif o else.

Las condiciones se van comprobando de arriba abajo, en el orden en que aparecen, de forma que primero se comprueba la condición del if y después las diferentes elif, si las hay.

En el momento en que se cumple una de las condiciones, se ejecuta su sentencia correspondiente y se sale de la estructura alternativa (no se sigue comprobando más).

Si no se cumple ninguna condición y hay una cláusula else, se ejecutará la sentencia de ésta.

Si no se cumple ninguna condición y no hay cláusula else, no se ejecuta ninguna sentencia.

Puede haber cláusulas elif y no haber else.

En el siguiente código:

a = 4
b = 3
if a != b:
    print('Son distintos')
    x = 5
else:
    print('Son iguales')

tenemos las siguientes estructuras, anidadas una dentro de la otra:

1. Una secuencia formada por un bloque de tres sentencias: las asignaciones a = 4 y b = 3 y la sentencia if ... else que va desde la línea 3 hasta la 7.

2. La selección if ... else.

3. Una secuencia formada por las sentencias de las líneas 4–5.

Recordemos: cada estructura es una sentencia en sí misma, y contiene a otras sentencias (que pueden ser simples u otras estructuras).

Aquí se ven representadas visualmente las estructuras que forman el código fuente del programa:

Se aprecia claramente que hay tres estructuras (dos secuenciales y una alternativa) y cinco sentencias simples (las asignaciones y los print), por lo que hay ocho sentencias en total.

Ahora nuestra gramática se amplía:

La estructura repetitiva asocia una condición a una sentencia, de forma que lo primero que se hace nada más entrar en la estructura es comprobar la condición:

• Si la condición no se cumple, se salta la sentencia y se sale de la estructura, pasando a la siguiente sentencia que haya tras el bucle.

• Si la condición se cumple, se ejecuta la sentencia y se vuelve otra vez al principio de la estructura, donde se volverá a comprobar si la condición se cumple.

  Este ciclo ciclo de «comprobación y ejecución» se repite una y otra vez hasta que se compruebe que la condición ya no se cumple, momento en el que se saldrá del bucle.

Cada vez que se ejecuta el cuerpo del bucle decimos que se ha producido una iteración o paso del bucle.

Es importante observar que la comprobación de la condición se hace justo al principio de cada iteración, es decir, justo antes de ejecutar la sentencia en la iteración actual.

Si la condición se cumple siempre y nunca evalúa a False, la ejecución nunca saldrá del bucle y tendremos lo que se denomina un bucle infinito.

Generalmente, los bucles infinitos indican un fallo en el programa y, por tanto, hay que evitarlos en la medida de lo posible.

Sólo en casos muy particulares resulta lógico y conveniente tener un bucle infinito.

Por ejemplo, los siguientes bucles serían infinitos:

while True:
    print("Hola")

i = 0
while i >= 0:
    print("Hola")
    i += 1

Ahora ampliamos de nuevo nuestra gramática, esta vez con la estructura de iteración (o sentencia while):

Por ejemplo:

>>> 10 * (1 / 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero
>>> 4 + spam * 3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'spam' is not defined
>>> '2' + 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't convert 'int' object to str implicitly

La última línea del mensaje de error indica qué ha ocurrido.

Hay distintos tipos de excepciones y ese tipo se muestra como parte del mensaje: los tipos del ejemplo anterior son ZeroDivisionError, NameError y TypeError.

El resto de la línea proporciona detalles sobre el tipo de excepción y qué lo causó.

Su funcionamiento es el siguiente:

• Se intenta ejecutar el bloque de sentencias del try.

• Si durante su ejecución no se levanta ninguna excepción, se saltan los except y se ejecutan las sentencias del else.

• Si se levanta alguna excepción, se busca (por orden de arriba abajo) algún except que cuadre con el tipo de excepción que se ha lanzado y, si se encuentra, se ejecutan sus sentencias asociadas.

• Finalmente, y en cualquier caso (se haya levantado alguna excepción o no), se ejecutan las sentencias del finally.

Por ejemplo, el siguiente programa pide al usuario que introduzca un número entero por la entrada. Si el dato introducido es correcto (es un número entero), lo muestra a la salida multiplicado por tres y dice que la cosa acabó bien. Si no, muestra un mensaje de advertencia:

try:
    x = int(input("Introduzca un número entero: "))
    print(x * 3)
except ValueError:
    print("¡Vaya! No ha introducido un número entero.")
else:
    print("La cosa ha acabado bien.")
finally:
    print("Fin")

En cualquiera de los dos casos, siempre acaba diciendo Fin.

Se basa en suponer que, en cada nivel de refinamiento, todos los elementos (instrucciones, expresiones, funciones, etc.) que aparecen en la solución están ya disponibles directamente en el lenguaje de programación, aunque no sea verdad.

Esos elementos o recursos se denominan abstractos porque los podemos usar directamente en un determinado nivel de refinamiento sin tener que saber cómo funcionan realmente por dentro, o incluso si existen realmente. Nosotros suponemos que sí existen y que hacen lo que tienen que hacer sin preocuparnos del cómo.

En el siguiente refinamiento, aquellos elementos que no estén implementados ya directamente en el lenguaje se refinarán, bajando el nivel de abstracción y acercándonos cada vez más a una solución que sí se pueda implementar en el lenguaje.

El refinamiento acaba cuando la solución se encuentra completamente definida usando los elementos del lenguaje de programación (ya no hay recursos abstractos).

Al diseñar un programa estructurado, se deben estructurar al mismo tiempo tanto el programa como los datos que éste manipula.

Por tanto, el diseño descendente por refinamiento sucesivo se debe ir aplicando también a los datos además de a las instrucciones.

En cada paso del refinamiento, tanto las instrucciones como los datos se deben considerar recursos abstractos, de forma que, en un determinado nivel de abstracción, las instrucciones y los datos deberían estar refiniados con el mismo nivel de detalle.

Hay que evitar, por tanto, que las instrucciones estén poco detalladas y los datos muy detallados, o viceversa.

La sentencia «leer n» ya está suficientemente refinada (se puede traducir a un lenguaje de programación) pero la segunda no; por tanto, es un recurso abstracto.

Podríamos traducir ya la sentencia «leer n» al lenguaje de programación, o podríamos esperar a tener todas las sentencias refinadas y traducirlas todas a la vez. En este caso, lo haremos de la segunda forma.

La construcción de la tabla se puede realizar fácilmente escribiendo en una fila los múltiplos de 1, en la fila inferior los múltiplos de 2, y así sucesivamente hasta que lleguemos a los múltiplos de n.

Por tanto, el siguiente paso es refinar la sentencia abstracta «construir la tabla de n \times n», creando un nuevo nivel de refinamiento:

donde ahora aparece la sentencia «escribir la fila de i», que escribe cada una de las filas de la tabla, y que habrá que refinar porque no se puede traducir directamente al lenguaje de programación.

En este nivel refinamos la sentencia que nos falta, quedando:

Este es el último nivel de refinamiento, porque todas las instrucciones ya se pueden traducir directamente a un lenguaje de programación.

Por ejemplo, en Python se escribiría así:

n = int(input('Introduce el número: '))
i = 1
while i <= n:
    j = 1
    while j <= n:
        print(i * j, end=' ')
        j += 1
    print()
    i += 1

O mejor aún:

try:
    n = int(input('Introduce el número: '))
    i = 1
    while i <= n:
        j = 1
        while j <= n):
            print(f'{i * j:>3}', end=' ')
            j += 1
        print()
        i += 1
except ValueError:
    print('Número incorrecto')