Estrategias de diseño
Estrategia de arriba hacia abajo
La estrategia de arriba hacia abajo utiliza el enfoque modular para desarrollar el diseño de un sistema. Se llama así porque comienza desde la parte superior o el módulo de nivel más alto y avanza hacia los módulos de nivel más bajo.
En esta técnica, se identifica el módulo de más alto nivel o módulo principal para desarrollar el software. El módulo principal se divide en varios submódulos o segmentos más pequeños y simples según la tarea realizada por cada módulo. Luego, cada submódulo se subdivide en varios submódulos del siguiente nivel inferior. Este proceso de dividir cada módulo en varios submódulos continúa hasta que no se identifican los módulos de nivel más bajo, que no se pueden subdividir más.
Estrategia de abajo hacia arriba
La estrategia de abajo hacia arriba sigue el enfoque modular para desarrollar el diseño del sistema. Se llama así porque comienza desde abajo o desde los módulos de nivel más básico y avanza hacia los módulos de nivel más alto.
En esta técnica,
Se identifican los módulos en el nivel más básico o más bajo.
Estos módulos luego se agrupan en función de la función realizada por cada módulo para formar los siguientes módulos de nivel superior.
Luego, estos módulos se combinan aún más para formar los siguientes módulos de nivel superior.
Este proceso de agrupar varios módulos más simples para formar módulos de nivel superior continúa hasta que se logra el módulo principal del proceso de desarrollo del sistema.
Diseño estructurado
El diseño estructurado es una metodología basada en el flujo de datos que ayuda a identificar la entrada y salida del sistema en desarrollo. El principal objetivo del diseño estructurado es minimizar la complejidad y aumentar la modularidad de un programa. El diseño estructurado también ayuda a describir los aspectos funcionales del sistema.
En el diseño estructurado, las especificaciones del sistema actúan como base para representar gráficamente el flujo de datos y la secuencia de procesos involucrados en un desarrollo de software con la ayuda de DFD. Después de desarrollar los DFD para el sistema de software, el siguiente paso es desarrollar el diagrama de estructura.
Modularización
El diseño estructurado divide el programa en módulos pequeños e independientes. Estos están organizados de arriba hacia abajo con los detalles que se muestran en la parte inferior.
Por lo tanto, el diseño estructurado utiliza un enfoque llamado modularización o descomposición para minimizar la complejidad y gestionar el problema subdividiéndolo en segmentos más pequeños.
Advantages
- Las interfaces críticas se prueban primero.
- Proporciona abstracción.
- Permite que varios programadores trabajen simultáneamente.
- Permite la reutilización de código.
- Proporciona control y mejora la moral.
- Facilita la identificación de la estructura.
Gráficos estructurados
Los gráficos estructurados son una herramienta recomendada para diseñar un sistema modular de arriba hacia abajo que define los diversos módulos de desarrollo del sistema y la relación entre cada módulo. Muestra el módulo del sistema y su relación entre ellos.
Consiste en un diagrama que consta de cajas rectangulares que representan los módulos, flechas de conexión o líneas.
Control Module - Es un módulo de nivel superior que dirige módulos de nivel inferior, llamado subordinate modules.
Library Module - Es un módulo reutilizable y puede invocarse desde más de un punto en el gráfico.
Tenemos dos enfoques diferentes para diseñar un gráfico estructurado:
Transform-Centered Structured Charts - Se utilizan cuando todas las transacciones siguen la misma ruta.
Transaction–Centered Structured Charts - Se utilizan cuando no todas las transacciones siguen el mismo camino.
Objetivos del uso de diagramas de flujo de estructura
Fomentar un diseño de arriba hacia abajo.
Apoyar el concepto de módulos e identificar los módulos adecuados.
Mostrar el tamaño y la complejidad del sistema.
Identificar el número de funciones y módulos fácilmente identificables dentro de cada función.
Para representar si cada función identificable es una entidad manejable o debe dividirse en componentes más pequeños.
Factores que afectan la complejidad del sistema
Para desarrollar software de sistema de buena calidad, es necesario desarrollar un buen diseño. Por lo tanto, el enfoque principal al desarrollar el diseño del sistema es la calidad del diseño del software. Un diseño de software de buena calidad es aquel que minimiza la complejidad y el gasto de costes en el desarrollo de software.
Los dos conceptos importantes relacionados con el desarrollo del sistema que ayudan a determinar la complejidad de un sistema son coupling y cohesion.
Acoplamiento
El acoplamiento es la medida de la independencia de los componentes. Define el grado de dependencia de cada módulo de desarrollo del sistema del otro. En la práctica, esto significa que cuanto más fuerte es el acoplamiento entre los módulos de un sistema, más difícil es implementar y mantener el sistema.
Cada módulo debe tener una interfaz simple y limpia con otros módulos, y la cantidad mínima de elementos de datos debe compartirse entre los módulos.
Alto acoplamiento
Este tipo de sistemas tienen interconexiones con unidades de programa que dependen unas de otras. Los cambios en un subsistema tienen un gran impacto en el otro subsistema.
Acoplamiento bajo
Este tipo de sistemas están formados por componentes independientes o casi independientes. Un cambio en un subsistema no afecta a ningún otro subsistema.
Medidas de acoplamiento
Content Coupling - Cuando un componente modifica realmente a otro, el componente modificado depende completamente de la modificación de uno.
Common Coupling - Cuando la cantidad de acoplamiento se reduce un poco al organizar el diseño del sistema para que los datos sean accesibles desde un almacén de datos común.
Control Coupling - Cuando un componente pasa parámetros para controlar la actividad de otro componente.
Stamp Coupling - Cuando se utilizan estructuras de datos para pasar información de un componente a otro.
Data Coupling - Cuando solo se pasan datos, los componentes se conectan mediante este acoplamiento.
Cohesión
La cohesión es la medida de cercanía de la relación entre sus componentes. Define la cantidad de dependencia de los componentes de un módulo entre sí. En la práctica, esto significa que el diseñador de sistemas debe asegurarse de que:
No dividen los procesos esenciales en módulos fragmentados.
No reúnen procesos no relacionados representados como procesos en el DFD en módulos sin sentido.
Los mejores módulos son aquellos que son funcionalmente cohesivos. Los peores módulos son aquellos que coinciden en la cohesión.
El peor grado de cohesión
La cohesión coincidente se encuentra en un componente cuyas partes no están relacionadas con otra.
Logical Cohesion - Es donde se colocan varias funciones o elementos de datos relacionados lógicamente en un mismo componente.
Temporal Cohesion - Es cuando un componente que se usa para inicializar un sistema o establecer variables realiza varias funciones en secuencia, pero las funciones están relacionadas por el tiempo involucrado.
Procedurally Cohesion - Es cuando las funciones se agrupan en un componente solo para garantizar este orden.
Sequential Cohesion - Es cuando la salida de una parte de un componente es la entrada a la siguiente parte del mismo.