Programación modular

Introducción
La programación modular está presente desde los primeros tiempos de la
programación como disciplina. De hecho existía programación modular antes de
existiera programación estructurada para poder abordar problemas complejos.
Cuando se requieren resolver problemas más complejos, en los que el número de
instrucciones aumenta, existen técnicas que permiten resolverla de forma eficiente
estos problemas, facilitando al programador la construcción de la solución.
Se puede definir a la programación modular como aquella que usa el concepto de
dividir un problema complejo en subproblemas más pequeños, hasta que estos
sean fáciles de tratar y resolver por separado. Así la solución de los subproblemas
en conjunto dan como resultado la solución del problema completo (López
Román, 2003).
Aplicando este principio a la hora de hacer un programa, entonces habría que
dividir el programa en “subprogramas” que realicen tareas específicas. Es
importante considerar que para poner en práctica la modularización, es necesario
un mecanismo que permita aplicarla en los lenguajes de programación; este
mecanismo existe prácticamente en todos los lenguajes y consiste en la
posibilidad de definir tareas específicas como módulos de código independientes
del programa principal. En consecuencia estos módulos de código independientes
del programa deben poder invocarse desde el programa o módulo principal para
que empiecen a trabajar y deben acabar devolviendo el control al programa o
módulo principal cuando terminen de ejecutarse.
La programación modular permite:
a) Dividir la complejidad de un problema convirtiendo problemas complejos en
un conjunto de problemas más simples y por tanto más sencillos de
implementar.
b) Reutilizar el código de un programa en cualquier momento de la ejecución
del mismo.
Evidentemente la división de un problema en módulos no tiene por qué ser ni
única ni obligatoria, pero si es claramente aconsejable a la hora de abordar un
problema para lo cuál que se aplican diversos conceptos y técnicas entre las que
se encuentran el diseño descendente, el proceso de modularización y el paso de
parámetros, por mencionar algunos. A continuación se abordaran cada uno de
ellos.

4
1. Diseño descendente.
Es una técnica que permite diseñar la solución de un problema con base en la
modularización o segmentación dándole un enfoque de arriba hacia abajo (Top
Down Design). Esta solución permite dividir el problema en módulos que se
estructuran e integran jerárquicamente (ver figura 1), como si fuera el organigrama
de una empresa (López Román, 2003).

Subprograma
principal

Módulo I Módulo II

Módulo I.I Módulo I.II Módulo II.I

Figura 1. Concepción de módulos.

1.1 Módulo.
Es un segmento, rutina, subrutina, subalgoritmo o procedimiento que puede ser
definido dentro de un algoritmo mayor con el propósito de ejecutar una tarea
específica, pudiendo ser llamado o invocado desde el módulo principal cuando se
requiera.
Este enfoque de segmentación o modularización es útil:
 Cuando existe un grupo de instrucciones o una tarea específica que debe
ejecutarse en más de una ocasión.
 Cuando un problema es complejo o extenso, entonces la solución se
“divide” o “segmenta” en módulos que ejecutan “partes” o tareas
específicas.
Dicha solución se organiza y divide en partes más pequeñas que sean fácilmente
manejables y que, lógicamente, puedan ser separadas; así cada una de estas
partes se dedica a ejecutar una determinada tarea, lo que redundará en una
mayor concentración, entendimiento y capacidad de solución a la hora de diseñar
la lógica de cada una de estas.
Las partes en las que se divide una empresa (funcionalmente separadas) son el
equivalente a los módulos o segmentos del algoritmo, algunos de ellos son
módulos directivos o de control, que son los que se encargarán de distribuir el

5
trabajo a los demás módulos, de tal forma que se puede diseñar una especie de
organigrama que indique la estructura general de un algoritmo (López Román,
2003).

1.2 Diseño descendente con pseudocódigo.

Cuando el enfoque de diseño descendente se utiliza de manera conjunta con la
técnica del pseudocódigo, se logra una herramienta de diseño de algoritmos
(programas) muy poderosa. A continuación se explica el procedimiento para
hacerlo:
1. Se tiene un problema ya analizado.
2. Se diseña la estructura general del algoritmo utilizando el diseño
descendente, es decir, se definen los módulos que integrarán el algoritmo.
3. Se toma cada módulo y se diseña su lógica utilizando pseudocódigo.
La llamada de un módulo en pseudocódigo se hace siguiendo la siguiente
sintaxis:
Llamar NombreModulo
Donde:
Llamar: identifica la acción de llamar o invocar a un módulo
NombreModulo: es el nombre del módulo que se está llamando

Formato general de un algoritmo con módulos:

Parte 1. Se tiene el encabezado del algoritmo. Es obligatorio.

Parte 2. Se tiene una parte de declaraciones globales, donde se pueden declarar
 Constantes
 Tipos
 Variables
Que son globales, es decir, se pueden utilizar en cualquier módulo del
algoritmo. Es opcional; es decir, puede estar presente o no.
Parte 3. Se tiene el módulo principal, es el paso 1 del algoritmo. Es obligatorio.

6
Parte 4. Se tiene uno o más módulos o funciones subordinados, son opcionales
(ver figura 2).

Encabezado del algoritmo

(obligatorio)

Declaraciones globales
(opcional)

Módulo principal
(obligatorio)

Uno o más módulos o funciones

subordinados
(opcional)

Figura 2. Algoritmo con módulos.

2. Proceso de modularización o segmentación.

El proceso de segmentación consiste en hacer una abstracción del problema, del
cual se tiene inicialmente el panorama general. Enseguida se procede a
“descomponer” o “dividir” el problema en partes pequeñas y simples (ver figura 3).
I. Se forma un primer módulo enunciando el problema en términos de la
solución de éste.

II. Se toma este módulo y se busca la forma de dividirlo en otros módulos más
pequeños, que ejecuten tareas o funciones específicas. Normalmente serán
las mismas funciones que se desea que ejecute el algoritmo, lo que permite
de una forma simple definir los módulos, y de esta forma dividir el problema
en partes más manejables.

III. Se repite el paso anterior para cada módulo nuevo definido, hasta llegar a
un nivel de detalle adecuado, es decir, hasta hacer que cada módulo
ejecute una tarea específica, claramente definida y que el diseño y la
codificación de la lógica del mismo resulte fácil (Ver anexo I).

7
 Problema en términos de
la solución general

Módulos que ejecuten

Módulos más pequeños tareas o funciones
específicas

Figura 3. Descomposición de módulos.

2.1 Modularización funcional.

Los bloques de código independientes del programa principal que se han definido
como módulos tienen siempre una connotación funcional. Esto quiere decir que
estos segmentos realizan alguna tarea específica por lo que cuando se definen
estos subprogramas, lo que se hace es identificar actividades concretas y
desarrollar el subprograma para resolverlas.
Una ventaja al dar solución a los problemas mediante la modularización es que se
pueden “encapsular” las distintas tareas que se quiere realice el programa,
logrando así colocar como una unidad todas las instrucciones relevantes para una
sección específica del programa, lo que también permite que cuando existe la
necesidad de realizar algún cambio en dichas instrucciones se tenga claridad a
donde dirigirse para hacer ese cambio y no haya necesidad de analizar de manera
completa todo el desarrollo, lo que hace que los programas sean fáciles de probar
y mantener.
Lo anterior permite que si se logra tener un programa que resuelva una tarea
específica y este proceso está suficientemente probado, entonces una vez que
está programado, es posible usarlo tantas veces como sea necesario con la única
condición de conocer los datos que lo alimentan y los resultados que arroja. Por
otro lado, esta condición evita que se repita el código muchas veces y que si se
comete un error de programación en este segmento del código solo se tenga que
corregir una vez.
Estos bloques de código o subprogramas reciben distintas denominaciones en los
diferentes lenguajes, por ejemplo en los no orientados a objetos la división
tradicional distingue entre:

8
  Subprogramas, subrutinas o procedimientos, si pueden devolver más de un
valor.
 Funciones, si devuelven un único valor a través de su identificador.
La estructura del programa en función de sus módulos se puede representar con
los denominados diagramas de estructura, que son herramientas típicas del
diseño estructurado y forman parte de una completa metodología de trabajo. Estos
diagramas son una representación en forma de árbol jerárquico de la estructura
del software, donde los diferentes módulos se representan como cajas
rectangulares. La relación de invocaciones de unos módulos a otros se
representan en estos diagramas por medio de flechas y el sentido de las flechas
representa el orden de invocación de los módulos.

3. Cohesión y acoplamiento.
Los módulos deben cumplir dos características básicas para ser candidatos a una
buena división del problema.
 Alta cohesión: las instrucciones contenidas dentro de un módulo deben
contribuir a la ejecución de la misma tarea.
 Bajo acoplamiento: a dependencia entre módulos debe ser mínima. Lo que
implica que no debe haber dantos compartidos entre los módulos (ver figura
4).
Por lo general se espera que cada módulo de código realice una sola tarea; es
decir, todos los componentes de un módulo (sentencias) deben ir dirigidos a
resolver un y sólo un problema. A esta propiedad se le denomina cohesión y se
dice que los módulos deben ser cohesivos.

ALTA
Cohesión

BAJO
Acoplamiento

Figura 4. Características de programas modulares.

El objetivo en el diseño modular es conseguir módulos tan cohesivos como sea

posible. Muchas veces esto no es posible al cien por ciento pero siempre debe
pretenderse desarrollar módulos con alta cohesión.

9
La cohesión tiene que ver con que cada módulo del sistema se refiera a un único
proceso o entidad. A mayor cohesión el módulo en cuestión será más sencillo de
diseñar, programar, probar y mantener.
En el diseño estructurado, se logra alta cohesión cuando cada módulo (función o
procedimiento) realiza una única tarea trabajando sobre una sola estructura de
datos. Una prueba que se recomienda hacer a los módulos funcionales para ver si
son cohesivos es analizarlos y describirlos con una oración simple que contenga
un solo verbo activo. Si existe más de un verbo presente en la descripción del
procedimiento o función, se debía plantear más de un módulo, y volver a hacer la
prueba con los módulos resultantes (ver figura 5).

Estadísticas

Promedio Desviación estándar

Figura 5. Problema dividido en módulos.

Otro aspecto que destaca al usar modularidad es el acoplamiento que mide el

grado de relación de un módulo con los demás. Con un menor acoplamiento el
módulo es más sencillo de diseñar, programar, probar y mantener.
En el diseño estructurado, se logra bajo acoplamiento reduciendo las interacciones
entre procedimientos o funciones, reduciendo la cantidad y complejidad de los
parámetros y disminuyendo al mínimo los parámetros por referencia.

4. Alcance de las variables.

Cuando se consideran varios módulos de software y no un solo programa
principal, se pueden declarar variables tanto en el contexto global del algoritmo,
como de manera local en cada módulo a lo que se le conoce como alcance de las
variables, en otras palabras esto permite identificar la zona del programa donde
una variable es accesible “conocida”. Desde este punto de vista, las variables
pueden ser de dos tipos: locales o globales.

10
4.1 Variables globales.
Son las que son accesibles desde cualquier punto del programa y se pueden usar
desde cualquier módulo o subprograma, esto lleva a considerar que la variable
puede usarse en cualquier parte del programa y su valor se puede alterar
incontroladamente, y si posteriormente es necesario usar la variable en otra parte
del programa con su valor original, se tendrá un error. El punto donde se da el
error es fácil de localizar, pero no lo es tanto el origen del mismo. Este tipo de
efectos colaterales produce errores cuyo origen es difícil de trazar y localizar: La
programación modular sugiere que se evite el uso de variables globales (ver figura
6).

Algoritmo GLOBALES
num: Entero Declaración de num como variable global

Módulo principal
num ← 0
Llamar resultado
Escribir num Todos los módulos reconocen la variable
Fin Módulo principal num como global y la pueden cambiar

Módulo resultado
El resultado al num ←1
Fin Módulo resultado
escribir el valor
de num sería 1

Figura 6. Variables globales.

4.2 Variables locales.

Las variables locales sólo existen en un ámbito determinado del programa, por
ejemplo en un subprograma o en un bloque de sentencias. Solo pueden ser
utilizadas en el módulo donde fueron definidas (ver figura 7).
Entonces si son analizados los conceptos de variables globales y locales, es
posible resumir que cuando se usan variables locales, éstas son independientes
de las globales y de las de otros módulos.

11
 Algoritmo LOCALES
num:Entero Declaración de num como variable global

Módulo principal
num ← 0
Llamar resultado
Escribir num
Fin Módulo principal

Módulo resultado Al momento de declarar num dentro de un

num: Entero módulo, es una variable local y solo tiene
num ←1 efecto dentro de ese módulo
Fin Módulo resultado global y la pueden cambiar
El resultado al
escribir el valor
de num sería 0
Figura 7. Variables locales.

4.3 Parámetros.
Entre los módulos que componen la estructura completa de un problema, se
establece una serie de comunicaciones a través de determinadas interfaces
(llamadas a los módulos) que permiten el paso de información de un módulo a otro
así como la trasferencia del control de la ejecución del programa.
Un método puede aceptar información para usarla en su cuerpo de sentencias.
Esta información es suministrada en forma de literales, variables pasadas al
método a través de su cabecera y cada uno de estos elementos de información se
denomina parámetro.
De manera más formal se puede definir un parámetro como un valor que se pasa
al método cuando éste es invocado. La lista de parámetros en la cabecera (al
inicio) de un método especifica los tipos de los valores que se pasan y los
nombres por los cuales el método se referirá a los parámetros en la definición del
método.
 En la definición del método los nombres de los parámetros aceptados se
denominan parámetros formales.
 En las invocaciones al método desde algún punto del programa, los valores
que se pasan al método se denominan parámetros actuales (reales).
Los parámetros actuales y los parámetros formales no necesitan tener los mismos
nombres, ya que se corresponden por tipo y posición.

12