Como se ha explicado un sistema complejo puede dividirse en piezas más

simples llamadas módulos, un sistema compuesto de módulos es llamado

modular. La modularidad es acto de fragmentar un programa en componentes
individuales puede reducir su complejidad en algún grado.
Cada una de esas partes en que se encuentre dividido el sistema recibe el
nombre de módulo. Idealmente un módulo debe poder cumplir las condiciones
de caja negra, es decir, ser independiente del resto de los módulos y
comunicarse con ellos (con todos o sólo con una parte) a través de unas entradas
y salidas bien definidas.
Es correcto decir que la modularidad y el encapsulamiento van de la mano.
Por ejemplo
En C++ no son más que ficheros compilados separadamente. Las dependencias
entre archivos pueden declararse mediante el macro #include. En Pascal la
sintaxis para los módulos distingue entre la interfaz y la implantación de un modo.
Pueden declararse solamente en la interfaz del módulo. Ada un package tiene
dos partes: la especificación del paquete y el cuerpo del mismo.
Los módulos sirven como los contenedores físicos en los que se declaran las
clases y objetos del diseño lógico realizado. Pueden utilizarse puertas NAND,
NOR, NOT, para construir la lógica necesaria, pero estas deben estar
empaquetadas.
Para problemas muy pequeños, el desarrollador podría decidir declarar todas las
clases y objetos en el mismo paquete.
En el diseño estructurado tradicional, la modularización persigue ante todo el
agrupamiento significativo de subprogramas, utilizando los criterios de
acoplamiento y cohesión.
Los principios de abstracción encapsulamiento y modularidad son sinérgicos. Un
objeto proporciona una frontera bien definida alrededor de una sola abstracción,
y tanto el encapsulamiento como la modularidad proporcionan barreras que
rodean a la abstracción.
Hay dos problemas técnicos más que pueden afectar a las decisiones de la
modularización.
Primero, puesto que los módulos sirven usualmente como las unidades de
software elementales e indivisibles a la hora de reutilizar código, un desarrollador
debería empaquetar clase y objetos en modulo que la forma de su reutilización
fuera conveniente.
Segundo, muchos compiladores generan código objeto en segmentos uno para
cada módulo. Por tanto, puede haber límites prácticos al tamaño de un módulo
individual.
En los lenguajes orientados a objetos, como Java, el concepto esencial es el de
clase, y los programas consisten básicamente en conjuntos de declaraciones de
clases. En la mayoría de los lenguajes OO, existen, sin embargo, mecanismos
para agrupar las clases relacionadas en conjuntos de clases, asimilables a los
módulos de los lenguajes no OO.
Un módulo de programa tiene dos partes bien diferenciadas:

 La definición del módulo

 La invocación o llamada al módulo.

La definición de un módulo es donde se dice qué es lo que el mismo hará, es

decir, cuáles serán sus efectos al ser invocado, es decir cuando se ejecute.

Una invocación o llamada ocurre cuando se usa el módulo. En el punto del

programa donde se hace la invocación al módulo es donde, en tiempo de
ejecución del programa, se ejecutarán las acciones comprendidas en la
definición del módulo.

En un programa, por cada módulo, habrá una única definición, ya que bastará
con una vez para decirse qué es lo que el módulo hace. Sin embargo, puede
haber más de una invocación al mismo, ya que una solución puede usarse tantas
veces como sea necesario.

Características de los módulos:

 Contiene instrucciones lógicas de procesos y estructura de datos.

 Pueden ser compilados de forma individual y usados o almacenados
como bibliotecas.
 Pueden incluirse dentro de un programa.
 Se pueden usar invocando un nombre y cero o más parámetros.
 Pueden usar otros módulos.

El principio de modularidad tiene tres 3 objetivos principales:

 Capacidad de descomponer un sistema complejo

 Capacidad de componerlo a partir de módulos existentes
 Comprensión del sistema en piezas (o pedazos).

La posibilidad de componer un sistema está basada en obtener el sistema final

de forma bottom up a partir de componentes elementales. Idealmente en la
producción de software se quisiera poder ensamblar nuevas aplicaciones
tomando módulos de una biblioteca y combinándolos para formar el producto
requerido; estos módulos deberían ser diseñados con el objetivo expreso de ser
reusables, utiliza la técnica divide y vencerás.

La capacidad de comprender cada parte de un sistema en forma separada ayuda

a la modificabilidad del sistema. Debido a la naturaleza evolutiva del software
muchas veces se debe volver hacia atrás al trabajo previo y modificarlo. Si el
sistema solo puede ser comprendido como un todo} las modificaciones serán
difíciles de aplicar y el resultado será poco confiable. Cuando se hace necesario
reparar el sistema, la modularización apropiada ayuda a restringir la búsqueda
de la fuente de error a componentes separados.

La capacidad de comprender cada parte de un sistema en forma separada ayuda

a la modificalidad del sistema. Debido a la naturaleza evolutiva del software
muchas veces de debe volver hacia atrás al trabajo previo y modificarlo

Un método de diseño que merezca ser llamado modular, debería satisfacer

además de los objetivos anteriores los dos siguientes:

1. Continuidad modular: Se satisface si un pequeño cambio en la

especificación de un problema provoca sólo cambios en un solo módulo o en un
número pequeño de módulos.

2. Protección modular: Si produce arquitecturas en las cuales el efecto de una

situación anormal ocurrida en un módulo durante la ejecución, queda confinado
a ese módulo (o se propaga sólo a unos pocos vecinos).

De los objetivos expuestos para asegurar la modularidad, se derivan cinco

reglas:
1. Correspondencia directa: Conexión de un sistema de software con los
sistemas externos con que está relacionado. La estructura modular obtenida,
debe seguir siendo compatible con cualquier otra estructura modular en el
dominio del problema.

2. Pocas interfaces de módulos: Cada módulo debe comunicarse con el

menor número de módulos posible.

3. Interfaces pequeñas (acoplamiento débil): Si dos módulos se comunican,

deben intercambiar la menor información posible.
4. Interfaces explícitas: Siempre que dos módulos A y B se comuniquen, esto
debe ser obvio a partir del texto de A, del de B o de ambos.

5. Ocultar información: Mostrar sólo lo necesario.

Para alcanzar estos objetivos los módulos en los que se divida el sistema deben
tener alta cohesión y bajo acoplamiento. Un módulo tiene alta cohesión si todos
sus elementos están fuertemente relacionados y son agrupados por una razón
lógica, esto es todos cooperan para alcanzar un objetivo común que es la
función del módulo. La cohesión es una propiedad interna de cada módulo, por
el contrario el acoplamiento caracteriza las relaciones de un módulo con otros.
El acoplamiento mide la interdependencia de dos módulos, por ejemplo si el
módulo A hace una llamada a una rutina provista por el módulo B o accede a
una variable declarada por el módulo B. Si dos módulos dependen fuertemente
uno del otro tienen un alto acoplamiento lo que los vuelve difíciles de analizar,
comprender, modificar, testear o reusar en forma separada. Idealmente se
quiere que los módulos de un sistema tengan bajo acoplamiento.
Una estructura modular con alta cohesión y bajo acoplamiento permite ver los
módulos como cajas negras cuando se describe la estructura global del sistema
y luego encarar cada módulo por separado cuando se analiza o describe la
funcionalidad del módulo.