Transcript

““AAnnáálliissiiss yy DDiisseeññoo OOrriieennttaaddoo aa PPrroocceessooss””

SSeecccciióónn:: �� 55TT22__CCoo..

GGrruuppoo:: �� NN°° 22

DDoocceennttee:: �� IInngg.. MMaaggddaa LLuunnaa..

AAssiiggnnaattuurraa:: �� IInnggeenniieerrííaa DDee SSooffttwwaarree IIII

IInntteeggrraanntteess::

�� YYeesssseenniiaa DDeell CCaarrmmeenn MMeelléénnddeezz MMoorraalleess 22000011--1100000077.. �� TTaanniiaa MMaarrggaarriittaa MMoorreennoo SSaarrrriiaa 22000011--1100991100.. �� RRuutthh AAmmaannddaa PPéérreezz BBeerrmmúúddeezz 22000011--1100000088..

VViieerrnneess 66 ddee MMaayyoo ddeell 22000055

Í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

1

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.

Análisis Orientado a Procesos

3

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.

Análisis Orientado a Procesos

4

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

Análisis Orientado a Procesos

5

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

Análisis Orientado a Procesos

6

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

Análisis Orientado a Procesos

7

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.

Análisis Orientado a Procesos

8

Información del Cliente Factura

Tarifas

Petición de reportes

Tonos de llamada Reloj

Reportes

Ejemplo del Diagrama de Contexto:

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.

Sistema de Control

de Llamadas Telefónicas

Cliente

Empresa

Línea telefónica

Cliente

Empresa

Reloj

Análisis Orientado a Procesos

9

Ejemplo del Nivel 1:

Empresa

Sistema Línea Telefónica

Información del cliente

Registro del cliente

Reportes

Solicitud de Reportes

Información de Llamada

Información de Llamada

Reloj Tonos de Llamadas

Registro de Tarifas

Registro de Tarifas

Registro de Tarifas

Factura

Información de Llamada

Información del Cliente Procesado

Cliente

1. Procesar Datos del Cliente

5. Generar Reportes

4. Calcular Costo de Llamada

3. Procesar Llamadas

2. Procesar Tarifas

Cliente

Empresa

Registro del cliente

Tarifas

Información de Llamada

Análisis Orientado a Procesos

10

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):

1.1 Leer

Datos del Cliente

1.2 Verificar Cliente

1.3 Añadir Nuevo Cliente

1.4 Modificar Cliente

Cliente Datos del Cliente

Datos del Cliente Leído

Datos del Cliente No existe

Datos de Cliente a modificar

Registro del Cliente

Datos del Cliente

Registro del Cliente

Registro del Cliente

4.3

Diseño Orientado a Procesos

12

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.

Diseño Orientado a Procesos

13

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.

Diseño Orientado a Procesos

14

Ejemplo: Diagrama Entidad-Relación

Cliente

Empresa

Factura

Tonos

Llamada

Solicita Servicio

Recibe

Genera

Determina

0 : M

1 : 1

1 : 1 0 : M

1 : M

1 : M

1 : M

0 : M

Diseño Orientado a Procesos

15

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.

Diseño Orientado a Procesos

16

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.

Diseño Orientado a Procesos

17

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.

Diseño Orientado a Procesos

18

Ejemplo: Diagrama de Estructura

SCLLT

Leer Datos Calcular Costo de Llamada

Salida de Datos Mantenimiento de Tablas

Procesar Llamadas Facturar Generar

Reportes

Calcular Tiempo de Llamada

Determinar Zona y Tarifa de Llamada

Leer Puerto

Interpretar Datos

Determinar Progreso

Leer Reloj

Leer Puerto

Interpretar Datos

Determinar Número Telefónico

Determinar Tarifa de Zona

Procesar Datos del Cliente

Procesar Tarifa

Actualización Ordenamiento Respaldos

19

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.

20

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.

21

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.

22

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ó

Centro de transacción

T

Caminos de acción

23

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:

24

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.

25

Datos del Cliente

Datos del Cliente leído

Datos del Cliente

Datos del Cliente existente

Datos del Cliente a modificar

Datos del Cliente no existente

Registro del Cliente Registro del

Cliente

Registro del Cliente

Ejemplo de Diagramas de Transformación/Transacción Proceso 1: Procesar Datos del cliente

1.1 Leer Datos del Cliente

1.2.1 Comparar Datos del Cliente

1.2.2 Seleccionar Modificar/

No Modificar Cliente

4.3

1.3 Añadir Nuevo Cliente

1.4 Modificar Cliente

26

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:

27

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.

28

29

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.

30

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

31

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.


Recommended