Archivo Maestro ción Campo inválido
Editar campo
Campo válida Registro maestro válido Validar registro Registro maestro inválido Registro maestro Reunir informe
Campo Línea de Formatear línea de informe registro maestro Efectuar Aparear Registro
cruzada juntado Transac- ción aplicada Nuevo registro maestro maestro Registro maestro sin transacción Inicio de camino aferente Fin de Registro maestro actualizado Fin de camino eferente
Fig. IV-10: Ejemplo de análisis de transformaciones Las líneas punteadas marcan los diferentes caminos de datos a través del DFD. Hay dos Caminos Aferentes que co- mienzan en los flujos Campo y Registro Maestro y dos Caminos Eferentes que finalizan en los flujos Nuevo Registro Maestro y Línea de Informe. Los procesos en el interior de la curva son candidatos a integrar el centro de transforma- ciones, ellos son Aparear Transacción con Registro Maestro y Actualizar Registro Maestro.
76 Capítulo IV. — Derivación de los Diagramas de Estructura tro. Así el proceso Formatear Nuevo Registro Maestro no compone el centro de transformación e incrementa el camino eferente. Como podemos ver, existe subjetividad en la elección de la transformación central, raramente surgen grandes acuerdos relativos a esa elección. El diseñador se podrá preguntar sobre un proceso aquí o allá, sin embargo, eso parece hacer poca diferencia en el diseño final. Por eso, si hubiera du- das sobre un proceso, ése no debe pertenecer al centro de transformación. En sistemas de información el centro de transformación está compuesto por una pequeña por- ción del DFD y no incluye procesos de edición, formateo o verificación y corrección de errores.
IV.4.1.3. Producir un Primer Diagrama de Estructura (First-Cut) Una vez reconocido el centro de transformación y los caminos aferentes y eferentes, una pri- mera versión del DE puede ser desarrollada aplicando los cuatro pasos siguientes: 1. Convertir el DFD en una jerarquía de módulos: Tirar el DFD desde los procesos marcados como participantes del centro de transformaciones y dejar caer los otros procesos, por acción de la gravedad. C
A b c e
B f
a g D
j k
h
F
i m E
n o H p l
G q X F G D A
a b d c f
g h
X q k
m p l n H o E B e
C
i
j 2. Sustituir los depósitos de datos por módulos de lectura o grabación (dependiendo de la orientación del flujo), los agentes externos por módulos de captación o presentación de datos y adicionar módulos debajo de los flujos sin des- tinatario u origen. Se deben asociar nombres adecuados a los módulos adi- cionales, dependiendo de la actividad de lectura (capta- ción) o escritura (presentación) que deben ejecutar. 3. registro. 4. Indicar un único módulo como raíz del DE, sea por selección de uno de los módulos participantes del centro de transformaciones o, por la incorporación de un módulo nuevo.
IV.4.1.4. Mejorar el Diagrama de Estructura Obtenido El diagrama de estructura resultante del paso anterior, con certeza, puede ser mejorado. Eso simplemente es una primera aproximación y se debe beneficiar con la aplicación de los criterios de calidad (presentados mas adelante), especialmente Descomposición, Cohesión y Acoplamiento. d
b ? e
B c A a ? C f
? g h
F i
? o
H
? p D k m ? j
Leer X l E n G
q
Escr X B a H
Or A Ic Ec b Convertir los flujos de datos en invocaciones (apun- tando al módulo invocado) y los datos transportados por los flujos en cuplas. Cada uno de los módulos deberá ser analizado para determinar y adicionar los datos de entrada necesa- rios. Por ejemplo, el módulo Leer X debe recibir como entrada la clave de acceso para la lectura del c d e g
C f Et Er h F i D
k
Em j
Leer X l
m
G q
Escr X E
n o
p
Nuevo Reg Maestro Fmt Actualizado 77 P P
P P P
P P Por lo menos, la siguiente revisión debería ser hecha en el diagrama de estructura: Reorganizar, y descomponer si fuese necesario, los módulos aferentes y eferentes. Descomponer la transformación central, si fuese necesario, usando el DFD como base. Los niveles del DFD son útiles en este caso. Adicionar los módulos de manipulación de errores. Adicionar detalles de inicialización y terminación (si son requeridos). Tener certeza que todos los módulos tengan nombres correspondientes a su representación en la jerarquía. Adicionar todas las cuplas necesarias (de datos y de control). Chequear todos los criterios de calidad y mejorar el diseño de acuerdo con esos criterios. Transacción Válida FTV Reg Maestro Válido # Cuenta Campo Editado FCE RMV TV Transacción sin Reg Maestro Línea de Error FC FCE FT Fin de Campo Fin de Campo Editado Fin de Transacción Fin de Transacción Válida Registro Maestro Válido Transacción Válida FTV RMV TV De esta manera, aplicando los cuatro pasos en el DFD de la Fig. IV-10, el DE resultante es el que muestra la Fig. IV-11.
IV.4.1.5. Garantizar la Funcionalidad del Diseño El paso final es el paso más importante: tener certeza que el DE es funcionalmente equivalen- te al DFD de origen. El propósito del análisis de transformaciones, es obtener rápidamente un DE que implemente correctamente la especificación del problema y cumpla los criterios de calidad.
IV.4.2. Análisis de Transacción
El análisis de transformaciones es la principal estrategia para convertir un DFD (de transfor- mación de datos) en un DE. Sin embargo, una pregunta está sin responder: ¿que criterio puede ser aplicable para particionar un DFD mayor en un conjunto de DFDs de transformación? Una técnica suplementaria, llamada análisis de transacción es extremadamente valiosa para
Actualizar Archivo Maestro Obtener Transacción Válida Obtener Registro Maestro Juntar Registro Maestro Informar Transacción Errónea Transacción FT
Obtener Transacción Campo Editado FCE Reg Maestro # Cuenta Reg Maestro sin Trans Leer Generar Registro Registro Maestro Maestro Nuevo Reg Maestro RMV Reg Maestro TV Actualizar Registro Maestro Transacción Aplicada Transacción Aplicada
Imprimir Transacción Aplicada
Línea Obtener Campo Editado Campo FC Formatear Línea de Informe Imprimir Línea de Informe Obtener Campo Fig. IV-11: Resultado de aplicar análisis de transformaciones en el DFD de la Fig. IV-10
Capítulo IV. — Derivación de los Diagramas de Estructura
78 Capítulo IV. — Derivación de los Diagramas de Estructura Obtener Tipo de Transacción Transacción TipoA Transacción Tipo B dividir un DFD de alto grado de complejidad en DFDs de menor complejidad. Esta técnica divide en distintos DFDs, uno para cada transformación que el sistema procesa. Esos DFDs menores serán suficientemente simples como para permitir su conversión por medio del análisis de transformacio- nes en Diagramas de Estructura (DE). El análisis de transacción también puede ser usado para com- binar los diagramas de estructura individuales (de transacciones separadas) en un diagrama de es- tructura mayor y más flexible. Una transacción, en general, es un estímulo para un sistema que posee un conjunto de activi- dades a ser realizadas internamente. Ejemplos de transacciones son: incluir un nuevo cliente, gene- rar una factura por venta de mercaderías, actualizar el stock de un producto, disminuir la temperatu- ra de un reactor nuclear, actualizar archivo maestro o generar el reporte de movimientos de cuenta corriente. Los DE que resultan del análisis de transacción tienen la forma descripta por la Fig. IV-12. De manera similar al análisis de transformaciones, en el análisis de transacción la actividad principal para derivar un DE a partir del DFD es identificar el centro de transacción. Frecuentemente, es muy fácil reconocer transacciones, centros de transacciones y procesos de transacción a través del forma- to del diagrama. Siempre que un flujo de datos entra en un proceso que determina su tipo y lo envía a un proceso relacionado con el tipo, se puede tener certeza de haber localizado un centro de tran- sacciones. El DFD para un centro de transacción de operaciones en cuenta corriente está representado en la Fig. IV-13. El proceso Iniciar Operación Deseada contiene el centro de transacción el cual activa el
Aplicar Transacción
Tipo de Transacción Transacción Tipo C Fig. IV-12: La estructura típica de los DE generados por análisis de transacción # de cuenta # de cuenta
# de cuenta # de cuenta Saldo Movimiento Movimiento
Saldo Movimiento Movimiento
Valor Iniciar operación deseada Operación deseada Registro del cliente
Generar informe de movimiento Consultar saldo de cuenta Registrar depósito Cuenta Corriente Clientes # de cuenta Registrar extracciones
Fig. IV-13: Ejemplo de DFD de transacciones
79 proceso apropiado dependiendo de la Operación Deseada. Sin embargo, la manifestación del centro de transacción en un DFD es frecuentemente más sutil. En el DFD de la Fig. IV-14, las diferentes transacciones son identificadas claramente pero, ¿dónde está el centro de transacción?. Una posibilidad es adicionar un proceso que recibe todos los flujos de entrada y determine la transacción adecuada pero, esa situación artificial complicaría inne- cesariamente el diseño y tornaría el sistema inflexible (ya que un único proceso debería preocuparse de todos los tipos de transacciones del sistema). La solución más adecuada es incorporar un proceso de control que solamente reciba la infor- mación de control necesaria para determinar la transacción que tiene que ser ejecutada. En la reali- dad, un centro de transacción tiene la mayoría de las veces la funcionalidad de un proceso de con- trol. Así, el DFD de la Fig. IV-14, con el centro de transacción incorporado, es mostrado en la Fig. IV-15. El ejemplo de las transacciones bancarias de la Fig. IV-13 es un poco diferente. El centro de transacción Iniciar Operación Deseada no fue incluido artificialmente. Eso se muestra en el DFD, tal vez, por algún motivo de modelado y puede traer alguna otra funcionalidad diferente a la de con- trol. Ese es un proceso normal que tiene el rol de control y además tiene la función de control; ese hecho, puede ser modelado de la forma mostrada en la Fig. IV-16. Una vez identificado el centro de transacción, el DFD original resulta subdividido en un nú- Direccionar el barco Ajustar curso Localizar objetivo Disparar misil Terminal de control Timón Giróscopo Misil Parámetro de direccionamiento Parámetro de curso Parámetro de seguimiento
Parámetro de disparo Curso corriente Coordenadas del objetivo Detalle del disparo Ángulo de direccionamiento Fig. IV-14: Ejemplo de DFD de transacciones sin mostrar el centro Direccionar el barco Ajustar curso Localizar objetivo Disparar misil Terminal de control Timón Giróscopo Misil Parámetro de direccionamiento Parámetro de curso Parámetro de seguimiento
Parámetro de disparo Curso corriente Coordenadas del objetivo Detalle del disparo Ángulo de direccionamiento Inv. op. adecuada Señal de control Fig. IV-15: Ejemplo de DFD de transacciones incorporando el centro
Capítulo IV. — Derivación de los Diagramas de Estructura
80 # de cuenta # de cuenta
# de cuenta # de cuenta # de cuenta Saldo Movimiento Movimiento
Saldo Movimiento Movimiento
Valor Iniciar operación deseada Operación deseada Registro del cliente
Generar informe de movimiento Consultar saldo de cuenta Registrar depósito Registrar extracciones Cuenta Corriente Clientes Obtener señal de control Ajustar curso Localizar objetivo Fig. IV-16: Ejemplo de DFD de transacciones
mero de DFDs menores, uno por cada transacción, que pueden ser derivados por análisis de trans- formaciones o, nuevamente, por análisis de transacción. La Fig. IV-17 muestra el DE resultante para los ejemplos de la Fig. IV-15 y la Fig. IV-16. El análisis de transacciones genera un esqueleto de diagrama de estructura que deberá ser uni- do (substituyendo las hojas) con los diagramas de estructura de cada una de las transformaciones identificadas.
IV.5. Criterios de Validación de Calidad
Las estrategias de análisis de transformación y análisis de transacción nos permiten derivar
Gobernar barco Señal de control Disparar misil Controlar dirección del barco operación deseada Obtener operación deseada Consultar saldo Registrar depósito Registrar extracción Generar reporte de movims # de cuenta
# de cuenta Transacción bancaria
# de cuenta # de cuenta # de cuenta Fig. IV-17: DE para los ejemplos de la Fig. IV-15 y la Fig. IV-16
Capítulo IV. — Criterios de Validación de Calidad
81 diagramas de estructura a partir de los DFDs del análisis, pero estos diagramas de estructura resul- tantes necesitan mejoras. Ni los diagramas de estructura ni las especificaciones de módulos por si solos nos dicen mucho con respecto a la calidad de un diseño. Los diagramas de estructura son simplemente una herramienta para modelar los módulos de un sistema y sus relaciones y, junto con las especificaciones de funcionalidad de los módulos y las estructuras de datos de las cuplas, componen un diseño inicial que deberá ser analizado y mejorado. Uno de los principios fundamentales del diseño estructurado es que un sistema grande debería particionarse en módulos mas simples. Sin embargo, es vital que esa partición sea hecha de tal ma- nera que los módulos sean tan independientes como sea posible y que cada módulo ejecute una úni- ca función. Para que los diseños tengan esas cualidades, son necesarios algunos criterios de medi- ción que permitan clasificar y mejorar los diagramas de estructura. A continuación se describen los criterios utilizados para mejorar un diseño.
IV.5.1. Acoplamiento
El acoplamiento entre módulos clasifica el grado de independencia entre pares de módulos de un DE. El objetivo es minimizar el acoplamiento, es decir, maximizar la independencia entre módu- los. A pesar que el acoplamiento, es un criterio que clasifica características de una invocación (una relación existente entre dos módulos), será usado para clasificar un DE completo. Un DE se caracte- riza por el peor acoplamiento existente entre pares de sus módulos, ya que ese es el problema que debe ser resuelto para mejorar la calidad del DE completo. Un bajo acoplamiento indica un sistema bien particionado y puede obtenerse de tres maneras: P
P
P Eliminando relaciones innecesarias: Por ejemplo, un módulo puede recibir algunos datos, innecesarios para él, porque debe enviarlos para un módulo subordinado. Reduciendo el número de relaciones necesarias: Cuanto menos conexiones existan entre mó- dulos, menor será la chance del efecto en cadena (un error en un módulo aparece como sínto- ma en otro) Debilitando la dependencia de las relaciones necesarias: Ningún módulo se tiene que pre- 1.- 2.- 3.- 4.- 5.- ocupar por los detalles internos de implementación de cualquier otro. Lo único que tiene que conocer un módulo debe ser su función y las cuplas de entrada y salida (cajas negras). A cada invocación de un DE le será atribuido uno de los cinco tipos posibles de acoplamiento: de datos, estampado, de control, común o por contenido (Fig. IV-18).
IV.5.1.1. Acoplamiento sin Cuplas Hay una categoría de acoplamiento no considerada en la tabla anterior por ser un caso poco frecuente, el Acoplamiento sin Cuplas. Un acoplamiento sin cuplas representa una invocación don- de ningún argumento se comunica y el módulo llamado no retorna ningún valor. El acoplamiento sin cuplas puede ser considerado el punto cero en una tabla de acoplamientos
Mejor Acoplamiento de datos Acoplamiento estampado Acoplamiento de control Acoplamiento común Acoplamiento por contenido Peor Bueno
Medio
Malo Pares de módulos relacionados por invocación normal a procedimientos y funciones
Pares de módulos relacionados por mecanismos oscuros y hasta patológicos (datos globales, transferencia de control, etc.) Fig. IV-18: Tipos de acoplamiento
Capítulo IV. — Criterios de Validación de Calidad
82 siempre que, en la realidad, ningún dato sea comunicado. Si el módulo llamado hace referencia para áreas de memoria globales, podría corresponder a otro tipo de acoplamiento (típicamente acopla- miento común o acoplamiento por contenido).
IV.5.1.2. Acoplamiento de Datos Dos módulos están acoplados por datos si todas las cuplas comunicadas en una invocación son parámetros simples (tipos de datos básicos en un lenguaje de programación: integer, real, string, etc.) o tablas homogéneas. Una tabla homogénea es una tabla en la cual cada entrada contie- ne el mismo tipo de dato y tiene la misma interpretación. La Fig. IV-19 muestra ejemplos de ambos tipos. El acoplamiento de datos es una comunicación de datos necesaria entre módulos. Una vez que los módulos tienen que comunicarse, la vinculación de datos es inevitable e inofensiva (si es míni- ma). A pesar que es el tipo de acoplamiento recomendado, existen dos importantes riesgos: P
P Interfaz Compleja: Cuando un módulo recibe un gran cantidad de cuplas (ej. 10 o 15), a pesar que todas sean simples o tablas homogéneas, la interfaz del módulo queda muy oscura. Así, las grandes ventajas de mantenimiento que el acoplamiento de datos ofrece, son de poca im- portancia para el gran esfuerzo que representa la comprensión. Una gran cantidad de cuplas, en general, es un síntoma de cohesión pobre. La solución es intentar una mejor descomposi- ción de los módulos. Datos Vagabundos (tramp data): Cuando una cupla recorre una cantidad de módulos innece- sariamente, se dice que es una cupla vagabunda. Los riesgos de mantenimiento, en presencia de cuplas vagabundas es casi semejante a los riesgos del acoplamiento común, ya que cual- quiera de los módulos visitados puede producir modificaciones, por error, y los síntomas apuntarán para el módulo que la usa efectivamente. Las cuplas vagabundas son muy comunes, principalmente en DE derivados por análisis de transformaciones. Para corregir el defecto, se recomienda la reorganización del DE. El acoplamiento de datos es el acoplamiento recomendado ya que: la interfaz es la mínima posible, la interfaz es clara y fácil de comprender, los síntomas de los errores aparecen en el mismo módulo donde se produce el error, la modificación de un módulo no produce efecto en cascada en Calcular deuda por servicio Acumular total de notas Calcular la cuenta total del cliente
Valor total del servicio Datos simples Datos simples Cantidad de notas Calcular promedio de notas Suma de las notas a)
Valor normal del servicio Tasa de interés Días después del vencimiento b) Tabla homogénea
Tabla de notas Fig. IV-19: Ejemplos de acoplamiento de datos Calcular la cuenta total del cliente Procesar pedido de cliente del servicio Tasa de interés Fecha vencimiento Calcular deuda por servicio Valor total del servicio
Datos simples Estructura de datos Pedido
Descontar stock de los productos a) Datos compuestos Valor normal b) Fig. IV-20: Ejemplos de acoplamiento estampado
Capítulo IV. — Criterios de Validación de Calidad
Capítulo IV. — Criterios de Validación de Calidad 83 otros módulos, un módulo puede ser cambiado por otro fácilmente siempre que, el nuevo módulo tenga la misma funcionalidad y la misma interfaz (a pesar que sean implementados de manera muy diferente).
IV.5.1.3. Acoplamiento Estampado Dos módulos están vinculados por un acoplamiento estampado si, por lo menos una cupla contiene una estructura de datos (un grupo de ítems de datos simples o compuestos), o un dato sim- ple interpretado como una estructura de datos, como en los ejemplos de la Fig. IV-20. Por ejemplo, si en un programa PASCAL, un argumento es de tipo RECORD, o un argumen- to de tipo INTEGER que representa un dato empaquetado (4 bits para el día: 24 = 16; 5 bits para el mes: 25 = 32; y los 7 bits restantes para el año 27 = 128, del año 1900 al 2028). A pesar que el acoplamiento estampado no es el mejor, es un acoplamiento bueno si es bien usado. Por ejemplo considere la porción de DE de la Fig. IV-21. Un tablero es una estructura de datos natural pa- ra el problema: no sería muy inteligente considerar cada cuadrado del tablero separadamente, porque eso haría que necesitáramos de 64 cuplas para el tablero y una mas para el movimiento. Pero existen dos riesgos importantes en este tipo de acoplamiento: P Información innecesaria: Cuando una estructura P de datos es pasada a un módulo y, frecuentemente, no precisa de todos los ítems de datos de la estructura. Cuando el módulo usa apenas uno o dos ítems de un conjunto mayor, la interfaz queda oscura, compleja y poco flexible. Un ejemplo es el módulo Descontar Stock de los Productos mostrado anteriormente. Recibe la estructura de datos Pedido y solamente precisa de los identificadores de producto y las cantidades para descontar del stock. Empaquetamiento artificial (bundling): Considere el módulo de la Fig. IV-22. Para reducir la Realizar Movimiento Movimiento Tablero anterior Jugar Ajedrez
Tablero nuevo Fig. IV-21 Impuesto de venta Precio por item Tipo de descuento
Calcular costo total cantidad de cuplas de datos que recibe el módulo, se empaquetan en una estructura de datos llamada Información para cálculo de costo. Esta idea de agrupar datos, no relacionados razo- nablemente, en un estructura de datos artificial genera una interfaz oscura innecesariamente. Los módulos acoplados por estructuras de datos tienen un acoplamiento mayor que los módu- los relacionados solamente por datos simples. Si una estructura de datos debe ser modificada, todos los módulos que la reciben deberán ser modificados (o, por lo menos re-compilados). Así mismo, si una estructura de datos no es artificial (se basa en ideas de modelado) y el módulo precisa de todos los componentes, es un buen acoplamiento.
IV.5.1.4. Acoplamiento de Control Dos módulos están acoplados por control si uno pasa para el otro un dato (o grupo de datos) destinado a controlar la lógica interna del otro.
Cantidad Costo total Información para cálculo de costo
Calcular costo total Costo total Fig. IV-22
84 Capítulo IV. — Criterios de Validación de Calidad 1. 2. 3. Leer siguiente registro de cliente. Actualizar registro de ciente. Borrar registro de cliente. Así, el módulo Procesar Registro de Cliente explícitamente decide cual parte de la lógica in- terna del Control de Entrada/Salida se debe ejecutar. Para que el módulo llamador tome tal deci- sión, necesita saber como está organizada e implementada la lógica interna del módulo llamado. En módulos acoplados por control, aquel que recibe la cupla de control no es una caja negra. Peor aún es cuando una cupla de control se dirige hacia arriba, de un módulo subordinado a su jefe (como el acoplamiento entre Generar Informe de Pagos y Buscar Nombre del Cliente, en la Fig. IV-23-b). Esta situación es también síntoma de partición errónea y es llamada Inversión de Autoridad, que significa que un módulo subordinado da órdenes a su jefe. Esa partición errónea podría ser mejorada de dos maneras: P
P El tratamiento de errores debería ser una función del módulo que lo reconoce. Así, el módulo Buscar Nombre del Cliente debería emitir el mensaje de error. El módulo Buscar Nombre del Cliente puede no saber realmente que ocurre el error. El módu- lo jefe debería ser capaz de corregir un error que no puede ser identificado por el módulo subordi- nado. En este caso, el módulo subordinado debe- ría solamente reportar que el nombre no fue en- contrado (Fig. IV-24). En la segunda alternativa, los dos módulos cumplen con las restricciones impuestas como ca- jas negras y, así, el acoplamiento deja de ser de control para convertirse en un acoplamiento de da- tos y, la cupla diseñada como una cupla de control es llamada Cupla Descriptiva.
IV.5.1.5. Acoplamiento Híbrido Una cupla de control frecuentemente contiene valores discretos y fácilmente identificables, pero en algunos casos una cupla de datos cumple el rol de cupla de control. Por ejemplo, un código de cliente que tiene diferentes significados dependiendo del valor (de 1 a 50.000 es un cliente nor- mal, de 50.001 a 60.000 es un cliente con bonificación de 10%, de 60.001 a 90.000 es un proveedor, etc.). El elemento de datos descripto, a pesar de no ser un flag, gobierna la lógica interna del módu- lo que el recibe. Si, en un futuro, tuviéramos más de 50.000 clientes sin bonificación (o mas de 30.000 proveedores), el sistema entraría en colapso. Ese tipo de acoplamiento es llamado Acoplamiento Híbrido porque, la cupla es un híbrido en- tre cupla de datos y cupla de control. Procesar registro de cliente Control de entrada/salida Generar informe de pago Buscar nombre del cliente operación # de cliente Registro de cliente Datos simples Cupla de control Datos simples # de cuenta Cliente inexistente Nombre del cliente Mostrar mensaje de error: a) Cupla de control Realizar b) Fig. IV-23: Ejemplos de acoplamiento de control
En la Fig. IV-23-a, la cupla Realizar Operación, tiene como valor: Datos simples
# de cuenta
Buscar nombre del cliente Generar informe de pago Nombre del cliente Nombre inexistente
Cupla descriptiva Fig. IV-24: Solución del acoplamiento de con- trol de la Fig. IV-23-b
Capítulo IV. — Criterios de Validación de Calidad 85 IV.5.1.6. Acoplamiento Común Dos módulos poseen acoplamiento común si hacen referencia a la misma área de datos global. En este caso, hablamos de una clase de acoplamiento existente entre dos módulos que no precisan estar relacio- nados por una invocación, como se puede ver en la Fig. IV-25. Tanto el acoplamiento común como el acoplamiento por contenido pueden aparecer entre dos módulos no rela- cionados en el DE. Así, son categorías de acoplamiento que no se aconsejan por las dificultades de comprensión y manteni- miento que generan. El acoplamiento co- mún no es aconsejable por: P
P
P
P
P No localización de errores: Un error en cualquier módulo que use un área global de datos puede aparecer en cualquier otro módulo que use aquella área. Baja Reusabilidad: Módulos que referencian datos globales generalmente lo hacen a través de nombres explícitos. Por ejemplo, un módulo que verifica la corrección de un dato almacenado en un área global, hace referencia a una fecha por un nombre explícito y queda sujeto al nom- bre, no puede verificar una fecha si no está almacenado en una área global con ese nombre. Tiene perdido una gran posibilidad de reutilización de ese módulo simplemente por la com- plejidad innecesaria de las convenciones de uso. Conversión Implícita de Tipos: La misma área global puede ser usada por módulos diferentes para almacenar datos de tipos diferentes. Difícil Comprensión: Programas con muchos datos globales son extremadamente difíciles de entender. Poca Flexibilidad: Cuando un módulo tiene que ser modificado es difícil descubrir qué datos precisan ser cambiados y, peor aún, si alguna área de datos global es modificada es muy difí- cil descubrir qué módulos deben ser modificados también.
IV.5.1.7. Acoplamiento por Contenido (o Patológico) Dos módulos presentan acoplamiento por contenido (o patológico) si uno hace referencia al interior del otro: por ejemplo, si un módulo desvía la secuencia de control para adentro de otro o si un módulo altera un comando o un área de datos local del otro. El acoplamiento por contenido torna el concepto de módulo (como una caja negra) sin sentido, ya que obliga a un módulo a conocer el contenido e implementación de otro. El acoplamiento por contenido hace que los módulos sean tan dependientes entre ellos que es no posible modificar uno sin tener que modificar el otro.
IV.5.2. Cohesión
Otro medio para evaluar la partición en módulos (además del acoplamiento) es observar como las actividades de un módulo están relacionadas unas con otras, este es el criterio de cohesión. Ge- neralmente el tipo de cohesión de un módulo determina el nivel de acoplamiento que tendrá con otros módulos del sistema. Cohesión es la medida de intensidad de asociación funcional de los elementos de un módulo. Por elemento debemos entender una instrucción, o un grupo de instrucciones o una llamada a otro módulo o, un conjunto de procedimientos o funciones empaquetados en el mismo módulo. Actualizar tablero
Tablero Tablero de ajedrez Evaluar posición en tablero
Área global Tablero de memoria Fig. IV-25: Ejemplo de acoplamiento común
86 Capítulo IV. — Criterios de Validación de Calidad P P P P P Calcular el Coseno de un ángulo Leer el Registro de Transacción Determinar la Deuda del Cliente Calcular el Punto de Impacto del Misil Calcular el Salario Líquido del empleado Note que cada un de estos módulos tiene un propósito fuerte y único. Cuando el módulo es invocado tiene solamente una tarea para concluir sin quedar involucrado en otra actividad. No im- porta cuan complejo sea el módulo y cuantas sub-funciones deben ser ejecutadas para completar su trabajo, si pueden ser resumidas en una única función, entonces el módulo tiene cohesión funcional. El nombre del módulo con cohesión funcional siempre incluye un verbo. Si el nombre contie- ne dos verbos, entonces seguramente ejecuta dos tareas.
IV.5.2.2. Cohesión Secuencial Un módulo con cohesión secuencial es aquel cuyos elementos están involucrados en activida- des tales que los datos de salida de una actividad sirven como datos de entrada para la próxima. Por ejemplo, considere un módulo que incluye los pasos necesarios para pintar un auto de un color dife- rente al actual: 1. 2. 3. 4. Limpiar el Auto Tapar los Orificios de Chapa Lijar el Auto Aplicar la Primer Capa de Pintura ¿Qué nombre tiene el módulo? Es difícil asociar un nombre que contenga apenas un verbo, un nombre posible es: Limpiar, Tapar Orificios y Lijar la Chapa y Aplicar la Primera Capa de Pintura o se puede imaginar un nombre mas resumido como: Reparar la Chapa y Aplicar la Primer Capa de Pintura, pero no es posible resumirlo un nombre que contenga apenas un verbo. Si adicionamos los pasos siguientes: 1.- 2.- 3.- 4.- 5.- 6.- 7.- Cohesión funcional Cohesión secuencial Cohesión comunicacional Cohesión procedural Cohesión temporal Cohesión lógica Cohesión coincidencial Mejor Peor Bueno
Medio
Malo Caja negra
Caja casi negra
Caja gris
Caja blanca Fig. IV-26: Tipos de cohesión
El objetivo del diseño estructurado es obtener módulos altamente cohesivos, cuyos elementos estén fuerte y genuinamente relacionados unos con otros. Por otro lado, los elementos de un módulo no deberían estar fuertemente relacionados con elementos de otros módulos, porque eso llevaría a un fuerte acoplamiento entre ellos. Clasificamos cada uno de los módulos de un DE con uno de los tipos de cohesión mostrados en la Fig. IV-26.
IV.5.2.1. Cohesión Funcional Un módulo con cohesión funcional contiene elementos que contribuyen con la ejecución de una y solo una función. Ejemplos de nombres de módulos con cohesión funcional son:
Registro original Capítulo IV. — Criterios de Validación de Calidad 87 5. 6. 7. Ahora sí se puede imaginar un nombre con apenas un verbo (que indique una única función): Pintar el Auto. La Fig. IV-27 muestra otro ejemplo, la salida de la primera actividad (formato) es la entrada para la siguiente (validación). Note que el módulo reúne dos funciones bien definidas. Un módulo con cohesión secuencial generalmente tiene buen acoplamiento y es de fácil man- tenimiento. La gran diferencia con los módulos con cohesión funcional es que un módulo con cohe- sión secuencial no es tan reutilizable, por contener actividades que en general no son útiles juntas.
IV.5.2.3. Cohesión Comunicacional Un módulo con cohesión comunicacional es aquel cuyas actividades usan los mismos datos de entrada. Tomemos un módulo que contiene funciones que retornan datos sobre un libro: 1. 2. 3. 4. Buscar el Título del Libro Buscar el Precio del Libro Buscar el Código del Libro Buscar el Autor del Libro Las cuatro actividades anteriores están relacionadas porque todas trabajan sobre los mismos datos de entrada: el libro. Otro ejemplo de un módulo con cohesión comunicacional se muestra en la Fig. IV-28, las dos actividades del módulo usan el mismo dato de entrada # Cuenta. El acoplamiento entre un módulo con cohesión comunicacional y su llamador es usualmente aceptable. Usualmente son de fácil mantenimiento, a pesar que puedan existir problemas; por eje- meplo, es posible que algún otro módulo en el sistema necesite obtener el nombre del cliente pero no estuviese interesado en su saldo. Este módulo debería descartar los datos del saldo o precisaría de otro módulo que implemente apenas la funcionalidad de consultar el nombre (duplicación de código). Los módulos con cohesión comunicacional y secuencial se parecen mucho, pues ambos con- tienen actividades organizadas en torno a los datos. Ellos también tienen acoplamientos bastante claros porque pocos de sus elementos están relacionados con elementos en otros módulos. La prin- cipal diferencia entre ellos es que un módulo con cohesión secuencial trabaja en secuencia sobre los datos, una secuencia de transformación de datos semejante a una línea de producción (hay una or- den escrita entre los componentes). Pero en un módulo con cohesión comunicacional, el orden de Registro válido formateado Formatear y validar registro Módulo Formatear y Validar Registro usa Registro original Formatear Registro original Validación cruzada de campos del registro retorna Registro válido formateado Fin del módulo Fig. IV-27: Ejemplo de módulo con cohesión secuencial Determinar detalles del cliente # Cuenta Módulo usa Determinar detalles del cliente # Cuenta Informar nombre del cliente Informar saldo del cliente retorna Saldo y Nombre Fin del módulo Saldo Nombre Fig. IV-28: Ejemplo de módulo con cohesión comunicacional
Aplicar la Segunda Capa de Pintura Encerar el Auto Pulir el Auto
88 Capítulo IV. — Criterios de Validación de Calidad Los módulos con cohesión procedural tienden a estar com- puestos por algunas funciones poco relacionadas entre sí (excepto por ser ejecutadas en un cierto orden). Sin embargo, esas funciones probablemente tienen mucho que ver con funciones en otros módu- los. En la Fig. IV-30, Grabar, Leer y Editar Registro termina la ejecución de la última transacción (grabar el registro) y comienza la transacción siguiente (leer y editar el registro nuevo). Es típico de un módulo con cohesión procedural que los datos de entrada tengan poca relación con los datos de salida. También es típico que sus salidas sean re- sultados parciales, flags, claves, etc.
IV.5.2.5. Cohesión Temporal Un módulo con cohesión temporal es aquel cuyos elementos están involucrados en activida- des que están relacionadas en el tiempo. Considere el siguiente ejemplo: 1. 2. 3. 4. Inicializar Tabla Leer Configuración del Sistema Inicializar Variables Auxiliares Completar Tabla con Valores Fijos Estas actividades no están relacionadas entre sí, excepto porque son ejecutadas en un momen- to dado: son todas actividades de un módulo de inicialización al comienzo de ejecución de un pro- grama. Los ejemplos típicos de cohesión temporal son módulos de inicialización y finalización. Los módulos con cohesión temporal, como los módulos con cohesión procedural, tienden a estar com- puestos de funciones parciales cuya única relación es que todas suceden en un cierto momento. Las actividades están generalmente mas relacionadas a actividades en otros módulos que entre si, una situación que lleva a un elevado acoplamiento. Los módulos con cohesión temporal, como los de cohesión procedural, no representan cajas negras. Son cajas grises ya que no es muy fácil definir simplemente la función de tal módulo sin mencionar sus detalles internos. También son parecidos, en el sentido que los módulos procedurales y temporales varían de mediocres a pobres. La diferencia entre ellos es igual a la diferencia entre Cohesión secuencial Cohesión comunicacional Registro formateado Formatear registro Validar registro Informar nombre cliente Informar saldo Registro original Registro válido formateado # cuenta Saldo Nombre cliente
Fig. IV-29: Diferencia entre Cohesión Secuencial y Comunicacional
ejecución no es importante. Esta diferencia es ilustrada en la Fig. IV-29, usando una notación com- binada de DE y DFDs.
IV.5.2.4. Cohesión Procedural Un módulo con cohesión procedural es aquel cuyos elementos están involucrados en activida- des diferentes, en las que el control es la principal relación. De manera semejante a los módulos con cohesión secuencial, el orden de los elementos es importante pero, en este caso, la secuencia es guiada por el control y no por la transformación de datos. Registro Registro nuevo editado Grabar, leer y editar registro
Fig. IV-30: Ejemplo de módulo con cohesión procedural
Capítulo IV. — Criterios de Validación de Calidad 89 cohesión secuencial y comunicacional: el orden de ejecución de actividades es importante sólo en módulos con cohesión procedural. Además, los módulos procedurales tienden a compartir ciclos y decisiones entre funciones, mientras que los módulos temporales tienden a contener una codifica- ción mas lineal.
IV.5.2.6. Cohesión Lógica Un módulo con cohesión lógica es aquel cuyos elementos contribuyen en actividades de una misma categoría general, donde la actividad o las actividades a ser ejecutadas son seleccionadas fuera del módulo. 1. Leer Registro de Cliente 2. Leer Registro de Vendedor 3. Leer Registro de Producto 4. Leer Registro de Proveedor La única relación entre las actividades del módulo del ejemplo anterior es que todas son operaciones de lectura. Un punto crucial y que identifica esta categoría de módulos es que en ejecución, se debe escoger una de estas actividades. Los módulos con cohesión lógica representan cajas blancas ya que son totalmente transparentes. Son de difícil comprensión y mantenimiento, no solamente por la mezcla de sus actividades, sino también, por la interfaz. Considere el ejemplo de la Fig. IV-31. Comúnmente, un módulo con cohesión lógica necesita recibir una cupla de control para determinar la operación que tiene que ser ejecutada y, varios argumentos adicionales de los que sólo uno es usado. Esa es una interfaz muy compleja y de difícil manteni- miento.
IV.5.2.7. Cohesión Coincidencial Un módulo con cohesión coincidencial es aquel cuyos elementos contribuyen en actividades sin relación significativa entre ellos. Felizmente es rara. Entre sus causas están las tentativas inútiles para economizar tiempo o memoria, la incrustación de codificación monolítica en módulos arbitra- rios y las alteraciones de mantenimiento intentando mejorar la mala cohesión de algunos otros mó- dulos del sistema (dejando en un mismo módulo las porciones de código descartados de los otros). Los módulos lógicos y coincidenciales son similares en sus problemas. Como ellos no tienen ninguna función bien definida, el módulo jefe necesita enviar un flag completamente artificial para decirle qué hacer. Esto viola el principio de caja negra, ya que el módulo superior necesita conocer los detalles internos de los subordinados. El acoplamiento para ambos tipos de módulos es terrible- mente oscuro. Hay una diferencia en favor de cohesión lógica, por lo menos las componentes de un módulo con cohesión lógica están relacionadas.
IV.5.2.8. Clusters de Información (Cohesión Informacional) Los clusters de información sirven para modelar tipos abstractos de datos en un diagrama de estructura. Muestran una estructura de datos junto con los módulos de acceso y actualización. Una pregunta a veces difícil de responder es: ¿Qué co- hesión tiene un cluster de información? En realidad, cada uno de los módulos incluidos en un cluster de información es un módulo independiente y debe ser estudiado por separado. Así, en la Fig. IV-32, debemos identificar la cohesión y el acopla- tipo de registro RegistroA Registro B Registro C Leer registro AoBoC
Fig. IV-31: Ejemplo de módulo con cohesión lógica Movimiento
Hacer movimiento Validación
Validar posición Tablero de ajedrez
Fig. IV-32: Ejemplo de cluster de información
90 miento del módulo Hacer Movimiento y Evaluar Posición por separado. A pesar que todos los módulos hacen referencia a un área de datos que, para ellos es global, ese área de datos está aislado en el cluster y no hereda los problemas de un acoplamiento común. Cuando todos los módulos de un cluster de información tienen cohesión funcional, el cluster completo podría ser clasificado en otra categoría de cohesión identificada por Glenford Myers [Myers 78] como Cohesión Informacional:
Cuando un conjunto de módulos de cohesión funcional trabajan sobre la misma estructura de datos (en realidad son dependientes de esa estructura de datos), po- drían ser reunidos en un sólo módulo y, el módulo resultante, tendría Cohesión Informacional.
Reunir todos los módulos que trabajan sobre la misma estructura de datos en un módulo sólo con cohesión informacional tiene la ventaja de aislar la estructura de datos del resto de los módulos. De esta manera, si la estructura de datos debe ser modificada, los módulos involucrados son fácil- mente reconocidos. Un cluster de información permite reunir los módulos sin pérdida de identidad.
IV.5.2.9. Determinación de la cohesión de un módulo Es posible determinar el tipo de cohesión que presenta un módulo contestando una sucesión de preguntas acerca de él, como lo muestra la Fig. IV-33.
IV.5.3. Descomposición (Factoring)
La descomposición es la separación de una función contenida en un módulo, para un nuevo módulo. Puede ser hecha por cualquiera de las siguientes razones.
IV.5.3.1. Reducir el Tamaño del Módulo La descomposición es una manera eficiente de trabajar con módulos grandes. Un buen tamaño para un módulo es alrededor de media página (30 líneas). Ciertamente, toda codificación de un mó- dulo debería ser visible en una página (60 líneas) o en dos páginas consecutivas. La cantidad de líneas no es un patrón rígido, otros criterios para determinar cuando es conve- niente terminar de realizar la descomposición, son los siguientes: P
P ¿El módulo ejecuta una única función? ¿Qué relaciona las actividades del módulo? ¿La secuencia es importante?
¿La secuencia es importante?
¿Las actividades están en la misma categoría general? Funcionalidad: Terminar de realizar la descomposición cuando no se pueda encontrar una función bien definida. No empaquetar líneas de código dispersas, de otros módulos, porque probablemente juntas podrán formar módulos con cohesión temporal, coincidencial o proce- dural. Complejidad de Interfaz: Terminar de realizar la descomposición cuando la interfaz de un módulo es tan compleja como el propio módulo. Un módulo de mil líneas es muy confuso, mas mil módulos de una línea son aún más confusos.
1.- Funcional 2.- Secuencial 3.- Comunicacional 4.- Procedural 5.- Temporal 6.- Lógica 7.- Coincidencial Si
No Si No Si No Si No Datos
Control Ninguna Fig. IV-33: Determinación de la cohesión de un módulo
Capítulo IV. — Criterios de Validación de Calidad
IV.5.3.2. Hacer el Sistema más Claro La descomposición no debe- ría ser hecha de una manera arbitra- ria, los módulos resultantes de la descomposición de un módulo de- ben representar sub-funciones del módulo de mas alto nivel en el DE. En una descomposición no se debe preocupar por conceptos de programación. Si una sub-función, presentada como un módulo sepa- rado permite una mejor compren- sión del diseño, puede ser descripta como se presenta en la Fig. IV-34, aún cuando, en una imple- mentación, el código del módulo sea programado dentro del módulo jefe.
IV.5.3.3. Minimizar la Duplicación de Código Cuando se reconoce una función que puede ser reutilizada en otras partes del DE, lo mas con- veniente es convertirla en un módulo separado. Así, se puede localizar mas fácilmente las funciones ya identificadas y evitar la duplicación del mismo código en el interior de otro módulo. De esta ma- nera, los problemas de inconsistencia en el mantenimiento (si esa función debe ser modificada) pueden ser evitados, y se reduce el costo de implementación.
IV.5.3.4. Separar el Trabajo de la ‘Administración’ Un administrador o gerente de una compañía bien organizada debería coordinar el trabajo de los subordinados en lugar de hacer el trabajo. Si un gerente hace el trabajo de los subordinados no tendrá tiempo suficiente para coordinar y organizar el trabajo de los subordinados y, por otro lado, si hace el trabajo los subordinados no serían necesarios. Lo mismo se puede aplicar al diseño del DE, relacionado a los módulos de Trabajo (edición, cálculo, etc.) y a los módulos de Gerencia (de- cisiones y llamadas para otros módulos). El resultado de este tipo de organización es un sistema en cual los módulos en los niveles me- dio y alto de un DE son fáciles de implementar, porque ellos obtienen el trabajo hecho por la mani- pulación de los módulos de los niveles inferiores. La separación del trabajo de la administración mejora la mantenibilidad del diseño. Una alte- ración en un sistema es: un cambio de control o un cambio de trabajo, pero raramente ambos.
IV.5.3.5. Crear Módulos más Generales Otra ventaja de la descomposición es que, frecuentemente, se pueden reconocer módulos más generales y, así, más útiles y reutilizables en el mismo sistema y, además, pueden ser generadas bibliotecas de módulos reutilizables en otros sistemas.
IV.5.4. Fan-Out El fan-out de un módulo es usado como una medida de complejidad. Es el número de subordinados inmediatos de un mó- dulo (cantidad de módulos invocados). Si un módulo tiene un fan-out muy grande, entonces com- pone el trabajo de muchos módulos subordinados y, casi con cer- teza, tiene toda la funcionalidad no trivial representada por ese
Capítulo IV. — Criterios de Validación de Calidad Promedio
Dividir total por la cantidad Calcular promedio de alumno Total Cantidad
Símbolo de absorción Los módulos subordinados serán incluidos en el código del módulo jefe, porque implementan una función muy simple Tabla de conceptos
Acumular total de conceptos Fig. IV-34 A
C B Fan-out de A =3
D
91
92 Capítulo IV. — Criterios de Validación de Calidad subárbol en el DE. Para tener acotada la complejidad de los módulos se debe limitar el fan-out a no más de siete más o menos dos (7 ± 2). Un módulo con muchos subordinados puede fácilmente ser mejorado por descomposición.
IV.5.5. Fan-In El fan-in de un módulo es usado como una medida de reusa- bilidad, es el número de superiores inmediatos de un módulo (la cantidad de módulos que lo invocan). Un alto fan-in es el resultado de una descomposición inteli- gente. Durante la programación, tener una función llamada por muchos superiores evita la necesidad de codificar la misma fun- ción varias veces. Existen dos características fundamentales que deben ser garantizadas en módulos con un alto fan-in: P Buena Cohesión: Los módulos con mucho fan-in deben tener cohesión funcional, secuencial o comunicacional (es muy probable que tenga acoplamiento de datos). P Interfaz Consistente: Cada invocación para el mismo módulo debe tener el mismo número y tipo de parámetros. En el ejem- plo de la derecha, hay un error de este tipo. IV.5.6. Criterios Adicionales de Diseño Existen otros criterios para evaluar un diseño que, usados en combinación con cohesión, aco- plamiento, descomposición, fan-out y fan-in permiten proyectar sistemas más fáciles de mantener. Algunos de estos criterios son presentados a continuación.
IV.5.6.1. Evitar División de Decisiones Una decisión tiene dos partes: el reconocimiento de una condición particular y la ejecución de acciones asociadas. Esas partes son muy diferentes, considere el siguiente ejemplo: Si Entonces el # de cuenta del cliente es desconocido rechazar el registro del cliente Reconocimiento Ejecución Fin
Los datos usados por la parte de reconocimiento (# de cuenta del cliente) y los usados por la parte de ejecución (registro del cliente) no son los mismos, y tal vez no estén disponibles en mismo módulo. Si los datos no están disponibles en el mismo módulo, ocurre una división de decisión, esto es, la separación de las dos partes de una decisión en módulos diferentes. La parte de ejecución de decisión debe ser mantenida tan cerca como sea posible de la parte de reconocimiento (si es posible, en el mismo módulo), con el objetivo que la información recono- cida no tenga que recorrer un largo camino para ser procesada. La división de decisiones es un sín- toma de pobre organización de módulos y, frecuentemente, genera datos vagabundos, como se muestra en la Fig. IV-35.
IV.5.6.2. Forma del Sistema Hasta ahora, todos los criterios descriptos, estudian las características de un módulo o de un par de módulos. Sin embargo, algunas características generales del diagrama de estructura, conside- rado en conjunto, proporcionan también indicios de calidad del sistema. C
A B D
Fan-in de A =3 C D A B X X X Y Y Y Z ??
Capítulo IV. — Criterios de Validación de Calidad 93 P
P
P El acoplamiento es generalmente alto, debido a los problemas de división de decisiones. Note que el módulo Formatear Campo envía una cupla de control para arriba Precisa de Otra Lí- nea (acoplamiento de control con inversión de autoridad). Muchos módulos en la parte superior del DE están relacionados con el formato físico de en- trada. Una gran parte del sistema sería afectado si se produce un cambio de especificación se- cundaria (el formato físico de entrada de las transacciones). Los módulos que producen entradas editadas pueden no ser reutilizables. Actualizar transacciones Obtener maestro Obtener transacción válida Formatear nuevo maestro Grabar nuevo maestro Grabar maestro Preguntar al usuario si continúa Transacción Maestro Maestro Transacción
Actualizar maestro Maestro actualizado Nuevo maestro Respuesta de continuación Nuevo maestro formateado Nuevo maestro Nuevo maestro formateado Ejecución Reconocimiento
Respuesta de continuación Fig. IV-35: DE con división de decisiones Aferente
Eferente Transformación
Coordinación Un módulo envía datos a su jefe
Un módulo envía datos a sus subordinados Un módulo recibe datos de su superior y los retorna transformados
Un módulo coordina la comunicación de sus subordinados Fig. IV-36: Cuatro tipos de módulos
La forma del sistema se relaciona con la combinación de cuatro tipos básicos de módulos, de- terminados por la dirección de sus flujos de datos: módulos aferentes, módulos eferentes, módulos de transformación (o de trabajo), y módulos de coordinación. Esos cuatro tipos de módulos son mostrados en la Fig. IV-36. Tradicionalmente los diferentes tipos de módulos están agrupados en el diagrama de estructu- ra, como indica la Fig. IV-37.
IV.5.6.2.1. Sistemas Dirigidos por Entradas Físicas (Physically Input-Driven) Un sistema dirigido por entradas físicas es aquel que realiza poco procesamiento en su lado aferente, de modo que los módulos superiores tienen que trabajar con datos vírgenes, muy depen- dientes de los dispositivos físicos (no editados y no-refinados). Considere el ejemplo de la Fig. IV-38. Este es un sistema dirigido por la entrada física, porque el módulo superior Actualizar Archivo, debe trabajar con datos físicos y no refinados. Algunos defectos de estos tipos de sistemas son:
Línea de terminal Precisa otra línea bien 94 Capítulo IV. — Criterios de Validación de Calidad C A C C E C T T C A T T E “Coordinación” en los niveles centrales y superior Principal “Transformación” en el medio “Aferente” a la izquierda, preferentemente “Eferente” a la derecha, preferentemente Fig. IV-37: Forma del patrón de agrupamiento de los tipos de módulos
Actualizar Obtener reg maestro Formatear campo Editar campo Actualizar reg maestro Grabar reg maestro Línea de terminal
Obtener línea de terminal Línea de terminal archivo Campo editado Campo bien Precisa Obtener otra línea campo editado Campo editado Campo Campo formateado Campo editado Último campo de la transacción
Aplicar transacción # cuenta Campo Registro editado maestro registro maestro actualizado Nuevo registro maestro Fig. IV-38: Ejemplo de sistema dirigido por la entrada física
Menos comunes son los sistemas dirigidos por la salida física. En este caso, el módulo supe- rior queda sujeto al formato físico exacto de la salida. Esos sistemas tienen casi todos los problemas idénticos a los sistemas dirigidos por la entrada física.
IV.5.6.2.2. Sistemas Balanceados En un sistema balanceado, los detalles dependientes de los dispositivos físicos de entrada y salida quedan aislados en los niveles más bajos del diagrama de estructura. Una mínima cantidad de módulos deben trabajar con dispositivos físicos y, los módulos del nivel medio y superior, trabajar solamente con datos refinados. En otras palabras, la idea es independencia de dispositivos. Un sistema balanceado de esta forma puede ser definido como que no está siendo dirigido por la entrada física, ni por la salida física. Una de las principales ventajas del análisis de transforma- ciones es que el resultado siempre son diagramas de estructura balanceados. La Fig. IV-39 muestra un ejemplo.
IV.5.6.3. Tratamiento de Errores Los errores deben ser informados por el módulo que los detecta y que conoce su naturaleza. Por ejemplo, supóngase que se necesita generar un registro de entrada leyendo campo a campo, y chequear la validez de cada campo. En la Fig. IV-40 se presentan dos ejemplos de tratamiento de error. En el caso a), el error se presenta en el momento en que es reconocido, el módulo Presentar Mensaje de Error puede pre- sentar dos tipos de mensajes:
95 P
P "el nombre de la ciudad es inválido": En este caso, un módulo claramente reutilizable como Validar Campo Alfabético solamente puede ser usado para la validación de nombres de ciu- dades. El módulo pierde su flexibilidad de uso innecesariamente. "el campo alfabético es inválido": este mensaje sólo serviría para confundir al usuario. La mejor solución sería postergar el tratamiento del error para que sea tratado por un módulo que conozca más acerca del campo alfabético que esta siendo leído. Así, el módulo Validar Campo Alfabético simplemente informa que un error fue identificado y, el error será tratado por algún otro módulo. En el caso b), la anomalía anterior es corregida pero, el error está siendo tratado a cierta dis- tancia de donde es detectado. Eso acarrea un acoplamiento extra (la cupla Nombre de Ciudad Invá- Transacción válida Formatear reg maestro Grabar reg maestro Obtener línea de terminal # cuenta Actualizar archivo Registro maestro Obtener transacción válida Transacción Obtener reg maestro Transacción válida Aplicar transacción Registro maestro Grabar nuevo reg maestro Registro maestro formateado Nuevo registro maestro Reg maestro actualizado Transacción válida Reg maestro actualizado Obtener transacción
Campo
Obtener campo Efectuar validación cruzada Campo válido
Validar campo Línea Fig. IV-39: Ejemplo de sistema balanceado Nombre de ciudad validado Nombre de b) Nombre de Nombre de ciudad invalidado Obtener registro Obtener nombre de ciudad Validar campo alfabético Nombre de ciudad válido Obtener nombre de ciudad válido Nombre de ciudad a) Obtener registro ciudad válido Nombre de ciudad invalidado Obtener nombre de ciudad válido Nombre de ciudad ciudad inválido
Presentar mensaje de error Obtener nombre de ciudad Validar campo alfabético Nombre de ciudad inválido Presentar mensaje de error
Fig. IV-40: Dos ejemplos de tratamiento de error
Capítulo IV. — Criterios de Validación de Calidad
96 Capítulo IV. — Criterios de Validación de Calidad P
P
P P Es más fácil conservar consistente el texto y el formato de las mensajes. Los usuarios quedan muy confundidos cuando reciben dos mensajes diferentes o con diferente formato. Es posible almacenar el texto de los mensajes en un archivo y no tener siempre probablemente una gran cantidad de mensajes diferentes, cargados en memoria. Es más fácil evitar mensajes duplicados. Es más fácil actualizar mensajes y hasta traducirlos a otro lenguaje. IV.5.6.4. Relación entre Estructuras de Datos y Estructura de Programa La programación de muchos módulos se facilita si la estructura del sistema sigue la estructura de los datos. Por ejemplo, suponga que es preciso leer una línea de 120 caracteres, sin embargo, la entrada tiene un dispositivo que proporciona caracteres simples. En este caso, en el diagrama de estructura se debería tener una estructura semejante a la estructura de datos. Es decir, un módulo para procesamiento de líneas y un módulo subordinado a él para el procesamiento de cada carácter (que será invocado 120 veces por el módulo jefe).
IV.5.6.5. Memoria Estática Un módulo común muere y retorna a sus superiores una vez cumplida su función. Cuando el mismo módulo es llamado nuevamente, este reacciona como si fuera la primera vez que lo llaman. El módulo no tiene memoria de ninguna cosa que haya ocurrido en las llamadas anteriores, menos aún, no tiene conocimiento de si existió algún llamado previo. Hay una clase de módulos que tiene conocimiento de su pasado a través de la memoria estáti- ca. Es un dato interno que sobrevive a las invocaciones sucesivas. Un módulo con memoria estática generalmente es impredecible, porque aunque lo llamemos con entradas idénticas, el módulo puede actuar diferente o producir diferentes salidas cada vez que se lo invoca. Es más difícil mantener módulos con memoria estática que módulos comunes, ya que los errores asociados a módulos con memoria estática pueden depender del estado actual de la me- moria. Esta es una buena razón para evitar los módulos con memoria estática. Obtener registro Obtener nombre de ciudad Nombre de ciudad válido Obtener nombre de ciudad válido Nombre de ciudad Validar campo alfabético Nombre de ciudad invalidado Nombre de ciudad inválido
Presentar mensaje de error Fig. IV-41: Otro ejemplo de tratamiento de error
lido, a pesar que sea una cupla descriptiva, es un dato vagabundo). La Fig. IV-41 muestra una forma más adecuada donde el error es tratado en un módulo que tiene conocimiento del error. Una cuestión aún no respondida es dónde tratar los mensajes de error. Los mensajes pueden estar esparcidos por todo el sistema, de modo que cada mensaje pertenezca al módulo que detecta el error, o pueden estar todos almacenados en un sólo módulo. La segunda opción (almacenar todas juntas) consiste en incorporar un módulo que probablemente tenga cohesión lógica y que, con cer- teza, tendrá acoplamiento de control. Sin embargo esta solución posee varias ventajas, algunas de las cuales son:
Capítulo IV. — Criterios de Validación de Calidad 97 P P
P La inicialización está muy lejos del uso, es muy probable que la inicialización se olvide. El módulo Computar e Imprimir Salario Promedio no es muy útil, no puede ser reutilizado ya que no inicializa nada. El módulo Inicializar Todo tampoco es muy útil ya que cada vez que se lo llama inicializa todos los datos. Podemos mejorar Inicializar Todo si lo factorizamos en una cierta cantidad de módulos de inicialización, uno por cada función inicializadora. Además cada uno de estos módulos se debería ubicar en el lugar donde se lo usa.
IV.5.6.7. Edición ¿Cómo debería hacerse la edición de una pieza de entrada? Para responder esta pregunta su- ponga que se debe ingresar el nombre de una provincia argentina. Para ello tenga en cuenta lo siguiente: P
P P Siempre se debe chequear el formato y luego el sentido. Por ejemplo, MEN;DOZA es sintác- ticamente incorrecto, mientras que MENDOSA es semánticamente incorrecto. Primero se validan los datos individualmente y luego en conjunto. Antes de procesar la entrada esté seguro que todo está verificado. Por ejemplo, en una opera- ción de extracción de dinero, la suma de 200 dólares es sintácticamente correcta, pero debe rechazarse si se tiene un saldo de 150 dólares. X Imprimir salario promedio Salario total Inicializar todo Leer salario A B Y
Salario total Computar e imprimir salario promedio Fig. IV-42: Ejemplo de módulo de inicialización
IV.5.6.6. Módulos de Inicialización y Terminación Las inicializaciones y terminaciones en algún momento deben hacerse, pero no deberían crear problemas de cohesión temporal. Veamos un ejemplo. La Fig. IV-42 muestra que se inicializaron todos los datos en un módulo Inicializar Todo, incluyendo Salario Total, que es usado por el módulo Computar e Imprimir Salario Promedio. Para eso Salario Total pasa como una cupla vagabunda a otros módulos. Hay otros problemas:
98 Capítulo IV. — Criterios de Validación de Calidad Obtener registro X validado Validar campos de X Obtener registro completo
Obtener campo semánticamente válido Obtener campo sintácticamente válido Verificar semántica del campo Obtener campo Verificar sintaxis del campo Obtener línea de entrada Dividir en campos Fig. IV-43: Fragmento de DE que realiza la edición de una entrada
Un diagrama de estructura general para editores podría ser similar al que aparece en la Fig. IV-43.
Bibliografía [Adler88]
[Batini92]
[Boria87] [Chen76]
[Codd71]
[Codd72]
[Constant74]
[DeMarco79]
[Flavin81] [Gane79]
[Martin81]
[Martin87]
[Martin91] Mike Adler, "An Algebra for Data Flow Diagram Process Decomposition", IEEE Trans on Soft Eng, Vol 14 Nº 2, Feb 1988. Carlo Batini, Stefano Ceri & Shamkant B. Navathe, "Conceptual Database Design an Entity- Relationship Approach", Addison-Wesley, Benjamin/Cummings Pub, Inc., 1992. Jorge Boria, "Ingenieria de Software", (I EBAI), Kapelusz S.A., Bs.As. Arg, 1987. Peter Pin-Shan Chen, "The Entity-Relationship Model – Toward a Unified View of Data", ACM Trans. on Database Systems, Vol 1, Nº 1, Mar 1976. Codd, E.F., "Normalized Database Structures: A brief tutorial", Proc ACM SIGFIDET 1971, Workshop, San Diego, Calif., Nov 1971. Codd, E.F., "Further Normalization of the Data Base Relational Model", Courant Computer Sci- ence Symposia, 6, Data Base Systems, edited by R. Rustin, Prentice-Hall Inc., Englewood Cliffs, N.J., 1972. Wayne Stevens, Glenford j. Myers & Larry L. Constantine, "Structured Design", IBM System Journal, Vol 13, Nº 2, May 1974. Tom DeMarco, "Structured Analysis and Systems Specification", Prentice-Hall, Inc., Englewood Cliffs, N.J., 1979. M. Flavin, "Fundamental Concepts of Information Modeling", Yourdon Press, N.Y., 1981. Chris Gane and Trish Sarson, "Structured Systems Analysis: Tools and Techniques", Prentice-Hall, Inc., Englewood Cliffs, N.J., 1979. James Martin & Clive Finkelstein, "Information Engineering", Savant Research Studies, Vol 1, 2, e 3, 1981. James Martin, "Recommended Diagramming Standards for Analysts and Programmers: A Basis for Automation", Prentice-Hall,Englewood Cliffs,1987. James Martin & Carma McClure, "Técnicas Estruturadas e CASE", McGraw-Hill Ltda., S.P., Brasil, 1991. [McMenam84] Sthephen M. McMenamim and Jhon F. Palmer, "Essential Systems Analysis", Prentice-Hall, Inc., 1984. [McMenam91] Sthephen M. McMenamim and Jhon F. Palmer, "Análise Essencial de Sistemas", Tradução Lars Gustav Erik Unonius, McGraw-Hill, Ltda e Makron Books Editora Ltda, 1991. [Myers78]
[Page88] [Page88b] [Parnas72]
[Parnas79]
[Peters81] [Rochfeld92]
[Ross76]
[Stevens81] [Stevens85] [Ullman82]
Bibliografía Glenford J. Myers, "Composite/Structured Design", Van Nostrand Reinhold, Litton Educational Pub., Inc., 1978. Meilir Page-Jones, "The Practical Guide to Structured System Design", Prentice-Hall, Inc. 1988. Meilir Page-Jones, "Diseño Estructurado de Sistemas", McGraw-Hill, Ltda., S.P. 1988. D.L. Parnas, "On the Criteria to Be Used in Decomposing Systems into Modules", CACM, Dec 1972. D.L. Parnas, "Designing Software for Ease of Extension and Contraction", IEEE Trans. on Soft. Eng., Mar 1979. Lawrence J. Peters, "Software Design: Methods & Techniques", Yourdon Press Inc, N. Y., 1981. Arnold Rochfeld & Pascal Negros, "Relationship of Relationships and other inter-relationship links in E-R model", Data & Knowledge Engineering, Nº 9, 1992. D. T. Ross & J. W. Brackett, "An approach to structured analysis", Comp. Decisions, Vol 8, Nº 9, Sep 1976. Wayne P. Stevens, "Using Structured Design", John Wiley & Sons, Inc., 1981. Wayne P. Stevens, "Projeto Estruturado de Sistemas", Editora Campus Ltda. R.J., 1985. Jeffrey D. Ullman, "Principles of Database Systems", Computer Science Press, Inc. 1982.
99
100 Bibliografía [Ward83]
[Ward85]
[Ward85a]
[Ward85b]
[Ward86]
[Ward86]
[Yourdon78]
[Yourdon89] [Yourdon90] Paul T. Ward, "Systems Development Without Pain: a user's guide to modeling organizational patterns", Yourdon Press. 1983. Paul T. Ward & Stephen J. Mellor, "Structured Development for Real-Time Systems", Vol 1: In- troduction & Tools, Prentice-Hall Inc., Englewood Cliffs, N.J., 1985. Paul T. Ward and Stephen J. Mellor, "Structured Development for Real-Time Systems" Vol 1: In- troduction & Tools, Prentice-Hall, Inc., 1985. Paul T. Ward and Stephen J. Mellor, "Structured Development for Real-Time Systems" Vol 2: Es- sential Modeling Techniques, Prentice-Hall, Inc., 1985. Paul T. Ward and Stephen J. Mellor, "Structured Development for Real-Time Systems" Vol 3: Im- plementation Modeling Techniques, Prentice-Hall, Inc., 1986. Paul T. Ward, "The Transformation Schema: An Extension of the Data Flow Diagram to Represent Control and Timing", IEEE Trans. on Soft. Eng., Vol 12, Nº 2, Feb 1986. Edward Yourdon & Larry L. Constantine, "Structured Design: Fundamentals of la Discipline of Computer Program and Systems Design", Yourdon Press, N.Y., 1978. Edward Yourdon, "Modern Structured Analysis", Prentice-Hall, Inc., 1989. Edward Yourdon, "Análise Estruturada Moderna", Traducción Dalton Conde de Alencar, Editora Campus Ltda., 1990.
| Página siguiente |