Unidad 9: Análisis de Transacción

9.0 Introducción

En el último capítulo exploramos la estrategia del análisis de transformación como la estrategia principal para el diseño de programas y sistemas bien estructurados. En verdad, el análisis de transformación, servirá de guía en el diseño de la mayoría de los sistemas. Sin embargo hay numerosas situaciones en las cuales estrategias adicionales pueden utilizarse para suplementar, y aún reemplazar, el enfoque básico del análisis de transformación.

Una de estas estrategias suplementarias principales se conoce como Análisis de Transacción.

El análisis de transacción es sugerido por un DFD del siguiente tipo:

fig9-1.gif (2971 bytes)

En este DFD existe una transformación que bifurca la corriente de datos de entrada en varias corrientes de salida discretas. En muchos sistemas tal transformación puede ocurrir dentro de la transformación central. En otros, podremos encontrarla tanto en las ramas aferentes como eferentes del diagrama de estructura.

La frase análisis de transacción sugiere que construiremos un sistema alrededor del concepto de "transacción", y para muchos la palabra transacción está asociada con sistemas administrativos. Esto si bien es cierto, es común encontrar centros de transacción en los sistemas administrativos, también pueden encontrarse en otro tipo de sistemas como ser los de tiempo real, aplicaciones de ingeniería, etc.

Un factor importante es como definimos el término transacción. En el sentido más general podemos decir:

Una transacción es cualquier elemento de datos, control, señal, evento, o cambio de estado, que causa, dispara, o inicia alguna acción o secuencia de acciones.

Acorde a esta definición, un gran número de situaciones encontradas en aplicaciones de procesamiento de datos comunes pueden ser consideradas transacciones. Por ejemplo cualquiera de los siguiente casos pueden considerarse transacciones:

El operador presiona el botón de inicio de un dispositivo de entrada.
Algún tipo de datos de entrada que designe un ingreso en el inventario.
Un carácter de escape desde una terminal, indicando la necesidad de un procesamiento especial.
Una interrupción de hardware ante un índice fuera de los rangos definidos dentro de un programa de aplicación.
Un cuelgue o descuelgue de teléfono para un sistema de control de llamadas telefónicas.

9.1 Estrategia del Análisis de Transacción

9.1.1 Centro de Transacción

La estrategia del Análisis de Transacción, simplemente reconoce que los DFD de la forma planteada previamente pueden mapearse en una estructura de programa particular.

Un centro de transacción de un sistema debe ser capaz de:

obtener o responder a transacciones en forma "cruda"
analizar cada transacción para determinar su tipo
despachar acorde al tipo de transacción
completar el procesamiento de cada transacción

En la forma más factorizada, el centro de transacción puede ser modularizado de la siguiente manera:

fig9-2.gif (4229 bytes)

 

La raíz de esta estructura (transacción), puede estar subordinada a cualquier parte de un sistema mayor. Cada un de los módulos "Obtener Trans.", "Analizar Trans.", "Hacer tipo 1", "Hacer tipo n", pueden ser en sí mismas raíces de subsistemas enteros.

En forma ortodoxa, la subestructura debajo del módulo de despacho puede ser modelada en un sistema de cuatro niveles. Estos niveles son los siguientes:

Procesador de transacción (o nivel P)
Nivel de Transacción (o nivel T)
Nivel de Acción (o nivel A)
Nivel de Detalle (o nivel D)

fig9-3.gif (4230 bytes)

 

En la forma ortodoxa, el procesador de transacciones (Despachador) esperará recibir una transacción desde su subordinado cuando sea activado. Un sistema puede incluir cualquier número de centros de transacción. Un centro de transacción puede estar ubicado en una rama aferente, de transformación, o eferente.

Las salidas del centro de transacción pueden consistir de:

Una versión convertida o formateada de la transacción entrante, las cuales pueden ser pasadas hacia arriba para alimentar niveles superiores de procesos aferentes.
Una simple bandera indicando cuando la transacción entrante fue válida. Podemos esperar encontrar este tipo de forma de validación frecuentemente en las ramas aferentes.
Resultados computados basados en el procesamiento de la transacción entrante. Los resultados pueden pasarse hacia arriba al módulo superior para ser utilizados en otras transformaciones centrales , o hacia abajo hacia los niveles inferiores de procesos eferentes.
Una forma actualizada (modificada) de un elemento o elementos de datos base, internos o externos.

 

9.1.2 La Estrategia

Utilizando las figuras previas como modelos, podemos resumir los pasos de la estrategia del análisis de transacción como sigue:

  1. Identificar las fuentes de transacción. En muchos casos, las transacciones serán mencionadas explícitamente en la definición del problema, en cuyo caso será usual asumir que las transacciones provienen de un medio físico de entrada. En otros casos, el diseñador puede tener que reconocer módulos aferentes, eferentes, o de transformación que generen transacciones. Esto puede hacerse más obvio luego de los primeros pasos de factorización de un diseño centrado en la transformación. Más de una corriente de transacción puede alimentar el módulo de nivel P, las cuales pueden mezclarse desde diferentes direcciones (p.e. aferentes y eferentes). Las corrientes de transacción pueden también mezclarse con corrientes de datos no transaccionales.
  2.  

  3. Especificar la organización centrada en la transacción apropiada. La figura planteada puede ser un buen modelo, pero el diseñador deber sentirse libre de alterarla como considere necesario, basándose en la teoría y las heurísticas vistas.
  4.  

  5. Identificar las transacciones y sus acciones definidas. De nuevo, a menudo encontraremos que todos los requisitos de información serán provistos por la definición del problema mismo. Si las transacciones son generadas internamente por el sistema, el diseñador deberá definir cuidadosamente el proceso a realizar para cada transacción.
  6.  

  7. Identificar situaciones potenciales en que puedan combinarse módulos. Como en el caso del análisis de transformación, podemos encontrar situaciones en las que un módulo de nivel intermedio pueda ser creado desde un grupo funcionalmente cohesivo de módulos de bajo nivel. Esta combinación puede ser apropiada en situaciones en las que la sintaxis o semántica de varias transacciones es similar.
  8.  

  9. Para cada transacción, o colección cohesiva de transacciones, especificar un módulo de transacción para procesarlo completamente. Debido a que las transacciones en un sistema son a menudo similares, existe una tentación a agrupar el procesamiento de varias transacciones en un módulo. Esto deberá evitarse si el módulo resultante tiene baja cohesión. Trataremos evitar módulos con solo cohesión de comunicación, o lógica.
  10.  

  11. Para cada acción en una transacción, especificar un módulo de acción subordinado al módulo de transacción correspondiente. En esencia esto es un paso de factorización tal como se vio anteriormente. Debe notarse que pueden existir muchas oportunidades para que módulos de transacción compartan módulos de acción comunes.
  12.  

  13. Para cada paso detallado en un módulo de acción, especificar un módulo de detalle subordinado a algún módulo de acción que lo necesite. Claramente esto es una continuación del proceso de factorización. Para un sistema grande con transacciones complejas, podremos tener varios niveles de módulos de detalle. En adición, debe tenerse en mente que módulos de acción similares pueden compartir módulos de detalle siempre que sea posible.

A través de este proceso, el diseñador será guiado por los principios de cohesión, acoplamiento, y las heurísticas de diseño. Además el diseñador deberá recordar el principio fundamental mencionado repetidamente: La estructura del sistema deberá reflejar lo más cercanamente posible la estructura del problema.

 

9.2 Ejemplo de Análisis de Transacción

Ejemplo: Liquidación de sueldos.

Se debe realizar liquidación de haberes de sueldo del personal. Para ello se dispone de tres archivos que contienen los datos necesarios, Empleados, Escalafones, y DatosBases. La estructura de estos almacenes es la siguiente:

 

EMPLEADOS = {Empleado}

Empleado = n_legajo + cod_escalafon + datos_personales

 

ESCALAFONES = {Escalafón}

Escalafón = @cod_escalafon + descripción + {cod_cpto}

 

DATOSBASES = {DatoBase}

DatoBase = @cod_cpto + datos_básicos

 

El proceso debe generar la liquidación en dos archivos: Liq_Cabeceras y Liq_Detalles, cuyas estructuras son las siguientes:

 

LIQ_CABECERAS = {Liq_Cabecera}

Liq_Cabecera = n_legajo + tot_cptos

 

LIQ_DETALLES = {Liq_Detalle}

Liq_Detalle = n_legajo + cod_cpto + imp_cpto

 

Diagrama de Flujo de Datos

fig9-4.gif (5944 bytes)

Primer nivel de Factorización

fig9-5.gif (4464 bytes)

Final

fig9-6.gif (3787 bytes)

 

9.3 Consideraciones especiales en el Procesamiento de Transacciones

Las ideas de la estrategia del análisis de transacción son muy familiares a la mayoría de profesionales de EDP. Muchos han intentado utilizar estos principios para organizar sistemas enteros. La experiencia ha establecido que dichos sistemas son más sencillos de organizar en principio, pero son más difíciles de modificar y mantener posteriormente.

En el caso límite, el módulo ejecutivo de mayor nivel puede ser el centro de transacción. Por lo tanto, todas las transacciones serán consolidadas en el módulo ejecutivo en una organización input-driven. Esto puede mezclar también transacciones de diferentes tipos y niveles de importancia, para el sistema. Esto llevará a que el módulo ejecutivo sea poco cohesivo.

Un ejecutivo, el cual es el centro de transacción, no controla el flujo general del proceso, sino que está involucrado en detalles procedurales para realizar alguna parte de la tarea general.

 

9.3.1 Estado de dependencia en Procesadores de Transacción

Un caso especial se tiene cuando el procesamiento de transacción incorpora un proceso de decisión estado-dependiente, esto ocurre cuando la salida de una determinada decisión depende no solo de los datos de entrada, si no además de los valores ingresados anteriormente. Por ejemplo una transacción tipo X podrá ser procesada como tipo X o tipo Y, dependiendo de que una transacción del tipo A haya sido procesada correctamente antes.

 

9.3.2 Procesamiento de Transacciones Sintáctico y Semántico

Entenderemos por elementos sintácticos, aquellos aspectos de procesamiento relacionados a la forma que toma la transacción. Entenderemos por semántico, las acciones resultantes: el "que" y el "como".

fig9-7.gif (4188 bytes)

 

Validando el formato de la transacción proveniente de la rama aferente (Obtener y Analizar), y convirtiéndola a un código interno, el resto del sistema Transacción, Despachar, y los superiores a Transacción, pueden ser escritos para que operen independientemente de la forma que la transacción tome. De esta manera es sencillo cambiar la apariencia y el procesamiento de la transacción de modo independiente uno de otro. En adición, los módulos de procesamiento de transacción, pueden ser usados correctamente con transacciones obtenidas en otros formatos desde fuentes completamente diferentes.

 

9.3.3 Efecto de colocar centros de transacción a diferentes niveles en la jerarquía

En algunos casos, el diseñador se encuentra diseñando un sistema con solo un centro de transacción, pero con varias opciones concernientes a la ubicación del centro de transacción dentro de la jerarquía. Es posible, y a veces tentador, ubicar el centro de transacción en el módulo ejecutivo de máximo nivel. Esto es generalmente una idea pobre, por razones de acoplamiento y cohesión. Entonces, dónde debe ubicarse el centro de transacción? Finalmente, acoplamiento y cohesión son los mejores criterios para decidir donde ubicarlo.

De cualquier modo, existe un aspecto filosófico de esta decisión que el diseñador debe tener en mente: ubicar el centro de transacción alto en la jerarquía, refleja la decisión del diseñador de permitir que el entorno (aquello que existe fuera del sistema de computadora) controle al sistema. Contrariamente, ubicar el centro de transacción en los niveles bajos de la jerarquía, refleja el deseo del diseñador de que el sistema control el entorno.

Por qué esto es así? Debe recordarse que el centro de transacción es un punto a partir del cual distintos tipos de procesamientos tendrán lugar, dependiendo de la naturaleza precisa de un elemento de datos. Por lo tanto, es el centro de transacción (el módulo de nivel P) está en el tope de la jerarquía, es análogo a que el presidente de una compañía diga: "No conozco a qué tipo de situaciones se enfrentará la corporación en los próximos milisegundos, pero yo quiero responder apropiadamente".

Si el centro de transacción se ubica cerca del nivel inferior de la jerarquía, entonces el tope de la jerarquía se organizará de modo acorde a las recomendaciones del método de Análisis de Transformación. En este caso, el módulo ejecutivo es análogo a un administrador que conoce precisamente que datos espera de sus subordinados, y exactamente qué hacer con dichos datos. Esto es más aproximado al caso en que el administrador controla el entorno, más que el caso en que el entorno lo controle a él.

Algunos diseñadores piensan que la cuestión del control sobre el entorno es meramente un reflejo de opción entre un sistema batch o un sistema en-línea o en tiempo real. Esto NO es así. Un sistema en línea puede tener sus centros de transacción cerca del tope y en el nivel inferior de la jerarquía. Si es ubicado cerca del tope de la jerarquía, refleja el deseo del diseñador de hacerlo tan interactivo como sea posible. Esto es como decir en un sistema en línea: "no tengo idea de qué es lo que el usuario va a tipear en la terminal, pero voy a realizar sus comandos". Un sistema en línea que tenga su centro de transacción cerca del nivel bajo de la jerarquía, refleja el deseo del diseñador de guiar al usuario de terminal a través de un dialogo ordenado para que realice lo que el sistema quiere que realice. Los módulos de nivel superior de este tipo de sistema forzarán al usuario a que suministre las entradas que el sistema desea.

De modo similar los sistemas batch (en lote) pueden tener el centro de transacción alto o bajo en la jerarquía según la filosofía del diseñador.

Sin emanar juicios de valoración sobre que filosofía utilice el diseñador, diremos que finalmente los principios de acoplamiento y cohesión serán los árbitros finales de lo bueno o malo que sea el sistema.

Un buen ejemplo de un sistema en línea en el cual el entorno controla al sistema son los monitores de teleproceso en los sistemas mainframe, o los shell de comandos en Unix.

 

WB01343_.gif (599 bytes) WB01344_.gif (1348 bytes) WB01345_.gif (616 bytes)