Modularidad

Un diseño modular se basa en la conocida estrategia de “divide y vencerás”. Descomponer de forma lógica y robusta el dominio de la aplicación.

Para conseguir la modularidad también debemos aplicar  las reglas de coherencia de métodos y clases que vimos con el principio de generalidad, es decir, hacer que nuestros componentes sean especialistas.

La modularidad facilita la reusabilidad y reduce costes, pero usada con prudencia.

Hay diversas condiciones que permiten llegar a la modularidad:

1.       Descomposición funcional. Ver cada módulo como un especialista (aplicación de la regla de la coherencia).

2.       Bajo acoplamiento. Además de ser especialistas tienen la mayor autonomía posible.

3.       Comprensibles para un observador externo. Esto es obvio, pero no es tan común como parece. El objetivo es que cada módulo sea comprensible de forma independiente (cómo mucho obligar a un somero repaso de otros módulos), para ello  los módulos deben obedecer a la lógica del dominio, ser legibles y estar bien documentados.

4.       De 1 y 3 se deduce la condición de la trazabilidad.

Cuando hablamos de un diseño modular hablamos de bajo acoplamiento o poca dependencia entre módulos. La regla del bajo acoplamiento implica:

• Interfaces pequeños: que los métodos públicos que intercambian información con otros módulos sean:

• El menor número posible.

• Pequeños. Pocos argumentos. Si un método tiene muchos parámetros, probablemente hay revisar el diseño o encapsular los parámetros en una clase.

                En el siguiente ejemplo tenemos dos versiones de un método. El segundo método no sólo tiene menos argumentos, además resulta más comprensible:

fabrica.solicitar_pedido( Fec, Hora, CodComer, Cantidad, PVP, ModoEntrega )

fabrica.solicitar_pedido( pedido nuevo_pedido )

• Regla de la continuidad modular: debemos diseñar y programas de tal forma que pequeños cambios en un módulo producen a lo sumo pequeños cambios en otro. Evidentemente, esto facilita la extensibilidad y minimiza los costes de mantenimiento.

• Regla de la protección modular: los errores en un módulo afectan como mucho a módulos adyacentes.

• Regla de la comunicación explicita: la comunicación entre módulos es clara. Normalmente por medio de interfaces con pocos parámetros y sin usar información global (que hace que la interacción quede oculta).

• Encapsular la implementación. También en los módulos hay que diferenciar lo público de lo privado. Un cambio en la parte privada no debería afectar al interfaz del módulo.

Antes dijimos que si  los módulos no obedecen a la lógica del dominio, no son legibles o no están bien documentados, entonces la descomposición es inútil y no permite la reusabilidad.

Cuando se dice que la descomposición de los módulos obedece a la lógica del dominio, se quiere decir que la mayoría de cada uno de  módulos debe ser una representación natural de entidades o relaciones del dominio (por ejemplo: cuenta, beneficiario, oficina, control de riesgo, etc.). Decimos la mayoría: ya que habrá módulos que no modelizan entes del dominio (pertenecen al dominio de la aplicación exclusivamente: interfaz gráfico, sentencia SQL, etc.).

Se debe representar la continuidad entre los conceptos del proceso de desarrollo.

La regla de la trazabilidad indica que cada conjunto lógico de entidades y relaciones del dominio tiene su correlato modular. Esto facilita la extensibilidad  y la reusabilidad.

Los métodos de Diseño orientado a facetas, orientados a aspectos o temas hacen énfasis en mejorar la trazabilidad de requisitos.

De todo lo anterior (coherencia, bajo acoplamiento, etc.) se deduce que gran parte de nuestras aplicaciones se descomponen en módulos que reflejan su especialización funcional:

• Interfaz con el usuario.

• Implementación. Se aplican cálculos y algoritmos específicos al dominio.

• Control. También implica conocimiento específico del dominio. Componentes que especifican el orden de las tareas y las condiciones de disparo (Si-entonces). Comprueban estados y errores. No tienen cálculos o algoritmos complejos. Por ejemplo, reglas de negocio del tipo: “Si el solicitante es cliente, entonces producir pedido; si no, solicitar registro de nuevo cliente”.

• Almacenamiento y conectividad. Módulos responsables de la interacción con la base de datos y otras aplicaciones.

En la práctica, sobre todo en aplicaciones que no son muy grandes,  se suelen reunir en un módulo las clases de implementación y de control.

Un ejemplo es la arquitectura en tres capas, tan usual en aplicaciones Web:

• Presentación

• Reglas de negocio

• Acceso a datos (almacenamiento y conectividad)