INGENIERIA DEL SOFTWARE I 3º Informática Gestión

DISEÑO DE FUNCIONES (TRATAMIENTOS)

Diseño Estructurado.
Estrategias para Derivar el Diagrama de Estructura.
Diseño de Módulos Programables.

1. DISEÑO ESTRUCTURADO

El Diseño es el proceso por el cual se traducen las especificaciones de requerimientos en una representación
del software. Representa un puente entre el análisis de un problema y la implementación de la solución a ese
problema.
El Diseño Estructurado se basa en los principios de abstracción, modularidad y ocultación de la
información. Utiliza el particionamiento del sistema en módulos y su organización jerárquica para reducir la
complejidad del mismo. Las características de un módulo son:
1. Se conocen las entradas que espera.
2. Se conocen las salidas que produce.
3. Se sabe qué función lleva a cabo.
4. No se necesita saber cómo realiza su función.

1.1. El Diagrama de Estructura

El Diagrama de Estructura (DE) es una herramienta gráfica que permite representar la descomposición de un
sistema en módulos. Tiene forma de árbol, en el cual cada nodo se corresponde con un módulo del sistema, de
tal forma que se expresa la jerarquía de control que se establece entre los módulos; es decir, qué módulo o
módulos pueden invocar a otros módulos. Además, muestra la comunicación existente entre los módulos, es
decir, mediante qué datos se comunican.

1.2. Representación Gráfica De Un Módulo.

En un DE un módulo se representa mediante un rectángulo, con el nombre dentro del mismo. El nombre
debe reflejar fielmente qué hace cuando es llamado, su función.
Para los módulos predefinidos o de librería, que son módulos que se definieron anteriormente en algún sitio,
se usa un rectángulo con dos líneas paralelas verticales.

1.3. Conexión Entre Módulos.

Las conexiones entre módulos, es decir, las llamadas de un módulo a otro, se representan mediante una
flecha que va desde el módulo que realiza la invocación hacia el módulo invocado.
Cuando un módulo invoca a otro, se produce un intercambio de información, según está determinado en la
definición de cada módulo. La información que se intercambia puede ser de dos tipos: datos y control (flag).
Acoplamiento por datos.
Acoplamiento por control (flag).
Las diferencias entre datos y flag son:
• Los datos son procesados, mientras que los flags son activados y testados,
• Los datos pertenecen al entorno del problema, mientras que los flags son entidades artificiales.

Diseño de Funciones Pág. 1 de 9

INGENIERIA DEL SOFTWARE I 3º Informática Gestión

1.4. Criterios para Evaluar la Calidad de un Diseño.

El Diseño Estructurado proporciona dos criterios fundamentales para evaluar la calidad de un diseño
software: el acoplamiento y la cohesión.

Acoplamiento
El acoplamiento es un medio de evaluar la relación entre los distintos módulos de un sistema. Esta relación
determina la facilidad para efectuar modificaciones o extensiones en el sistema.
Se define acoplamiento como la medida del grado de interdependencia entre los módulos de un sistema.
Lo deseable es tener módulos con poco acoplamiento; es decir, módulos que son independientes entre sí.
Los tipos de acoplamiento son:
• Normal: Por datos, por estampado (dato compuesto), por control.
• Común (o global).
• Por contenido.

Cohesión
El estudio de la cohesión se aplica a cada módulo y mide el grado de conexión funcional entre los
constituyentes o elementos de un mismo módulo. El nivel de cohesión de un módulo es una indicación de la
conexión funcional entre sus elementos.
Se define cohesión como la medida de la fuerza de la relación funcional entre los elementos de un módulo.

Diseño de Funciones Pág. 2 de 9

INGENIERIA DEL SOFTWARE I 3º Informática Gestión

Los tipos de cohesión son:

• Funcional.
• Secuencial.
• Comunicacional.
• Procedural.
• Temporal.
• Lógica.
• Casual.

2. ESTRATEGIAS PARA DERIVAR EL DIAGRAMA DE ESTRUCTURA (DE).

El Diseño Estructurado suministra un procedimiento general de transformación que permite pasar de un
DFD que contenga un solo tipo de transacción a un DE. Este diagrama debe refinarse posteriormente utilizando
fundamentalmente los criterios de acoplamiento y cohesión.
El procedimiento consta de dos estrategias: análisis de transacciones y análisis de transformaciones, que se
aplican en el siguiente orden:
1. Análisis de transacciones: Para determinar el número de transacciones que posee el DFD del sistema.
2. Análisis de transformaciones: Es el procedimiento de transformación en sí, toma la parte del DFD
inicial que se corresponde con un tipo de transacción y genera de forma casi mecánica un DE.
3. Análisis de transacciones: Para componer los DE en un solo diagrama, usando un centro de
transacciones.

Diseño de Funciones Pág. 3 de 9

INGENIERIA DEL SOFTWARE I 3º Informática Gestión

Si en el sistema hay varios tipos de transacciones, el análisis de transacciones se aplica dos veces, al
principio y al final del proceso. Si posee un solo tipo de transacción se aplica únicamente análisis de
transformaciones.

2.1. Análisis de transacciones.

Consiste en revisitar los DFD generados en la fase de análisis para determinar los tipos de transacciones que
posee el sistema.
Una transacción es un estímulo a un sistema que dispara o activa dentro de él un conjunto de actividades.
Toda transacción posee los siguientes componentes:
• EVENTO: Algo que sucede en el entorno del sistema y que le es relevante.
• ESTIMULO: Señal o conjunto de datos que se emplean para activar una transacción.
• ACTIVIDAD: Está formada por el conjunto de operaciones o de acciones que ocasiona la transacción
dentro del sistema.
• RESPUESTA: Son las señales o datos que emite el sistema y que tienen un efecto sobre el entorno del
mismo.
Los distinto tipos de transacciones se pueden identificar considerando los estímulos que conducen a ese
sistema.
Por ejemplo, en un sistema de Pedidos se pueden identificar tres tipos de transacciones: “Realizar venta”,
“Realizar devolución” y “Admitir pago”. Cada una posee un estímulo que la activa: “Datos de Venta”, “Datos
de Devolución” y “Datos de Pago”.

Las transacciones suelen llevar asociado un código de transacción, porque es posible que los estímulos
compartan la misma interfaz con el usuario, de modo que tiene que haber alguna forma de decirle al sistema la
transacción que el usuario quiere seleccionar.
Por ejemplo, una posible pantalla de selección de transacciones en el anterior sistema de Pedidos sería:

Pulse Código de Transacción

Código Transacción
1 Realizar Venta
2 Realizar Devolución
3 Admitir Pago
4 Salir
Introduzca Código>

Lo habitual para determinar los tipos de transacciones en un sistema es revisar la tabla de eventos que se
utilizó para descomponer el sistema.
Esta descomposición inicial permite obtener una primera descomposición del sistema que se quiere construir
en subsistemas. Cada uno de estos ha de descomponerse, a su vez, para dar lugar a nuevos DFD. Estos
diagramas son los que se usan en el análisis de transformaciones.

Diseño de Funciones Pág. 4 de 9

INGENIERIA DEL SOFTWARE I 3º Informática Gestión

2.2. Análisis de Transformaciones.

El análisis de transformaciones es la estrategia que propone el Diseño Estructurado para convertir en un DE
cada pieza del DFD que se ha obtenido utilizando análisis de transacciones.
La estrategia permite únicamente obtener una primera aproximación al diseño final del sistema. Esta
aproximación ha de evaluarse y refinarse utilizando los criterios de la metodología. Dependiendo de la
complejidad de conexiones del DFD, las modificaciones sobre esa primera versión serán más o menos
profundas.
En pasos, las etapas son las siguientes:
1. Identificar las funciones centrales del DFD o el Centro de Transformación.
2. Convertir el DFD en una primera aproximación o corte al DE.
3. Refinar el DE mediante los criterios de diseño y las guías adicionales.
4. Comprobar que el DE final verifica los requerimientos del DFD inicial.

2.2.1. Identificación del Centro de Tranformación.

El Centro de Transformación es la parte del DFD que contiene las funciones esenciales del mismo y que es
independiente de una implementación particular de la entrada/salida.
En un DFD hay caminos que llevan información desde los límites del sistema hacía el interior del mismo,
ramas aferentes (de entrada). De forma análoga los caminos que llevan información desde el interior hacia los
límites del sistema reciben el nombre de ramas eferentes (de salida).

Para detectar el conjunto de procesos que forman la transformación central se recorren las ramas de entrada
y las ramas de salida de la siguiente forma:
1. Cada rama aferente se rastrea desde el exterior hacia el interior del DFD. Se marca el flujo de datos que
representa a la entrada en su forma esencial (lógica). Es decir, el lugar donde los datos han sido
refinados, desempaquetados y validados pero aún no se ha hecho ningún cálculo con ellos.
2. Cada rama eferente se recorre desde el exterior hacia el interior del DFD. Se marcan los flujos que
representan la salida en su forma esencial (lógica). Es decir, el lugar donde la salida ha sido construida,
pero aún no ha sido preparada para volcarla en un dispositivo externo.
3. Si se unen los puntos marcados en las etapas anteriores los procesos que quedan dentro de esa línea de
demarcación forma la transformación central del DFD.
2.2.2. Primer Corte del DE
Con el primer corte se pretende conseguir una versión inicial del DE del sistema.
Para obtener el primer corte hay dos aproximaciones llamadas respectivamente promover un jefe y alquilar
un jefe.

Diseño de Funciones Pág. 5 de 9

INGENIERIA DEL SOFTWARE I 3º Informática Gestión

Para promover un jefe se busca dentro de la transformación central:

• Un proceso que pertenezca a la misma.
• Que haga poco trabajo y que coordine el trabajo del resto de los procesos de esa transformación central.
• Que se encuentre en un lugar geométrico apropiado.

Una vez seleccionado ese proceso, se tira del mismo hacia arriba manteniendo la estructura (es decir, las
conexiones) del DFD. Al tirar del mismo, se obtiene un tipo de modelo híbrido entre DFD y DE.
El modelo contiene los procesos conectados, tal como lo estaban en el DFD inicial, y muestra también la
dirección en la cual ha de fluir la información.

Después, cada proceso se convierte en un módulo y los datos que fluyen entre procesos se convierten en
parámetros de las llamadas a los módulos. Las ramas de entrada se completan con módulos de lectura y las de
salidas con módulos de escritura.

Diseño de Funciones Pág. 6 de 9

INGENIERIA DEL SOFTWARE I 3º Informática Gestión

La otra aproximación se llama alquilar un jefe. En este caso, se introduce un nuevo proceso dentro del DFD
que se convierte en módulo jefe del DE.
De este proceso se cuelgan las ramas de entrada y de salida, se introduce también un proceso que engloba la
transformación central, que se cuelga del proceso jefe. Finalmente se eliminan las conexiones que hubiese
dentro de la transformación central y se cuelgan todos los procesos contenidos en la misma del proceso que la
engloba.

Después, se añaden los módulos de lectura en las ramas de entrada y los de escritura en las ramas de salida.

Diseño de Funciones Pág. 7 de 9

INGENIERIA DEL SOFTWARE I 3º Informática Gestión

2.2.3. Revisión del Primer Corte.

Esta primera versión ha de someterse a diferentes refinamientos:
En las ramas de entrada y salida añadir los módulos de lectura y escritura necesarios para acceder a las
fuentes de información (base de datos).
Las ramas de entrada y salida del sistema necesitan un tratamiento especial: deben factorizarse y
reorganizarse.
Factorizar, si es necesario, la transformación central usando como guía los niveles del DFD.
Los flujos de rechazo en el DFD se convierten en llamadas a módulos que escriben mensajes de error.
Revisión del nombre de los módulos.
Adición de los flags que sean necesarios: fin de fichero,...
Comprobación de todos los criterios de diseño modular para mejorar el sistema.

2.2.4. Comprobación de que el Diseño Funciona.

El proceso de transformación conlleva una serie de pasos subjetivos: determinar los límites de la
transformación central, selección de la aproximación para obtener un jefe.
Cuando se realiza el primer corte y antes de refinar el sistema, debe imaginarse el pseudocódigo que tendrán
los módulos. Si alguno de los módulos parece tener un código enrevesado, seguramente nos habremos
equivocado en alguno de los pasos del proceso de transformación.
También hay que comprobar que el DE obtenido implementa la especificación correctamente.

2.3. Reconstrucción del Sistema

Este último paso tiene sentido si el sistema posee más de un tipo de transacción.
Si un sistema tiene varias clases de transacciones, aplicando análisis de transformaciones a cada una de
ellas, obtenemos varios DE independientes. Cada uno posee sus ramas aferentes, eferentes y de transformación.

Diseño de Funciones Pág. 8 de 9

INGENIERIA DEL SOFTWARE I 3º Informática Gestión

Ahora, hay que juntar todos estos DE en un solo diagrama. Esto se realiza mediante un centro de
transacciones que actúa como módulo jefe y otro módulo que permite seleccionar el tipo de transacción a
ejecutar.

En el diagrama de estructura no se pasa información desde el módulo jefe a cada una de las transacciones, ya
que cada una de estas es la encargada de obtener sus propios datos y de producir sus propios resultados.

Diseño de Funciones Pág. 9 de 9