El análisis y diseño estructurado español estructurado es otro método para evitar los problemas de ambigüedad del lenguaje al establecer condiciones y acciones, tanto en procedimientos como en decisiones. Este método no hace uso de árboles o tablas; en su lugar utiliza declaraciones para describir el proceso. El método no muestra las reglas de decisión-, las declara.

Sin embargo, este método también le permite hacer una lista de todos

los pasos en el orden en que se llevan a cabo, como lo muestran los ejemplos de esta sección. Para ello no se utilizan símbolos y formatos especiales, características de los árboles y tablas de decisión que para algunos resultan incómodos. Además, es posible describir con rapidez los procedimientos en su totalidad ya que para ello se emplean declaraciones muy similares al español.

El análisis estructurado, como todos los demás métodos de análisis de requisitos, es una actividad de construcción de modelos. Mediante una notación que es única de este método, se crean modelos que reflejan el flujo y el contenido de la información (datos y control); se parte el sistema funcionalmente y, según los distintos comportamientos, se establece la esencia de lo que se debe construir.

El diseño de software es un proceso mediante el que se traducen los requisitos en una representación del software.

En el diseño se realizan dos pasos. El diseño preliminar se centra en la transformación de los requisitos en los datos y arquitectura del software. El diseño detallado se ocupa del refinamiento de la representación arquitectónica que lleva a una estructura de datos detallada y a las representaciones algorítmicas del software.

Cuando se considera una solución modular para cualquier problema, pueden formularse muchos niveles de abstracción. En el nivel superior de abstracción, se establece una solución en términos amplios, usando el lenguaje del entorno del problema. En los niveles inferiores de abstracción se toma una orientación más procedimental. La terminología orientada al problema se acompaña con una terminología orientada a la implantación, en un esfuerzo para establecer una solución. Por último, en el nivel más bajo de abstracción, se establece la solución de forma que pueda implementarse directamente.

 

El refinamiento sucesivo es una primera estrategia de diseño descendente (propuesta por Niklaus Wirth). Un programa se desarrolla en niveles sucesivos de refinamiento de los detalles procedimentales. Se desarrolla una jerarquía descomponiendo una declaración macroscópica de una función en forma sucesiva hasta que se llega a las sentencias del lenguaje de programación. Cada paso de refinamiento implica algunas decisiones de diseño. Es importante que el programador sea consciente de sus decisiones y de la existencia de soluciones alternativas.

Se ha dicho que modularidad es el atributo individual del software que permite a un programa ser intelectualmente manejable. El software monolítico (compuesto por sólo un módulo) no puede ser fácilmente abarcado por un lector. El número de caminos de control, la expansión de referencias, el número de variables y la complejidad global podrían hacer imposible su correcta comprensión.

La calidad del diseño debe ser una meta para el diseñador. El diseño estructurado ofrece guías para apoyar al diseñador a determinar módulos, y sus interconexiones, que mejor realizarán los requerimientos especificados por el analista.

Grado en el cuál los módulos se interconectan o se relacionan entre ellos. Entre más fuerte sea el acoplamiento entre módulos en un sistema, más difícil es implantarlo y mantenerlo, pues entonces se necesitará un estudio cuidadoso para la modificación de algún módulo o módulos. En la práctica, esto significa que cada módulo debe tener interfaces sencillas y limpias con otros, y que se debe compartir un número mínimo de datos entre módulos. También significa que un módulo dado no debe modificar la lógica interna o los datos de algún otro módulo; lo que se conoce como una conexión patológica.

Grado en el cuál los componentes de un módulo (típicamente las instrucciones individuales que lo conforman) son necesarios y suficientes para llevar a cabo una sola función bien definida

Se dividen en varios tipos que se mostraran a continuación:

Los grados de cohesión, de menor a mayor son: a. Cohesión Coincidente. No existe una relación

significativa entre los elementos del módulo.   b. Cohesión Lógica. La relación entre los elementos

del módulo está basada en obtener ventajas en el procesamiento, por ejemplo, todos manipulan el mismo dato. Normalmente esto implica tener un código truculento o compartido, que degrada los propósitos de un buen diseño.

 c. Cohesión Temporal. Los elementos del módulo constituyen un conjunto que se ejecuta secuencialmente en un punto fijo en el tiempo. Aunque tiende, a veces, a confundirse con la cohesión lógica, la diferencia está en que este tipo de módulo s más simple y se ejecuta sin la intervención de otras aplicaciones.

 d. Cohesión Comunicacional. Los elementos del módulo hacen referencia al mismo conjunto de datos. Aquí se presenta un grado "aceptable" de cohesión.

 e. Cohesión Secuencial. Implica que la salida de un elemento es la entrada para el próximo.

 f. Cohesión Funcional. Aquí, todos los elementos del módulo están orientados a la realización de una función única.

De ser posible, cada módulo debe ser lo suficientemente pequeño como para caber en una sola página ( o para que se pueda desplegar en una sola pantalla). Desde luego, a veces no es posible determinar qué tan grande va a ser un módulo hasta haberlo escrito, pero las actividades iniciales de diseño a menudo darán al diseñador una buena pista de que el módulo será grande o complejo. Si es así, debe subdividirse en uno o más niveles de submódulos.

El número de subordinados inmediatos que un módulo administrador puede llamar se conoce como el alcance del control. Un módulo no debe poder llamar a más de una media docena de módulos de nivel inferior. La razón es evitar la complejidad: si el módulo tuviera, por ejemplo, que llamar a 25 módulos de nivel inferior, entonces seguramente contendrá tanta lógica compleja que nadie lo entenderá (un sin fin de if-then anidados). La solución es introducir un nivel intermedio de módulos administradores, como haría un administrador de una organización humana.

Esta regla sugiere que cualquier módulo afectado por el resultado de alguna decisión debe ser subordinado (aunque no necesariamente un subordinado inmediato) del módulo que toma la decisión. Es un tanto análogo a la regla de administración que dice que cualquier empleado afectado por los resultados de la decisión de algún administrador (es decir, dentro del alcance de efecto de la decisión), debe estar dentro del alcance de control del administrador (es decir trabajando entre la jerarquía de personas que se reportan con el administrador). Violar esta regla en un ambiente de diseño estructurado usualmente lleva a un paso innecesario de banderas y condiciones (lo cual incrementa el acoplamiento entre módulos), la toma redundante de decisiones o (en el peor de los casos) conexiones patológicas entre módulos.

 

Se refiere a la economía de recursos que se emplean para la obtención de un resultado. Esto es, sólo se debe realizar lo que se pide. Mientras mayor la parsimonia, mejor el diseño.

Los módulos deben tener la capacidad de manejar sus propias condiciones de error, tanto en la detección como en la corrección de los mismos. De no ser así, el manejo de banderas (flags) de control y la transmisión de datos erróneos a otros módulos aumentará considerablemente el acoplamiento.

Los diagramas de flujos de datos también son llamados Carta de Burbujas, DFD, Diagramas de burbujas, modelo de proceso, diagrama de flujo de trabajo o modelo de función en la literatura computacional.

  A medida que la información se mueve a través del

software, es modificada por una serie de transformaciones. El DFD es una técnica gráfica que representa el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida.