24 feb. 2014

Como ya se expuso en entradas anteriores los paradigmas de programación definen unos criterios de implementación de código basados en la filosofía procedimental de los mismos, existen múltiples clasificaciones válidas, basándonos en dos grandes grupos, la programación modular es un subconjunto que se halla dentro de lo que ya conocemos como programación imperativa y basa sus principios fundamentalmente en la división del código.

DIVIDE ET IMPERA (Divide y vencerás), tal y como afirmaron los romanos durante la conquista de Italia, es el concepto en el que se basa esta "filosofía" imperativa de la programación, ya se enfoca en dividir un programa en subconjuntos de código (módulos) a fin de dotar al código de legibilidad, flexibilidad y reutilización durante su manipulación, además, favorece el trabajo en equipo durante el desarrollo de un mismo proyecto.

Podemos ver la programación modular como una evolución funcional de la programación estructurada enfocada a adaptarse a la resolución óptima de propósitos mas ambiciosos así como dotar al código de cierto grado de reutilización (Uso del mismo fragmento de código en otro software diferente o en partes del mismo), ya que la resolución del problema en fragmentos puede implicar que algunos de esos fragmentos sean de utilidad directa para la creación de código de otro propósito, éste procedimiento de fragmentación también recibe el nombre de refinamiento sucesivo y es quizás el principal precursor de otros paradigmas orientados a la modularidad y reutilización de código. 



Pero, ¿Qué características describen lo que es, mas concretamente, un módulo?.Cada uno de estos fragmentos consta de una serie de operaciones (funciones y/o procedimientos) con el objetivo de resolver parte de el código final y algunos necesitan de otros previamente a su uso, en tal caso, puede comunicarse con ellos mediante una vía de comunicación que por lo general se define durante la creación del programa, también pueden llamar funciones de forma recursiva.

Objetivos de la programación modular:

  1. Pequeño tamaño: de esta forma el impacto de un cambio puede ser perfectamente aislado.
  2. Independencia modular: cuanto mayor es la independencia de los módulos y los procedimientos y funciones, más sencillo es trabajar con él. El diseño debe reducir la necesidad de compartir ficheros, datos, dispositivos y llamadas desde o hacia otros módulos y procedimientos y funciones.
  3. Características de caja negra: visión exclusiva de la funcionalidad de un módulo o procedimiento/función en base a sus entradas y salidas sin tener en cuenta como se realiza el proceso.
  4. Modelo conceptual: un diseño es más fácil de mantener si el modelo de diseño empleado se ha basado en conceptos lógicos de organización, los cuales sean más familiares y comprensibles para el personal de mantenimiento.
  5. Aislamiento de los detalles (encapsulación): en un sistema existen partes que reflejan la filosofía y otras que reflejan los detalles. Ambas partes deben diseñarse por separado para evitar que una variación en los detalles afecte a la filosofía del sistema. 

Ejemplo práctico (C++):


En conclusión, quizás deberíamos recurir a la programación modular, en caso de querer reutilizar el código, trabajar en equipo y/o en proyectos grandes, de forma completamente didáctica y/o más legible ó enfocar un programa a su posterior y fácil depuración y mantenimiento.
Reacciones:

0 comentarios:

Publicar un comentario