RESUMEN
La modularidad es la capacidad que tiene un sistema de ser estudiado, visto o entendido como la unión de varias partes que interactúan entre sí y que trabajan para alcanzar un objetivo común, realizando cada una de ellas una tarea necesaria para la consecución de dicho objetivo. 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.

Palabras claves: común, comunicarse, dividido, independiente, interactúan.

INTRODUCCIÓN
Ingeniería de software es la producción de software con calidad. Calidad implica dos tipos de factores: internos y externos. Los factores externos son cualidades que son "detectadas" por los usuarios, por ejemplo: velocidad y facilidad de uso. Los factores internos son cualidades perceptibles por profesionales del área de la computación, por ejemplo: modularidad y legibilidad.
Factores externos:
1. Correctitud: Capacidad para realizar con exactitud las tareas definidas en las especificaciones.
2. Robustez: Capacidad de reaccionar apropiadamente ante condiciones excepcionales.
3. Extensibilidad: Facilidad de adaptar los productos de software a los cambios en la especificación.
4. Reutilización: Capacidad de los elementos de software de servir para la construcción de muchas aplicaciones diferentes.
5. Compatibilidad: Facilidad de combinar unos elementos de software con otros.
6. Eficiencia: Capacidad para exigir la menor cantidad posible de recursos (tiempo de procesador, espacio de memoria, ancho de banda, etc.).
7. Portabilidad: Facilidad de transferir los productos de software a diferentes entornos de hardware y software.
8. Facilidad de uso: Cubre la facilidad de instalación, de operación y de supervisión.
9. Funcionalidad: Conjunto de posibilidades que proporciona un sistema.

El mantenimiento no se menciona como un factor, pero se estima que gran parte del costo del software se dedica al mismo.

A partir de los objetivos de extensibilidad y reutilización, dos de los factores de calidad más importantes, se desprende la necesidad de tener arquitecturas de sistemas flexibles, hechas con componentes autónomos de software. Esto se logra con una adecuada modularidad.

DESARROLLO
¿Por qué descomponer un problema en partes?
Experimentalmente está comprobado que:
1. Un problema complejo cuesta más de resolver que otro más sencillo.
2. La complejidad de un problema global es mayor que la suma de las complejidades de cada una de sus partes por separado.

Según esto, merece la pena el esfuerzo de dividir un problema grande en subproblemas más pequeños. Ahora la cuestión es ¿cómo realizar la descomposición?; realizando un estudio descendente Top-Down que pueda llevar desde la concepción del problema global hasta identificar sus partes. Esta técnica se repite aplicando una estrategia llamada de refinamiento sucesivo, que consiste precisamente en volver a aplicar el estudio descendente Top-Down a cada subproblema una y otra vez hasta obtener subproblemas suficientemente pequeños.

¿Cuándo parar el refinamiento?
Un refinamiento excesivo podría dar lugar a un número tan grande de sub problemas que haría poco práctica la descomposición. Se tendrán en cuenta estos criterios para dejar de descomponer:
1. Cuando no haya tareas bien definidas.
2. Cuando la interfaz de un sub problema sea tan complicada como el propio sub problema

Modularidad
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. El principal beneficio de la modularidad es que permite la aplicación del principio de separación de intereses en dos fases: al enfrentar los detalles de cada módulo por separado ignorando detalles de los otros módulos, y al enfrentar las características globales de todos los módulos y sus relaciones para integrarlos en un único sistema coherente. Si estas fases son ejecutadas en ese orden se dice que el sistema es diseñado de abajo hacia arriba (bottom up), en el orden inverso se dice que el sistema es diseñado de arriba hacia abajo (top down).

El principio de modularidad tiene tres 3 objetivos principales: capacidad de descomponer un sistema complejo, capacidad de componerlo a partir de módulos existentes y comprensión del sistema en piezas (o pedazos).

La posibilidad de descomponer un sistema se basa en dividir en subproblemas de forma top down el problema original y luego aplicar el principio a cada subproblema en forma recursiva. Este procedimiento refleja el bien conocido principio de Divide y Vencerás (Divide & Conquer).

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.

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.

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.

Jerarquía de módulos
Ésta es una consecuencia directa de la descomposición del problema mediante refinamientos sucesivos, el resultado será un conjunto de módulos estratificados en capas a modo de pirámide donde en la cima habrá un único módulo que representará al programa global y en los niveles inferiores aparecerán los módulos resultantes de las sucesivas divisiones.

Al final, debe obtenerse una estructura piramidal donde los módulos de los niveles superiores se encargan de las tareas de coordinación, lógica de la aplicación y manipulación de los módulos inferiores; estos otros deberán realizar tareas de cálculo, tratamiento y entrada/salida de información.

Algo más sobre módulos [1]
Dentro de una estructura software un modulo puede ser categorizado como:
Modulo secuencial:
Se referencia y ejecuta sin interrupción aparente. Son los más frecuentes.

Modulo incremental (corrutina):
Puede ser interrumpido y restablecido posteriormente. Estos módulos mantienen un puntero de entrada que permite al modulo restablecer el punto de interrupción.

Modulo paralelo (conrutina):
Se ejecuta simultáneamente con otro u otros módulos en entornos de multiprocesadores paralelos.
Las corrutinas y conrutinas requieren unos métodos especiales de diseño desde las primeras etapas del desarrollo.

Características de los módulos:
Contienen instrucciones, lógica de proceso y estructuras 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 a otros módulos.

Existen muchos criterios para definir la modularidad del sistema que van a determinar las estructuras resultantes para un sistema. Entre ellos:

El criterio convencional:
Cada modulo junto con sus subordinados corresponden a un paso del proceso en la secuencia de ejecución.
El criterio de ocultación: Cada modulo oculta a otros módulos una decisión difícil o modificable del diseño.
El criterio de abstracción de datos:
Cada modulo oculta detalles de representación y manipulación de la información.
Niveles de abstracción:
Los módulos y colecciones de módulos proporcionan una jerarquía de servicios más complejos.
Acoplamiento y cohesión:
Estructuración del programa para lograr la máxima cohesión y el mínimo acoplamiento.
Modelización de problemas:
La estructura modular de un problema se ajusta a la estructura del problema a resolver.

CONCLUSIONES
Un correcto diseño modular reduce la complejidad, facilita los cambios y da como resultado una implementación más fácil, posibilitando el desarrollo paralelo de diferentes partes del sistema, sin embargo es muy importante tener en cuenta cuando parar el refinamiento sucesivo para evitar la aparición de módulos que sean incapaces de definir una tarea.

GLOSARIO DE TERMINOS
Acoplamiento: Se define como el grado de interdependencia que hay ente los distintos módulos de un programa; lo deseable es que esta interdependencia sea lo menor posible, es decir, un bajo acoplamiento. Los niveles de acoplamiento, ordenados de menor (más deseable) a mayor (menos deseable) son:
- Acoplamiento normal.- Un módulo llama a otro de un nivel inferior y tan solo intercambian datos (parámetros de entrada/salida).
- Acoplamiento Común.- Dos módulo acceden a un mismo recurso común, típicamente memoria compartida, una variable global o un fichero.
- Acoplamiento de contenido.- Ocurre cuando un módulo necesita acceder a una parte de otro módulo.
- Cohesión: Se define como la medida de fuerza o relación funcional existente entre las sentencias o grupos de sentencias de un mismo módulo. Un módulo coherente ejecutará una única tarea sencilla interactuando muy poco o nada con el resto de módulos del programa. Se persigue que los módulos tengan una alta cohesión.

BIBLIOGRAFÍA
Modularidad.
Disponible en: http://es.wikipedia.org/wiki/Modularidad , Consultado 2 de febrero de 2008.

REFERENCIAS
[1]. Yepes Moyano, Miguel. Apuntes resumen de ingeniería del software, Junio de 2004, Universidad de Córdoba.

AUTOR
Alexander Rodríguez Torres.
Universidad de las Ciencias Informáticas.
Abril de 2008.
atorres@uci.cu

Enviado por Alexander Rodriguez Torres
Contactar mailto:atorres@uci.cu

Código ISPN de la Publicación: EkEppkkyAlHWhlhKZu
Publicado Monday 5 de May de 2008