Análisis Histórico del Diseño de Algoritmos y su Impacto en la

Formación de Ingenieros

M.C. Ricardo Vargas de Basterra 1 y Dr. Agustín Gutiérrez Tornés 2

1 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
2 Centro de Investigación en Computación-IPN, Av. Juan de Dios Batíz, esquina con Miguel

Otón de Mendizábal, México, D.F., 07738. México

atornez@cic.ipn.mx

Resumen. Con el paso de los años las teorías de la programación, los lenguajes, los
paradigmas, las técnicas de diseño de algoritmos, las técnicas de solución de problemas,
las herramientas, los tópicos curriculares, las técnicas de formación de ingenieros, las
herramientas y técnicas de enseñanza y muchas otras cosas de las cuales depende la
consolidación del conocimiento y talento de los programadores han evolucionado. Este
trabajo hace una recopilación histórica sobre los principales elementos, su impacto, su
evolución y su situación actual en el contexto de la Ingeniería de Software y la formación
de recursos humanos valiosos.

1 Introducción

La programación sigue siendo el corazón de todo proyecto de software. Este

trabajo hace una recopilación histórica, desde 1940 a la fecha, de las
principales teorías de programación y como estas han dictado la creación de
nuevos lenguajes, paradigmas, técnicas y herramientas que eventualmente se
convierten en los tópicos curriculares de los centros educativos.
Finalmente, con la información recopilada se elabora una red semántica (mapa
mental) que integra toda la información desde la cual se pueden hacer análisis
sobre nuestra realidad como resultado de nuestra historia.
.
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. Estos son los que serán mencionados.
 2.1 La programación como un arte

Importantes autores siguen considerando que la programación aún no está

en condiciones de recibir el título de ciencia. Entre ellos Budd [1], Glenn [2] y
Kunth [4] han señalado que a pesar de todos los formalismos que se han
creado, el diseño de algoritmos y su codificación sigue siendo un arte.
El valioso acervo de conocimientos, técnicas, herramientas y métodos son
imprescindibles para formar a un ingeniero de sistemas. Son el equivalente en
los pintores a dominar la teoría del color y las técnicas pictóricas, pero ese
conocimiento no puede, ni podrá jamás, guiar su mano para crear una obra
maestra.

2.2 Evolución de la Teoría de la Programación

Los principios y teorías de la programación han evolucionado

constantemente desde los tiempos de la programación dura hasta la era del
cómputo distribuido. Los principales hitos históricos son los siguientes:
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. Su arquitectura está formada
por cinco módulos: entrada, cálculo, control, memoria y salida. Sin embargo, 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, considerada la primer
computadora digital de la historia. 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. Esta idea es de tal envergadura que obliga a
los fabricantes de computadoras a revisar su arquitectura. Estas ideas dieron
nacimiento al paradigma de programación libre y a los primero 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]. En ella se presenta el
teorema de la estructura y las siguientes definiciones según [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].
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 en [8] con el
principio de acceso uniforme; Parnas en [9] con el principio de ocultación de
información; y Hoare en [10] y por Liskov y Zilles en [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 orienta a
aspectos

3 Diseño de Algoritmos

El diseño de algoritmos es la parte central de todo producto de software sin

importar el paradigma en que se esté desarrollando. Si se trata de
programación estructurada los módulos, rutinas y funciones subyacen en
algoritmos. Si se trata de objetos, cada método de cada clase contiene un
algoritmo. Si se trata de cómputo colaborativo y distribuido, cada componente
disperso se basa en algoritmos.

3.1 Técnicas de Diseño de Algoritmos

El auge de las técnicas de diseño de algoritmos se da en el seno del

paradigma estructurado dónde resaltan las siguientes: Warnier [13], Jackson
[14], Bertini [6][15], Tabourier [6] y Chapin (Nasi/Shneiderman) [6][15]. Todas
ellas plantean el hecho de que un algoritmo no se obtiene al primer intento sino
que deben de hacerse varias aproximaciones a través de mecanismos de
refinamiento. Todas utilizan algún tipo de diagrama como herramienta de
diseño.
Dentro del seno del paradigma orientado a objetos sobresale la propuesta de
Droomey [16]. Sin embargo, es notorio el poco desarrollo que se tiene en este
particular un tanto motivado por la intención de distintos autores de apartarse
de todo lo que fuese estructurado alegando que fomentaba malos hábitos en
programación.
Como resultado del auge del paradigma orientado a objetos una gran cantidad
de técnicas de análisis y diseño surgen concluyendo con la aceptación general
de UML como lenguaje de modelado. Sin embargo, no existe en este lenguaje
simbología para diseñar los procesos internos de los métodos ni tampoco
simbología para representar el teorema de la estructura a pesar de la obvia
necesidad de ello.

3.2 Herramientas conceptuales de diseño e algoritmos

Dentro del paradigma libre aparecieron con uso generalizado los Diagramas de
Bloques, Diagramas de Flujo, Grafos, Tablas de Verdad, Tablas de Decisiones,
Árboles de decisiones y HIPO. Cada uno con sus reglas y características
propias.
En el paradigma estructurado se continuó con la mayoría de las ya existentes y
se agregaron, o consolidaron, otras como son el Pseudocódigo y los
ordinogramas.
Durante el paradigma orientado a objetos no hay surgimiento de herramientas
nuevas sobre el diseño de algoritmos más que el diagrama de actividades [17]
que originalmente no era parte de UML aunque ya se le incluyó.
Es interesante observar que la mayoría de las herramientas aparecen en el
modelo de programación libre quizás por la ausencia de estructuras de control
formales. Muchas de ellas prevalecen durante la fase de la programación
estructurada pero solo el pseudocódigo sobrevive hasta la programación
orientada a objetos lo cual alerta de la necesidad de fortalecer o actualizar las
herramientas en este particular.

4 Aprendizaje de la Programación

4. 1 Conceptos

La manera como los ingenieros forman a nuevos ingenieros va de la mano

con las corrientes educativas del momento así como de la propia experiencia y
juicio de lo que se considera bueno o malo, apropiado o inapropiado. Es
interesante señalar que la “didáctica de la programación” - y sus sinónimos
como metodología de la programación y otros similares - ha sido parcialmente
atendida e incluso delegada a otras áreas del conocimiento y no a las ciencias
de la computación.

4. 2 Estrategias de enseñanza aprendizaje

Los más relevantes son los siguientes: Método inductivo (tradicional), Método
de la disección (leer primero programas escritos para averiguar que hacen),
Método deductivo (utiliza la disección pero también incluye la escritura directa
de código experimental), Acercamiento progresivo (ejemplo del robot Karel [18]
o de Logo). Modelo constructivista (Vigosky), Todos comparten el objetivo de
desarrollar la habilidad de la programación en los estudiantes, sin embargo, las
investigaciones en el área de conocimiento de las ciencias sociales no
concluyen cual es el modelo más efectivo. De hecho, Gardner ha explicado a
través de su teoría de las inteligencias múltiples que las personas no tienen
una sola inteligencia cognitiva sino que tienen varias que se entremezclan y
complementan para que pueda enfrentar de mejor forma los problemas que
trata de resolver. Adicionalmente, también existe la teoría de los diversos
estilos de aprendizaje que señala que hay personas que aprenden mejor
observando (denominadas visuales), otras escuchando (auditivas) y otras a
través de la acción y movimiento (llamas kinestésicas). Todo esto es rematado
con la idea humanista de Carl Rogers quien indica que el aprendizaje es un
viaje estrictamente individual basado en las experiencias propias y exclusivas
de la persona que aprende por lo que tratar de estandarizar en un solo método
los procesos de aprendizaje resulta infértil. En conclusión, lo que es claro es
que existe la necesidad de crear una masa crítica de profesionales
competentes en la programación pero no hay una respuesta contundente de
cómo debe lograrse esto.
 4.4 Tácticas (Técnicas Instrucionales) de enseñanza aprendizaje

Complementando las estrategias se encuentran las tácticas o visiones que

tienen los responsables del aprendizaje de los nuevos ingenieros. Estos
enfoques se han clasificado en tres básicos:
El enfoque directo al lenguaje sostiene que la mejor forma de aprender a
programar es programando en un lenguaje cualquiera y conocer directamente
la sintaxis de ese lenguaje y las herramientas que lo soportan. Entre los que
apoyan esta idea se encuentran Kernighan y Ritchie[19] y Decker y Hirshfield
[20].
El enfoque de conocer primero la semántica va más por la línea de
desarrollar la lógica de programación a través del dominio de las estructuras de
control representadas por medio de diversas técnicas manteniendo una
distancia prudente con la sintaxis de algún lenguaje particular. Finalmente, por
supuesto que es necesario aterrizar en algún lenguaje pero sostiene que si los
programadores desarrollan habilidades en el diseño de soluciones algorítmicas
podrán cómodamente moverse entre diversos lenguajes. Además, señala que
uno de los principales problemas de iniciar directo con algún lenguaje es que
rápidamente se cae en el problema de estudiar la interfaz de programación
(IDE) y las características de la herramienta perdiendo de vista el tema central
que es la capacidad de resolver problemas en lugar de cómo utilizar un editor.
Entre los autores que se proponen a favor de este enfoque se encuentran Budd
[1], Alcalde y García [6], Joyanes [15], Gosling [21], Voss [22], Patis [18] y
Dijkstra quien para escribir su libro en [23] justifica su decisión de no elegir un
lenguaje específico de la siguiente forma: “Cuando se comienza un libro como
este, uno se enfrenta de inmediato a la pregunta: ‘Que lenguaje de
programación voy a utilizar?’. ¡Esto no es únicamente una cuestión de
presentación! El más importante, pero también más elusivo, aspecto de
cualquier herramienta es la influencia que produce en los hábitos de aquellos
que tratan de entrenarse en su uso. Si la herramienta es un lenguaje de
programación, su influencia – nos guste o no – es directa en nuestros hábitos
de pensar. Después de haber analizado esta influencia con mi mayor empeño,
he llegado a la conclusión de que ninguno de los lenguajes de programación
existentes, ni ningún subconjunto de los mismos coincidirían con mi propósito”
El enfoque de mezclar semántica con sintaxis de lenguajes sostiene que es
tan importante dominar la semántica de las estructuras de control como la
sintaxis de un lenguaje y que debido a la necesidad de programar se
recomienda utilizar algún lenguaje en específico cuidando de concentrarse en
los temas relevantes y no en los temas accesorios. Glenn [2] es uno de los que
proponen está visión.
Cada una de estas visiones tiene sus pros y sus contras. Todos los autores
reconocen que el desarrollar las habilidades de programación en algún
lenguaje es el fin último pero que esta habilidad depende a su vez de la
habilidad de solucionar problemas por medio de diseño de soluciones
algorítmicas que son, por su propia naturaleza, independientes del lenguaje.
Sin embargo, son más los autores que se manifiestan a favor de privilegiar las
habilidades de diseño algorítmico a través del fortalecimiento del dominio de la
semántica de cada una de las estructuras de control y que el dominio del
lenguaje puede darse posteriormente.
4 Conclusiones y trabajos futuros.

• La realidad actual en materia de diseño algorítmico es resultado del

proceso histórico que se ha vivido.
• La programación aún requiere de habilidades personales que rayan en
la capacidad artística para el diseño de algoritmos.
• La calidad del software es un tema prioritario y de preocupación mundial
• La calidad de cualquier producto de software depende del talento
humano y de lo que éste ha aprendido dentro del marco de su propio
desarrollo.
• El talento humano es posible desarrollarlo a partir de combinar una
colección de conocimientos, habilidades y destrezas así como la
metodología con que se enseñan y aprenden.
• La didáctica de la programación y la forma como aprenden los futuros
ingenieros no puede ser responsabilidad exclusiva de los pedagogos,
debe ser co-responsabilidad de los científicos e investigadores de las
ciencias de la computación.
• Si bien desde el punto de vista cognoscitivista están muy claros los
tópicos que deben ser del dominio de un buen programador, la
identificación científica de las habilidades mentales que requiere y la
forma de desarrollarlas es un tema que aún no ha sido investigado.

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
[16] R. Geoff Dromey, A model for software product quality, IEEE Transactions on Software Engineering,
vol. 21, No. 2 Febrary 1995 pp 146-162
[17] Martin Fowler, UML distiled, Addison Wesley Longman, 1997
[18] Richard E. Pattis, Introducción Gradual a la programación . El Robot Karel, Limusa, 1987
[19] Brian W. Kernighan y Dennis M. Ritchie, El Lenguaje de Programación C, Pearson Educación, pp.4-5,
1991
[20] Rick Decker y Stuart Hirshfield, Pascal's Tirangle. Reading, Writen and Reasoning, PWS-Keny, pp.
xiv, 1992
[21] Peter E. Gosling, Programación Estructurada para microcomputadoras, Mc Graw Hill, pp 1, 1985
[22] Greg Voss, Programación Orientada a Objetos: una introducción, McGraw-Hill, pp.20, 1994
[23] Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall. pp xiii. 1976
 Lenguaje Máquina
Duro Bajo Nivel
Pseudocódigo Ensamblador
Diagramas de bloques Libre
Ordinogramas Macroensamblador 1a, 2a y 3a
Diagramas de flujo Estructurado
Chapin (Nassi/ oleada
Grafos Orientado a Objetos
Shneiderman Paradigmas
Tablas de verdad Distribuido-Colaborativo
Tablas de decisiones Orientado a Aspectos 3GL
Árboles de decisiones Otros Alto nivel

Orientadas a 4GL
Libres
Estructuradas objetos
Taxonomía
Diagramas de
Actividades Imperativos
Polya Lenguajes Lógicos
Funcionales
Gosling Descriptivos
Herramientas y
Joyanes técnicas Arte de la
Decker Globales programación
Alcalde Teoría de la Von neumann
Glenn Métodos de programación
Levine análisis de LIbre
Perry problemas
De
Programación
ESTADO DEL ARTE
EN EL MODELADO Teorías Böhm-Jacopini
ALGORÍTMICO Orientado a Diagrama propio
objetos Estructurado Programa Propio
Diseño Teorema de la
Algorítmico ADT-Ocultamiento- estructura
HIPO Conceptos Acceso uniforme
Herencia
Encapsulamiento Distribución
Polimorfismo Otras Colaboración
Aspectos
Libres Métodos de
diseño
algorítmico Aprendizaje y Teorías Vigosky
aplicación de la Rogers
Métricas
programación Glosanof
Guilford
Warnier/Orr Gardner
Jackson
Bertini Impacto en la Teoría de sistemas
Tabourier Estructuradas calidad del software Pensamiento complejo
Lógica de Tácticas de
programación* enseñanza
aprendizaje Inductivo
Heurísticas Estratégias de Deductivo
enseñanza Progressivo (Karel)
Pressman
aprendizaje Constructivista
Ledine
Vargas Herramientas
Directo al lenguajes y su sintaxis Aprendizaje basado en Problemas (PBL)
Enfoques Aprendizaje basado en Casos (CBL)
Primero semántica independiente del lenguaje
Modelo combinado Pirámide de habilidades Aprendizaje basado en Proyectos (POL)
Disección Aprendizaje colaborativo
IDE’s Técnicas expositivas
CASE Otros