Descomposición y modularizacion.

La descomposición y modularidad son consecuencia de la complejidad de los problemas, y de la necesidad de hacer manejable el desarrollo de la solución de los mismos. Para abarcar el desarrollo del sistema complejo, el problema se divide en subproblemas más fácilmente manejables, que integrados formaran la solución al sistema completo. Más formalmente, Meyer [30] ha definido una serie de propiedades para evaluar la modularidad:

Descomposición Esta propiedad permite definir componentes de alto nivel en otros de bajo nivel. Esta descomposición puede ser recursiva, es decir, aplicando la máxima de divide y vencerás.

Composición La composición se puede ver como el problema inverso a la descomposición. Un módulo de programación preserva la composición modular si facilita el diseño de elementos de programación que se pueden ensamblar entre sí para desarrollar aplicaciones. Un ejemplo de composición modular son los componentes ya desarrollados (COTS, Commercial-off-the-Shelf). La composición modular está directamente vinculada con la reutilización, mediante mecanismos que permitan diseñar elementos que respondan a funcionalidades bien definidas y reutilizables en diversos de contextos.

Comprensión Un método de programación preserva la comprensión modular si facilita el diseño de elementos de programación que se pueden interpretar fácilmente sin tener que conocer el resto de los módulos.

Un aspecto fundamental de la comprensión es la documentación y en el caso particular de los componentes COTS, la gestión e indexación de los mismos para facilitar su reutilización.

Continuidad La continuidad se refiere a que un pequeño cambio en la especificación debe conllevar en la implementación un cambio igualmente pequeño. Una de las leyes de Lehman sobre la evolución del software, afirma que si un proyecto está vivo inevitablemente evolucionara y cambiara. Por tanto, es importante que los cambios en los requisitos repercutan en un número limitado y localizado de módulos.

Protección Esta propiedad consiste en que los efectos de las anomalías de ejecución queden confinados al módulo donde se produjo el error, o que se propaguen a un número limitado de módulos con los que interactúan directamente. Un ejemplo de protección se da en la validación de datos introducidos por parte del usuario, dicha validación debería hacerse en los módulos que tratan la entrada, sin permitir que los datos incorrectos se propaguen a aquellos módulos donde se procesan.

Medición de la modularidad.

Las propiedades y reglas mencionadas anteriormente buscan que las dependencias entre módulos sean mínimas. La modularidad se suelen medir con los conceptos de acoplamiento y cohesión definidos a continuación.

Acoplamiento:

El acoplamiento mide el grado de interconexión existente entre los módulos en los que se ha dividido el diseño de la arquitectura de un sistema software.

El objetivo es conseguir un acoplamiento bajo entre módulos, también llamado débil, genera sistemas más fáciles de entender, mantener y modificar, ya que cambios en la interfaz de un componente afectarían un número reducido de cambios en otros componentes. Por tanto, debemos acercarnos al mínimo número de relaciones posibles entre todos los módulos en la que un módulo sólo se comunicaría con otro módulo, es decir, (n-1) comunicaciones entre módulos, donde n es el número de módulos de un sistema (figura 1(a)).

Por el contrario debemos alejarnos del máximo número de conexiones, (n(n- 1)/2), donde se produce un acoplamiento fuerte (figura 1 (b)).

Además del número de conexiones, el grado de acoplamiento puede depender de la complejidad de las conexiones, los lugares donde se realicen

Figura 1: (a) Acoplamiento débil; (b) Acoplamiento fuerte

Las referencias a los módulos, el volumen y tipo de datos que intercambian los módulos.

Cohesión:

Otro aspecto fundamental del diseño, también derivado de una concepción modular del mismo, es la cohesión. Un subsistema o módulo tiene un alto grado de cohesión si mantiene unida funcionalidad común. Por ejemplo, una clase dedicada al manejo de fechas, tiene sólo operaciones relacionadas con las fechas y no otras funcionalidades que usen fechas como podrían ser la gestión de cumpleaños, etc.

Por tanto, el objetivo es diseñar módulos robustos y altamente cohesionados cuyos elementos estén fuertes relacionados entre sí buscando la cohesión funcional, en la que un módulo realiza operaciones bien definidas y suscritas a una funcionalidad requerida facilitando las propiedades compresibilidad, reutilización.

Cuando los módulos agrupan funcionalidad por otros motivos que no sean funcionalidad la cohesión no será óptima. Por ejemplo, cohesión secuencial en la que la funcionalidad se agrupa por la secuencia de ejecución, cohesión por comunicación al compartir los mismos datos, o la peor de todas, cohesión por coincidencia agrupando funcionalidad sin orden (cajón desastre).