Dise o estructurado (2)

Ingeniería del Software.
.- Diseño Estructurado.
TEMA - DISEÑO ESTRUCTURADO
1. INTRODUCCIÓN
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 areas 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.
.- 1 -.
Ingeniería del Software.
.- Diseño Estructurado.
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.
REPRESENTACION EXTERNA
FLUJO ENTRANTE
REPRESENTACION INTERNA
FLUJO de
TRANSFORMACION
REPRESENTACION EXTERNA
FLUJO SALIENTE
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, moviendose 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 evalua la transacción
y deacuerdo con su valor, el flujo sigue por uno de los muchos caminos de acción.
CAMINOS
TRANSACCION
T
DE
CENTRO DE
TRANSACCION
ACCION
Suele ser una selección,
dependiendo del valor del
dato se va por un camino
o por otro.
.- 2 -.
Ingeniería del Software.
.- Diseño Estructurado.
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) pudiendose 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 basandose en la naturaleza prevaleciente del DFD.
Se aislan 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
.- 3 -.
Ingeniería del Software.
.- Diseño Estructurado.
salida. Los módulos de nivel intermedio ejecutan algún control y realizan moderadas cantidades de trabajo.
Ejemplo:
A
B
F
E
C
D
FLUJO ENTRANTE
H
I
J
K
G
FLUJO DE
TRANSFORMACION
FLUJO SALIENTE
CONTROLADOR
PRINCIPAL
CONTROLADOR
DEL FLUJO
ENTRANTE
CONTROLADOR
DEL FLUJO DE
TRANSFORMACION
CONTROLADOR
DEL FLUJO
SALIENTE
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.
.- 4 -.
Ingeniería del Software.
.- Diseño Estructurado.
CONTROLADOR
PRINCIPAL
CONTROLADOR
DEL FLUJO
ENTRANTE
B
D
A
C
CONTROLADOR
DEL FLUJO DE
TRANSFORMACION
E
F
G
H
CONTROLADOR
DEL FLUJO
SALIENTE
I
J
K
Así obtenemos 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 sólo
módulo, o tambien 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
sofware.
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
.- 5 -.
Ingeniería del Software.
.- Diseño Estructurado.
transformaciones, o no se puede conseguir un bajo acoplamiento por la necesidad de trabajar
con datos globales.
Conclusión :
• El objetivo que se quiere conseguir con la aplicación de estos pasos, es el desarrollo de una
Representación general del software.
• Podremos evaluar y refinar la arquitectura del software considerando que es la base de la calidad y fácil mantenimiento del software.
5. ANÁLISIS DE TRANSACCIÓN.
Cuando en un sistema hay un flujo de transacción, dependiendo del valor de ese elementotransacció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 controls 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).
Ejemplo:
E
C3
A
B
D
H
C
C2
F
G
C1
I
J
.- 6 -.
K
L
M
Ingeniería del Software.
.- Diseño Estructurado.
CONTROL DE
TRANSACCION
CONTROL DEL
FLUJO ENTRANTE
C
CAMINO 1
CAMINO 2
DISTRIBUIDOR
CAMINO 3
B
K
A
L
M
J
6. Descomponer y refinar la estructura de transaccion 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.
Idem anterior.
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.
2. Intentar minimizar las estructuras con alto grado de salida, fomentar un alto grado de entrada conforme aumente la profundidad.
Ejemplo:
.- 7 -.
Ingeniería del Software.
.- Diseño Estructurado.
Se trata de evitar esto
y conseguir esto
3. Mantener el efecto de un módulo dentro del ámbito de control de ese módulo.
El ámbito del efecto de un módulo m se define por todos los módulos que quedan afectados por
una decisión tomada en el módulo m.
El ámbito de control del módulo m está formado por todos sus módulos subordinados.
Ejemplo:
Se trata de evitar esto
Efecto de
la decisión
y conseguir esto
Decisión
Decisión
Efecto de la
decisión
4. Evaluar los interfaces de los módulos para reducir la complejidad y la redundancia y mejorar la 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.
.- 8 -.
Ingeniería del Software.
.- Diseño Estructurado.
7. Empaquetar el software de acuerdo con las restricciones del diseño y los requisitos de portabilidad.
7. DISEÑO PROCEDIMENTAL
Se realiza despues de que se ha establecido la estructura del programa y de los datos. Debe especificar los 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.
La CONDICION
La SECUENCIA
CONDICION
PRIMERA
TAREA
F
T
PARTE
ELSE
PARTE
THEN
SEGUNDA
TAREA
IF - THEN - ELSE
La SELECCIÓN
T
F
PARTE DEL
CASO
T
CASOS DE
CONDICIÓN
F
T
F
.- 9 -.
Ingeniería del Software.
.- Diseño Estructurado.
La REPETICION
CUERPO
DEL BUCLE
T
CONDICION
DEL BUCLE
F
WHILE - DO
CUERPO
DEL BUCLE
CONDICION
DEL BUCLE
F
T
REPEAT - UNTIL
NOTACIONES GRÁFICAS DE DISEÑO.
• El DIAGRAMA DE FLUJO u ORGANIGRAMA es la representación gráfica más ampliamente usada para el diseño procedimental. Como ya hemos visto en el gráfico anterior, la notación es la siguiente:
un paso de procesamiento
Las construcciones estructuradas pueden estar anidadas
unas en otras, desarrollando
de esta forma esquemas lógicos complejos.
una condición lógica
flujo de control
• El DIAGRAMA DE CAJAS:
CONDICION
TAREA1
F
T
TAREA2
...
PARTE PARTE
SECUENCIA
ELSE
THEN
IF - THEN - ELSE
.- 10 -.
Ingeniería del Software.
.- Diseño Estructurado.
CONDICION BUCLE
CASO DE CONDICION
PARTE
WHILE - DO
PARTE
REPEAT - UNTIL
VALOR
VALOR
PARTE
DEL
CASO
PARTE
DEL
CASO
. . .
SELECCION
CONDICION BUCLE
REPETICION
NOTACIONES TABULARES DE DISEÑO:
Las Tablas de Decisión nos permiten representar las condiciones y acciones que se han de
contemplar en un módulo.
Condiciones y Acciones
Condiciones
Acciones
Reglas
Alternativas de la condición
Registro de las Acciones
Ejemplo: Política de Ventas de un Almacén
Condiciones y Acciones
Cantidad < 50.000 Pts. ...
Pago al contado
Pago con cheque
Pago con tarjeta
Registrar la venta .
Autorizar por el supervisor
Comprobar crédito tarjeta
1
2
Reglas
3 4 5
S S S N N
S N N S N
N S N N S
N N S N N
X X
X
X
X
6
3+6
N
N
N
S
--N
N
S
X
X
X
Regla 5 ⇒ Si el total NO es inferior de 50.000 Pts. y el cliente NO paga al contado y Paga con
cheque y NO paga con tarjeta,
Entonces la venta se autorizará por el supervisor
.- 11 -.
Ingeniería del Software.
.- Diseño Estructurado.
OFERTA DE TRABAJOS. SELECCION.
R E
G
Condiciones y Acciones 1+2 1
2
3
4
Está trabajando
N
N
N
N
N
Tiene cargas familiares
N
N
N
S
S
Recibe ayuda estado (sub- -N
S
N
S
sidio)
Añadir a lista preferente
X
X
Añadir a lista ordinaria
X
X
X
L
5
S
N
N
A
6
S
N
S
X
S
7
S
S
N
8
S
S
S
X
Para construir la tabla de decisión se define su tamaño máximo, eliminando cualquier situación
imposible.
Para desarrollar una tabla de decisión se aplican los siguientes pasos:
1. Listar todas las acciones que puedan realizarse
2. Listar todas las condiciones que puedan afectar a la condición
3. Rellenar todas las alternativas de la condición, eliminando posteriormente las situaciones
imposibles, contradictorias y redundantes
4. Asociar conjuntos específicos de condiciones con acciones determinadas. Es decir, determinar las reglas.
5. Combinar las reglas donde sea aparente que una alternativa no implique diferencias en la
salida.
NOTACIÓN ALGORÍTMICA. LENGUAJE DE DISEÑO DE PROGRAMAS (LDP).
El LDP es el pseudocódigo de uso general, aunque existen LDP comerciales que permiten
traducirlo a representación gráfica (ej: Diagramas de flujo).
La diferencia entre un LDP y un lenguaje de programación de alto nivel real se encuentra
en el uso de texto descriptivo en las sentencias del LDP, por lo que no puede ser compilado.
Un lenguaje de diseño de programas debe tener las siguientes características:
a) Una sintaxis fija de palabras clave que permitan construir todas las construcciones
estructuradas, declarar datos y establecer características de modularidad.
b) Una sintaxis libre en lenguaje natural para describir las características del procesamiento.
c) Facilidades para la declaración de datos, incluyendo estructuras de datos simples y
complejas.
d) Un mecanismo de definición de subprogramas y de invocación, soportando los distintos modos de descripción de interfaces.
Normalmente se utiliza un lenguaje de programación de alto nivel como base para el LDP.
Anteriormente hemos visto distintas notaciones de diseño:
• Diagramas de Flujo
• Diagramas de Caja
• Tablas de Decisión
• Lenguaje de diseño de programas
.- 12 -.
Ingeniería del Software.
.- Diseño Estructurado.
Una notación de diseño debe conducir a una representación procedimental, que sea fácil de
comprender y revisar. También debe de facilitar la codificación.
8. RESUMEN
El diseño es técnicamente la parte central de la ingeniería del software.
El diseño da como resultado representaciones del software cuya calidad se puede evaluar.
Los conceptos de modularidad y de abstracción permiten al diseñador simplificar y reutilizar los
componentes del software.
El refinamiento es un mecanismo que permite representar sucesivas capas de detalle funcional.
La estructura de programa y de datos contribuyen a la visión general de la arquitectura del software.
La notación del diseño, junto con los conceptos de programación estructurada, permite al diseñador representar los detalles procedimentales, facilitando su traducción al código.
Las herramientas disponibles son:
• gráficas
• tabulares
• textuales
.- 13 -.