Ingeniería de Software | Acoplamiento y Cohesión

Introducción: El propósito de la fase de Diseño en el Ciclo de Vida de Desarrollo de Software es producir una solución a un problema dado en el documento SRS (Software Requirement Specification). El resultado de la fase de diseño es el Documento de diseño de software (SDD). 

Básicamente, el diseño es un proceso iterativo de dos partes. La primera parte es el Diseño Conceptual que le dice al cliente lo que hará el sistema. En segundo lugar, está el diseño técnico, que permite a los creadores de sistemas comprender el hardware y el software necesarios para resolver el problema del cliente. 

coupling and cohesion

Diseño conceptual del sistema: 

  • Escrito en un lenguaje sencillo, es decir, en un lenguaje comprensible para el cliente.
  • Explicación detallada de las características del sistema.
  • Describe la funcionalidad del sistema.
  • Es independiente de la implementación.
  • Vinculado con el documento de requisitos.

Diseño Técnico del sistema: 

  • Componente de hardware y diseño.
  • Funcionalidad y jerarquía de los componentes de software.
  • Arquitectura de software
  • Red de arquitectura
  • Estructura de datos y flujo de datos.
  • componente de E/S del sistema.
  • Muestra la interfaz.

Modularización: La modularización es el proceso de dividir un sistema de software en múltiples módulos independientes donde cada módulo funciona de forma independiente. Hay muchas ventajas de la modularización en la ingeniería de software. Algunos de estos se dan a continuación: 

  • Fácil de entender el sistema.
  • El mantenimiento del sistema es fácil.
  • Un módulo se puede utilizar muchas veces según sus requisitos. No es necesario escribirlo una y otra vez.

Acoplamiento: El acoplamiento es la medida del grado de interdependencia entre los módulos. Un buen software tendrá bajo acoplamiento. 
 

coupling

Tipos de acoplamiento: 

  • Acoplamiento de datos: si la dependencia entre los módulos se basa en el hecho de que se comunican pasando solo datos, se dice que los módulos están acoplados por datos. En el acoplamiento de datos, los componentes son independientes entre sí y se comunican a través de datos. Las comunicaciones del módulo no contienen datos de trampa. Ejemplo-sistema de facturación al cliente.
  • Acoplamiento de sellos En el acoplamiento de sellos, la estructura de datos completa se pasa de un módulo a otro módulo. Por lo tanto, se trata de datos vagabundos. Puede ser necesario debido a factores de eficiencia: esta elección fue hecha por el diseñador perspicaz, no por un programador perezoso.
  • Acoplamiento de control: si los módulos se comunican pasando información de control, se dice que están acoplados por control. Puede ser malo si los parámetros indican un comportamiento completamente diferente y bueno si los parámetros permiten factorizar y reutilizar la funcionalidad. Ejemplo: función de clasificación que toma la función de comparación como argumento.
  • Acoplamiento Externo: En el acoplamiento externo, los módulos dependen de otros módulos, externos al software que se está desarrollando oa un determinado tipo de hardware. Protocolo Ex, archivo externo, formato de dispositivo, etc.
  • Acoplamiento común: los módulos tienen datos compartidos, como estructuras de datos globales. Los cambios en los datos globales implican rastrear todos los módulos que acceden a esos datos para evaluar el efecto del cambio. Por lo tanto, tiene desventajas como dificultad para reutilizar módulos, capacidad reducida para controlar el acceso a los datos y capacidad de mantenimiento reducida.
  • Acoplamiento de contenido: en un acoplamiento de contenido, un módulo puede modificar los datos de otro módulo, o el flujo de control se pasa de un módulo a otro módulo. Esta es la peor forma de acoplamiento y debe evitarse.

Cohesión: La cohesión es una medida del grado en que los elementos del módulo están funcionalmente relacionados. Es el grado en que todos los elementos dirigidos a realizar una sola tarea están contenidos en el componente. Básicamente, la cohesión es el pegamento interno que mantiene unido el módulo. Un buen diseño de software tendrá una alta cohesión. 

cohesion

Tipos de cohesión: 

  • Cohesión funcional: todos los elementos esenciales para un solo cálculo están contenidos en el componente. Una cohesión funcional realiza la tarea y las funciones. Es una situación ideal.
  • Cohesión secuencial: un elemento genera algunos datos que se convierten en la entrada para otro elemento, es decir, el flujo de datos entre las partes. Ocurre naturalmente en lenguajes de programación funcionales.
  • Cohesión comunicacional: Dos elementos operan sobre los mismos datos de entrada o contribuyen a los mismos datos de salida. Ejemplo: actualizar el registro en la base de datos y enviarlo a la impresora.
  • Cohesión Procesal: Elementos de cohesión procesal aseguran el orden de ejecución. Las acciones todavía están débilmente conectadas y es poco probable que sean reutilizables. Ex- calcular el GPA del estudiante, imprimir el registro del estudiante, calcular el GPA acumulativo, imprimir el GPA acumulativo.
  • Cohesión Temporal: Los elementos se relacionan por su temporización involucrada. Un módulo conectado con la cohesión temporal todas las tareas deben ejecutarse en el mismo lapso de tiempo. Esta cohesión contiene el código para inicializar todas las partes del sistema. Muchas actividades diferentes ocurren, todas en la unidad de tiempo.
  • Cohesión Lógica: Los elementos están lógicamente relacionados y no funcionalmente. Ejemplo: un componente lee entradas de cinta, disco y red. Todo el código para estas funciones está en el mismo componente. Las operaciones están relacionadas, pero las funciones son significativamente diferentes.
  • Cohesión Coincidente: Los elementos no están relacionados (sin relación). Los elementos no tienen otra relación conceptual que la ubicación en el código fuente. Es accidental y la peor forma de cohesión. Ex- imprime la siguiente línea e invierte los caracteres de una string en un solo componente.

Publicación traducida automáticamente

Artículo escrito por Josikakar y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *