“Análisis y Diseño Orientado a Procesos”

Sección:

5T2_Co.

Grupo:

N° 2

Docente:

Ing. Magda Luna.

Asignatura:

Ingeniería De Software II

Integrantes:

Yessenia Del Carmen Meléndez Morales 2001-10007.

Tania Margarita Moreno Sarria 2001-10910.

Ruth Amanda Pérez Bermúdez 2001-10008.

Viernes 6 de Mayo del 2005

 Índice

Introducción........................................................................................................... 1
Análisis Orientado a Procesos ............................................................................. 3
I. Definición .............................................................................................................. 3
II. Objetivos Primarios.............................................................................................. 3
III. Características .................................................................................................. 3
IV. Componentes.................................................................................................... 4
V. Modelado Funcional y Flujo de Información ...................................................... 4
V.1 Diagrama de Flujo de Datos.................................................................................... 5
V.1.1 Convenciones Usadas en Diagramas de Flujo de Datos .................................................. 5
V.1.2 Desarrollo de Diagramas de Flujo de Datos....................................................................... 6
V.1.2.1 Creación del Diagrama de Contexto.......................................................................... 7
V.1.2.2 Expansión del Diagrama de Contexto. ...................................................................... 8
V.1.2.3 Creación de Diagramas Hijos (Niveles mas detallados) ........................................ 10
Diseño Orientado a Procesos............................................................................. 12
VI. Definición ........................................................................................................ 12
VII. Objetivos ......................................................................................................... 12
VIII. Características ................................................................................................ 12
IX. Fases del Diseño Estructurado ..................................................................... 13
IX.1 Diseño de Datos .................................................................................................... 13
IX.2 Diseño Arquitectónico .......................................................................................... 15
IX.2.1 El Proceso del Diseño Arquitectónico.............................................................................. 15
IX.2.1.1 Flujo De Transformación .......................................................................................... 15
IX.2.1.2 Flujo de transacción ................................................................................................. 16
IX.3 Análisis de las Transformaciones ........................................................................ 19
IX.3.1 Pasos del Diseño ................................................................................................................ 19
IX.4 Análisis de las Transacción .................................................................................. 22
IX.4.1 Pasos del Diseño:............................................................................................................... 23
IX.5 Heurísticas De Diseño........................................................................................... 26
IX.6 Diseño Procedimental ........................................................................................... 27
Conclusión ........................................................................................................... 31
Análisis y Diseño Orientado a Procesos

Introducción

La ingeniería del software utiliza una serie de modelos que permiten una
especificación completa de los requisitos y una representación del diseño general
del software a construir.

Entre los modelos de análisis y diseño esta el estructurado.

El Análisis estructurado es una actividad de construcción de modelos, estos

representan el contenido y flujo de la información.

El Diseño Estructurado 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 previamente especificados.

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.

1
 Análisis Orientado a Procesos

Análisis Orientado a Procesos

I. Definición

El análisis estructurado es un método para el análisis de sistemas manuales

o automatizados, que conduce al desarrollo de especificaciones para sistemas
nuevos o para efectuar modificaciones a los ya existentes. Éste análisis permite al
analista conocer un sistema o proceso en una forma lógica y manejable al mismo
tiempo que proporciona la base para asegurar que no se omite ningún detalle
pertinente.

El análisis estructurado se concentra en especificar lo que se requiere que

haga el sistema o la aplicación. Permite que las personas observen los elementos
lógicos (lo que hará el sistema) separados de los componentes físicos
(computadora, terminales, sistemas de almacenamiento, etc.). Después de esto se
puede desarrollar un diseño físico eficiente para la situación donde será utilizado.

El objetivo que persigue el análisis estructurado es organizar las tareas

asociadas con la determinación de requerimientos para obtener la comprensión
completa y exacta de una situación dada.

Muchos especialistas en sistemas de información reconocen la dificultad de

comprender de manera completa sistemas grandes y complejos. El método de
desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por
medio de:
1. La división del sistema en componentes.
2. La construcción de un modelo del sistema.

II. Objetivos Primarios

El modelo de análisis debe lograr los siguientes objetivos primarios:

• Describir las necesidades del cliente.

• Establecer una base para la creación de un diseño de software, es decir,
establecer las especificaciones internas.
• Definir un conjunto de requisitos que se puedan validar una vez que se
ha construido el software.
• Obtener la aprobación del cliente.

III. Características

• Se basa en construir un modelo de las prácticas administrativas que deben ser

realizadas por el nuevo sistema (desde el punto de vista lógico).
• Es crítica en esta fase la determinación y la definición de requerimientos ya
que el fracaso de las especificaciones rompen todo el esfuerzo de desarrollo.

3
 Análisis Orientado a Procesos

• Se busca conocer y especificar lo que se quiere. Si no se sabe lo que se desea

no se puede esperar éxito.
• Las salidas (output) del análisis estructurado son (especificaciones
estructuradas):
- Diagrama de Flujo de Datos Nivelado (DFD) o Modelo Lógico del
Sistema.
- Diccionario de Datos.
- Mini Especificaciones de los Procesos.
• Amplia difusión.
• Presente en numerosas metodologías.
- Jackson.
- Page-Jones.
- Gane & Sarson.
- Yourdon / De Marco.
- Warnier.
- Chen.
- Merise.
- SSADM.
- Métrica.
- Eurométodo
• Herramientas CASE disponibles.

IV. Componentes

1. Símbolos gráficos: Iconos y convenciones para identificar y describir los

componentes de un sistema y las relaciones entre estos.
2. Diccionarios de datos: Descripciones de todos los datos utilizados en el
sistema pueden ser manual o automatizado.
3. Descripciones de procesos y procedimientos: declaraciones formales que
usan técnicas y lenguajes que permiten a los analistas describir actividades
importantes que forman parte del sistema.
4. Reglas: Estándares para describir y documentar el sistema en forma correcta
y completa.

V. Modelado Funcional y Flujo de Información

La información se transforma a medida que fluye por un sistema basado en

computadoras. El sistema acepta entradas en una gran variedad de formas, aplica
elementos de hardware, software y humanos para transformar la entrada en
salida, y produce salida en una gran variedad de formas.

El análisis estructurado es una técnica del modelado del flujo y del contenido
de la información.

4
 Análisis Orientado a Procesos

V.1 Diagrama de Flujo de Datos

El diagrama de flujo de datos es una técnica 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.

Es la herramienta más importante y la base sobre la cual se desarrollan otros

componentes.

Los diagramas de flujo de datos consisten en procesos, flujos, agregados de

datos y terminadores:

• Los procesos se representan por medio de círculos, o 'burbujas' en el

diagrama. Representan las funciones individuales que el sistema lleva a
cabo. Las funciones transforman entradas en salidas.
• Los flujos se muestran por medio de flechas curvas, son conexiones entre
los procesos y representa la información que dicho proceso necesita como
entrada o genera como salida.
• Los agregados de datos se representan por medio de dos líneas paralelas o
mediante una elipse. Muestran colecciones de datos que el sistema debe
recordar por un período de tiempo. Cuando los diseñadores de sistema y
programadores terminen de construir el sistema, estos serán archivos o
bases de datos.
• Los terminadores muestran la entidad externa con la que el sistema se
comunica, típicamente son individuos; grupos de personas; organizaciones
externas; otros sistemas, etc.

El modelo original se detalla en diagramas de bajo nivel que muestran

características adicionales del sistema. Cada proceso puede desglosarse en
diagramas de flujos de datos cada vez más detallados. Repitiéndose esta
secuencia hasta que se obtienen suficientes detalles para que el analista
comprenda la parte del sistema que se encuentra bajo investigación.

V.1.1 Convenciones Usadas en Diagramas de Flujo de Datos

Son cuatro símbolos, que fueron desarrollados y promovidos al mismo tiempo

por dos organizaciones: Yourdon y Gane - Sarson.

• Flujo de datos: son movimientos de datos en una determinada dirección, desde

un origen hasta un destino. Es un paquete de datos.

Yourdon Gane - Sarson

5
 Análisis Orientado a Procesos

• Proceso: son personas, procedimientos o dispositivos que utilizan o producen

datos. No identifica el componente físico.

Yourdon Gane - Sarson

• Fuente o destino de los datos: pueden ser personas, programas,

organizaciones u otras entidades que interactúan con el sistema pero que se
encuentre fuera.

Yourdon Gane - Sarson

• Almacenamiento de datos: es un lugar donde se guardan los datos. El

almacenamiento de datos puede representar dispositivos tanto computarizados
como no computarizados.

Yourdon Gane - Sarson

Cada componente en un diagrama de flujo de datos tiene una etiqueta con un

nombre descriptivo. Los nombres de los procesos reciben un número para poder
identificarlos, este número tiene un valor adicional cuando se estudian los
componentes que integran un proceso específico.

V.1.2 Desarrollo de Diagramas de Flujo de Datos

El diagrama de flujo de datos (DFD) permite al ingeniero del software

desarrollar los modelos del ámbito de información y del ámbito funcional al mismo
tiempo. A medida que se refina el DFD en mayores niveles de detalle, el analista
lleva a cabo implícitamente una descomposición funcional del sistema. Al mismo
tiempo, el refinamiento del DFD produce un refinamiento de los datos a medida
que se mueven a través de los procesos que componen la aplicación.

6
Análisis Orientado a Procesos

Las reglas que deben de tomarse en cuenta durante la descomposición de un

diagrama de flujo de datos son:

1. El diagrama de flujo de datos del nivel cero debe reflejar el software/sistema

como una sola burbuja.
2. Se deben anotar cuidadosamente la entrada y la salida principal.
3. El refinamiento debe comenzar aislando los procesos, los objetos de datos y
los almacenes de datos que sean candidatos a ser representado en el
siguiente nivel.
4. Todas las flechas y las burbujas deben ser rotuladas con nombres
significativos.
5. Entre sucesivos niveles se debe mantener la continuidad del flujo de
información.
6. Se deben refinar las burbujas de una en una.

V.1.2.1 Creación del Diagrama de Contexto

Con un enfoque de arriba hacia abajo para diagramar el movimiento de datos,

los diagramas se mueven de lo general a lo especifico. El diagrama de contexto
inicial debe ser un panorama que incluya entradas básicas, el sistema en general
y las salidas. Este será el diagrama más genérico y la conceptualización más
amplia del sistema.

El diagrama de contexto es el nivel más alto en un diagrama de flujo de datos y

contiene solamente un proceso que representa al sistema completo. Al proceso le
es dado el número cero. Todas las entidades externas son mostradas en el
diagrama de contexto, así como los flujos de datos principales que entran y salen
de él.

Es bastante simple de crear una vez que las entidades externas y el flujo de
datos de y hacia ellas es conocido por los analistas apartir de entrevistas con
usuarios y análisis de documento.

7
 Análisis Orientado a Procesos

Ejemplo del Diagrama de Contexto:

Cliente Cliente
Información del Cliente
Factura

Tarifas Sistema de Control

Empresa de Llamadas
Telefónicas Reportes

Petición de
reportes Empresa

Línea Tonos de llamada Reloj

telefónica

Reloj

V.1.2.2 Expansión del Diagrama de Contexto.

Un mayor detalle que el que permite el diagrama de contexto se logra

“Explotando o fragmentando los diagramas”. Las entradas y salidas especificadas
en el primer diagrama permanecen constantes en todos los diagramas
subsecuentes. Sin embargo, el resto del diagrama original es explotado en
acercamientos que involucran de tres a nueve procesos, y muestra almacenes de
datos y nuevos flujos de datos de nivel más bajo.

Cada proceso es numerado con un entero, comenzando, por lo general, en la

esquina superior izquierda del diagrama y trabajando hacia la esquina superior
derecha.

8
 Análisis Orientado a Procesos

Ejemplo del Nivel 1:

Cliente
Información
del cliente

1.
Procesar
Datos del Información del Cliente
Cliente Procesado

Registro del
cliente

Cliente
Registro del
cliente Factura

Registro de Registro de
5. Tarifas Tarifas 4.
Empresa Generar Calcular
Reportes Reportes Costo de
Registro de Llamada
Tarifas
Solicitud de
Reportes
2.
Información
Procesar
de Llamada Tarifas

Información
de Llamada
Información
de Llamada Tarifas

Empresa
3. Información
Procesar de Llamada
Llamadas

Tonos de
Reloj Llamadas

Sistema Línea
Telefónica
9
Análisis Orientado a Procesos

V.1.2.3 Creación de Diagramas Hijos (Niveles mas detallados)

Cada proceso del nivel 1 puede a su vez ser explotado para crear un diagrama
hijo más detallado. Al diagrama hijo se le da el mismo número que a su proceso
padre en el nivel 1. Por ejemplo, el proceso 1 generará procesos hijos, los cuales
son numerados 1.1, 1.2, 1.3, etc. Esta convención permite al analista trazar una
serie de procesos a través de muchos niveles de explosión.

Los procesos pueden o no ser explotados, dependiendo de su nivel de

complejidad. Cuando un proceso no es explotado se dice que es funcionalmente
primitivo y es llamado un proceso primitivo.

Ejemplo del diagrama hijo (Nivel 2):

Datos del
Cliente
4.3

Datos del
1.1 Cliente Leído 1.2
Cliente Leer Verificar
Datos del Datos del Cliente
Cliente
Cliente

Datos de
Datos del Cliente a
Cliente No Registro modificar
existe del
Cliente

1.4
1.3 Modificar
Añadir Cliente
Nuevo
Cliente

Registro del
Registro del Cliente
Cliente

10
 Diseño Orientado a Procesos

Diseño Orientado a Procesos

VI. Definición

El Diseño Estructurado 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 previamente especificados.

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.

La herramienta fundamental del Diseño Estructurado es el diagrama

estructurado que es de naturaleza gráfica y evitan cualquier referencia relacionada
con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los
programas (que es la tarea de los diagramas de flujo). Los Diagramas Estructurados
describen la interacción entre módulos independientes junto con los datos que un
módulo pasa a otro cuando interacciona con él.

VII. Objetivos

 Obtener una estructura modular y los detalles de proceso del sistema partiendo
solamente de la información obtenida en la fase de Análisis del Sistema.
 Especificar cómo se va a construir el sistema.
 Obtener un diseño que funcione, que sea fácil de mantener, favorezca la
reutilización y se pueda probar y comprender fácilmente.
 Utilizar métodos gráficos (diagramas de estructuras) para representar la
estructura modular del sistema.

VIII. Características

 Una vez conocido ¿Que? (Análisis Estructurado), el Diseño Estructurado se

encarga del ¿Cómo?. Permite implementar mejor el modelo en términos del
costo total de por vida del sistema (Desarrollo y Mantención).
 El diseño estructurado busca establecer la organización interna del software,
produciendo sistemas que sean fáciles de entender (y por ende de construir y
mantener).
 Las salidas del análisis estructurado son entradas (input) para el diseño
estructurado.
 Las salidas (output) del diseño estructurado son:
1. Diagrama Estructurado (estructura de software).
2. Especificación de Módulos.
3. Diccionario de Datos del Sistema.

12
 Diseño Orientado a Procesos

IX. Fases del Diseño Estructurado

Las fases del diseño estructurado son las siguientes:

• Diseño de Datos.
• Diseño Arquitectónico.
• Análisis de Transformaciones.
• Análisis de Transacción.
• Heurísticas de Diseño
• Diseño Procedimental.

IX.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.

Principios para la especificación de datos:

1. Los principios del análisis sistemático aplicado a la función y al
comportamiento deberían aplicarse también a los datos.
2. Todas las estructuras de datos y las operaciones a llevar a cabo en cada una
de ella deberían estar claramente identificadas.
3. Se debería establecer un diccionario de datos y usarlo para definir el diseño de
los datos y del programa.
4. Las decisiones de diseño de datos de bajo nivel debería dejarse para el final
del proceso de diseño.
5. La representación de las estructuras de datos debería conocerla solo aquellos
módulos que deban hacer uso directo de los datos contenidos dentro de la
estructura.
6. Debería desarrollarse una estructura de datos útiles y de las operaciones que
se les pueden aplicar.
7. Un diseño del software y un lenguaje de programación debería soportar la
especificación y realización de los tipos abstractos de datos.

13
Diseño Orientado a Procesos

Ejemplo:

Diagrama Entidad-Relación

1:1 Recibe 0:M Factura

Cliente
1:M
0:M

Genera

Solicita
Servicio

1:M
Tonos
1:1
Empresa 1:M

0:M Determina
Llamada

14
 Diseño Orientado a Procesos

IX.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.

IX.2.1 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.

IX.2.1.1 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.

15
 Diseño Orientado a Procesos

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.

IX.2.1.2 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.

16
Diseño Orientado a Procesos

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.

17
Diseño Orientado a Procesos

Ejemplo: Diagrama de Estructura

SCLLT

Leer Datos Calcular Costo Salida de Datos Mantenimiento

de Llamada de Tablas

Procesar
Llamadas Facturar Generar Procesar Datos Procesar Tarifa
Reportes del Cliente

Calcular Determinar
Tiempo de Zona y Tarifa
Llamada de Llamada

Leer Puerto Leer Puerto

Interpretar Interpretar
Datos Datos Actualización Ordenamiento Respaldos

Determinar Determinar
Progreso Número
Telefónico
Leer Reloj
Determinar
Tarifa de
Zona

18
IX.3 Análisis de las Transformaciones

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.

IX.3.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.

19
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.

20
 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í 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 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.

21
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.

IX.4 Análisis de la Transacción

Cuando en un sistema hay un flujo de transacción, dependiendo del valor de

ese elemento de transacción, se seguirá uno u otro camino de acción de todos los
posibles.

Transacció Caminos de
acción
Centro de
transacción
T 

 


22
IX.4.1 Pasos del Diseño:

1. Revisar el modelo fundamental del sistema: comprende el DFD del nivel 0 y la

información que lo soporta. Evaluación de la especificación del sistema y de la
especificación de requisitos del software.

2. Revisar y refinar los DFD: La información obtenida de los modelos de análisis

contenidos en la especificación de requisitos del software se refina para obtener
mayor detalle.

3. Determinar si el DFD tiene características de flujo 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 controla 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:

23
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.

24
 Ejemplo de Diagramas de Transformación/Transacción

Proceso 1: Procesar Datos del cliente

Datos del Cliente

Datos del Cliente

1.1 4.3
Leer Datos
del Cliente
Datos del Cliente
leído

1.2.1
Comparar
Datos del Datos del Cliente
Cliente existente
1.2.2
Seleccionar
Modificar/
No Modificar
Registro del Cliente
Cliente Datos del Cliente
no existente

Datos del Cliente a

modificar

1.3 1.4
Añadir Modificar
Nuevo Cliente
Cliente

Registro del
Cliente Registro del
Cliente

25
 IX.5 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:

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:

26
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.

7. Empaquetar el software de acuerdo con las restricciones del diseño y los

requisitos de portabilidad.

IX.6 Diseño Procedimental

Se realiza después 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.

27
28
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.

29
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.

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.

Ejemplo de Diseño Procedural

Pseudocódigo

Función Leer Datos del Cliente

Pedir los datos del cliente
“Datos del Cliente” = datos del cliente introducidos
Llamar Verificar Cliente
Fin de Función Leer Datos del Cliente

Función Verificar Cliente

Función Comparar Datos del Cliente
Para todos los registros hacer
Comparar registro con “Datos del Cliente”
Si “Datos del Cliente” es diferente a los registros entonces
Llamar función Añadir Nuevo Cliente
Si no
Selección = función Seleccionar Modificar/ No Modificar Cliente
Si Selección = “Si” entonces
Llamar función Modificar Cliente
Fin si
Fin si
Fin para
Fin de Función Comparar Datos del Cliente

Función Seleccionar Modificar/No Modificar Cliente

Si hay cambios en los “Datos del cliente” entonces
Imprimir “Desea salvar los cambios”
Leer Selección
Retornar Selección
Fin si
Fin de Función Seleccionar Modificar/No Modificar Cliente
Fin de Función Verificar Cliente

30
 Conclusión

Para emprender la realización de un sistema es necesario seleccionar un

método de análisis y diseño que nos ayude a comprender las relaciones entre los
datos y los procesos que deben llevarse a cabo.

Uno de los métodos más utilizado es el análisis y diseño estructurado. Este

proporciona una estructura modular que permite dividir el trabajo entre todos los
participantes del proyecto.

31