DISEÑO ESTRUCTURADO
Los
métodos de diseño del software se obtienen del estudio de cada uno de los tres
dominios del modelo de análisis. El dominio de los datos, el funcional y el de
comportamiento sirven de directriz para la creación del diseño.
En
el diseño estructurado orientado al flujo de datos, partimos de la
representación del flujo de la información obtenida en la fase de análisis,
donde la información puede representarse como un flujo continuo que sufre una
serie de transformaciones conforme va de la entrada a la salida.
El
diagrama de flujo de datos DFD (o de burbujas) se utiliza como herramienta
gráfica para la descripción del flujo de la información.
1.DISEÑO DE DATOS
El
impacto de la estructura de datos sobre la estructura del programa y la complejidad
procedimental hace que el diseño de datos tenga una gran influencia en la
calidad del software.
Los
datos bien diseñados pueden conducir a una mejor estructura de programa, a una
modularidad efectiva y a una complejidad procedimental reducida.
2. DISEÑO
ARQUITECTÓNICO
El
objetivo principal del diseño arquitectónico es desarrollar una estructura
de programa modular y representar las relaciones de control entre los
módulos. Mezcla la estructura de programas y la estructura de datos y define las
relaciones que facilitan el flujo de los datos a lo largo del programa.
El
diseño orientado al flujo de datos es compatible con un amplio rango de áreas
de aplicación. Es particularmente útil cuando se procesa secuencialmente la
información y no existe ninguna estructura jerárquica formal. De hecho, todo el
software puede representarse como un diagrama de flujo de datos. Ejemplo: aplicaciones con microprocesadores,
procedimientos de análisis numérico, procesos de control, etc.
3. EL PROCESO DEL
DISEÑO ARQUITECTÓNICO
El
diseño orientado al flujo de datos define varias representaciones que
transforman el flujo de la información en la estructura del programa.
El
Diseño Orientado al Flujo de Datos permite una cómoda transformación de las
representaciones de la información (DFD) a una descripción de la estructura del
programa. Este proceso debe seguir los siguientes pasos:
1. Establecer el
tipo de flujo de información.
- Flujo de
transformación.
- Flujo de
transacción.
2. Determinar
los límites del flujo.
3. Convertir el
DFD en la estructura del programa
4. Definir la
jerarquía de control descomponiéndola mediante particionamiento.
5. Refinar la
estructura resultante usando medidas y heurísticas de Diseño.
El tipo de flujo de información es lo que
determina el método de conversión requerido en el paso
3.
FLUJO DE
TRANSFORMACIÓN:
En
un sistema, la información entra y sale en una forma del mundo exterior
(entradas de teclado, tonos telefónicos, imágenes de visualización,...). Esos
datos externos, deben ser convertidos a una forma adecuada para el
procesamiento.
La
información entra al sistema mediante caminos que transforman los datos
externos a una forma interna y se identifica como Flujo Entrante.
En
el interior del software se produce una transición, los datos entrantes pasan a
través de un centro de transformación, moviéndose ahora hacia la salida del
software. Estos datos forman el Flujo Saliente.
El
flujo de datos global ocurre de forma secuencial y sigue uno o pocos caminos
directos. Cuando una parte del DFD tiene estas características decimos que es
un Flujo de Transformación.
· FLUJO DE TRANSACCIÓN:
El flujo de
transacción se caracteriza por el movimiento de datos a través de un camino de
llegada que convierte la información del mundo exterior en una transacción. Se evalúa
la transacción y de acuerdo con su valor, el flujo sigue por uno de los muchos caminos
de acción.
El
centro del flujo de información desde el que emanan los caminos de acción se
denomina Centro de Transacción. Dentro de un flujo de transacción, el
flujo de información a través de un camino de acción puede tener
características de flujo de transformación.
En
el DFD de un sistema, generalmente estarán presentes los dos tipos de flujos:
el flujo de transformación y el flujo de transacción.
El
Diseño Orientado al Flujo de Datos comienza con una evaluación del DFD a nivel
2 ó 3. Se establece el tipo de flujo de información y se definen los límites
del flujo que delimitan el centro de transformación o de transacción. Se
convierten las transformaciones (burbujas del DFD) en módulos, como estructuras
de programa. Se factoriza la estructura, es decir, los módulos se definen y
organizan mediante una distribución descendente del control en la estructura.
Por último se refina la estructura obtenida.
4. ANALISIS DE
TRANSFORMACIÓN
El
análisis de transformación es un conjunto de pasos de diseño que permiten
convertir un DFD, con características de flujo de transformación, en una
plantilla predefinida para la estructura del programa.
4.1.- PASOS DEL
DISEÑO
Los
pasos comienzan con una reevaluación del trabajo hecho durante el análisis de
requisitos y luego evoluciona hacia el desarrollo de la estructura del
programa. Estos pasos son:
1. Revisar el
modelo fundamental del sistema: revisar el DFD nivel 0 y la información
complementaria.
2. Revisar y
refinar los DFD del software: se examinan los DFD nivel 1, 2 y 3 hasta el
nivel en que cada transformación tiene una cohesión alta (es decir, cada
transformación ejecuta una función sencilla y diferenciada) pudiéndose
implementar como un módulo. En este paso se llega al nivel que contiene
suficiente detalle como para establecer un diseño inicial para la estructura
del programa.
3. Determinar
si el DFD tiene características de transformación o de transacción: en
general, el flujo de información de un sistema podrá representarse siempre como
una transformación.
Si
tiene una característica obvia de transacción es conveniente tratarla como tal.
El diseñador
selecciona la característica general del flujo basándose en la naturaleza
prevaleciente del DFD.
Se
aíslan las regiones locales de flujo de transformación o de transacción, lo que
nos permitirá refinar la estructura del programa posteriormente.
4. Aislar el
centro de transformación especificando los límites de los flujos entrante y
saliente: la interpretación de los límites es algo subjetivo dependiente
del diseñador, así es posible obtener distintas soluciones alternativas
variando los límites del flujo. El diseñador debe establecer unos límites
razonables.
5. Realizar
una descomposición de primer nivel: la estructura del programa representa
una distribución descendente del control. La descomposición da como resultado
una estructura de programa en la que los módulos de nivel superior toman las
decisiones de ejecución y los módulos de nivel inferior ejecutan la mayoría del
trabajo de entrada, de procesamiento y de salida. Los módulos de nivel
intermedio ejecutan algún control y realizan moderadas cantidades de trabajo.
(Ejemplo)
En
la parte superior de la estructura del programa se encuentra un módulo de
control, que sirve para coordinar las funciones de control subordinadas, que
son:
a). Controlador
del procesamiento de la información entrante, que coordina la recepción de
todos los datos que llegan
b). Controlador
del centro de transformación, que supervisa todas las operaciones sobre los
datos en su forma interna
c) Controlador
del procesamiento de la información saliente, que coordina la producción de la
información que sale.
Cada
módulo de control tiene un nombre que indica la función de los módulos
subordinados que controla.
6. Realizar
descomposición de segundo nivel: se realiza mediante la conversión de las
transformaciones individuales (burbujas) de un DFD, en los módulos
correspondientes a la estructura del programa.
Comenzando
dentro de los límites del centro de transformación y yendo hacia fuera a través
de los caminos de entrada y luego de salida, las transformaciones se convierten
en niveles subordinados de la estructura de control.
Así se obtiene
una estructura de programa inicial, también llamada Diagrama de Estructura.
Aunque
hemos hecho una correspondencia uno a uno entre las burbujas del DFD y los
módulos del software, también se pueden combinar 2 ó 3 burbujas,
representándolas como un solo módulo, o también puede dividirse una burbuja en
dos o más módulos.
Aunque
los módulos que forman la estructura de programa tienen un nombre que indica la
función que realiza, se debe escribir para cada uno de ellos un breve texto que
explique su procesamiento.
La información
que contendrá es:
· La información que entra y la que sale
del módulo
· La información que es retenida en el
módulo (ejemplo: en almacenamientos de datos)
· Explicación del procedimiento, indicando
los principales puntos de decisión y las tareas.
· Tratamiento de las restricciones y
características especiales, si las hay.
7. Refinar la
estructura inicial del programa usando heurísticas para mejorar la calidad del
software.
La
estructura inicial del programa siempre puede refinarse aplicando los
fundamentos de diseño, por ello, se puede aumentar o reducir el número de
módulos para obtener una descomposición con una buena cohesión, un mínimo
acoplamiento, una estructura de fácil implementación, prueba y mantenimiento.
Los refinamientos se rigen por consideraciones prácticas y de sentido común.
Hay
ocasiones en las que el controlador de flujo de datos entrante/saliente es innecesario,
o se requiere un procesamiento de la entrada en un módulo subordinado al controlador
de transformaciones, o no se puede conseguir un bajo acoplamiento por la necesidad
de trabajar con datos globales.
5. ANÁLISIS DE
TRANSACCIÓN.
Cuando
en un sistema hay un flujo de transacción, dependiendo del valor de ese elemento
transacción, se seguirá uno u otro camino de acción de todos los posibles.
Pasos a seguir:
1. Revisar el
modelo fundamental del sistema.
2. Revisar y
refinar los DFD.
3. Determinar
si el DFD tiene características de transformación o de transacción.
4. Identificar
el centro de transacción y las características del flujo de cada camino de
acción.
El
centro de acción se localiza fácilmente en el DFD, es el origen de varios
caminos de información que fluyen radialmente de él. También deben aislarse el
camino entrante y todos los caminos de acción.
5. Transformar
el DFD en una estructura de software adecuada al procesamiento de transacciones.
El
flujo de transacción se convierte en una estructura de programa que contiene una
rama entrante y una rama de distribución.
· la rama entrante se obtiene igual que el
análisis de transformación, desde el centro de transacción hacia fuera, se
convierten las burbujas en módulos.
· la rama de distribución tiene un módulo
distribuidor que controles todos los módulos de acción subordinados.
El flujo de cada
camino de acción del DFD se convertirá en una estructura que se corresponda con
las características del flujo (de transformación o de transacción).
6. Descomponer y refinar la
estructura de transacción y la estructura de cada camino de acción. Cada
camino de acción del DFD tiene sus propias características de flujo de
información o de transacción. La subestructura de cada camino de acción se
obtiene siguiendo los pasos del análisis correspondiente.
7. Refinar la estructura
inicial del software usando heurísticas de diseño para mejorar la calidad.
6. HEURÍSTICAS DE
DISEÑO
La Heurística es
un método de resolver problemas utilizando técnicas de ensayo y error. El diseño
heurístico de programas provee de un marco para resolver el problema en
contraposición con un conjunto fijo de reglas que no pueden variar.
Estas
heurísticas de diseño consisten en los siguientes pasos:
1.
Evaluar la estructura de programa preliminar para
reducir el acoplamiento y mejorar la cohesión. Los módulos pueden expandirse o
reducirse siempre que se mejore la independencia de los módulos. A
menudo se produce un módulo expandido cuando en dos o más módulos existe
un componente de procesamiento común y puede redefinirse como un módulo
cohesivo aparte.
Intentar minimizar
las estructuras con alto grado de salida, fomentar un alto grado de entrada
conforme aumente la profundidad. Ejemplo.
1.
3.
Mantener el efecto de un módulo dentro del ámbito de control de ese módulo.
4. Evaluar los interfaces de
los módulos para reducir la complejidad y la redundancia y mejorarla
consistencia. Quiere decir que se debe revisar la información que se pasa
en los interfaces para pasar únicamente la información necesaria.
5. Definir módulos cuyas
funciones sean predecibles, para evitar módulos que sean demasiado restrictivos.
6. Fomentar módulos con
entrada única y salida única, evitando las “conexiones patológicas”. El
software es más fácil de comprender y mantener cuando se entra a los módulos
por el principio y se sale por el final.
7. Empaquetar el software de
acuerdo con las restricciones del diseño y los requisitos de portabilidad.
7. DISEÑO
PROCEDIMENTAL
Se
realiza después de que se ha establecido la estructura del programa y de los
datos. Debe especificarlos detalles de los procedimientos sin ambigüedad.
Los
fundamentos del diseño procedimental se establecieron cuando se propuso el uso
de un conjunto de construcciones lógicas con las que podía formarse cualquier
programa.
Las
construcciones son: la
secuencia ; la condición ; y la repetición.
Estas
tres construcciones son fundamentales en la programación estructurada. Las
construcciones estructuradas se propusieron para limitar el diseño procedimental
del software a un conjunto reducido de operaciones predecibles, facilitando la
legibilidad, prueba y mantenimiento de los programas.
