En la programación modular
consta de varias secciones dividas de forma que interactúan a
través de llamadas a procedimientos, que integran el programa en su totalidad.
En la programación modular, el programa principal coordina las llamadas a los
módulos secundarios y pasa los datos necesarios en forma de parámetros.
A su vez cada modulo puede contener sus propios datos y llamar a otros módulos o
funciones. En la figura siguiente se muestra
un cuadro comparativo entre programación estructurada y modular.
Para redondear
la programación modu- lar es
un paradigma de programa- ción que
consiste en dividir un programa en módulos o subprogramas con el fin de
hacerlo más legible y manejable.
Al aplicar la programación
modular, un problema complejo debe ser dividido en varios subproblemas
más simples, y estos a su vez en otros subproblemas más simples.
Esto debe hacerse hasta
obtener sus problemas lo suficientemente simples como para poder ser
resueltos fácilmente con algún lenguaje de programación. Ésta técnica se
llama refinamiento sucesivo, divide
y vencerás ó análisis descendente (Top-Down).
Un módulo es cada una de las partes de un programa
que resuelve uno de los subproblemas en que se divide el problema
complejo original. Cada uno de estos módulos tiene una tarea bien
definida y algunos necesitan de otros para poder operar. En caso de que
un módulo necesite de otro, puede comunicarse con éste mediante una
interfaz de comunicación que también debe estar bien definida.
Uno de los problemas
habituales del programador ocurre cuando los programas alcanzan un tamaño
considerable en cuanto a línea de código. El problema se puede volver tan
complejo que fuera inabordable. Para mitigar este problema apareció la
programación modular.
Cada programa contiene un
módulo denominado programa principal que controla todo lo que sucede; se
transfiere el control a submodulos (posteriormente se denominarán subprogramas),
de modo que ellos puedan ejecutar sus funciones; sin embargo, cada submodulo
devuelve el control al módulo principal cuando se haya completado su tarea. Si
la tarea asignada a cada submodulo es demasiado compleja, este deberá romperse
en otros módulos más pequeños. El proceso sucesivo de subdivisión de módulos
continua hasta que cada módulo tenga solamente una tarea específica que
ejecutar. Esta tarea puede ser entrada, salida, manipulación de datos, control
de otros módulos o alguna combinación de estos. Un módulo puede transferir
temporalmente (bifurcación) el control a otro modulo; sin embargo, cada módulo
debe devolver el control al módulo del cual se recibe originalmente el control.
Algunos lineamientos para la programación modular
son:
1. Mantener cada módulo de un tamaño
manejable (de manera ideal incluyendo sólo una función)
2. Prestar atención particular en
las interfaces criticas (esto es, a los datos y a las variables de control que
pasan entre los
módulos)
3. Minimizar el número de módulos que el
usuario necesite modificar cuando haga cambios.
4. Mantener las relaciones jerárquicas
establecidas en las etapas de descenso.
Veamos un ejemplo de
cómo emplear el diseño descendente para resolver un problema. Supongamos
que un profesor quiere crear un programa para gestionar las notas de
sus alumnos.
Quiere que dicho programa le permita realizar tareas tales como asignar notas,
cambiar notas, ver las notas según distintas calificaciones, etc. A continuación
se muestra un esquema que representa una de las posibles divisiones del problema
en módulos
Un
procedimiento es un subprograma que realiza una tarea específica. Para invocarlo,
es decir, para hacer que se ejecute, basta con escribir su nombre en el
cuerpo de otro procedimiento o en el programa principal. Pero, hay que tener muy
en cuenta que su declaración debe hacerse antes de que sea llamado por otro
módulo. En un
procedimiento se compone de la palabra procedure seguida del nombre del
procedimiento y una lista de parámetros que es opcional.
Todas estas
diferencias y similitudes que hemos comentado, puedes apreciarlas en los
siguientes esquemas que representan las estructuras de un programa y de un
procedimiento:
Los parámetros (argumentos)
Como habrás observado, con los procedimientos nos llega un concepto nuevo, el de
los parámetros. A los parámetros
también se les conoce como argumentos y tienen la
misión de comunicar al procedimiento con el programa que lo llama. Por ejemplo, si quieres hacer
un subprograma que multimplique dos números, lo más cómodo es que al llamar al
procedimiento le pases los valores que
participarán en la operación. Podría ser algo como:
|
procedure
producto (a,b : integer; var rdo :
integer) ;
(* resto
del procedimiento *)
|
En el
ejemplo anterior se observan las dos clases de argumentos que existen en Pascal:
Los
parámetros por
valor tiene
dicho nombre porque lo que recibe el subprograma no son más que copias de los
valores de los datos que el programa invocador le pasa. Por tanto si en el
procedimiento modificamos alguno de estos valores, los datos originales
permaneceran inalterados. En el ejemplo, son a y b.
En cambio,
en los parámetros por
referencia lo que se pasa al
procedimiento son los datos en sí. Y si éste los modifica, los cambios
permanecerán una vez que la ejecución vuelva al módulo que invocó al
procedimiento. Se utilizan para obtener valores de los cálculos que haga un
subprograma, y en el anterior ejemplo es rdo.
¿Cómo se especifica que
un parámetro es por valor o por referencia?
Pues es tan sencillo como anteponer la palabra reservada var cuando
quieres que un argumento sea considerado como referencia. Esto se observa
claramente con el parámetro rdo del ejemplo.
|
