MODULARIDAD
Modularidad en Ciencias de la Computación: es la característica por la cual un programa de ordenador
está compuesto de partes separadas a las que llamamos módulos. El diseño estructurado es la técnica de diseño
de algoritmos en que se basa la programación modular, paradigma de programación que persigue desarrollar
programas modulares.
Módulo: Un módulo que se supone que representa una función lógica es una secuencia léxicamente continúa de
instrucciones que se encuentra limitado por elementos de fronteras y además se caracteriza por disponer de un
nombre o identificador
Módulo: Es aquél que está constituido por una o varias instrucciones físicamente contiguas y lógicamente
encadenadas, las cuales se pueden referenciar mediante un nombre y pueden ser llamadas desde diferentes
puntos de un programa.
Un módulo puede ser:
Un programa
Una función
Una subrutina (o procedimiento)
La modularidad se basa en la descomposición de un problema en una serie de sub problemas; dividiéndolo en
módulos que resultan de segmentar el problema en funciones lógicas que son perfectamente diferenciadas. Esta
división exige la presencia de un módulo denominado módulo de base o principal a objeto de que controle y se
relacione con los demás.
Es una técnica de programación que todavía se utiliza tanto para la construcción de algoritmos computacionales
básicos así como apoyo al desarrollo de sistemas de gestión (en el diseño de diagramas modulares).
La salida del módulo debe ser función de la entrada, pero no de ningún estado interno. En la creación de los
módulos deben cumplirse tres aspectos básicos: descripción, rendimiento y diseño.
En la descripción se definen las funciones y objetivos del programa. Para obtener el máximo rendimiento se
ha de comprobar que el programa realice el proceso aprovechando al máximo todos los recursos de los que
dispone. En cuanto al diseño, se debe comprobar la estructura que sigue el módulo, así como la estructura de
los datos y la forma de comunicaciones entre los diversos y diferentes módulos.
Conforme se extiende el tamaño de los algoritmos, se hace más difícil su revisión, actualización y/o corrección.
Una política común para solventar este problema consiste en la modularización. Esto significa que el algoritmo
se fragmenta en partes llamadas módulos. En realidad, es un método de diseño que tiende a dividir el problema,
de forma lógica, en partes perfectamente diferenciadas que pueden ser analizadas, programadas y puestas a
punto independiente.
Objetivos:
Descomponer el sistema en módulos:
Los grupos deben maximizar el enlace y minimizar el acoplamiento.
Determinar las relaciones entre módulos:
Identificar y especificar las dependencias entre módulos.
Determinar la forma de comunicación entre módulos (variables llamadas a funciones, memoria
compartida, paso de mensajes)
Especificar las interfaces de los módulos:
Facilita la prueba independiente entre los módulos.
Mejora la comunicación e integración del grupo
Características:
Permite reducir la complejidad global del sistema descentralizado; ejm. Divide y vencerás.
Mejora la escalabilidad y la productividad (los módulos pueden desarrollarse independientemente por
varias personas)
Principios para asegurar diseños modulares:
Soporte de lenguaje para unidades modulares.
Los módulos deben corresponder a unidades sintácticas del lenguaje utilizado.
Pocas interfaces:
Cada módulo debe comunicarse con tan pocos como sea posible.
Interfaces pequeñas (Acoplamiento débil):
Si dos módulos se comunican, deben intercambiar la menor información posible.
Interfaces explícitas:
Cuando dos módulos se comunican, debe estar claro en el texto de uno o de ambos.
Ocultación de la información:
Toda la información sobre un módulo debe ser privada al módulo, a menos que se haya declarado
específicamente como pública.
Algunas ventajas de utilizar módulos son:
Ventajas del uso de módulos Desventajas del uso de módulos
Un programa modular es fácil de mantener y modificar.
Un programa modular es más fácil de escribir y depurar La programación modular requiere más
(ejecutar, probar y poner a punto). memoria y tiempo de ejecución.
Un programa modular es más fácil de controlar. El desglose de No se dispone de algoritmos formales de
un problema en módulos permite encomendar los módulos más modularidad, por lo que a veces los
complejos a los programadores más experimentados y los más programadores no tienen claras las ideas de los
sencillos a los programadores nóveles. módulos.
Posibilita el uso repetitivo de las rutinas en el mismo o en
diferentes programas.
Acoplamiento y Cohesión
Existen dos criterios de evaluación no matemáticos a nivel de sistema (ACOPLAMIENTO) y a nivel de módulo
(COHESION), que se utilizan para medir el nivel del software final. No son matemáticos, es decir se deducen a
partir de la experiencia.
ACOPLAMIENTO. Mide el grado de interdependencia entre los módulos de un sistema, puede también
definirse como la probabilidad de que al modificar o codificar un módulo tengan que considerarse detalles
relativos a otros módulos.
Lo ideal es tener bajo acoplamiento, es decir, módulos que sean muy independientes unos de otros.
Queremos módulos independientes por 3 motivos:
1. Cuantas menos conexiones existan entre dos módulos, menos oportunidad habrá de que aparezca el efecto
onda (un defecto de un módulo, puede aparecer afectando a otro).
2. Se desea tener posibilidad de cambiar un módulo con el mínimo riesgo de tener que cambiar otro, se trata de
que cada cambio realizado afecte lo menos posible a otros módulos.
3. Mientras se esté manteniendo un módulo, es deseable no necesitar preocuparse en los detalles internos
(código) de cualquier otro módulo.
Principios del acoplamiento: Son los que se aplican para reducir la complejidad entre los módulos.
El acoplamiento lo podemos relacionar con la complejidad de la interface. Reducir esa complejidad implica
reducir el acoplamiento con lo cual conseguimos mas independencia entre los módulos. Cuando hablamos de
complejidad de la interface nos referimos a la capacidad de un programador para deducir qué información está
siendo transmitida y qué hace la llamada al módulo. Si es más difícil saber qué hace la llamada, la interface es
más compleja.
Los tipos de acoplamiento son:
Normal (es el acoplamiento ideal)
o Por datos
o Por estampado ó imagen
o Por control
Común
o Por variables globales
o Por contenido
ACOPLAMIENTO NORMAL
Por datos: Se dice que dos módulos están acoplados por datos si cada parámetro que se pasan en la llamada es
un dato que no tiene estructura interna. Este acoplamiento no da ningún tipo de problemas, pero hay que
controlar que los datos se generen lo más cerca posible del módulo que los vaya a utilizar.
Por estampado ó imagen: Dos módulos están acoplados por estampado si uno le pasa a otro al menos un
parámetro que tiene estructura interna.
Por control: Dos módulos están acoplados por control si uno le pasa al otro un dato con la intención de controlar
su lógica interna, es decir, si los datos de comunicación son controles.
ACOPLAMIENTO COMÚN
Por variables globales: Es similar a cuando utilizamos variables globales en un lenguaje imperativo como puede
ser Pascal. Dos módulos están acoplados globalmente por variables globales si ellos se refieren a una misma área
de datos global.
Por contenido: Ocurre cuando un módulo cualquiera necesita o accede a una parte de otro, rompiendo la
jerarquía de funcionalidad de la estructura. Si ocurre esto habrá que evitarlo descomponiendo el módulo al que
se accede o duplicando esa parte de código en el módulo que llama.
COHESIÓN. Es la medida de la fuerza o relación funcional de los elementos de un módulo, entendiendo por
elementos a la sentencia o grupo de sentencias que lo componen, a las definiciones de datos o a las llamadas a
otros módulos.
Un módulo coherente ejecuta una tarea sencilla en un programa o procedimiento y requiere poca interacción con
otros procedimientos que se ejecuten en otras partes del programa. Un módulo coherente sólo debe hacer
(idealmente) una cosa. El objetivo que se intenta conseguir es obtener módulos con una alta cohesión.
La cohesión se estudia a nivel de módulo, el sistema total no tiene cohesión.
Asegurar que los módulos tienen una buena cohesión es la mejor manera de minimizar el acoplamiento.
Escala de cohesión (Introducida en los años 70 por L. Constantine, Yourdon, Stevens y Myers.)
Mejor mantenimiento (Cohesión más fuerte) - Peor mantenimiento (Cohesión más débil)
o Funcional
o Secuencial
o Comunicacional
o Procedural
o Temporal
o Lógica
o Casual (Coincidental)
Esta escala sirve para determinar un buen mantenimiento y una buena modificabilidad. No se puede determinar
exactamente que cohesión tiene un módulo. Lo conveniente es que la mayor parte de los módulos tengan un
nivel aceptable de cohesión (es lo que se considera como sistema bueno).
COHESIÓN FUNCIONAL: Un módulo tiene cohesión funcional si contiene elementos que contribuyen todos a la
implementación de una sola función relacionada con el entorno del problema.
COHESIÓN SECUENCIAL: Un módulo tiene cohesión secuencial si realiza distintas tareas dentro de él en
secuencia, de forma que las entradas de cada tarea son las salidas de la anterior.
COHESIÓN COMUNICACIONAL: Se dice que un módulo tiene cohesión comunicacional si realiza actividades
paralelas que usan los mismos datos de entrada y/o los mismos datos de salida.
La diferencia fundamental entre la cohesión secuencial y comunicacional es que en la primera es importante el
orden de las actividades.
COHESIÓN PROCEDURAL: Un módulo tiene cohesión procedural si contiene elementos que están envueltos en
actividades diferentes y posiblemente sin relacionar donde el flujo de control pasa de una actividad a la siguiente.
Es importante señalar que suele haber poca relación entre los datos de entrada y salida de los módulos.
COHESIÓN TEMPORAL: Un módulo tiene cohesión temporal si contiene elementos que están involucrados en
actividades que están únicamente relacionadas con el tiempo.
En la cohesión procedural importa el orden de las actividades sin embargo en la cohesión temporal no importa el
orden, esta es la única diferencia.
COHESIÓN LÓGICA: Un módulo con cohesión lógica contiene actividades de la misma categoría general donde
la actividad o actividades a usar en cada momento se seleccionan desde fuera del módulo.
COHESIÓN CASUAL: Un módulo tiene cohesión casual si contiene un grupo de actividades sin relación
significativa entre ellas. Las características más frecuentes de los módulos que presentan cohesión lógica o casual
son difíciles de entender y difíciles de mantener, y sus módulos jefes tienen que utilizar banderas para
seleccionar la parte del módulo que desean usar.
Podemos utilizar para determinar la cohesión una sentencia descriptiva: Consiste en inspeccionar el módulo y
tratar de escribir una sentencia que describe que hace el módulo (hay que mirar dentro de un módulo) de esta
forma se puede deducir que cohesión tiene el módulo.
Los módulos con cohesión funcional están descritos por una sentencia formada por un verbo imperativo y un
nombre.
Los módulos con cohesión secuencial quedan descritos mediante sentencias que contienen nombres de
varias funciones.
Los módulos con cohesión comunicacional quedan descritos mediante sentencias que contienen varios
nombres de funciones estando relacionadas estas funciones por el hecho de que trabajan con los mismos
datos de entrada y salida.
Los módulos con cohesión procedural quedan descritos por una sentencia que contiene nombres que hacen
referencia a partes de organigramas y de flujos de control.
Los módulos con cohesión temporal suelen contener referencias al tiempo.
Los módulos con cohesión lógica suelen contener nombres de propósito general.
Los módulos con cohesión casual suelen contener nombres poco significativos.
Si todas las actividades de un módulo están relacionadas por más de un nivel de cohesión, entonces el
módulo tiene la cohesión del nivel más fuerte.
A continuación se ofrecen una serie de ideas prácticas que pueden ayudar a mejorar la calidad del diseño:
Hay que reducir el número de parámetros que intercambian los módulos tanto como sea posible, es mejor
que los datos de comunicación que se pasen sean elementos de registros.
hay que evitar pasar parámetros de un módulo a otro, a menos que tengan una utilidad práctica.
No se debe compartir código entre las actividades que están incluidas en un módulo. Esto hace difícil
modificar una actividad sin cambiar la otra.
Se debe parar la descomposición cuando no se encuentren funciones bien definidas, pues no se debe crear un
módulo con una serie de líneas de código agrupadas aleatoriamente.
Se puede parar la descomposición cuando la interface con un módulo sea tan complicada como el módulo en
sí mismo.
Se deberán conseguir diseños lo más equilibrados que sea posible. Puede decirse que un diseño está
equilibrado si y sólo si, trata con datos lógicos en su parte alta y con datos físicos en su parte baja.
Ejemplos de Cohesión
COHESIÓN: mide la relación que existe entre los diferentes elementos de un módulo.
COHESION FUNCIONAL: Módulo en el cual todos sus elementos contribuyen a la ejecución de una y solo una
tarea relacionada con el problema.
Ejemplo.
LEER_CLIENTE:
CLI_COD_CLIENTE = W_COD_CLIENTE
clave CLI_COD_CLIENTE
leer REG_CLIENTE
retorno
COHESION SECUENCIAL: Módulo en el cual sus elementos se relacionan unos con otros por ejecutar diferentes
partes de una secuencia de operaciones, en la cual la salida de una operación es la entrada de la siguiente.
Ejemplo.
PROCESAR_FACTURA:
ejecutar CALCULAR_TOTAL_BRUTO
W_MONTO_IVA = ACU_TOTAL_EXENTAS * 10 /100
W_MONTO_FACTURA = W_TOTAL_EXENTAS + W_TOTAL_GRAVADAS + W_MONTO_IVA
retorno
COHESION COMUNICACIONAL: Módulo en el cual sus elementos contribuyen a actividades que usan los
mismos datos (de entrada o de salida).
Ejemplo.
INGRESAR_DATOS_CLIENTE:
ingresar “Nombre del cliente:”, CLI_NOMBRE
repetir
ingresar “Tipo de cliente (B/R/M):”, CLI_TIPO
hasta CLI_TIPO = “B” o “R” o “M”
ingresar “Fecha de ingreso:”, CLI_FECHA_INGRESO
grabar REG_CLIENTE
retorno
COHESION PROCEDURAL: Módulo en el cual sus elementos están involucrados en diferentes actividades, y
posiblemente, no relacionadas entre sí, que sin embargo deben ejecutarse en cierto orden.
Ejemplo.
LOOP_INGRESAR_DATOS:
ingresar “Código de alumno:”, ALU_COD_ALUMNO
mientras ALU_COD_ALUMNO < > 0
ejecutar INGRESAR_CALENDARIO_ACADEMICO
ejecutar LEER_ALUMNO
si no existe(ALUMNO)
ingresar “Nombre del alumno:”, ALU_NOMBRE
ingresar “Fecha de nacimiento:”, ALU_FEC_NACIMIENTO
grabar REG_ALUMNO
fin_si
ejecutar BUSCAR_PRECIO_CUOTA
ingresar “Código de alumno:”, ALU_COD_ALUMNO
fin_mientras
retorno
COHESION TEMPORAL: Módulo en el cual sus elementos están relacionados por el tiempo, más no necesitan
ocurrir en un cierto orden u operar sobre los mismos datos.
Ejemplo.
CORTE_ARTICULO:
imprimir “Total Ventas del Artículo:”, ACU_VENTAS_ARTICULO
CON_LINEAS = CON_LINEAS + 1
ACU_VENTAS_GENERAL = ACU_VENTAS_GENERAL + ACU_VENTAS_ARTICULO
retorno
COHESION LOGICA: Módulo en el cual sus están involucrados en actividades de cierto tipo, y los procesos que
se deben realizar son seleccionados desde fuera del módulo.
Ejemplo.
LECTURA_ARCHIVOS:
si W_PROCESO = 1
clave TRA_NRO_TRANSACCION + TRA_COD_ARTICULO
leer REG_TRANSACCION
sino
si W_PROCESO = 2
clave ART_COD_ARTICULO
leer REG_ARTICULO
sino
si W_PROCESO = 3
clave CLI_CODIGO
ubicar REG_CLIENTE
ejecutar LEER_SGTE_CLIENTE
sino
si W_PROCESO = 4
clave TRA_NRO_TRANSACCION + TRA_COD_ARTICULO
ubicar REG_TRANSACCION
ejecutar LEER_SGTE_TRANSACCION
fin_si
fin_si
fin_si
fin_si
retorno
COHESION COINCIDENTAL: Módulo en el cual sus elementos no están relacionados ni por la función que
representa el módulo, ni los procedimientos del mismo, ni los datos o por cualquier otro factor.
Ejemplo.
PROCESO_GENERAL:
ingresar “Código de Artículo:”, W_COD_ARTICULO
ejecutar LEER_CLIENTE
si BAN_PRIMERA_FACTURA = “S”
ejecutar INICIALIZAR_DATOS_FACTURA
fin_si
si CON_REG_LEIDOS = 0
ejecutar GRABAR_ERROR_ARCHIVO
ejecutar INGRESAR_DATOS_FACTURA
sino
imprimir “Cantidad de registros leídos:”, CON_REG_LEIDOS
fin_si
retorno
SUGERENCIAS PARA DETERMINAR EL NIVEL DE COHESION DE UN MODULO
Una manera interesante de determinar el nivel de cohesión de un módulo, consiste en describir en una sentencia,
la función del módulo.
Cohesión Funcional: el nombre está compuesto por un verbo y un nombre de objeto en singular.
Ejemplo: CALCULAR_MONTO_IVA
Cohesión Secuencial: se describe como una serie de funciones encadenadas.
Ejemplo: GRABAR_TRANSACCION_Y_ACTUALIZAR_CLIENTE
Cohesión Comunicacional: se mencionan una serie de funciones no secuenciales, trabajando sobre los mismos
datos.
Ejemplo: CALCULAR_SUELDO_PROMEDIO_Y_SUELDO_MAXIMO
Cohesión Procedural: en el nombre se hace referencia a procesos genericos que involucran o no a los mismos
datos.
Ejemplo: LOOP_CALCULAR_MONTOS
Cohesión Temporal: el nombre tiene alguna relación con el tiempo.
Ejemplo: INICIO_ARTICULO
Cohesión Lógica: el nombre hace referencia a algún tipo de operación aplicado a algo genérico o a en forma
detallada a diferentes tipos de datos.
Ejemplo: INGRESAR_DATOS
Cohesión Coincidental: el nombre sugiere funciones diversas e inconexas.
Ejemplo: PROCESOS_VARIOS