Introducción

En el vasto universo de la ingeniería de software, la calidad de un sistema no solo se mide por su

funcionalidad, sino también por la robustez y elegancia de su arquitectura interna. Dos de los
principios más cruciales que guían un diseño de software de alta calidad son la cohesión y el
acoplamiento. La cohesión se refiere a cuán relacionadas están las responsabilidades dentro de un
módulo, mientras que el acoplamiento mide el grado de interdependencia entre diferentes
módulos. Este trabajo de investigación profundizará en ambos conceptos, explorando sus
características, tipos y la importancia de buscar un diseño que maximice la cohesión y minimice el
acoplamiento para crear sistemas de software más robustos, fáciles de mantener y reutilizables.

Cohesión

La cohesión es la medida de la fuerza con la que se relacionan las responsabilidades de un módulo

entre sí. Un módulo con alta cohesión está diseñado para realizar una única tarea bien definida, lo
que lo hace más fácil de entender, mantener y reutilizar. Los tipos de cohesión, de mayor
(deseable) a menor (indeseable), son:

Cohesión Funcional (Ideal): Las responsabilidades del módulo contribuyen a la realización de una
única función bien definida. Por ejemplo, un módulo llamado Calcular Impuestos solo contendría la
lógica para calcular impuestos.

Cohesión Secuencial: Los elementos del módulo están involucrados en una secuencia de
actividades donde la salida de una es la entrada de la siguiente. Por ejemplo, un módulo Procesar
Pedido que primero valida el pedido y luego calcula el total.

Cohesión Comunicacional: Los elementos del módulo operan sobre el mismo conjunto de datos de
entrada o salida. Por ejemplo, un módulo que lee un registro de un archivo y luego lo valida.

Cohesión Procedimental: Los elementos del módulo se agrupan porque siguen una secuencia de
ejecución específica, pero las funciones no están relacionadas lógicamente. Por ejemplo, un
módulo Guardar Y Mostrar que guarda un dato en la base de datos y luego muestra un mensaje al
usuario.

Cohesión Temporal: Los elementos se agrupan porque se ejecutan en el mismo momento, no

porque estén lógicamente relacionados. Por ejemplo, un módulo de inicialización InicializarSistema
que configura varias variables globales, abre archivos y establece conexiones a la base de datos.
Cohesión Lógica: Los elementos se agrupan porque se utilizan para realizar funciones que están
lógicamente relacionadas, pero no necesariamente están en el mismo tipo de operación. Por
ejemplo, un módulo ManejarImpresion que puede imprimir en PDF, en impresora o en pantalla,
seleccionando la función adecuada con un parámetro.

Cohesión Casual (La Peor): No hay una relación lógica entre los elementos. Se agrupan
arbitrariamente. Por ejemplo, un módulo que contiene funciones aleatorias como ValidarUsuario,
CalcularIVA y GenerarReporte.

Acoplamiento

El acoplamiento es el grado de interdependencia entre módulos de software. Un bajo

acoplamiento es deseable porque reduce el impacto de los cambios en un módulo sobre otros. Los
tipos de acoplamiento, de menor (deseable) a mayor (indeseable), son:

Acoplamiento de Datos (Ideal): Los módulos interactúan pasando datos simples como argumentos.
La interdependencia es mínima. Por ejemplo, la función calcularArea(ancho, alto) solo necesita los
valores de ancho y alto.

Acoplamiento por Sello o Estampa: Los módulos se comunican pasando estructuras de datos
complejas (objetos) completas, pero el módulo receptor solo utiliza una pequeña parte de la
información. Esto puede ser ineficiente y aumentar la dependencia.

Acoplamiento de Control: Un módulo pasa información de control a otro módulo, lo que influye en
la lógica de ejecución del segundo. Esto crea una dependencia fuerte ya que el módulo receptor no
puede funcionar sin la decisión del emisor.

Acoplamiento Externo: Los módulos dependen de estructuras de datos o protocolos externos (por
ejemplo, formato de archivos, llamadas a la API de un sistema operativo, o un dispositivo de
hardware externo).

Acoplamiento Común: Dos o más módulos acceden a la misma área de datos global. Un cambio en
la estructura de datos global afectará a todos los módulos que la utilizan. Esto es difícil de
mantener y depurar.
Acoplamiento de Contenido (El Peor): Un módulo accede o modifica directamente el contenido
interno de otro módulo, como variables locales o código. Esto crea una dependencia
extremadamente fuerte y frágil. Por ejemplo, una función que modifica una variable local de otra
función.

En resumen, la combinación ideal en un diseño de software es alta cohesión y bajo acoplamiento.

Un sistema con estas características es más fácil de mantener, entender, probar y reutilizar.

Conclusión

En conclusión, la búsqueda de un alto grado de cohesión y un bajo acoplamiento no es

meramente una formalidad académica, sino una práctica fundamental para la construcción de
sistemas de software sostenibles y eficientes. Hemos visto cómo la cohesión funcional y el
acoplamiento de datos representan los estados ideales, permitiendo que los módulos actúen como
entidades independientes y bien definidas. Por el contrario, las formas más débiles de cohesión,
como la casual, y las más fuertes de acoplamiento, como el de contenido, introducen fragilidad,
complejidad y una carga de mantenimiento significativa. Al aplicar estos principios, los
desarrolladores pueden mitigar riesgos, mejorar la legibilidad del código y facilitar la evolución del
sistema. En última instancia, un diseño bien cohesionado y débilmente acoplado es la base sobre la
cual se erigen sistemas de software exitosos y duraderos.
Definir el prototipo o sistema de información

Prototipo de Sistema de Cajero Automático

Presentación de nuestra aplicación para Cajeros Automáticos

Buenos días a todos. Hoy les voy a presentar un sistema que busca hacer la experiencia bancaria
más rápida y segura para nuestros clientes.

Prototipo de Sistema de Cajero Automático

Nuestra aplicación es el software para el cajero automático. Su objetivo es simple: permitir que
cualquier persona con una tarjeta bancaria realice sus transacciones esenciales de forma
autónoma, sin tener que pasar por una sucursal o hablar con un cajero humano.

El proceso es muy sencillo. El cliente solo tiene que insertar su tarjeta e ingresar su contraseña de
4 dígitos. Una vez dentro, se encuentra con un menú claro e intuitivo que le da el control total de
sus finanzas.

Las opciones disponibles son las que todos necesitamos a diario:

 Retiro de efectivo: Para obtener dinero al instante.

 Depósito bancario: Para ingresar dinero a sus cuentas de forma rápida.

 Transferencia de fondos: Para enviar dinero a otras cuentas, ya sea propias o de terceros.

 Consulta de saldo: Para saber cuánto dinero tiene disponible en todo momento.

Todo esto funciona en tiempo real, ya que la aplicación se conecta directamente con la base de
datos del banco. Esto garantiza que cada transacción es precisa y segura.

En resumen, hemos diseñado un sistema que es:

 Intuitivo: Fácil de usar para cualquier persona.

 Eficiente: Realiza las operaciones en cuestión de segundos.

 Seguro: Protege la información y el dinero de nuestros clientes.

Nuestra meta es ofrecer una solución que optimice el tiempo de los usuarios y fortalezca la
confianza en nuestros servicios.
Acoplamiento entre Módulos

El acoplamiento es el grado de interdependencia entre los distintos módulos. Un buen diseño de

software busca un bajo acoplamiento, lo que significa que los módulos son lo más independientes
posible.

 Ejemplo de Bajo Acoplamiento: El módulo de "Retiro de Efectivo" solo necesita recibir del
menú la cantidad a retirar y el número de cuenta. No necesita saber cómo funciona el
módulo de "Depósito Bancario" o el de "Transferencia". Si hay un cambio en el módulo de
depósitos, no debería afectar al de retiros. La única dependencia es la base de datos de
clientes.

 Problemática de Alto Acoplamiento: Un alto acoplamiento se daría si el módulo de

"Transferencia a Otras Cuentas" tuviera que acceder directamente a las variables internas
o la lógica del módulo de "Depósito Bancario" para funcionar. Si se modifica algo en
"Depósito", probablemente se rompería el código de "Transferencia", creando un efecto
dominó de errores.

Resumen del Sistema

En el sistema propuesto, la problemática reside en garantizar que la comunicación entre los

módulos (retiro, depósito, transferencia, consulta) y la base de datos de clientes esté bien
gestionada. Para evitar problemas, se debe buscar:

1. Alta Cohesión: Cada módulo del menú (retiro, depósito, etc.) debe centrarse
exclusivamente en su tarea. El módulo de autenticación solo valida las credenciales.

2. Bajo Acoplamiento: Los módulos del menú deben interactuar con la base de datos a través
de interfaces bien definidas, y no depender unos de otros. Esto permite modificar un
módulo (por ejemplo, cambiar la lógica de un retiro) sin afectar a los demás.

El diseño ideal es una arquitectura en la que el menú es el intermediario que llama a cada módulo
específico, y todos los módulos se comunican de forma independiente con la base de datos, sin
depender entre sí.