analisis y disenyo con sa

8/17/2019 Analisis y Disenyo Con SA

http://slidepdf.com/reader/full/analisis-y-disenyo-con-sa 1/15

Metodología y Tecnología de la Programación. Departamento de Sistemas Informáticos y Computación.EUI - FI. Universidad Politécnica de Valencia.

1

Introducción al Análisis y DiseñoEstructurado usando System Architect (SA)

1 Introducción

Tradicionalmente, el análisis es visto como la definición de los requisitos del sistema.

Por otro lado, el diseño establece una arquitectura para el software tal que satisfaga

dichos requisitos y permita una posterior implementación ajustada a ciertos criterios de

calidad. Dicho de otro modo, el análisis detalla el qué mientras que el diseño desarrolla

el cómo.

El Diseño Estructurado tuvo sus comienzos con la Programación Estructurada (que

incorporaba las tres estructuras de control básicas de un programa: secuencia, selección

e iteración). El aporte del Diseño Estructurado fue considerar el concepto de módulo yla propiedad de modularidad de los sistemas resultantes como atributo que

caracterizaba la calidad de los mismos.

El Análisis Estructurado aparece como complemento al Diseño Estructurado. Así, el

propósito del Análisis Estructurado es proveer una técnica de análisis que permite una

adecuada transición hacia el Diseño Estructurado. El Análisis Estructurado está basado

en el modelado de flujos de información y su transformación mediante procesos, es

decir, el analista se preocupa fundamentalmente de las funciones que debe llevar a cabo

el sistema.

Las propuestas iniciales de Análisis y Diseño Estructurado se centraban en el modeladode procesos dejando en segundo término el modelado de datos. El Enfoque Estructurado

Moderno sugiere realizar paralelamente el modelado de procesos y de datos (este último

mediante Diagramas Entidad-Relación y modelado relacional de datos). En este

documento nos concentraremos en el modelado de procesos en SA.

2 Modelado de Procesos en SA

A continuación se presenta una breve descripción del uso en SA de los Diagramas de

Flujo de Datos y Diagramas de Estructura utilizados en Análisis y Diseño Estructurado,

respectivamente.

2.1 Análisis usando Diagramas de Flujo de Datos (DFDs)

Primero crearemos un nuevo diagrama:

• Opción File, New Diagram indicando el nombre que se le da al diagrama así comosu tipo. La Figura 2.1.1 muestra el diálogo asociado a la creación de un DFD con

notación Yourdon/DeMarco y que se llama Ventas.




2

Figura 2.1.1: Diálogo de creación de diagramas

La paleta de dibujo un DFD es la que se incluye en la Figura 2.1.2.

Figura 2.1.2: Paleta de dibujo

De izquierda a derecha y de arriba a abajo, la funcionalidad asociada a cada elemento dela paleta es la siguiente:

- Selección típica.

- Arco que representa al flujo de datos.

- Proceso del DFD.

- Almacén de datos o Data Store.

- Entidad Externa.

- Conexión AND de dos o más flujos de datos formando uno sólo.

- Conexión XOR de dos o más flujos de datos de manera que la salida es alguno de

los de la entrada.

- Adición de texto al diagrama de hasta 1000 caracteres.

- Adición de un rectágulo para documentación del diagrama.

- Conector entre páginas para la documentación.

- Cuadro de documentación actualizado automáticamente a partir de la información

del diagrama.

Cada elemento que incluimos (borremos) en el diagrama DFD será incluido (borrado)

en la lista de definiciones disponibles1.

Las Figuras 2.1.3 y 2.1.4 nos muestran la información necesaria en la definición de un

proceso dentro del DFD en el que se incluye.

1 Siempre que se tenga habilitada la opción Auto Definition y Auto Delete en Preferences.




3

Figura 2.1.3: Definición del símbolo de proceso

Figura 2.1.4: Definición de un proceso

Existe una tercera ventana que permite aportar más información relativa a la

complejidad del proceso. En la miniespecificación del proceso VENTAS se ha usado un

pseudolenguaje estructurado y para ser distinguidos los datos del resto, se han

referenciado en mayúsculas (tal es el caso de PEDIDO y FACTURA).

Los botones Elem, Struct , Check y Choices permiten la definición y comprobación de

los datos incluidos en la miniespecificación. Posteriormente, detallaremos la

funcionalidad asociada.

Consideraremos como entidades externas a CLIENTES y a PROVEEDORES . Los

clientes realizan PEDIDOS al sistema que tras ser validados implican que se emita una

FACTURA para el cliente. Los proveedores reciben del sistema listados de COMPRAS recibiéndose posteriormente en el sistema las FACTURAS_COMPRAS asociadas. La

Figura 2.1.5 nos muestra el diagrama de contexto con las entidades externas

participantes así como un detalle del contenido del diccionario de datos (véase a laizquierda).




4

Figura 2.1.5: Diagrama de Contexto

La Figura 2.1.6 nos muestra cómo podemos modificar la definición de los datos que

previamente hemos introducido en el DFD2.

Figura 2.1.6: Definición de un dato

El cuadro de la Figura 2.1.6 detalla la composición de un registro de PEDIDO. El

símbolo inicial @ de los dos primeros campos indican que forman la clave primaria del

2 Evidentemente, pudimos definir al tiempo que se incluía el dato en sí.




5

registro. Cuando la clave es compuesta se numeran secuencialmente los campos que

forman la clave. Todos los datos aparecen una vez excepto el último que es

estructurado. Para los simples elegimos la definición correspondiente con ELEM y

STRUCT caso de tener varias ocurrencias. Podemos reusar definiciones existentes desde

CHOICES . La Figura 2.1.7 muestra la definición del campo COD_CLIENTE . Existen 5

pantallas más asociadas a la definición de COD_CLIENTE, cada una dependiendo de la plataforma final escogida3.

Figura 2.1.7: Definición de un dato

La Figura 2.1.8 muestra alguna de las otras pantallas asociadas a COD_CLIENTE en

relación con C++.

Figura 2.1.8: Definición de COD_CLIENTE. Pantalla de C++

3 Esta primera es relativa a SGBR Ingres, escogido al crear la enciclopedia.




6

Para la definición del dato estructurado LINEAS_PEDIDO aparece una ventana similar

a la anterior 4 y que detallamos en la Figura 2.1.9.

Figura 2.1.9: Definición de LÍNEAS_PEDIDO

La inclusión de dominios permite que una definición que es usada por varios datos

pueda ser reusada. Veamos dos formas de definir el campo FECHA de PEDIDOS , (1)

de forma directa a partir del tipo de datos DATE suministrado por la base de datos

escogida5 y (2) a través de la definición de un dominio. La Figura 2.1.10 muestra el

primer caso en el que FECHA se define como tipo elemental.

Figura 2.1.10: Definición del campo FECHA como elemental

4 Recordemos que la definición de un dato estructurado, tal como expone Jackson, se hace a partir de los

tres operadores básicos: secuencia, selección e iteración de elementos, que, de forma recurrente forma eldato compuesto definido a partir de datos simples.5 En nuestro caso Ingres.




7

Para incluir un dominio que se llame, por ejemplo, FECHA_STANDARD, haremos click

en la opción Dictionary, Open, Definition. En el browser entonces seleccionamos

Data Domain. La Figura 2.1.11 nos muestra el diálogo asociado.

Figura 2.1.11: Definición del dominio FECHA_STANDARD

La Figura 2.1.12 nos muestra cómo definir el campo FECHA de PEDIDO usando el

dominio FECHA_STANDARD. Para ello se ha seleccionado el dominio a través de la

opción Choices que aparece en el diálogo.

Figura 2.1.12: Definición usando el dominio FECHA_STANDARD




8

Las Figuras 2.1.13 y 2.1.14 nos muestran el mismo uso del dominio pero esta vez

siendo un dominio estructurado6 en vez de simple. Consideramos en el ejemplo que

FECHA_STANDARD está formada por DÍA, MES y AÑO (a los que les asignamos, por

ejemplo, el tipo NUMERIC de SQL).

Figura 2.1.13: Definición del dominio FECHA_STANDARD como estructurado.

Figura 2.1.14: Definición del campo FECHA a partir del dominio.

6 En la ventana de definición se debe escoger DATA STRUCT DOMAIN en vez de DATA DOMAIN .




9

Explosión de Procesos

A partir de un diagrama, mediante la explosión de procesos podemos ir incrementando

el detalle de la funcionalidad del sistema. Por ejemplo, seleccionado el único proceso

del diagrama de contexto y haciendo click con el botón derecho escogemos la opciónChild Create mostrándose el diálogo de la Figura 2.1.15 en el que se escoge el tipo de

diagrama. Vemos que al proceso seleccionado podemos asociarle distintos diagramas.

En nuestro caso nos interesa asociar a un proceso un nuevo DFD de más detalle.

Figura 2.1.15: Creación de un subproceso.

La Figura 2.1.16 es un diálogo previo a la creación del subproceso en el que se pregunta

qué elementos del padre pasan al hijo. Es importante destacar que no existe más

conexión entre los dos diagramas que el que sencillamente los relaciona. Esto es,

modificaciones en el hijo (por ejemplo, suprimir un flujo de entrada) no conlleva que se

hagan en el padre (ni viceversa), etc. por lo que las operaciones que se realicen

implicará que el sistema esté balanceado o no, propiedad que posteriormente se debe

comprobar.

Figura 2.1.16: Diálogo previo a la creacióndel subproceso.

La Figura 2.1.17 nos muestra una posible descomposición del proceso destacándose la

inclusión del almacén de datos STOCK_ARTÍCULOS que se ve modificado ante la

emisión de pedidos y/o la llegada de facturas del proveedor. Se destaca en la parte




10

izquierda de la ventana la relación existente de diagramas, a saber, dos DFDs de

Yourdon-DeMarco en el que uno de ellos está attached 7 a un proceso del otro.

Figura 2.1.17: Nuevo diagrama como subproceso del proceso inicial.

7 Es decir, enganchado. Utilizamos el término anglosajón por ser el que se utilizó en la herramienta en la

explosión del proceso.




11

Descomposición de Datos

La descomposición por niveles puede realizarse no sólo para los procesos sino también

para los datos ( flujos de datos y almacenes de datos). La estructura de la

descomposición viene dada a través del diccionario de datos. La Figura 2.1.18 muestra

un DFD con un almacén llamado BASEDATOS y un flujo de datos de E/S al único proceso representado.

Figura 2.1.18: DFD ejemplo para descomponer datos

Las Figuras 2.1.19 y 2.1.20 nos muestran la descomposición realizada con respecto del

almacén de datos BASEDATOS y del flujo de datos DATOS_BASEDATOS ,respectivamente.

Figura 2.1.19: Descomposición del almacén de datos




12

Figura 2.1.20: Descomposición del flujo de datos

Evidentemente, en el proceso que explosione al anterior, debe incluir la información delas Figuras 2.1.19 y 2.1.20 si queremos que los diagramas estén balanceados entre sí. A

modo de ejemplo8, se incluye en la Figura 2.1.21 cómo podría ser tal descomposición.

Debe tenerse siempre en cuenta que la descomposición debe estar balanceada.

Figura 2.1.21: Descomposición del procesoque usa la descomposición de datos

8 No se han incluido todos los datos relevantes al ejemplo y se ha destacado en negrita lo que es de

interés.




13

2.2 Diseño usando Diagramas de Estructura

Primero crearemos un nuevo diagrama:

• Opción File, New Diagram indicando el nombre que se le da al diagrama así como

su tipo. La Figura 2.2.1 muestra el diálogo asociado a la creación de un DE que sellama Ventas.

Figura 2.2.1: Diálogo de creación de diagramas

La Figura 2.2.2 muestra la paleta de herramientas disponibles al dibujar un DE.

Figura 2.2.2: Paleta disponible en la creación de un DE

Debemos destacar que se distinguen tres tipos de llamadas a módulos, normal 9,asíncrono10 e iterativo11. Se permiten definir datos globales ( global data) que se

conectan a los módulos que los usan con la conexión Data Access. Los módulos Stub

son aquellos que se consideran en el diseño aunque no se especificará nada de ellos, por

el momento. Podemos detallar en el DE qué módulos van a ser incluidos en la misma

unidad de compilación (por ejemplo, caso de ser el lenguaje C , se referirá a funciones

9

El módulo que llama espera que el módulo invocado finalice su ejecución.10 El módulo que llama no espera a la finalización del llamado.11 Se entenderá entonces que la llamada se realiza dentro de un bucle tipo for , while, o do...while.




14

que estarán dentro del mismo módulo). Para ello utilizamos el Physical Package. La

paleta permite distinguir entre flags descriptivos y flags de control . El resto de

elementos, bien ya son conocidos, bien ya existen en la paleta de los Diagramas de

Flujo de Datos.

La Figura 2.2.3 muestra el DE asociado a VALIDAR_PEDIDO indicando los datos deentrada y salida así como módulos con sombrero12 (VALIDAR_STOCK ) que aunque se

incluye en el DE finalmente no será implementado aparte sino que dentro de quien lo

llama. Para asociar un dato a una llamada concreta (es decir, la herramienta no lo

deduce por cercanía sino que se debe indicar de forma explícita) se debe seleccionar el

dato, pulsar shift y seleccionar la llamada, y por último realizar Connect Flags de la

opción Draw del menú. Por otro lado, si queremos girar la flecha del dato para

acomodarlo a la inclinación de la llamada lo hacemos seleccionando el dato haciendo

click en el botón izquierdo y sucesivamente pulsar el botón derecho.

Figura 2.2.3: DE para el proceso Validar Pedido

En SA la descripción de un módulo puede hacerse mediante pseudo código o asociando

un Diagrama de Flujo. La Figura 2.2.4 muestra la definición del módulo VALIDAR

STOCK y su especificación utilizando pseudolenguaje.

12 Included Module o Hat Module.




15

Figura 2.2.4: Definición del módulo Validar Stock

Organización del DE

De forma similar a como se organizan los DFD, los DEs también pueden ser

particionados en varios diagramas. En el caso de los DEs la idea es continuar una

porción del DE en otro diagrama. Para esto se utiliza el símbolo Page Connector, el

cual se dibuja en ambos diagramas. Este símbolo representa una llamada que debe

leerse entre dos DEs, por lo cual es importante poner en ambos diagramas los

correspondientes flujos. Por ejemplo, en la Figura 2.2.3 el conector llamado “interfaz”

indica que se trata de una porción de DE que está siendo invocada desde otro DE en el

cual aparecerá una llamada hacia dicho símbolo. Además SA permite asociar dichos

diagramas haciendo un child create (o attach) sobre el conector del diagrama superior,

tal como se explicó para la explosión de procesos.

analisis y disenyo con sa

Documents