De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda

La programación estructurada es un paradigma de programación destinado a mejorar la claridad, la calidad y el tiempo de desarrollo de un programa informático mediante un uso extensivo de las construcciones de flujo de control estructurado de selección ( si / entonces / si no ) y repetición (mientras y para ), estructuras de bloques y subrutinas .

Surgió a finales de la década de 1950 con la aparición de los lenguajes de programación ALGOL 58 y ALGOL 60 , [1] este último incluye soporte para estructuras de bloques. Los factores que contribuyen a su popularidad y aceptación generalizada, al principio en el mundo académico y luego entre los profesionales, incluyen el descubrimiento de lo que ahora se conoce como el teorema del programa estructurado en 1966, [2] y la publicación del influyente " Ir a la declaración considerada perjudicial ". carta abierta en 1968 del científico informático holandés Edsger W. Dijkstra , quien acuñó el término "programación estructurada". [3]

La programación estructurada se usa con mayor frecuencia con desviaciones que permiten programas más claros en algunos casos particulares, como cuando se debe realizar el manejo de excepciones .

Elementos [ editar ]

Estructuras de control [ editar ]

Siguiendo el teorema del programa estructurado , todos los programas se consideran compuestos de estructuras de control :

  • "Secuencia"; sentencias ordenadas o subrutinas ejecutadas en secuencia.
  • "Selección"; se ejecuta una o varias sentencias dependiendo del estado del programa. Esto generalmente se expresa con palabras clave como if..then..else..endif. La declaración condicional debe tener al menos una condición verdadera y cada condición debe tener un punto de salida como máximo.
  • "Iteración"; se ejecuta una instrucción o bloque hasta que el programa alcanza un cierto estado, o se han aplicado operaciones a cada elemento de una colección. Esto normalmente se expresa con palabras clave como while, repeat, foro do..until. A menudo, se recomienda que cada bucle solo tenga un punto de entrada (y en la programación estructural original, también solo un punto de salida, y algunos lenguajes lo imponen).
  • "Recursión"; una sentencia se ejecuta llamándose a sí misma repetidamente hasta que se cumplen las condiciones de terminación. Si bien son similares en la práctica a los bucles iterativos, los bucles recursivos pueden ser más eficientes computacionalmente y se implementan de manera diferente como una pila en cascada.
Representación gráfica de los tres patrones básicos - secuencia, selección y repetición - usando diagramas NS (azul) y diagramas de flujo (verde).

Subrutinas [ editar ]

Subrutinas ; Las unidades invocables, como procedimientos, funciones, métodos o subprogramas, se utilizan para permitir que una secuencia sea referida por una sola instrucción.

Bloques [ editar ]

Los bloques se utilizan para permitir que los grupos de declaraciones se traten como si fueran una sola declaración. Los lenguajes estructurados en bloques tienen una sintaxis para encerrar estructuras de alguna manera formal, como una declaración if entre corchetes if..ficomo en ALGOL 68 , o una sección de código entre corchetes BEGIN..END, como en PL / I y Pascal , sangría de espacios en blanco como en Python - o las llaves {...}de C y muchos idiomas posteriores .

Lenguajes de programación estructurados [ editar ]

Es posible realizar programación estructurada en cualquier lenguaje de programación, aunque es preferible utilizar algo como un lenguaje de programación procedimental . Algunos de los lenguajes utilizados inicialmente para la programación estructurada incluyen: ALGOL , Pascal , PL / I y Ada , pero la mayoría de los lenguajes de programación procedimental nuevos desde ese momento han incluido características para fomentar la programación estructurada y, a veces, deliberadamente omitieron características, en particular GOTO, en una esfuerzo para dificultar la programación no estructurada . Programación estructurada (a veces conocida como programación modular [ cita requerida ])) impone una estructura lógica en el programa que se está escribiendo para hacerlo más eficiente y más fácil de entender y modificar.

Historia [ editar ]

Fundamento teórico [ editar ]

El teorema del programa estructurado proporciona la base teórica de la programación estructurada. Afirma que tres formas de combinar programas (secuenciación, selección e iteración) son suficientes para expresar cualquier función computable . Esta observación no se originó con el movimiento de programación estructurada; estas estructuras son suficientes para describir el ciclo de instrucción de una unidad central de procesamiento , así como el funcionamiento de una máquina de Turing . Por lo tanto, un procesador siempre está ejecutando un "programa estructurado" en este sentido, incluso si las instrucciones que lee de la memoria no son parte de un programa estructurado. Sin embargo, los autores suelen atribuir el resultado a un artículo de 1966 de Böhm y Jacopini, posiblemente porqueDijkstra citó este documento él mismo. [4] El teorema del programa estructurado no aborda cómo escribir y analizar un programa estructurado útil. Estos problemas se abordaron a fines de la década de 1960 y principios de la de 1970, con importantes contribuciones de Dijkstra , Robert W. Floyd , Tony Hoare , Ole-Johan Dahl y David Gries .

Debate [ editar ]

PJ Plauger , uno de los primeros en adoptar la programación estructurada, describió su reacción al teorema del programa estructurado:

Nosotros, los conversos, agitamos esta interesante noticia ante las narices de los programadores en lenguaje ensamblador no reconstruidos que seguían avanzando con intrincados fragmentos de lógica y diciendo: "Apuesto a que no puedes estructurar esto". Ni la prueba de Böhm y Jacopini ni nuestros repetidos éxitos en la escritura de código estructurado los trajeron un día antes de lo que estaban listos para convencerse a sí mismos. [5]

Donald Knuth aceptó el principio de que los programas deben escribirse teniendo en cuenta la demostrabilidad, pero no estuvo de acuerdo (y aún no está de acuerdo [ cita requerida ] ) con la abolición de la declaración GOTO. En su artículo de 1974, "Programación estructurada con declaraciones Goto", [6] dio ejemplos en los que creía que un salto directo conduce a un código más claro y eficiente sin sacrificar la demostrabilidad. Knuth propuso una restricción estructural más flexible: debería ser posible dibujar un diagrama de flujo de un programa con todas las ramas hacia adelante a la izquierda, todas las ramas hacia atrás a la derecha y sin ramas que se crucen entre sí. Muchos de los conocedores de compiladores y teoría de grafoshan abogado por permitir solo gráficos de flujo reducibles [ cuando se definen como? ] . [ quien? ]

Los teóricos de la programación estructurada ganaron un aliado importante en la década de 1970 después de que el investigador de IBM Harlan Mills aplicara su interpretación de la teoría de la programación estructurada al desarrollo de un sistema de indexación para el archivo de investigación del New York Times . El proyecto fue un gran éxito de ingeniería y los gerentes de otras empresas lo citaron en apoyo de la adopción de una programación estructurada, aunque Dijkstra criticó las formas en que la interpretación de Mills difería del trabajo publicado. [ cita requerida ]

Todavía en 1987 era posible plantear la cuestión de la programación estructurada en una revista de ciencias de la computación. Frank Rubin lo hizo en ese año con una carta abierta titulada "GOTO consideró perjudicial" considerado perjudicial ". [7] Siguieron numerosas objeciones, incluida una respuesta de Dijkstra que criticaba duramente tanto a Rubin como a las concesiones que otros escritores hicieron al responderle.

Resultado [ editar ]

A finales del siglo XX, casi todos los informáticos estaban convencidos de que es útil aprender y aplicar los conceptos de programación estructurada. Los lenguajes de programación de alto nivel que originalmente carecían de estructuras de programación, como FORTRAN , COBOL y BASIC , ahora las tienen.

Desviaciones comunes [ editar ]

Si bien goto ahora ha sido reemplazado en gran medida por los constructos estructurados de selección (si / entonces / si no) y repetición (mientras y para), pocos lenguajes están puramente estructurados. La desviación más común, que se encuentra en muchos idiomas, es el uso de una declaración de retorno para la salida anticipada de una subrutina. Esto da como resultado múltiples puntos de salida, en lugar del único punto de salida requerido por la programación estructurada. Hay otras construcciones para manejar casos que son incómodos en la programación puramente estructurada.

Salida anticipada [ editar ]

La desviación más común de la programación estructurada es la salida anticipada de una función o bucle. A nivel de funciones, esta es una returnafirmación. En el nivel de los bucles, esta es una breakdeclaración (terminar el bucle) o continuedeclaración (terminar la iteración actual, continuar con la siguiente iteración). En la programación estructurada, estos se pueden replicar agregando ramas o pruebas adicionales, pero para los retornos de código anidado, esto puede agregar una complejidad significativa. C es un ejemplo temprano y destacado de estos constructos. Algunos lenguajes más nuevos también tienen "roturas etiquetadas", que permiten salir de algo más que el bucle más interno. Las excepciones también permiten la salida anticipada, pero tienen más consecuencias y, por lo tanto, se tratan a continuación.

Pueden surgir múltiples salidas por una variedad de razones, la mayoría de las veces porque la subrutina no tiene más trabajo que hacer (si devuelve un valor, ha completado el cálculo) o ha encontrado circunstancias "excepcionales" que le impiden continuar, por lo que necesita manejo de excepciones.

El problema más común en la salida anticipada es que la limpieza o las declaraciones finales no se ejecutan; por ejemplo, la memoria asignada no se desasigna o los archivos abiertos no se cierran, lo que provoca pérdidas de memoria o de recursos . Estos deben realizarse en cada sitio de devolución, que es frágil y puede provocar fácilmente errores. Por ejemplo, en un desarrollo posterior, un desarrollador podría pasar por alto una declaración de retorno, y una acción que debería realizarse al final de una subrutina (por ejemplo, una declaración de seguimiento ) podría no realizarse en todos los casos. Los idiomas sin una declaración de devolución, como Pascal estándar y Seed7 , no tienen este problema.

La mayoría de los lenguajes modernos brindan soporte a nivel de idioma para evitar tales filtraciones; [8] ver discusión detallada en gestión de recursos . Por lo general, esto se hace a través de la protección de desenrollado, que asegura que se garantice la ejecución de cierto código cuando la ejecución sale de un bloque; esta es una alternativa estructurada a tener un bloque de limpieza y un goto. Esto se conoce try...finally,y se considera más a menudo como parte del manejo de excepciones . En caso de múltiples returndeclaraciones, la introducción try...finally,sin excepciones puede parecer extraña. Existen varias técnicas para encapsular la gestión de recursos. Un enfoque alternativo, que se encuentra principalmente en C ++, es la adquisición de recursos es inicialización, que utiliza el desenrollado normal de la pila (desasignación de variables) en la salida de la función para llamar a los destructores en las variables locales para desasignar recursos.

Kent Beck , Martin Fowler y los coautores han argumentado en sus libros de refactorización que los condicionales anidados pueden ser más difíciles de entender que un cierto tipo de estructura más plana que utiliza múltiples salidas predicadas por cláusulas de protección.. Su libro de 2009 afirma rotundamente que "un punto de salida no es realmente una regla útil. La claridad es el principio clave: si el método es más claro con un punto de salida, use un punto de salida; de lo contrario, no lo haga". Ofrecen una solución de libro de cocina para transformar una función que consta solo de condicionales anidados en una secuencia de declaraciones de retorno (o lanzamiento) protegidas, seguidas de un solo bloque no protegido, que está destinado a contener el código para el caso común, mientras que las declaraciones protegidas son supuestamente para lidiar con los menos comunes (o con errores). [9] Herb Sutter y Andrei Alexandrescu también argumentan en su libro de consejos de C ++ de 2004 que el punto de salida único es un requisito obsoleto. [10]

En su libro de texto de 2004, David Watt escribe que "los flujos de control de entrada múltiple y salida única son a menudo deseables". Usando la noción de secuenciador del framework de Tennent, Watt describe uniformemente las construcciones de flujo de control que se encuentran en los lenguajes de programación contemporáneos e intenta explicar por qué ciertos tipos de secuenciadores son preferibles a otros en el contexto de los flujos de control de múltiples salidas. Watt escribe que los gotos sin restricciones (secuenciadores de salto) son malos porque el destino del salto no se explica por sí mismo para el lector de un programa hasta que el lector encuentra y examina la etiqueta o dirección real que es el objetivo del salto. Por el contrario, Watt sostiene que la intención conceptual de un secuenciador de retorno se desprende de su propio contexto, sin tener que examinar su destino. Watt escribe que una clase de secuenciadores conocidos como secuenciadores de escape, definido como un "secuenciador que termina la ejecución de un comando o procedimiento que lo encierra textualmente", abarca tanto las rupturas de los bucles (incluidas las rupturas de varios niveles) como las declaraciones de retorno. Watt también señala que, si bien los secuenciadores de salto (gotos) se han restringido un poco en lenguajes como C, donde el objetivo debe ser un bloque interno o un bloque externo envolvente, esa restricción por sí sola no es suficiente para hacer que la intención de los gotos en C sea propia. -describiendo y así todavía pueden producir " código espagueti ". Watt también examina en qué se diferencian los secuenciadores de excepción de los secuenciadores de escape y salto; esto se explica en la siguiente sección de este artículo. [11]

En contraste con lo anterior, Bertrand Meyer escribió en su libro de texto de 2009 que las instrucciones como breaky continue"son solo los viejos gotocon piel de oveja" y desaconsejó firmemente su uso. [12]

Manejo de excepciones [ editar ]

Basado en el error de codificación del desastre de Ariane 501 , el desarrollador de software Jim Bonang argumenta que cualquier excepción lanzada desde una función viola el paradigma de salida única y propone que todas las excepciones entre procedimientos deberían estar prohibidas. Bonang propone que todo C ++ que se ajuste a una sola salida debe escribirse de la siguiente manera:

bool  MyCheck1 ()  throw ()  {  bool  éxito  =  falso ;  try  {  // Haz algo que pueda generar excepciones.  if  ( ! MyCheck2 ())  {  lanzar  SomeInternalException ();  }  // Otro código similar al anterior.  éxito  =  verdadero ;  }  catch  (...)  {  // Todas las excepciones capturadas y registradas.  }  retorno  exitoso ; }

Peter Ritchie también señala que, en principio, incluso un solo throwderecho antes de la returnfunción in a constituye una violación del principio de salida única, pero argumenta que las reglas de Dijkstra se escribieron antes de que el manejo de excepciones se convirtiera en un paradigma en los lenguajes de programación, por lo que propone permitir cualquier número de puntos de lanzamiento además de un único punto de retorno. Señala que las soluciones que envuelven excepciones con el fin de crear una salida única tienen una mayor profundidad de anidamiento y, por lo tanto, son más difíciles de comprender, e incluso acusa a quienes proponen aplicar tales soluciones a lenguajes de programación que admiten excepciones de participar en el pensamiento de culto de carga. . [13]

David Watt también analiza el manejo de excepciones en el marco de los secuenciadores (presentado en este artículo en la sección anterior sobre salidas tempranas). Watt señala que una situación anormal (generalmente ejemplificada con desbordamientos aritméticos o fallas de entrada / salida como archivo no encontrado) es un tipo de error que "se detecta en alguna unidad de programa de bajo nivel, pero [para el cual] un manejador se encuentra más naturalmente en una unidad de programa de alto nivel". Por ejemplo, un programa puede contener varias llamadas para leer archivos, pero la acción a realizar cuando no se encuentra un archivo depende del significado (propósito) del archivo en cuestión para el programa y, por lo tanto, no se puede realizar una rutina de manejo para esta situación anormal. ubicado en el código del sistema de bajo nivel. Watts señala además que la introducción de pruebas de indicadores de estado en la persona que llama,como implicaría la programación estructurada de salida única o incluso los secuenciadores de retorno (de salida múltiple), da como resultado una situación en la que "el código de la aplicación tiende a saturarse con las pruebas de los indicadores de estado" y que "el programador podría omitir, por descuido o pereza, probar un indicador de estado. De hecho, las situaciones anormales representadas por indicadores de estado se ignoran por defecto ". Señala que, a diferencia de las pruebas de indicadores de estado, las excepciones tienen lo contrariocomportamiento predeterminado , lo que hace que el programa finalice a menos que el programador se ocupe explícitamente de la excepción de alguna manera, posiblemente agregando código para ignorarlo intencionalmente. Basado en estos argumentos, Watt concluye que los secuenciadores de salto o secuenciadores de escape (discutidos en la sección anterior) no son tan adecuados como un secuenciador de excepción dedicado con la semántica discutida anteriormente. [14]

El libro de texto de Louden y Lambert enfatiza que el manejo de excepciones difiere de las construcciones de programación estructuradas como whilebucles porque la transferencia de control "se establece en un punto diferente en el programa que aquél en el que tiene lugar la transferencia real. En el punto donde la transferencia realmente ocurre , puede que no haya ninguna indicación sintáctica de que el control se transferirá de hecho ". [15] El profesor de informática Arvind Kumar Bansal también señala que en los lenguajes que implementan el manejo de excepciones, incluso estructuras de control como for, que tienen la propiedad de salida única en ausencia de excepciones, ya no la tienen en presencia de excepciones, porque una excepción puede prematuramente provocar una salida anticipada en cualquier parte de la estructura de control; por ejemplo, si init()lanza una excepción enfor (init(); check(); increm()), entonces no se alcanza el punto de salida habitual después de comprobar (). [16] Citando múltiples estudios anteriores de otros (1999-2004) y sus propios resultados, Westley Weimer y George Necula escribieron que un problema significativo con excepciones es que "crean rutas de flujo de control ocultas que son difíciles de razonar para los programadores". . [17] : 8:27

La necesidad de limitar el código a puntos de salida únicos aparece en algunos entornos de programación contemporáneos centrados en la computación paralela, como OpenMP . Las diversas construcciones paralelas de OpenMP, como parallel do, no permiten salidas anticipadas desde el interior hacia el exterior de la construcción paralela; esta restricción incluye todo tipo de salidas, desde breakexcepciones de C ++, pero todas ellas están permitidas dentro de la construcción paralela si el objetivo de salto también está dentro de ella. [18]

Entrada múltiple [ editar ]

Más raramente, los subprogramas permiten múltiples entradas. Por lo general, esto es solo una reentrada en una corrutina (o generador / semicorutina), donde un subprograma cede el control (y posiblemente un valor), pero luego puede reanudarse donde lo dejó. Hay una serie de usos comunes de dicha programación, especialmente para transmisiones.(particularmente entrada / salida), máquinas de estado y simultaneidad. Desde el punto de vista de la ejecución de código, el rendimiento de una corrutina está más cerca de la programación estructurada que el regreso de una subrutina, ya que el subprograma no ha terminado en realidad y continuará cuando se vuelva a llamar; no es una salida anticipada. Sin embargo, las corrutinas significan que varios subprogramas tienen un estado de ejecución, en lugar de una sola pila de llamadas de subrutinas, y por lo tanto introducen una forma diferente de complejidad.

Es muy raro que los subprogramas permitan la entrada a una posición arbitraria en el subprograma, ya que en este caso el estado del programa (como los valores de las variables) no está inicializado o es ambiguo, y esto es muy similar a un goto.

Máquinas de estado [ editar ]

Algunos programas, particularmente los analizadores sintácticos y los protocolos de comunicación , tienen varios estados que se suceden de una manera que no se reduce fácilmente a las estructuras básicas, y algunos programadores implementan los cambios de estado con un salto al nuevo estado. Este tipo de cambio de estado se usa a menudo en el kernel de Linux. [ cita requerida ]

Sin embargo, es posible estructurar estos sistemas haciendo que cada cambio de estado sea un subprograma separado y usando una variable para indicar el estado activo (ver trampolín ). Alternativamente, estos se pueden implementar a través de corrutinas, que prescinden del trampolín.

Ver también [ editar ]

  • DRAKON
  • Evaluación mínima
  • Diagrama de Nassi-Shneiderman
  • Diagrama de estructura
  • Declaración de cambio

Referencias [ editar ]

Citas [ editar ]

  1. ^ Clark, Leslie B. Wilson, Robert G .; Robert, Clark (2000). Lenguajes de programación comparativos (3ª ed.). Harlow, Inglaterra: Addison-Wesley. pag. 20. ISBN 9780201710120. Archivado desde el original el 26 de noviembre de 2015 . Consultado el 25 de noviembre de 2015 .
  2. ^ Bohm, Corrado; Giuseppe Jacopini (mayo de 1966). "Diagramas de flujo, máquinas de Turing y lenguajes con sólo dos reglas de formación" (PDF) . Comunicaciones de la ACM . 9 (5): 366–371. CiteSeerX 10.1.1.119.9119 . doi : 10.1145 / 355592.365646 . S2CID 10236439 . Archivado (PDF) desde el original el 23 de septiembre de 2015.   
  3. ^ Dijkstra 1968 , "El uso desenfrenado de la declaración go to tiene como consecuencia inmediata que se vuelve terriblemente difícil encontrar un conjunto significativo de coordenadas en las que describir el progreso del proceso ... La declaración go to tal como está es simplemente demasiado primitivo, es una invitación demasiado a hacer un lío en el programa ". error sfn: múltiples objetivos (2 ×): CITEREFDijkstra1968 ( ayuda )
  4. ^ Dijkstra, EW (marzo de 1968). "Cartas al editor: ir a la declaración considerada nociva". Comunicaciones de la ACM . 11 (3): 147-148. doi : 10.1145 / 362929.362947 . ISSN 0001-0782 . S2CID 17469809 .  
  5. ^ Plauger, PJ (12 de febrero de 1993). Programación con propósito, ensayos sobre diseño de software (1 ed.). Prentice Hall. pag. 25 . ISBN 978-0-13-721374-0.
  6. ^ Donald Knuth - Programación estructurada con declaraciones go to Archivado el 23 de octubre de 2013 en la Wayback Machine.
  7. ^ Frank Rubin (marzo de 1987). " " GOTO Considerado Dañino "Considerado Dañino" (PDF) . Comunicaciones de la ACM . 30 (3): 195-196. doi : 10.1145 / 214748.315722 . S2CID 6853038 . Archivado desde el original (PDF) el 20 de marzo de 2009.  
  8. ^ Anciano, Jackson y Liblit 2008 .
  9. ^ Jay Fields; Shane Harvie; Martin Fowler; Kent Beck (2009). Refactorización: Ruby Edition . Educación Pearson. págs. 274-279. ISBN 978-0-321-60350-0.
  10. ^ Herb Sutter; Andrei Alexandrescu (2004). Estándares de codificación C ++: 101 reglas, pautas y mejores prácticas . Educación Pearson. ISBN 978-0-13-265442-5. "Ejemplo 4: Entrada única, salida única (" SESE "). Históricamente, algunos estándares de codificación han requerido que cada función tenga exactamente una salida, es decir, una declaración de retorno. Este requisito es obsoleto en los lenguajes que admiten excepciones y destructores, donde las funciones suelen tener numerosas salidas implícitas ").
  11. ^ David Anthony Watt; William Findlay (2004). Conceptos de diseño de lenguajes de programación . John Wiley e hijos. págs. 215-221. ISBN 978-0-470-85320-7.
  12. ^ Bertrand Meyer (2009). Toque de clase: aprender a programar bien con objetos y contratos . Springer Science & Business Media. pag. 189. ISBN 978-3-540-92144-8.
  13. ^ "Entrada única, salida única, ¿debería seguir siendo aplicable en lenguajes orientados a objetos? - Blog de MVP de Peter Ritchie" . Archivado desde el original el 14 de noviembre de 2012 . Consultado el 15 de julio de 2014 .
  14. ^ David Anthony Watt; William Findlay (2004). Conceptos de diseño de lenguajes de programación . John Wiley e hijos. págs. 221–222. ISBN 978-0-470-85320-7.
  15. ^ Kenneth C. Louden; Kenneth A. Lambert (2011). Lenguajes de programación: principios y prácticas (3 ed.). Aprendizaje Cengage. pag. 423. ISBN 978-1-111-52941-3.
  16. ^ Arvind Kumar Bansal (2013). Introducción a los lenguajes de programación . Prensa CRC. pag. 135. ISBN 978-1-4665-6514-2.
  17. ^ Weimer, W y Necula, GC (2008). "Situaciones excepcionales y confiabilidad del programa" (PDF) . Transacciones ACM sobre lenguajes y sistemas de programación . 30 (2). Archivado (PDF) desde el original el 23 de septiembre de 2015.
  18. ^ Rohit Chandra (2001). Programación paralela en OpenMP . Morgan Kaufmann. pag. 45. ISBN 978-1-55860-671-5.

Fuentes [ editar ]

  • Edsger Dijkstra , Notas sobre programación estructurada , p. 6.
  • Böhm, C .; Jacopini, G. (mayo de 1966). "Diagramas de flujo, máquinas de Turing y lenguajes con solo dos reglas de formación" (PDF) . Comunicaciones de la ACM . 9 (5): 366–371. CiteSeerX  10.1.1.119.9119 . doi : 10.1145 / 355592.365646 . S2CID  10236439 .
  • Dijkstra, Edsger W. (marzo de 1968). "Cartas al editor: Ir a declaración considerada perjudicial" (PDF) . Comunicaciones de la ACM . 11 (3): 147-148. doi : 10.1145 / 362929.362947 . S2CID  17469809 .
  • Michael A. Jackson , Principios del diseño de programas , Academic Press, Londres, 1975.
  • O.-J. Dahl , EW Dijkstra , Programación estructurada CAR Hoare , Academic Press, Londres, 1972. ISBN 0-12-200550-3 . 
    • este volumen incluye una versión ampliada de las Notas sobre programación estructurada , que se incluyen arriba, que incluye un ejemplo ampliado del uso del enfoque estructurado para desarrollar un algoritmo de retroceso para resolver el problema de las 8 reinas .
    • una versión en pdf está en la serie de libros clásicos de ACM
    • Tenga en cuenta que el tercer capítulo de este libro, de Dahl, describe un enfoque que se reconoce fácilmente como Programación Orientada a Objetos. Puede verse como otra forma de "estructurar de manera útil" un programa para ayudar a demostrar que es correcto.
  • Anciano, Matt; Jackson, Steve; Liblit, Ben (octubre de 2008). Code Sandwiches (PDF) (Informe técnico). Universidad de Wisconsin – Madison . 1647, abstractoCS1 maint: posdata ( enlace )

Enlaces externos [ editar ]

  • BPStruct : una herramienta para estructurar sistemas concurrentes (programas, modelos de proceso)
  • J. Darlinton; M. Ghanem; HW To (1993), "Programación Paralela Estructurada", en Modelos de Programación para Computadoras Masivamente Paralelas. IEEE Computer Society Press. 1993 : 160–169, CiteSeerX  10.1.1.37.4610