Atlas & Maps

Definición de Programación estructurada

0

 Técnica de construcción de programas que proporciona a estos una estructura, con el fin de aumentar la eficacia de la programación y el mantenimiento de los programas, haciendo que los mismos sean más fiables, adaptables, manejables, fácilmente comprensibles y transportables.

Métodos de programación estándar

La METODOLOGÍA DE LA PROGRAMACIÓN es la técnica que permite que la programación sea lo más eficaz posible de cara al desarrollo y mantenimiento de los programas creados.

Cuando la complejidad del problema aumenta, es necesario recurrir a técnicas que ayuden en la descripción de los organigramas y algoritmos que se hayan diseñado previamente. Si se realiza un programa sin seguir un método de programación riguroso, a la larga, aunque funcione, no será más que un conjunto más o menos grande de instrucciones que podrían producir problemas como los que a continuación se enumeran:

- Rigidez en los programas.
- Pérdida de tiempo de los programadores para corregirlos.
- Difícil comunicación entre programadores.
- Uso de “parches”, con lo que se conseguirá que el programa quede en desuso.
- Deficiencias en la documentación, etc.

Los problemas anteriores junto con los no previstos, imposibilitan la evolución y mantenimiento de los programas. Por consiguiente, es de suma importancia prever las futuras modificaciones para mantener los programas funcionando correctamente y actualizados. Esas posibles modificaciones se pueden prever si los programas se crean con la suficiente flexibilidad, para que sean capaces de adaptarse a los cambios. Se deben crear programas inteligibles y breves con el objeto de que puedan ser leídos, entendidos y fácilmente modificados.

Concretando, se deben establecer una serie de normas que permitan conseguir una programación estándar con la que se consiga la disminución de los costes informáticos, independencia para el programador y más seguridad en el funcionamiento.

La programación de una aplicación debe seguir unas reglas de normalización, encaminadas a conseguir un diseño eficaz. Cualquier programa debe tener una serie de características básicas para que pueda definirse como eficaz, estas propiedades son:

- Debe ser CORRECTO: Debe resolver la tarea para la que fue creado.
- Debe ser LEGIBLE: Debe ser perfectamente entendido por cualquier programador, de manera que se puedan realizar modificaciones del programa sin problemas de comprensión.
- Debe ser MODIFICABLE: Debe tener un diseño flexible que pueda ser modificado si cambian las condiciones de trabajo.
- Debe ser DEPURABLE: Debe ser fácil la detección y corrección de los errores.

Para conseguir un diseño en el que se cumplan todas estas características, el programador debe seguir unas normas que se agrupan en las llamadas TÉCNICAS DE PROGRAMACIÓN. Se puede definir una Técnica de Programación como el conjunto de reglas de programación encaminadas a conseguir una aplicación correcta, legible, modificable y depurable, es decir, un “buen diseño” programático.

Las dos técnicas de programación más usadas son: la Programación Modular y la Programación Estructurada. Estas dos técnicas son complementarias. Un diseño programático óptimo suele consistir en dividir el problema en partes independientes, llamadas módulos, y programar cada una de ellas de forma estructurada.

Un poco de historia

El primer método de programación empleado, si es que podía ser considerado como tal, fue el CONVENCIONAL. En los inicios de la Informática, los programadores se planteaban un problema, lo analizaban, elegían un lenguaje de programación y comenzaban sin más la tarea de crear las instrucciones que resolvieran el problema. Pero este método, o mejor dicho, este “desmétodo” ( ya que en realidad no se sigue ninguna metodología) pronto demostró su ineficacia. El programa resultaba una sucesión de instrucciones más o menos grande. Las etapas de programación no estaban definidas y existía una falta de continuidad en el programa.

Este tipo de programación, denominada también “tradicional”, produce una serie de errores muy difíciles de solucionar una vez que el programa esta hecho. Estos “defectos” de programación son los siguientes:

1.- LOS PROGRAMAS SON RÍGIDOS: Es muy difícil hacer evolucionar el programa hacia las nuevas necesidades que se desarrollan en su ámbito de aplicación.

El realizar modificaciones es una tarea compleja que ocupa mucho tiempo, ya que puede afectar a una gran parte de las instrucciones, y que se complica cuando el encargado de realizarlas es distinto del programador original.

Por todo esto, o bien se tiende a realizar “parches” en el programa original, que complican el diseño inicial y por lo tanto su mantenimiento; o bien, se abandona el programa y se crea otro, con la consiguiente perdida de tiempo y de recursos.

2.- FALTA DE DOCUMENTACIÓN: El programador no atiende las necesidades documentales del programa. Realiza descripciones incompletas, no utiliza diagramas de esquematización, no actualiza con documentación los cambios en el programa, etc…

Por todo ello el mantenimiento de este tipo de programas se convierte en una tarea excesivamente complicada.

3.- RELACIÓN PROGRAMADOR-PROGRAMA: Los programadores prefieren utilizar sus propios programas, con lo que la comunicación entre programadores es mínima. Los programadores prefieren escribir sus propios programas antes que gastar su tiempo en ampliar o modificar programas hechos por otros. Cada programador tiene y utiliza sólo los programas creados por él mismo, con lo que se crea una relación demasiado rígida entre creador y obra.

4.- CORRECCIÓN DE ERRORES: Los programadores gastan demasiado tiempo en corregir sus errores, ya que la detección de la instrucción en la que se producen es muy complicada.

Todos estos problemas hacen que el desarrollo y mantenimiento de este tipo de programas sea demasiado complicado.

Por lo tanto, el programador, en su labor, debe seguir una serie de normas que impidan la aparición de los defectos anteriormente citados, consiguiendo pasar de una realización demasiado artesanal a una normalización de la programación. Con ello se logra una mayor independencia programador-programa y también reducir los costes informáticos.

Mas tarde, surgieron la programación modular y la estructurada, de la necesidad de establecer unos criterios unificados para resolver cada problema.

La programación modular es más bien una filosofía de programación en la que se dan una serie de consejos para la realización de programas descomponiéndolos en módulos. Sin embargo, programar cada módulo implica aplicar las técnicas clásicas de diseño de organigramas, ordinogramas y algoritmos, sin introducir ninguna norma.

Se necesita dotar a los programas de una estructura, para aumentar la eficacia de la programación y su mantenimiento; para aumentar la fiabilidad y eficacia y además para asegurarse de que los programas son adaptables, manejables, fácilmente comprensibles y transportables, claros y simples.

Aparece entonces la programación estructurada. Según Luis Joyanes esta se puede definir como “la técnica de construcción de programas que utiliza al máximo los recursos del lenguaje, limita el conjunto de estructuras aplicables a leer, y presenta una serie de reglas que coordinan adecuadamente el desarrollo de las diferentes fases de programación”.

Aunque la programación estructurada fue desarrollada de forma más profunda por E. Dijkstra, Hoare, Wirth, Knuth, Dahl, Behm, Jacopini y Warnier también participaron en su estudio y avance. Según Dijkstra la programación estructurada “se basa en el concepto de diagrama o programa propio tal que toda estructura tenga un sólo punto de entrada y otro de salida”,

Además, plantea que aquellos programas con un único punto de entrada y de salida pueden resolverse con tres ÚNICOS tipos de estructuras de control: secuencial, alternativa, repetitiva. De aquí la célebre frase de Dijkstra: “la estructura GOTO es perjudicial para la programación”, ya que modifica el curso secuencial del programa, de tal forma que el ordenador al encontrarla pasa a la instrucción indicada en el número de instrucción y no a la siguiente de la secuencia, produciéndose, en la mayoría de las ocasiones, graves errores de ejecución.

Es conveniente utilizar lenguajes de programación que posean como soporte, las estructuras básicas de control de la programación estructurada, tales como Pascal, Fortran, ADA, C, C++, Visual Basic, Clipper, etc…, aunque el uso de los mismos no es ni mucho menos imprescindible. Cuando el lenguaje no soporta las estructuras básicas de control, es práctica aconsejable simular dichas estructuras.

Concepto de programación estructurada

El término de programación estructurada se refiere al conjunto de técnicas que han ido evolucionando desde los primeros trabajos de Edsgar Dijkstra. Estas técnicas aumentan considerablemente la productividad del programa reduciendo el tiempo requerido para escribir, verificar, depurar y mantener los programas.

La programación estructurada utiliza un número limitado de estructuras de control que minimizan la complejidad de los problemas y por consiguiente reducen los errores. Hace que resulte más fácil escribir, verificar, leer y mantener los programas que deberán estar dotados de una estructura.

Según Luis Joyanes “la programación estructurada es el conjunto de técnicas que incorporan un procedimiento de diseño descendente (top-down), recursos abstractos y unas estructuras básicas”. Veamos cada uno de estos aspectos.

Diseño descendente

Es el proceso mediante el cual un problema se descompone en una serie de niveles o pasos sucesivos de refinamiento. La metodología descendente consiste en efectuar una relación entre las sucesivas etapas de estructuración, de modo que se relacionen unas con otras mediante entradas y salidas de información.

El problema se descompone en etapas o estructuras jerárquicas, de modo que se puede considerar cada estructura desde dos puntos de vista:

- ¿ Qué hace ? y
- ¿ Cómo lo hace ?

Un programa estructurado puede representarse con una estructura arborescente. El proceso descendente está basado en dos características esenciales:

– representación en forma de árbol, y
– descomposición funcional.

En el primer nivel que representa el árbol, se resuelve totalmente el problema y en el segundo y sucesivos niveles se hacen refinamientos del primero, siguiendo siempre la metodología de recursos abstractos.

Recursos abstractos

La programación estructurada utiliza los recursos abstractos de un determinado lenguaje de programación. Según Dijktra, “descomponer un programa en términos de recursos abstractos consiste en descomponer una determinada acción compleja en términos de un número de acciones más simples capaz de ejecutarlas”.

El proceso de realización consiste en considerar la solución de un problema como un proceso abstracto, por lo que para diseñar un problema en términos abstractos no hay que tener en cuenta la máquina que deseamos que lo resuelva, ni el lenguaje de programación que se va a utilizar. Esto lleva a la necesidad de obtener el conjunto de acciones que se han de realizar para obtener una solución, independientemente de dónde vayan a ser ejecutadas.

Teorema de la programación estructurada

Un programa puede ser escrito, según Bohm y Jacopini, utilizando solamente tres tipos de estructuras de control: secuenciales, selectivas y repetitivas.

Cuando Bohn habla de programa, realmente se está refiriendo a un “programa propio”, y define como propios a aquellos programas que:

- Poseen un solo punto de entrada y uno de salida o fin para control del programa.

- En los que existen caminos que se pueden seguir desde la entrada hasta la salida y que además pasan por todas partes.

- En los que todas las instrucciones son ejecutables y no existen bucles infinitos (cerrados o sin fin).

Estructuras de control

Estructura secuencial

Se dice que una estructura es secuencial cuando una acción o instrucción le sigue a la otra inmediatamente después. La siguiente figura representa el diagrama de flujo de una estructura de este tipo.

Las acciones se suceden de manera que la salida de una es la entrada de la siguiente y así sucesivamente hasta que el proceso concluye.

Estructuras alternativas

La especificación formal de algoritmos es realmente útil cuando el algoritmo requiere una descripción más complicada que una sencilla lista de instrucciones. Este es el caso cuando existe un número de posibles alternativas resultantes de la evaluación de una determinada condición.

Las estructuras alternativas o selectivas se utilizan para tomar decisiones lógicas, por lo que a veces se hace referencia a ellas como estructuras de decisión. En una estructura alternativa se evalúa una condición y en función del resultado de la misma se realiza una opción u otra. Las condiciones se especifican usando expresiones lógicas.

La representación de una estructura alternativa se hace con palabras en pseudocódigo (if, then, else o bien en español si, entonces, sino), con una figura geométrica en forma de rombo o bien con un triángulo en el interior de una caja rectangular.

Las estructuras alternativas o selectivas pueden ser: simples, dobles o múltiples.

Alternativa simple

La estructura alternativa simple realiza una determinada acción cuando se cumple una determinada condición. Se pregunta por una condición y si ésta es verdadera, entonces se ejecuta una acción o conjunto de acciones; pero si la condición es falsa, entonces no se hace nada.

La siguiente figura es un ejemplo sencillo, representado mediante un diagrama de flujo. Véase primero el pseudocódigo.

si condición
entonces acción/es
fin_si

Alternativa doble

La estructura alternativa simple es muy limitada, por lo que el uso de la misma es poco frecuente. Normalmente se necesitan estructuras que permitan elegir entre dos opciones o posibles alternativas en función del cumplimiento o no de una determinada condición. Si la condición es verdadera, se ejecuta una acción determinada, y si no se ejecuta otra acción distinta también especificada.

La figura siguiente presenta un ejemplo sencillo. Obsérvese el pseudocódigo.

si condición
entonces acción/es (A)
en otro caso acción/es (B)
fin_si

Alternativa múltiple

Normalmente existen más de dos posibles opciones a elegir, y no queda más remedio que optar por una de ellas para seguir adelante. Este problema en el mundo de la programación estructurada se resuelve con el uso de estructuras alternativas simples o dobles, anidadas o en cascada. Cuando el número de opciones a elegir es grande (mayor de 4 por ejemplo), se pueden plantear problemas de escritura y legibilidad del algoritmo si se utiliza el anidamiento o el diseño en cascada.

La estructura alternativa múltiple evaluará una expresión que podrá tomar “n” valores distintos 1,2,3,4,…,n. Se realizará la acción que corresponda con la opción seleccionada, es decir que el flujo del algoritmo seguirá un determinado camino entre los “n” posibles.

La siguiente figura representa un ejemplo sencillo. Ver primero el pseudocódigo.

en caso expresión de
[op1]: acción/es (1)
[op2]: acción/es (2)
.
.
.
[opn]: acción/es (n)
en otro caso
acción/es (others)
fin

Estructuras repetitivas

Un tipo muy importante de estructura es la que se necesita para repetir una o varias acciones un número determinado de veces. Por ejemplo, un programa que lea una lista de números sólo tendrá que realizar una acción, la de “leer un número del fichero”, hasta que todos los números hayan sido leídos.

Un ejemplo muy ilustrativo es el del algoritmo para realizar la suma de una lista de números escritos desde teclado. Una posibilidad es leer los números e ir añadiendo sus valores a una variable “suma” que contenga las sucesivas sumas parciales. La variable “suma” se pone (inicializa) en un principio a 0 y va incrementándose en el valor del número cada vez que uno de ellos va leyéndose.

El algoritmo para resolver este problema es el siguiente:

algoritmo suma
inicio
suma  0
leer número
suma  suma + número
leer número

fin

Donde el símbolo “” significa “se asigna”, de forma que la expresión: suma  0, significa que a la variable “suma” se le asigna el valor de 0.

Este algoritmo se repetiría tantas veces como números tuviera la lista. Las acciones: “leer número; suma — suma + número” podrían incluirse en un “bucle”. Se denomina bucle a la estructura que repite una secuencias de acciones un número determinado de veces e iteración a cada una de las veces que se repite cada acción o acciones del bucle.

Luego a la hora de diseñar un bucle hay que preguntar por:

- lo que debe contener el bucle y
- por el número de veces que ha de repetirse (número de iteraciones).

El bucle tendrá que repetirse un número determinado de veces, por lo que se ha de pensar en algún método para detener el bucle. Considérese el ejemplo anterior:

- Se podría preguntar al usuario por la cantidad de números que desea sumar, se guardaría dicha cantidad en la variable “total” y se iría decrementándose en uno cada vez que cada vez que se sumara un número, es decir, cada vez que el bucle se repitiera. Esta forma de proceder añadiría una acción más al cuerpo del bucle: “total — total + 1″.

- Otra posibilidad sería la de inicializar la variable “total” a 0 e ir incrementándola en 1 con cada iteración, hasta llegar a la cantidad total de números que haya que sumar. El algoritmo resultante sería:

algoritmo suma_número
{leer número total en variable N}
TOTAL — N {también se podría hacer “leer N”}
SUMA — 0
{comienzo de bucle}
hacer lo siguiente mientras que TOTAL sea 0
leer número
SUMA — SUMA + número
TOTAL — TOTAL – 1
{fin de bucle}
escribir “la suma de los”, N, “números es”, SUMA

- Para finalizar el bucle, también podría haberse terminado poniendo cualquiera de estas condiciones:

1/ “hasta que TOTAL sea 0″
2/ o “desde 1 hasta N”

Existen varios tipos de estructuras repetitivas que se verán a continuación.

Repetitiva “mientras”

La estructura repetitiva mientras (“while” o “dowhile” en inglés) es aquella en la que el cuerpo del bucle se repite mientras se cumple una determinada condición.

Gráficamente se representa según la figura que se muestra a continuación.

El pseudocódigo podría ser el siguiente:

mientras condición hacer
acción 1
acción 2
.
.
.
acción n
fin_mientras

Cuando se ejecuta la instrucción mientras, lo primero que se hace es una evaluación de la condición:

- Si el resultado de la evaluación es falso, no se realiza ninguna instrucción del bucle, sino que se continúa con la siguiente instrucción del bucle; luego el cuerpo del bucle se ejecuta cero veces (esta es una práctica que aunque parezca inútil se usa a menudo en programación)

- Si el resultado de la evaluación es verdadero, se ejecuta el cuerpo del bucle, después de lo cual se evalúa de nuevo la condición, proceso que se repite una y otra vez “mientras” que la condición sea verdadera. Ocurre a veces que por error el bucle no encuentra el fin, en tal caso se llamaría bucle infinito. Los bucles infinitos deben evitarse, pero a veces pueden resultar útiles en determinadas tareas.

Existen cuatro métodos para terminar un bucle “mientras”:

1/ Preguntar antes de la iteración.
2/ Encabezar la lista de datos a leer con su tamaño.
3/ Finalizar la lista con su valor de entrada.
4/ Agotar los datos de entrada.

Repetitiva “repetir”

En una estructura “mientras” si al evaluar la condición, el resultado es falso, el cuerpo del bucle no se ejecuta; a veces se desea que el bucle se ejecute al menos una vez, de ahí la necesidad de este tipo de estructuras repetitivas.

La estructura repetir (repeat en inglés) se ejecuta hasta que se cumpla una condición determinada que se comprueba al final del bucle. El pseudocódigo es el siguiente:

repetir
acciones
.
.
.
hasta_que condición

El diagrama de flujo correspondiente aparece en la figura siguiente

Entre la estructura “repetir” y la estructura “mientras” existen un par de diferencias:

1 – La estructura “mientras” termina cuando la condición es falsa; la estructura “repetir” termina cuando la condición es verdadera.

2 – En la estructura “repetir” el cuerpo del bucle se ejecuta siempre al menos una vez; “mientras” es más general y permite que el bucle no sea ejecutado.

Repetitiva “para”

En bastantes ocasiones se conoce de antemano el número de veces que se desean ejecutar las acciones de un bucle. En estos casos, en el que el número de iteraciones es fija, se debe usar la estructura desde o para (for en inglés).

El diagrama de flujo se presenta a continuación.

La estructura “desde” ejecuta las acciones del bucle un número determinado de veces y de modo automático controla el número de iteraciones a través del cuerpo del bucle. El pseudocódigo es el siguiente:

desde variable (var) = var_i hasta var_f hacer
acciones
.
.
.
fin_desde

Estructuras de decisión anidadas

La instrucción “si” sirve para diseñar estructuras:

1/ que impliquen la selección de una de dos alternativas
si-entonces y si-entonces-en otro caso.

2/ de selección que contengan más de dos alternativas.
si-entonces puede contener otra estructura si-entonces, y ésta a su vez puede contener otra si-entonces.

Estructuras de este tipo se utilizan por ejemplo para algoritmos de ordenación de una serie de números dados.

Estructuras repetitivas anidadas

De la misma forma que se pueden anidar estructuras de selección, se puede también insertar un bucle en otro. Una estructura repetitiva anidada se construye incluyendo la estructura interna totalmente dentro de la externa sin que pueda existir solapamiento. Se puede anidar cualquier estructura repetitiva si cumple las condiciones de la figura siguiente.

Esta figura es un ejemplo de bucles anidados correctamente.

Esta otra figura es un ejemplo de bucles anidados incorrectamente.

Las variables de control de los bucles toman valores tal que por cada valor de la variable índice del ciclo externo se deba ejecutar totalmente el bucle interno.

Metodologías de programación estructurada

El diseño estructurado de un problema, debe realizarse con la aplicación de los siguientes principios:

1/ Jerarquización de los datos, descendiendo en la estructura del programa y en su nivel de detalle.

2/ Pasar de un qué muy general a un qué específico utilizando los recursos abstractos.

3/ Razonamiento por etapas:

1º etapa:
¿ Qué hay que hacer ?. Se olvida el cómo se hace.

2º etapa:
¿ Es codificable ?
Sí, entonces salida
No, entonces ir a la 3º etapa

3º etapa:
Redefinir el problema en subproblemas

La programación estructurada asume el problema según el procedimiento “top-down”, de arriba abajo; aplica unas estructuras básica predeterminadas y utiliza recursos abstractos, es decir, se concibe el problema de una forma natural, no en términos de instrucciones de ordenador, descendiendo hasta llegar al lenguaje de programación.

Estos principios se pueden desarrollar de diversas formas, lo que da lugar a distintas técnicas de programación estructurada. Las principales son:

– Método Warnier
– Método Bertini

Las ventajas más sobresalientes con respecto a la programación tradicional o convencional, es la sencillez de seguir un método y una vez aprendido éste, el programador sólo tiene que realizarlo paso a paso, con lo que se reduce la posibilidad de que el programador se equivoque.

Hay que destacar la independencia de partes dentro del programa. Esto permite que las mismas puedan ser tratadas por distintos programadores y que el mantenimiento resulte más sencillo, ya que caso de tener que realizar modificaciones, sólo habría que modificar la parte de la estructura afectada. Es en este sentido en el que se acerca al concepto de programación modular.

Metodología Warnier

La metodología Warnier es una técnica de programación estructurada que comenzó a ser utilizada de forma significativa a partir de mediados de los años setenta.

Esta metodología presenta un alto grado de formalización, por lo que necesita una formación y un tiempo superior a otras para su empleo eficiente, pero en contrapartida, permite un alto grado de automatización, proporcionando una mayor productividad y una mejor calidad.

Se basa en cuatro principios fundamentales:

A. Estructuras Básicas.
B. Empleo de la metodología de desarrollo “top-down”.
C. Establecimiento de una normalización.

Los principios A y B se explicaron en apartados anteriores. En cuanto al apartado C: se establece una normalización para el proceso. Warnier ataca el problema lógico con un formalismo matemático basado en la TEORÍA CONJUNTISTA, que utiliza para definir los datos de entrada, los datos de salida y los procedimientos que resuelven el problema.

Tanto los datos de entrada y los de salida como los procedimientos son conjuntos de informaciones. La solución a un problema informático consiste, por tanto, en la organización lógica de los conjuntos de informaciones que intervienen en el mismo.

Para el conjunto de los datos de entrada se dispone del Archivo Lógico de Entrada {ALE} , de igual forma que para el conjunto de datos de salida se dispone del Archivo Lógico de Salida {ALS} . El conjunto de los procedimientos se representa mediante un Cuadro de Descomposición de Secuencias {CDS} .

La metodología Warnier se desarrolla en cuatro etapas:

1ª etapa: Se definen los datos de entrada/salida.

2ª etapa: Se realiza el diseño lógico de los datos del programa, para lo cual se ordenan los datos de entrada/salida de forma lógica haciendo uso del archivo lógico de entrada y el archivo lógico de salida que es una descomposición jerarquizada de los datos de entrada/salida. Las operaciones o procedimientos para obtener los datos de salida a partir de los de entrada vienen reflejadas en el cuadro de descomposición de secuencias.

3ª etapa: Organización secuencial. Se organizan secuencialmente los datos de entrada/salida y los procedimientos con una serie de normas en las que trata como conjuntos al archivo lógico de entrada, al archivo lógico de salida y al cuadro de descomposición de secuencias, por lo que se hace necesario el uso de una simbología y una estructura de control para relacionar los datos.

4ª etapa: Se crea el pseudocódigo.

La figura que se muestra a continuación pone de manifiesto estas cuatro etapas.

La simbología de la representación estructurada propuesta por Warnier se basa en el uso de llaves, corchetes y otros símbolos para relacionar subconjuntos y conjuntos. Un programa se representa por un único diagrama que contiene todas las operaciones necesarias para solucionar el problema. Estas operaciones se colocan secuencialmente a la derecha de una llave en cuya parte izquierda se coloca el nombre del programa. En la parte superior de la llave figura el comentario INICIO, y en la parte inferior de la llave figura el comentario FIN.

El aspecto de una representación de Warnier se puede observar a continuación:

Metodología Bertini

La metodología Bertini está dirigida hacia el lenguaje de programación COBOL. Se representa el algoritmo mediante una estructura arborescente, llamada árbol programático, que se debe construir después de realizar el estudio y la descripción de los datos de entrada y salida.

La ventaja de utilizar el denominado árbol programático para codificar el problema es que esta operación se realiza de una forma muy sencilla. Además existe la misma facilidad para pasar del problema codificado al árbol programático.

Además de los árboles programáticos también utiliza las estructuras básicas: secuencial, alternativa simple y repetitiva.

Para diseñar el árbol programático la metodología Bertini hace uso de determinadas herramientas:

1/ Un círculo para cada tratamiento. Cada conjunto de tratamientos o de instrucciones se define con un círculo que se localiza en un nodo del árbol.

2/ Cuando el tratamiento es compuesto utiliza rectángulos para indicar las acciones que no se descomponen en más procesos.

En este método la lectura del programa se hace recorriendo el árbol programático en orden inverso o postorden, es decir, primero se visita la raíz, después se recorre el subárbol derecho en postorden, y después se recorre el subárbol izquierdo en postorden.

Representación de la estructura alternativa:

En el esquema siguiente si la condición C1 se cumple se realiza P1 y si no se cumple C1 se realiza P2.

En la figura siguiente si se cumple C1 se realiza P1, en otro caso no se hace nada.

Representación de la estructura Repetitiva:

1º Se evalúa la condición C2
2º Si C2 se verifica se vuelve a P
3º Si C2 no se verifica entramos a estudiar el tratamiento T.

Representación de estructuras Complejas:

Secuencial:

Jerarquizada:

La metodología Bertini establece una serie de Normas obligatorias:

1.- Es obligatorio escribir los nombres de los tratamientos que van en círculos.

2.- Los nombres de las condiciones siempre van definidos junto con el árbol programático.

Por otro lado, establece otra serie de normas pero en este caso no obligatorias, como por ejemplo la siguiente:

- Todas las instrucciones de los procedimientos se ponen debajo de ellos con las propias instrucciones en Cobol o en lenguaje natural.

El método Bertini se basa en:

1/ La lectura anticipada de registros.

2/ El diseño “top-down”, que sigue la jerarquía de niveles igual que en la metodología Warnier; es lo que se conoce como el principio del objeto complejo.

3/ El principio de selección, que califica de incorrecto sacar un tratamiento común fuera de su nivel, lo que implica seleccionar la posición o lugar adecuado para cada conjunto de tratamientos.

Maestro Oliver, Y.

PROGRAMACIÓN ESTRUCTURADA

Fuente: Britannica

So, what do you think ?