En esta primera entrada de la serie sobre Programación Modular discutiré los conceptos básicos de esta forma de programar y servirá como previo a los ejemplos que se mostrarán en entradas próximas.

¿Qué es la programación modular?

Los avances en la programación de computadoras han permitido crear hermosas y grandes aplicaciones, que no se pueden comparar a los primeros programas que se creaban en los años 1960’s y 1970’s.  Sin embargo, las aplicaciones modernas requieren un mayor esfuerzo para ser desarrolladas y no es factible que una persona se encargue de todo el proceso, desde su concepción, análisis, desarrollo, implementación y puesta en marcha. Por ello, las empresas que se dedican al desarrollo de software trabajan en base a equipos de desarrollo, en donde a cada integrante se le asigna una etapa del proceso. A su vez, el equipo de desarrollo se compone de varios programadores que reciben los requisitos del sistema y trabajan en conjunto para implementarlo. Esto implica que la tarea de programación se distribuye a través de varios programadores.

Este paradigma parte del principio “divide y vencerás”, pues resulta más fácil resolver un problema complejo cuando se divide en partes manejables.

La programación modular es un paradigma de programación que consiste en dividir un programa en módulos o subprogramas con el fin de hacerlo más legible y manejable [Wikipedia]

Simplemente consiste en descomponer un problema complejo o grande en partes más pequeñas. Estas partes pequeñas reciben diferentes nombres como módulos, subprogramas, funciones, procedimientos y/o métodos. De forma general las llamaremos módulos y de manera específica orientada al lenguaje Java las llamaremos métodos.

Ventajas de la programación modular.

Las ventajas de la programación modular son:

• Reducir la complejidad del problema
• Reducir el tamaño del problema
• Favorecer el entendimiento del problema
• Facilitar la cooperación entre programadores
• Reutilizar código.
• Facilitan la lectura del código.
• Ayuda a ser más clara la lógica del programa [Julien Hennefeld]
• Protege contra efectos colaterales (destrucción accidental de datos de programa) [Julien Hennefeld]
• Permite plantear una solución completa del problema, para luego profundizar en los detalles.
• La depuración es más fácil de realizar ya que primero se corrigen errores en los módulos de nivel inferior.

¿Cuáles son los componentes de un programa modular?

Un programa que ha sido diseñado bajo este paradigma contiene:

• Un módulo principal, encargado de coordinar la ejecución de los demás módulos.
• Una serie de módulos que resolverán cada de una las tareas concretas del problema

Figura 1. Estructura de un programa modular

Estrategias de programación

Para entender las estrategias del paradigma de la programación modular, debemos conocer un poco sobre los inicios de la programación.

Un poco de historia.

Como sabemos, las primeras computadoras eran máquinas grandes, muy complejas y que su capacidad para resolver problemas era muy limitada. En esa época, programar implicaba conectar o desconectar un circuito. Posteriormente aparecieron las tarjetas perforadas, el lenguaje ensamblador y los primeros lenguajes de alto nivel como FORTRAN, ALGOL, entre otros.

Figura 2. Fotografía de la computadora ENIAC [chw.net]

El código espagueti.

Al surgir lenguajes de alto nivel también creció la complejidad de los programas y la necesidad de escribir mejor código. En ese entonces, una estructura muy utilizada, heredada del lenguaje ensamblador fue la sentencia GOTO. Esta instrucción transfiere el control desde un punto del programa hacia otro, ejecutando lo que se conoce como un “salto”.  Estos saltos frecuentes generaban un problema al momento de seguir el flujo de control del programa para corregir  errores. Se considera que el abuso de esta instrucción genera código inconsistente, incompleto y/o complicado de mantener. Uno de sus principales detractores fue Edsger Dijkstra en una carta llamada “Go To Statement Considered Harmful” (‘Instrucción Go To Considerada Dañina‘).

A los programas que abusaban de esta instrucción se les conocía como “código espagueti”, de forma despectiva, comparando lo difícil (y a veces imposible) que sería seguir el hilo de un espagueti en un plato lleno de ellos. En la figura 3 te muestro una idea de cómo se veía el trazado de un código espagueti. ¿Aprecias lo difici que es seguir el flujo de control del programa?

Figura 3. Ejemplo de código espagueti

Paradigmas de la programación modular.

Por este motivo, entre lo 60’s y 70’s surge la programación estructurada, incorporando estructuras de control de flujo que hacen que un programa sea más fácil de trazar. Sin embargo, con programas grandes y complejos es necesario dividir el programa en unidades más pequeñas.  Es entonces cuando surge el paradigma de la programación modular buscando dividir un problema en sub. En ese punto surgen dos estrategias derivadas y aplicables a la programación modular:

• Top-down
  • El enfoque top-down o “de arriba hacia abajo” es la descomposición del programa en sub-programas, especificando sin entrar en detalles, los módulos inferiores. También se le llama programación descendente, porque los sub-programas o módulos van surgiendo “hacia abajo”, es decir, conforme bajamos de nivel se ve la necesidad de generar más módulos.
• Bottom-up:
  • La estrategia bottom-up o “de abajo hacia arriba” considera que primero se deben programar los módulos del nivel más bajo. Y después van surgiendo los módulos de niveles superiores. Implicar enfocarse en los detalles primero, y después en lo general.

Top-down fue ampliamente promovido en la década de los 1970’s por  Harlan Mills y Niklaus Wirth, quienes a su vez trabajaron en los conceptos de la programación estructurada. La estrategia top-down fue el estándar por muchos años hasta que surgió el paradigma de Programación Orientada a Objetos. Sin embargo, aún es utilizada como una estrategia rápida de diseño.

Por otra parte, bottom-up no tuvo tanto auge para el desarrollo de programas, pero sí en la fase de pruebas. Este paradigma pues hace énfasis en las pruebas tempranas, y en las pruebas de integración de un sistema.

Uso actual

Algunos programadores, aún sin saberlo, utilizan estas dos estrategias durante algún momento del ciclo de desarrollo de un software. Para construir el sistema completo, asignar tareas a los programadores y/o equipo de desarrollo, o simplemente para esbozar un primer acercamiento de lo que será un sistema, se utiliza top-down. Tiene sentido, pues ayuda a descomponer el problema modularmente, y hacia abajo, permitiendo descubrir las tareas de los niveles inferiores, necesarios para el desarrollo del sistema.

Por otro lado, al momento de integrar el sistema, los programadores suelen usar un enfoque bottom-up. Esto es, toman el módulo más inferior y hacen pruebas de cómo se integrará con el módulo superior que hace el llamado.  Una vez que ambos han sido probados y se ha observado que no tienen problemas de integración, pueden ahora a su vez ser integrados con un módulo en otro nivel superior.

Si bien son estrategias antiguas, es importante que los programadores nóveles las conozcan para que puedan aplicarlas cuando sea necesario.

Continúa leyendo sobre la programación modular en la siguiente entrada.

¡Hasta la próxima!

Guardar

Guardar