Digresion previa al estudio de las sentencias en Java: sentencias y programación estructurada.

La aparición de los lenguajes orientados a objetos no fue un simple avance en uno de los aspectos del desarrollo del software (la implementación) sino que formaba parte de una revolución en todas sus fases (análisis, diseño, etc.). En realidad la aparición de estos lenguajes es uno de los resultados de los estudios dentro de la ingeniería del software. Toda la tecnología de la orientación a objeto vino a complementar y superar un marco previo que era el conocido como de la "Programación estructurada". No se trata de una sustitución de una tecnología por otra sino de la inclusión de nuevas capacidades que eventualmente dejan sin efecto mecanismos anteriores, pero que en general se suman a ellos. La programación estructurada supuso una formalización importante en lo que se refiere a las sentencias a utilizar en un lenguaje de programación que sigue siendo válida dentro de la programación orientada a objeto.

Las instrucciones básicas proporcionadas por un computador de proposito general son de dos tipos: las que tras ser ejecutadas dejan al sistema en disposición de que se ejecute la siguiente instrucción (denominadas funcionales) y las que hacen que se pueda ejecutar a continuación una instrucción más o menos alejada (denominadas condicionales). Notese que en el primer grupo caben tanto las instrucciones simples como una operación aritmética o lógica, como una llamada a una subrutina, y que en el segundo caben tanto saltos condicionales como incondicionales (que se asimilan a saltos condicionales con el valor de la condición fijado). Bajo esta óptica, cualquier programa puede esquematizarse utilizando un bloque para cada uno de estos tipos de instrucción más uno que permita reunir en un punto distintas líneas de código. Con ello podemos representar los conocidos Diagramas de Flujo.

Los tres elementos básicos para construir diagramas de flujo

Relacionado con esto, la idea central de la programación estructurada es la de Programa Primo. Su origen se encuentra en las aportaciones de Bohm y Jacopini que demuestran en 1966 que la instrucción GOTO es innecesaria en un lenguaje de programación que proporcione una instrucción cíclica y otra condicional además del bloque funcional básico. Poco despues, en 1968, Edgar Dijkstra escribio un artículo de máxima repercusión bajo el título "GoTo Statement Considered Harmful" ("La sentencia GoTo considerada perjudicial") en el que argumentaba en contra del uso de la sentencia GoTo indicando que se trata de una sentencia que desorienta, imposibilita el análisis inverso (a partir del código hacia el algoritmo) y que se utilizaba con varios objetivos como eran: evitar un segmento de código, realizar repeticiones, salir de ciclos, ejecutar segmentos de código, etc.

Los tres elementos suficientes para construir programas sin GOTO

Consecuencia de todo ello fué la adopción por parte de todos los lenguajes de programación de un conjunto de instrucciones que incluía al menos los tres bloques básicos dando la posibilidad de no utilizar el GoTo, así como la teorización sobre la estructura de los programas que dió lugar al concepto de Programa Primo. Un programa primo será un segmento de código que presenta una sola entrada y una sola salida y que no puede ser descompuesto en partes menores con esta misma característica. De este modo, la idea de estructuración consiste en no permitir la aparición de programas primos demasiado complejos, sino limitar estos a un conjunto muy reducido, haciendo que los programas no triviales se estructuren como composiciones recursivas de estos primos.

Un programa primo no puede subdividirse en bloques con una sola entrada y una sola salida.	Un programa compuesto con sus estructuras primas.

El estudio de las posibles estructuras primas llevo a un conjunto que es el implementado en la actualidad por todos los lenguajes de programación imperativos. Es digno de comentario el hecho de que en este conjunto falte una estructura que debiera haber sido incluida y no se hizo dando lugar a la curiosa paradoja: ciertas capacidades de control de secuencia se deben basar en el uso de variables booleanas (indicadoras de la necesidad de evitar un código, romper una secuencia, etc) complicando innecesariamente la estructura. Lenguajes como el Pascal en sus primeras versiones fueron fieles al conjunto de estructuras primas, pero posteriormente se incluyeron en los lenguajes instrucciones de ruptura de secuencia que son GoTos encubiertos y limitados (sentencias break, continue) que "desbaratan" la estructuración de los programas de una manera "controlada". En la figura siguiente se comprueban los bloques primos que pueden obtenerse con el uso de 1, 2, 3 y 4 bloques básicos. Utilizando un bloque sólo se dispone de la posibilidad trivial del bloque funcional. Con dos elementos tenemos tres posibilidades: una función conpuesta por la concatenación de dos, y dos estructuras ineficaces (una identidad -en la que aparece una condicional que lleva al mismo punto por sus dos "salidas"-, y una función parcial no efectiva -un bucle vacío-). Con tres elementos disponemos de nuevo de la concatenación de funciones y de tres estructuras primas de interés y que se encuentran en los lenguajes de programación ("if-then", "while-do" y "do-while"). Con cuatro elementos, una vez más consideramos la concatenación de funciones, y aparecen dos estructuras de interés, la "if-then-else" -incluida en los lenguajes de programación- y la "do-while-do" que no fue incluida. Además aparecen otras estructuras ineficaces por ser bien identidades o bien funciones parciales no efectivas.

Podrían considerarse estructuras más complejas -con más elementos- pero no se hace así con el objetivo de mantener la simplicidad del enfoque: pocas estructuras y simples.

Sentencias en Java

Este apartado se estudiará mediante el curso completo de Java que tiene Angel Franco disponible en la red.