EL TEOREMA DE JACOPINI (TEOREMA DE LA ESTRUCTURA) EN EL

MUNDO DE LA PROGRAMACIÓN ORIENTADA A OBJETOS.

M. en C. Ricardo Vargas de Basterra

Universidad del Valle de México Campus Hispano, Av. José López Portillo 222,
Coacalco de Berriozabal, Estado de México, 55700. México
ricardo.vargas@uvmnet.edu

RESUMEN

La Programación Orientada Objetos es una realidad que llegó para quedarse. Incluso nuevos modelos
como el cómputo distribuido, los componentes y otros más ya consideran al polimorfismo, la herencia y
el encapsulamiento como parte implícita a su diseño. Después de varios años y varias propuestas el UML
ha sido adoptado como lenguaje de modelado para este paradigma. Sin embargo, hay algunas cosas que el
UML no resuelve como es el modelado algorítmico en el cual, el Teorema de Böhem- Jacopini, también
conocido como Teorema de la Estructura,(propuesto en la segunda mitad de los 60’s del siglo pasado)
tiene vigencia total en cuanto a la necesidad de utilizarlo pero ausencia en cuanto a técnicas de modelado
que lo implementen.
Este trabajo hace una reseña de las implicaciones que diversas teorías de la programación han tenido a los
largo de la historia. Aborda la necesidad actual de poder modelar algoritmos utilizando el Teorema de
Jacopini y plantea que ante la ausencia de técnicas formales actuales de modelado hay una clara
necesidad de trabajar en este sentido.

1. Introducción.

Todos los analistas concuerdan que el componente más costoso de un sistema

de información es el software. Esto ha llevado a muchos investigadores y
profesional del área a buscar metodologías, técnicas, herramientas, leyes,
principios y todo un conjunto de elementos que permitan la construcción de
software eficiente, barato, mantenible, libre de errores y eficaz, en una palabra
software de calidad.
El diseño de algoritmos es una parte crítica en el proceso de ingeniería de
software. A lo largo de los años han surgido diversas teorías, enfoques,
técnicas y herramientas para su diseño y construcción. Cada teoría de la
programación ha llevado al surgimiento de nuevas herramientas y de nuevos
paradigmas de programación. La mayoría más bien evolutivos que
revolucionarios. Estos ciclos han conformado una dialéctica de tesis, antitesis y
síntesis dinámica a la cual se debe estar atento para evitar caer en negaciones
o afirmaciones fundamentalistas que ocasionen el abandono de conocimientos
valiosos en el arte de la programación.
Los hitos históricos más relevantes nos han llevado a los paradigmas de la
programación dura, la programación suave (o libre), la estructurada, la
orientada a objetos y a otros más como la programación por componentes, la
programación distribuida y la programación orientada a aspectos. Cada uno de
estos paradigmas ha desarrollado sus propias herramientas, técnicas y
metodologías.
En particular este trabajo aborda al teorema de Jacopini, que dio nacimiento a
la programación estructurada y plantea como su concepción sigue vigente en el
mundo de la programación orientada a objetos pero que no contamos con
técnicas o herramientas de modelado claro para su implementación.
2 Teoría de la Programación

La teoría de la programación será considerada como el conjunto de principios

que rigen un paradigma y definen las características semánticas de cierto
conjunto de lenguajes.
La teoría de la programación aspira a dar certidumbre sobre las formas más
adecuadas de enfrentar un problema, modelarlo y encontrar su solución
algorítmica para poder codificarlo en algún lenguaje y ejecutar la solución en
una computadora. Para ello ha creado, con el paso del tiempo, una serie de
principios que han venido evolucionando. Estos principios han dado nacimiento
a diversos paradigmas dentro de los cuales han surgido lenguajes de
programación, técnicas específicas de diseño, herramientas (tanto
computacionales como manuales) para ayudar durante el proceso de solución
de problemas. Desde el nacimiento de las computadoras han pasado más de
cinco décadas pero solo ha habido unos cuantos hitos que han marcado la
historia.

2.1 Principales Teorías de la Programación

Con intención estrictamente informativa se citan las principales teorías:

La primera teoría de la programación.- La programación dura. Surge con el
nacimiento de la computadora cuando Charles Babbage alrededor de 1830
desarrolla el concepto de La Máquina Analítica. No fue sino poco más de cien
años después (1947) que fue posible la programación gracias a la creación de
la ENIAC. La técnica de programación se hacía en forma “dura” significando
que estaba físicamente cableada para resolver alguna tarea específica y si se
deseaba tener un programa diferente se tenía que modificar ese cableado. No
parece ser necesario justificar la importancia de este hito histórico.
La segunda teoría de programación.- La programación suave. Nace del modelo
de John von Neumann y consiste en permitir la coexistencia de datos con
instrucciones en la memoria para que la computadora pueda ser programada
de forma “suave” y no con cables. Estas ideas dieron nacimiento al paradigma
de programación libre y a los primeros lenguajes de programación.
La tercera teoría de programación.- Teorema de la Estructura. Resultado del
trabajo de Conrado Böhm y Giuseppe Jacopini [5]
La cuarta teoría de la programación.- ADT, ocultación y acceso uniforme. Se
debe al trabajo e ideas de varios autores, entre ellos: Geschke [8] con el
principio de acceso uniforme; Parnas [9] con el principio de ocultación de
información; y Hoare [10] y por Liskov y Zilles [11] con el concepto de Tipo de
Dato Abstracto. Con estos elementos y el concepto de Clase que apareció en
Simula en 1967 ya todo estaba dado para el nacimiento del paradigma de la
programación orientada a objetos.
Desde aquí has surgido otras como la programación distribuida y la orientada a
aspectos.

2.2 Implicaciones de las Teorías: Los Paradigmas

Estos hitos históricos dieron nacimiento a filosofías distintas para modelar el

mundo real. Estos principios (salvo los dos primeros) en realidad no marcan el
nacimiento de una tecnología revolucionaria que haya modificado
completamente la forma como se programa. De hecho, el modelo de
programación imperativo prácticamente ha sufrido muy pocas modificaciones
desde el nacimiento de los lenguajes de alto nivel. Los verdaderos e
importantes cambios están más del lado filosófico: cómo transitar del dominio
del problema al dominio de la solución.
Cada teoría de programación dio nacimiento a herramientas, lenguajes,
metodologías y paradigmas. Paradigma proviene del vocablo griego
paradeigma que significa mostrar o manifestar. Se ha utilizado como conjunto
de reglas y principios que rigen una forma de pensar y de actuar. Los
paradigmas no son conceptos propiamente del mundo de la computación, más
bien éste los ha adoptado para poder expresar sus propias formas, por
supuesto, de pensamiento y acción. Siendo un paradigma un aspecto de corte
filosófico más que tecnológico no tiene fronteras fijas de nacimiento y muerte,
de hecho, a lo largo del tiempo se ha venido solapando un paradigma sobre
otro cambiando paulatinamente, más en un proceso evolutivo que
revolucionario.

2.3 Conceptos Fundamentales al Interior de los Paradigmas

Cada uno de los principales Paradigmas cuenta con su propio conjunto de

reglas y principios gestados a partir de las teorías de programación ya
expuestas. Estas reglas y principios han conformado sus tesis y antítesis. Por
el interés de este trabajo solo se considerarán el paradigma estructurado (PE) y
el orientado a objetos (POO).

• Paradigma Estructurado
Propone tres conceptos fundamentales:
Una metodología formal de diseño basada en la descomposición funcional
descendente (top-down).
Un conjunto de recursos abstractos basados en la modularidad y las
características de la misma (cohesión y acoplamiento)
Un conjunto de estructuras básicas de programación llamadas: Secuencia,
Condición y Repetición eliminando al salto incondicional y salto condicional.

• Paradigma orientado a objetos:

Propone dos conceptos básicos:
Una metodología de diseño basada en la identificación de objetos de software
que representan objetos del mundo real y que tienen responsabilidades
asignadas. Los objetos pueden comunicarse entre sí y colaborar a partir de
mensajes e interfaces previamente pactadas. Estos objetos pueden agruparse
para su codificación en clases.
Un conjunto de recursos abstractos basados en el Encapsulamiento, la
Herencia y el Polimorfismo

2.3 Los paradigmas enfrentados

Según Cox [15] la diferencia sustantiva entre el PE y el POO es filosófica y se

basa principalmente sobre el como transitar del dominio del problema al
dominio de la solución para poder crear un modelo de la realidad que sea más
simple, efectivo, fácil de mantener.
El paradigma estructurado hizo evolucionar diversas técnicas ya existentes
previamente como los diagramas de bloques, diagramas de flujo, HIPO,
Pseudocódigo, tablas de verdad, tablas de decisión, árboles de decisión, etc.
También aparecieron nuevos métodos formales de modelado algorítmico como
los de Bertini, Jackson, Warnier/Orr, Chapin, Nassi/Shneiderman, Tabourier,
entre otros.
El nacimiento de la POO tuvo diversas implicaciones con respecto a lo que se
venía haciendo. Muchas personas consideraron que los hábitos de
programación desarrollados en un programador que había nacido en la PE
eran muy difíciles de cambiar y adaptarse a la POO motivo por el cual
rompieron con la PE. Esto ocasionó los siguientes fenómenos:
• Desconcierto en materia de diseño algorítmico. Son abandonadas los
métodos de Warnier, Jackson y otros autores.
• Las herramientas y técnicas tradicionales son abandonadas y las técnicas
de construcción estructurada de programas también incluyendo diagramas
de flujo, diagramas de flujo de datos, diagramas top-down, etc.
• Nuevos procesos para identificar responsabilidades aparecen como el uso
de las tarjetas CRC, los diagramas de jerarquías de clase y los diseños por
contrato, entre otros.
• La herencia genera un gran impacto ya que distribuye las responsabilidades
algorítmicas de los métodos en diversas clases que especializan, usan o
derogan las acciones.
• El encapsulamiento fuerza al diseño algorítmico a ver a los datos y los
procesos como una sola cosa y no como entes separados como sucedía en
el modelo estructurado.
• El polimorfismo impacta el diseño de algoritmos llevándolo a visualizar
comportamientos alternos ante una misma invocación

3 Teorema de Jacopini

El Teorema de Jacopini (ver Fig. 1) propone las siguientes definiciones [6]:

• Diagrama Propio: Aquel que posee un solo punto de inicio y uno solo de fin.
• Programa Propio: Posee un solo inicio y un solo fin; Todo elemento del
programa es accesible, es decir, existe al menos un camino desde el inicio
al fin que pasa a través de él; No posee ciclos infinitos.
• Equivalencia de programas: Dos programas son equivalentes si realizan,
ante cualquier situación de datos, el mismo trabajo pero de distinta forma.
• Teorema de la estructura: Todo programa propio, realice el trabajo que
realice, tiene al menos un programa propio equivalente que solo utiliza las
estructuras básicas de programación, que son: la secuencia, la selección y
la repetición.
Este teorema permitió el nacimiento del paradigma de la programación
estructurada cuando Dijkstra compiló sus Notes on Structures Programming
para luego ser integrado en [7].
 Figura 1. Representación del Teorema de Jacopini

3.1 Vigencia del Teorema de Jacopini

El teorema de Jacopini ha tenido una increíble influencia en los lenguajes de

programación ya que bastaría con que se implementara una sola instrucción
para cada una de estas tres estructuras y cualquier problema que tenga
solución algorítmica imperativa podrá ser resuelto. Hoy no se concibe un
lenguaje 3GL sin que tenga estas estructuras en su interior. Sin embargo, los
diseñadores actuales de algoritmos no cuentan más que con el viejo
pseudocódigo, y en algunos casos con los diagramas de flujo, para su
modelado sin que estos consideren las ventajas de la POO.
Uno de los aspectos más interesantes (e incluso se podría utilizar el término
dramático) de esta confrontación entre paradigmas es que no hubo
excepciones. Al nacer el POO y demostrar su superioridad filosófica de
modelado se rompió también con las técnicas y hasta con los métodos de
modelado algorítmico del PE. Si bien es absolutamente cierto que el POO es
superior al PE en muchas áreas de la ingeniería de software, todas estas
ventajas se manifiestan en un nivel de abstracción superior, pero cuando se
tiene que diseñar el algoritmo interno de un método en una clase no hay
propuestas formales que tengan vigencia. Hay un gran vacío.
Si se analizan uno a uno los principales conceptos de cada paradigma
encontramos lo siguiente:

Paradigma Estructurado P. Orientado a Objetos Observaciones

Conceptos
Descomposición Descomposición por La descomposición por
funcional de Arriba hacia
responsabilidad basado responsabilidades
abajo (Top-Down) en clases y objetos resulta superior en
muchos sentidos.
Modularidad basada en Objetos independientes La modularidad de la PE
alta cohesión y bajo que se comunican por evoluciona
acoplamiento mensajes utilizando notablemente con el
herencia, encapsulamiento de las
encapsulamiento y clases con el beneficio
polimorfismo de la reutilización a
través de la herencia y
el polimorfismo
Se propone el uso No hay propuesta El POO no dice nada al
formal de tres respecto explícitamente
estructuras de control pero implícitamente es
basadas en el teorema de suponer que lo
de Jacopini. Secuencia, acepta
condición e iteración
Herramientas para el modelado algorítmico
Diagramas de bloques, UML, Pseudocódigo. En la PE hay toda una
diagramas de flujo, variedad de
HIPO, Pseudocódigo, herramientas para
tablas de verdad, tablas modelar algoritmos. En
de decisión, árboles de la POO solo hay UML
decisión, que no tiene sintaxis
Nassi/Shneiderman alguna para modelar el
teorema de Jacopini.
Metodologías formales para el diseño algorítmico
Warnier/Orr, Jackson, No hay propuesta Hay un vacío en la POO
Tabourier, Chapin, para modelar algoritmos
Bertini. que propongan ventajas
claras para usar la
herencia, el
polimorfismo y el
encapsulamiento.

4. Conclusiones

Si bien es cierto que la POO resulta en el área de Ingeniería de Software y a

altos niveles de abstracción muy ventajosa contra el PE, particularmente en el
área de modelado algorítmico no cuenta con fortalezas claras.

El UML, que es el lenguaje de modelado más utilizado dentro del POO, cuenta
con diversos diagramas para modelar sistemas pero no para modelar
algoritmos. El diagrama más cercano es el Diagrama de Actividades pero no
tiene sintaxis para representar el teorema de Jacopini completo.

Las herramientas de modelado que se llegan a utilizar para diseñar algoritmos

no cuentan con sintaxis para potenciar las ventajas de la herencia, el
polimorfismo y el encapsulamiento.

Al abandonar los métodos formales de modelado algorítmico los estudiantes de

programación están desarrollando su lógica utilizando la semántica y sintaxis
de los lenguajes pero en términos de habilidades de programación
desarrolladas a través de procesos formales. Esto pone a los nuevos
estudiantes en desventaja educativa contra las generaciones anteriores.
Referencias

[1] Timothy Budd, Introducción a la Programación Orientada a Objetos. Addison Wesley, pp. 2, xiii. 1992.
[2] J. Glenn Brookshear. Introducción a las ciencias de la computación. Addison Wesley, pp. 149, 141.
1995.
[4] Donald Knuth. The Art of Computer Programming, Vol. 1: fundamental algorithms. Addison Wesley,
1997
[5] Conrado Böhm y Giuseppe Jacopini, Flow diagrams, Turing Machines and languages with only two
formation rules. ACM, vol. 9 num 5 mayo 1966.
[6] Eduardo Alcalde y Miguel Garcia, Metodología de la Programación. Aplicaciones en COBOL y Pascal,
MCGraw Hill, pp. 205, 219, 221, 224, xii, 1992
[7] Dahl, Ole, Edsger Dijkstra y Charles Hoare, Structured Programming, Academic Press, New Cork,
1972.
[8] C.M. Geschke y J.G. Mitchell, On the problem of uniform references to data structures, SIGPLAN
notices, vol. 10, No. 6 junio 1975, pp 31-42.
[9] David Lorge Parnas, A technique for software module specification with examples, Comunnications of
the ACM, vol. 15, No 5. Mayo 1972, pp.330-336.
[10] C.A.R. Hoare. Proof of correctness of data representations, Acta informática, Vol. 1, 1972, pp. 271-
281.
[11] Barbara H. Lizkov y Stephen N. Zilles. Programming with abstract data types, SIGPLAN notices, 9, 4
abril 1974 pp. 50-59.
[13] Jean D. Warnier. Entrainement a la programmation. Constriction des programmes. 1975
[14] M. A. Jackson, Principles of program design, Academic Press, Londres, 1975
[15] Luis Joyanes Aguilar, Metodología de la Programación.Diagramas de Flujo y programación
estructurada, McGraw Hill, pp 223, 39, 11 1987