Diseño Estructurado y las Técnicas que lo Caracterizan

1. REPUBLICA BOLIVARIANA DE VENEZUELA
UNIVERSIDAD FERMIN TORO
FACULTAD DE INGENIERIA
CABUDARE ESTADO LARA
Diseño Estructurado y las Técnicas que lo Caracterizan
Alumno: Jonathan Bastidas
C.I. 17.048.561
Cabudare, Noviembre 2012

2. DISEÑO DE SISTEMAS
Diagramas de estructura:
Son representaciones gráficas de la jerarquía existente entre los
módulos de un programa, y las estructuras de programación utilizadas para
controlar la operación de esos módulos.
Cada módulo se representa como un rectángulo. Los módulos a su vez
se pueden componer de otros, o ser módulos primitivos. Un módulo primitivo
se encarga de desarrollar el procesamiento de los datos, mientras que un
módulo no primitivo se encarga de administrar a otros módulos.
Conexión entre módulos:
Un sistema está compuesto por módulos organizados jerárquicamente,
cooperando y comunicándose entre sí para realizar una tarea. La llamada de
un módulo se representa con una flecha
Comunicación entre módulos:
La comunicación intermodular se realiza a través de los datos y los
flags. Los datos se procesan; por el contrario, los flags sólo sirven como
valores de condición para comunicar condiciones entre los módulos. Otra
diferencia es que los datos están relacionados con el problema y son
importantes para el mundo exterior, mientras que los flags sólo importan
para la comunicación de información.
Estrategias de diseño:
El diseño estructurado ofrece dos estrategias para conseguir una
creación rápida de un buen diseño a partir de una ERS:
- Diseño por Transformación: Los datos entran en el sistema
mediante caminos que se denominan flujos de entrada. En el núcleo se
produce una transformación de los datos, y finalmente, los datos se mueven
por caminos que conducen a la salida.
- Diseño por transacción: Existe un centro de transacción que es el
centro de flujo, desde el que emanan muchos caminos alternativos de forma
exclusiva.
El diseño estructurado permite una transición del DFD a una
descripción de diseño de la estructura del programa. Se definen unos pasos
que están en función del tipo de flujo de información de que se trate.

3. Análisis de transformación:
1. Revisión del modelo fundamental del sistema:
-Debe haberse aplicado análisis estructurado (DFD).
-Hay que considerar al el DFD expandido (3er nivel).
2. Determinar si el DFD tiene características de transformación o de
transacción:
-La mayoría de flujos se representan como transformaciones.
-Si existe un proceso con salidas exclusivas entonces se trata de un
problema de transacción.
3. Aislar el centro de transformación, especificando los límites del
flujo de llegada y de salida:
-El centro de transformación es la parte del DFD que contiene las
funciones esenciales del sistema.
-Los límites están abiertos a interpretación (diseñador) diferentes
soluciones de diseño según la localización de los límites del flujo.
4. Realizar el primer corte del diagrama de estructura:
-Primer nivel de factorización del DE: Módulo principal
coordinador, controlador de entrada, controlador del centro de
transformación, y módulo controlador de salida de datos del sistema.
-Los módulos deben tener nombres significativos.
-El nombre del Cm coincide con el nombre del diagrama de contexto.
5. Ejecución del segundo nivel de factorización:
-Se empieza en los límites y se dirige hacia fuera.
-Las transformaciones se convierten en módulos.
-Se introducen módulos predefinidos que proporcionen las diferentes
E/S que necesita/genera el sistema.
6. Refinar la estructura del sistema utilizando medidas y guías de
diseño:
-Se pueden aumentar disminuir el nº de módulos para producir una
factorización lógica, con buena calidad, fácil de
implementar/probar/mantener.
-Refinamientos: están dictados por consideraciones prácticas, sentido
común y requisitos del software.

4. -Reflejar los parámetros: datos=flujos de información del DFD;
flags=se obtienen de las descripciones de procesos.
7. Asegurarse del trabajo realizado por el diseño obtenido:
-Se puede revisar el DE comprobando que el orden de ejecución de los
módulos es el correcto.
Análisis de transacción:
-Revisión del modelo fundamental del sistema.
-Determinar si el DFD tiene características de transformación o de
transacción.
-Identificar el centro de transacción y las características del flujo de
cada camino de acción.
La posición del centro de transacción puede descubrirse
inmediatamente a partir del DFD. El centro de transacción está ligado al
origen de varios caminos de información que fluyen de él. La exclusividad no
se suele reflejar en el DFD, por lo que hay que conocer los requisitos.
Se identifica el camino de llegada, el centro de transacción y los
caminos de acción.
-Realizar el primer corte del diagrama de estructuras.
-Realizar el segundo nivel de factorización.
-Refinar la estructura del programa.
-Asegurarse del trabajo realizado por el diseño obtenido.
Atributos de la calidad de un diseño:
En cada proyecto se deben decidir cuáles son los requisitos de calidad
a cumplir, y decidir los más importantes.
Para asegurar y evaluar la calidad del software, ésta se debe poder
medir. Para ello se emplean las MÉTRICAS del software.
Aquí nos centramos en las métricas que miden la calidad estructural:
-Cohesión.
-Acoplamiento.
Cohesión:
Indica la relación que existe entre los elementos de un mismo módulo.
Es la medida de la relación funcional de los elementos de un módulo.

5. El objetivo es organizar estos elementos de manera que los que
tengan una mayor relación a la hora de realizar una tarea pertenezcan al
mismo módulo, y los elementos no relacionados, se encuentren en módulos
separados.
Acoplamiento:
Es el grado de interdependencia entre los módulos.
Un buen diseño se caracteriza por un acoplamiento mínimo, es decir,
unos módulos tan independientes los unos de los otros como sea posible.
Técnica de diseño estructurado
Objetivos de la técnica:
-Obtener la estructura modular y los detalles de proceso del sistema,
partiendo solamente de los productos obtenidos en la fase de Análisis del
Sistema.
-Cambiar la atención del QUE al COMO.
-Obtener un diseño que no sólo funcione, sino que también sea
mantenible, mejore la reutilización y se pueda probar y entender fácilmente.
-Utilizar herramientas gráficas (Diagramas de Estructura de Cuadros)
para representar la estructura modular del sistema.
Se trata por tanto, de conseguir que cada módulo de la estructura en
árbol que se obtenga cumpla las siguientes características:
Módulos de pequeño tamaño:
El impacto de un cambio a realizar puede ser perfectamente aislado. Si
el tamaño de los módulos es reducido, una determinada modificación
afectará a un número mayor de módulos, sin embargo, la cantidad de código
a considerar será menor.
Independencia modular:
Cuanto mayor es la independencia de un módulo es más sencillo
trabajar con él, por tanto, el diseño debe reducir la compartición de ficheros,
de datos, la de dispositivos, las interfaces comunes con el Sistema Operativo
y las llamadas, desde o hacia otros módulos.
Características de Caja Negra:
La característica de Caja Negra se aplica a cualquier sistema, programa
o módulo, para dar una visión exclusiva de sus entradas y salidas, sin tener

6. en cuenta los detalles de cómo se realiza el proceso. El uso de la Caja Negra
permite una visión más fácil del conjunto, posponiendo la consideración de
los detalles para una etapa posterior.
Modelización conceptual:
Un sistema será más fácil de mantener si el modelo utilizado en su
diseño se ha basado en los conceptos lógicos de la organización, los cuales
serán más familiares y comprensibles para el personal de mantenimiento que
las descripciones físicas (equipo, organización de la unidad, cómo se realiza el
trabajo en la actualidad).
Aislamiento de los detalles:
En un sistema existen partes que reflejan la filosofía y otras partes que
reflejan los detalles. Debido a que los detalles son más susceptibles de
cambiar, ambas partes deben diseñarse por separado para evitar que una
variación en los detalles afecte a la filosofía del sistema.
Diseño:
Es el proceso de definición de la arquitectura software: componentes
módulos, interfaces, procedimientos de prueba y datos de un sistema que se
crean para satisfacer unos requisitos especificados.
Se considerarán dentro del diseño, dos partes, atendiendo al nivel de detalle:
Diseño de arquitectura:
Proceso de definición de la colección de componentes del sistema y
sus interfaces.
Diseño detallado:
Proceso de descripción más detallada de la lógica del proceso y de las
estructuras de datos.
Diseño de procesos:
Una vez finalizada la Fase de Análisis del Sistema, se dispondrá, al
iniciar la Fase de Diseño de un conjunto de especificaciones funcionales que
describan, con términos precisos:
-Las entradas que suministran al sistema las entidades externas.
-Las salidas aportadas por el sistema a dichas entidades externas.
-Las funciones descompuestas que se han de realizar por ese sistema.

7. -El modelo de datos lógico del sistema.
-Toda esta información estará almacenada en el diccionario del
proyecto, mediante la descripción de Diagramas de Flujo de Datos, Procesos,
Flujos de Datos, Diagramas de Estructuras de Datos, Entidades y Atributos.
Para pasar a construir el nuevo sistema, es necesario convertir toda
esta información en especificaciones de programas.
Las tareas a realizar son:
-Determinar qué módulos implantarán los procesos terminales
obtenidos en la Fase Análisis del Sistema.
-Organizar la estructura de estos módulos y definir las conexiones
entre los mismos.
-Describir el pseudocódigo para cada módulo.
Para ello se seguirá el método propuesto por CONSTANTINE: el
Diagrama de Estructura de Cuadros, que permite definir cuándo, bajo qué
condiciones y cuántas veces se tienen que realizar los tratamientos
identificados en los PROCESOS. Los datos se contemplan como la interface
entre tratamientos sucesivos.
1. Descripción de la técnica:
El paso de la Fase de Análisis del Sistema al diseño será más fácil si se
ha llegado a un nivel de detalle muy bajo en los Diagramas de Flujo de
Datos.
La estructura Constantine nos da una visión de Arquitectura del
sistema. Se trata pues, de no tener ninguna restricción en cuanto al número
de objetos, siempre y cuando el dibujo pueda realizarse en una hoja, para no
perder la referencia y, en cualquier caso, poder explosionar aquella función
que se descomponga.
2. Herramientas de diseño: diagrama de estructura de Cuadros.
La herramienta más importante utilizada es el DIAGRAMA DE
ESTRUCTURA DE CUADROS (Structure Chart).
Este diagrama está compuesto por tres elementos básicos:
-Módulos
-Conexiones entre módulos
-Comunicación entre módulos

8. Modulo:
El módulo representa un programa, subprograma o rutina,
dependiendo del lenguaje que se vaya a utilizar. Se representa en el
Diagrama mediante un rectángulo.
El diseño estructurado NO ha impuesto la restricción de que un módulo
tenga que ser compilado independientemente.
Se considera al módulo como aquella parte de código que se puede
llamar.
Es, por tanto, algo que admite parámetros de llamada y retorna algún
valor, si es preciso.
Conexión:
La conexión entre módulos se representa mediante una línea.
3. Principios del diseño estructurado:
Descomposición:
La descomposición es la separación de una función en otras que
estuvieran contenidas en la primera.
La descomposición consigue los siguientes objetivos:
(a) Reducir el tamaño del módulo.
(b) Hacer el sistema más fácil de entender y modificar.
(c) Minimizar la duplicidad de código.
(d) Crear módulos útiles.
4. Estrategias de diseño:
El paso de los Diagramas de Flujo de Datos (DFD), obtenidos en la
Fase Análisis del Sistema, a los Diagramas de Estructura de Cuadros (DEC),
se puede hacer utilizando una serie de estrategias que ayuden a conseguir
una rápida derivación hacia un buen diseño.
Habrá que estudiar la forma del DFD sobre el que se vaya a realizar el
diseño y dependiendo de su estructura, utilizar una de las estrategias que se
describen a continuación. El uso de una de las dos estrategias no supone que
la otra no pueda ser utilizada. Dependerá únicamente de la forma del
DFD y del peso de la actividad de los procesos.
A partir de esta primera estructura y utilizando las métricas que se
verán en el siguiente apartado, se realizará la evaluación y refinamiento del
diseño hecho, consiguiéndose, de esa forma, un diseño con una calidad alta.
Estas estrategias son:

9. -Análisis de Transformación.
-Análisis de Transacción.
El objeto de estas estrategias es desarrollar una representación global
de la Arquitectura del Sistema. Una vez que se define la estructura, podemos
evaluar y refinar esta Arquitectura, viéndola como un todo.
Análisis de transformación:
El Análisis de Transformación es una estrategia, no un algoritmo. Si se
siguen los pasos de un algoritmo los resultados están asegurados y son
correctos, una estrategia consigue resultados buenos, pero no perfectos en
una primera aproximación.
El análisis de transformación es un conjunto de pasos que permiten
obtener, a partir de un DFD con características de transformación, la
estructura del sistema.
El DFD con características de transformación es aquél en el que se
pueden distinguir tres zonas:
-Flujo de llegada o entrada.
-Flujo de transformación o centro de transformación.
-Flujo de salida.
Esta división en tres partes va a facilitar que, los datos que necesite el
sistema se recojan por los módulos que se encuentren en la/s rama/s de la
izquierda, los datos que se intercambian en esa rama serán ascendentes:
información de entrada al sistema.
En las ramas centrales habrá movimiento de información compartida
tanto ascendente como descendente porque aquí los módulos elaboran
nuevos datos.
En la/s rama/s de la derecha, la información ya será la definitiva y el
sentido de los datos debe ser descendente.
En algún caso particular puede suceder que alguna de las partes sea vacía,
esto es, no exista.
Pasos del análisis de transformación:
(a) Aislar el centro de transformación.
(b) Realizar el primer nivel de factorización del Diagrama de Estructura
de Cuadros.
(c) Elaborar el segundo nivel de factorización.
(d) Refinar la estructura del sistema utilizando medidas y guías de
diseño.