Herramientas y metodologías de análisis y diseño estructurado (página 4)

pedido

item_pedido código_artículo := {carácter_valido} := {dígito} := [ Tandil | Villa Cacique | Barker | Juárez | Lobería | Posadas ] * localidades en las que se entregan pedidos * := nro_cliente + nombre_cliente + dirección_para_remito + 1 {item_pedido} 10 * un pedido puede contener hasta 10 items * := código_artículo + nombre_artículo + cantidad := 1 {dígito} 3 * identificador interno de un artículo, un número de hasta tres dígitos *

III.3. Modelo Entidad Relación (ERD)

La construcción del modelo entidad relación (ERD) es el paso previo a la creación y uso de bases de datos en un desarrollo. El proceso de generación de la base de datos comienza desde la etapa de análisis y se va completando hasta llegar a la etapa de implementación. El modelo entidad relación es una herramienta que permite especificar la estructura estática de la aplicación, modela dónde se encontrarán y cuál será la estructura de los datos. Los datos deben estar bien organizados ya que si datos que se refieren a algún objeto específico son almacenados en diferentes lugares la búsqueda de estos datos resulta muy difícil. Este modelo tiene los siguientes requisitos: P P

P

P Accesibilidad: Si los datos no son fáciles de acceder es muy difícil que sean utilizados. Oportunidad: Los datos deben reflejar un pasado relativamente inmediato. Los datos que no reflejan la situación presente con suficiente validez no tienen valor para tomar decisiones. Precisión: Cada valor almacenado debe estar dentro de un rango ‘aceptable’ de precisión al- rededor del valor ‘real’. Consistencia: Los datos deben representar fielmente la realidad.

46 Capítulo III. — Modelo Entidad Relación (ERD) P la organización. El modelo entidad relación permite describir la información involucrada en un sistema como un conjunto de entidades y las relaciones existentes entre ellas. La Fig. III-10 presenta un ejemplo de diagrama entidad relación. En esta figura se pueden dis- tinguir tres tipos de componentes diferentes: P

P

P Entidades: También llamado Tipo de Objetos o Clase de Objetos. Es diseñada como una caja y representa un conjunto de objetos, llamados instancias, que tienen características comunes. Por ejemplo, en la figura 9 la entidad Empleado representa el conjunto de todos los empleados que trabajan en una organización. Atributos: Los óvalos vinculados a una entidad son llamados atributos. Representan caracte- rísticas comunes a todas las instancias de una entidad. Relaciones: Son diseñadas como un rombo y representan la relación entre algunas instancias de una entidad con instancias de otra. Por ejemplo, en la figura 9 la relación Trabaja en indica que un empleado (instancia de una entidad Empleado) trabaja en un Departamento. La nota- ción 1 del lado del Departamento y N del lado del Empleado indica que la relación es uno a muchos, 1:N, y es interpretado como: varios empleados trabajan en un departamento, o en un departamento trabajan varios empleados.

III.3.1. Entidades y Atributos

Una entidad representa la información que es necesario almacenar, pudiendo esa necesidad de información abarcar personas o cosas tangibles como un empleado, un cliente o materiales. Puede ser intangible como el título de una función, una asociación, un préstamo, una compra o un pedido de seguro. Una entidad tiene varios atributos que describen la información que se desea mantener: tama- ño, valor, código, fecha de nacimiento, dirección. Generalmente, en el procesamiento de datos se almacena una colección de objetos semejantes tales como los empleados y se registra la misma in- formación para cada uno de ellos. Comúnmente, el programador mantiene un registro sobre cada instancia de una entidad, y un ítem de dato relacionado a cada atributo en cada uno de los registros. Los registros similares son agrupados en archivos y pueden presentarse como una tabla de dos dimensiones como la que apare- ce en la Fig. III-11. En el cuadro hay un conjunto de ítems de datos y es mostrado el valor de cada uno. Cada línea contiene los valores de los atributos de una instancia en particular de la entidad. Cada columna con- Empleado

Trabaja en Nombre

Sexo

Fecha de Nacimiento Salario

Título

Código de Función Empleado

Fig. III-10: Ejemplo simple de diagrama de Entidad/Relación

Disponibilidad: Un dato que se necesita pero que no puede ser accedido es un síntoma de ma-

Freda 3 Capítulo III. — Modelo Entidad Relación (ERD) 47 Número de Empleado Nombre Sexo Fecha de Nacimiento Depto Título Salario la Código de Función 5 r José María 2 Fred 53730 28719 53550 79632 15971 … Perez José Balanagan Lawrence Rockefeller Horseradish … M M F M F … 10/03/3 10/10/1 09/09/3 01/11/3 25/02/6 … 044 172 044 090 172 … Contado Abogado Escribano Consulto Ingeniero … 2.000 1.800 1.100 5.000 2.500 … 73 43 02 11 07 … Valores atributo s Conjunto de valores de un atributo o tipo de item de datos Estructura del Registro(Atributos de la Entidad) Ocurrencia de un registro (Instancia de una entidad) Archivo lógico o relación (Entidad) del Identificador registro (entidad) si Algunos atributos son por identificadores de otro registro (entidad) Fig. III-11

tiene un tipo específico de ítem de datos, relativo a un tipo de atributo dado. La columna de la iz- quierda contiene los ítems de datos que identifican a la entidad. En este ejemplo, la entidad es un empleado y el atributo designado como identificador de las instancias es el número de empleado. En un modelo de entidad relación bien definido, las entidades y las relaciones deben estar en tercera formal normal [Chen 76], sin embargo, frecuentemente las entidades no están bien definidas e incluyen características de otras entidades.

III.3.2. Relaciones

Una relación representa un conjunto de vínculos lógicos entre instancias de dos o más entida- des. Cada una de las relaciones en un diagrama entidad relación tiene una semántica propia que es definida por el tipo de vínculo existente en el dominio del problema modelado. Desde un punto de vista matemático puede ser definido como:

Una relación entre entidades simples es una lista ordenada de entidades y una en- tidad dada puede aparecer una o más veces en la lista [Ullman 82].

Si en un diagrama entidad relación hay una relación R entre las entidades E1, E2, …, En, repre- senta un conjunto compuesto por las listas (e1, e2, …, en), (e1',e2', …, en') …; donde las componentes ei, ei', … son instancias diferentes de la entidad Ei. La cantidad de entidades que participan en una relación es arbitraria, sin embargo, se recomienda la utilización de relaciones entre dos entidades, es decir, relaciones binarias. Una entidad dada puede participar en más de una relación. Se pueden clasificar las relaciones binarias en diferentes tipos como base en la cantidad de participantes de cada una de las entidades. En las siguientes secciones se definen los diferentes tipos de relaciones. Existen diferentes convenciones para la notación gráfica de las relaciones. En las secciones siguientes se utilizan las más usadas: la notación original de Chen [Chen 76] y la notación utilizada por James Martin [Mar- tin 81], denominada también diagrama de Bachmann.

48 Capítulo III. — Modelo Entidad Relación (ERD) III.3.2.1. Relación Uno-a-Uno Una línea uniendo las entidades A y B representa una relación uno-a-uno. La barra corta, más interna, cruzando la línea de la relación (notación de Martin) indica la obligatoriedad de la relación, es decir, una ocurrencia de la entidad tiene que existir para que la relación tenga sentido. A B R Notación de Martin A B R 1 Notación de Chen 1 P P Obligatoriedad Sólo una instancia es permitida

La figura representa gráficamente la siguiente regla: Cada ocurrencia de la entidad A esta relacionada a una y solo una ocurrencia de la entidad B. Cada ocurrencia de la entidad B esta relacionada a una y solo una ocurrencia de la entidad A. Por lo tanto, una ocurrencia, ni más ni menos, de la entidad A puede existir con una, ni más ni menos, ocurrencia de la entidad B. Esta relación es denominada relación uno-a-uno obligatoria. Las ocurrencias de las entidades A o B no pueden existir independientemente, una depende de la otra para existir. Chen no considera la interpretación de la obligatoriedad en las relaciones. La notación en la parte superior de la relación es interpretada como la cantidad permitida de participantes. Sin embar- go, considera una notación diferente para la dependencia de existencia por medio del uso de una flecha apuntando a la entidad dependiente. Por ejemplo, si la existencia de la entidad B depende de la existencia de la entidad A, se diseña una flecha apuntando a la entidad B. A B R III.3.2.1.1. Opcionalidad Un círculo sobre la línea de la relación de lado de la entidad B indica una relación de opciona- lidad. Mientras que la relación de B a A es obligatoria, la relación de A para B es opcional. A B R Notación de Martin A B R 1 Notación de Chen 0,1 P P Opcionalidad

Esto es interpretado de la siguiente manera: Cada ocurrencia de la entidad A esta relacionada con cero o una ocurrencia de la entidad B. Cada ocurrencia de la entidad B (si existe) esta relacionada a una y solamente una ocurrencia de la entidad A. Una entidad A puede existir sin la presencia de una entidad B. Mientras que si la entidad B existe, no puede haber mas que una ocurrencia de la entidad A relacionada. La entidad B no puede existir sin la presencia de la entidad A. La figura siguiente presenta una relación uno-a-uno opcional en los dos sentidos: A B R Notación de Martin A B R 0,1 Notación de Chen 0,1

Capítulo III. — Modelo Entidad Relación (ERD) 49 P P Cada ocurrencia de la entidad A esta relacionada con cero o una ocurrencia de la entidad B. Cada ocurrencia de la entidad B esta relacionada con cero o una ocurrencia de la entidad A. Tanto la ocurrencia de la entidad A como de la entidad B puede existir sin la presencia de la otra. Si la relación existe, cada ocurrencia de A puede estar relacionada solamente a una ocurrencia de la entidad B y viceversa.

III.3.2.2. Relación Uno-a-Muchos Las relaciones con varias instancias de una entidad se representa por medio del signo menor. Los siguientes ejemplos utilizan este tipo de relación: A B R Notación de Martin A B R 1 Notación de Chen 1,n Este ejemplo representa una relación uno-a-muchos obligatoria, debido a que las barras cortas cruzan a la línea de la relación. Este diagrama es interpretado de la siguiente manera: P P Cada ocurrencia de la entidad A esta relacionada a una o varias ocurrencias de la entidad B. Cada ocurrencia de la entidad B esta relacionada a uno y solamente una ocurrencia de la enti- dad A. Ninguna de las entidades A o B pueden existir sin la presencia de la otra. La relación debe existir entre ocurrencias específicas de las entidades A y B. Una ocurrencia de la entidad A en parti- cular puede estar relacionada a varias ocurrencias de la entidad B, debe haber por lo menos una ocu- rrencia de la entidad B. Por otro lado, una ocurrencia de la entidad B debe estar relacionada, siem- pre, a una y solo una ocurrencia de la entidad A.

III.3.2.2.1. Opcionalidad La siguiente relación indica una relación uno-a-muchos opcional con B: P

P Cada ocurrencia de la entidad A esta relacionada con cero, una o varias ocurrencias de la enti- dad B. Cada ocurrencia de la entidad B, si existe, será relacionada con una y solamente una ocurren- cia de la entidad A. A B R Notación de Martin A B R 1 Notación de Chen 0,n Siempre que existe una ocurrencia de la entidad B ella debe estar relacionada a una ocurrencia de la entidad A y no más ni menos que una. Si una ocurrencia en particular de la entidad A esta re- lacionada a cero ocurrencias de la entidad B, la relación no existe para esa ocurrencia de la entidad A. Por otro lado, si la relación existe, ella puede ser con una o varias ocurrencias de la entidad B. A B R Notación de Martin A B R 0,1 Notación de Chen 0,n P La relación anterior indica una relación uno-a-muchos opcional entre A y B: Cada ocurrencia de la entidad A esta relacionada con cero, una o varias ocurrencias de la enti- dad B.

50 Capítulo III. — Modelo Entidad Relación (ERD) P Cada ocurrencia de la entidad B esta relacionada con cero o una ocurrencia de la entidad A. Las entidades A o B no necesitan existir. Si existen, deben estar relacionadas. Si existe una re- lación entre ellas, una ocurrencia específica de la entidad A puede estar relacionada con cero, una o varias ocurrencias de la entidad B. Cada una de las ocurrencias de la entidad B pueden estar rela- cionadas a solamente una ocurrencia de la entidad A. Por lo tanto, las ocurrencias de la entidad B relacionadas a una ocurrencia de la entidad A no pueden estar relacionadas a ninguna otra ocurren- cia de la entidad A.

III.3.2.3. Relación Muchos-a-Muchos Dos relaciones uno-a-muchos para ambos lados pueden existir entre entidades, ellas se con- vierten en una sola relación muchos-a-muchos y es representada de la siguiente manera: A B R Notación de Martin A B R 1,n Notación de Chen 1,m P P Cada ocurrencia de la entidad A esta relacionada con una o varias ocurrencias de la entidad B. Cada ocurrencia de la entidad B esta relacionada con una o varias ocurrencias de la entidad A. A B R III.3.2.3.1. Opcionalidad

Notación de Martin A B R 1,n Notación de Chen 0,m P

P Cada ocurrencia de la entidad A esta relacionada con cero, una o varias ocurrencias de la enti- dad B. Cada ocurrencia de la entidad B, si existe, esta relacionada con una o varias ocurrencias de la entidad A. A B R Notación de Martin A B R 0,n Notación de Chen 0,m P

P Cada ocurrencia de la entidad A, si existe, esta relacionada con cero, una o varias ocurrencias de la entidad B. Cada ocurrencia de la entidad B, si existe, esta relacionada con cero, una o varias ocurrencias de la entidad A.

III.3.2.4. Relaciones Indefinidas Se ha descripto cómo se representan gráficamente las relaciones uno-a-uno y uno-a-muchos, obligatoria y opcional. Sin embargo, cuando se esta desarrollando un modelo entidad relación pue- de suceder que no se conozca el tipo de relación existente y que el tipo de relación no este hasta el momento definida. En estos casos la relación es descripta de la siguiente manera: A B R Notación de Martin A B R Notación de Chen

Capítulo III. — Modelo Entidad Relación (ERD) 51 III.3.3. Mecanismos de Abstracción

En la construcción de diagramas entidad relación existen mecanismos que permiten modelar diversos tipos de abstracción, muy útiles en la organización conceptual de los modelos de datos.

III.3.3.1. Clasificación El mecanismo de clasificación fue introducido intuitivamente, puesto que los tres conceptos básicos en los que se basan los diagramas entidad relación fueron desarrollados como una aplica- ción de abstracciones de clasificación: P

P

P Entidad: Una entidad es una clasificación que representa un conjunto de objetos con caracte- rísticas comunes. Atributos: Un atributo es una clasificación que representa un conjunto de valores de una pro- piedad atómica de una entidad o una relación. Relación: Una relación es una clasificación que representa el conjunto de vínculos entre obje- tos integrantes del mismo conjunto de entidades.

III.3.3.2. Agregación de Atributos (atributos compuestos) Un atributo de una entidad o relación puede ser una estructura compuesta por ítems que se de- sean identificar. La Fig. III-12 presenta una entidad Cliente con un atributo compuesto Dirección.

III.3.3.3. Especialización (es-un o es-subtipo-de) La relación es-un o es-subtipo-de es una relación muy común en una clasificación de entida- des. Es útil si existen entidades con la mayoría de la características comunes, pero con algunas ca- racterísticas diferentes. La Fig. III-13 presenta un ejemplo. Una especialización también puede ser útil si solamente un sub-conjunto de ocurrencias de las entidades, a ser relacionadas, participan en la relación.

III.3.3.4. Agregación de Entidades (compuesto-por) La relación compuesto-por es una relación que permite describir composición, por ejemplo la Cliente Número Ciudad CP Calle

Dirección

Provincia Fig. III-12: Ejemplo de atributos compuestos Alumno de Pos-Grado Alumno Nombre Edad

Alumno de Grado Notación de Martin Alumno de Pos-Grado Alumno Nombre Edad

Alumno de Grado Notación de Chen Fig. III-13

52 Capítulo III. — Modelo Entidad Relación (ERD) 1. Para cada evento construir una relación a. b. c. El sujeto del evento es una de las entidades de la relación. El predicado del evento es la otra entidad de la relación. El verbo del evento es el nombre de la relación. Cliente Factura paga 2. Eliminar las entidades que no posean datos que identifiquen instancias diferentes. BCRA Balance recibe Encabezado Totales Línea 1 1,n 1 Encabezado Totales Notación de Chen

Factura Línea Notación de Chen

Factura 1 Comp por Fig. III-14 Alumno Disciplina Notación de Martin

Matrícula Alumno Disciplina Notación de Chen

Matrícula 1,n 1,n Fig. III-15

composición de una factura como se describe en la Fig. III-14.

III.3.3.5. Entidades Relacionantes Existen situaciones en las cuales una relación se convierte en una entidad. Por ejemplo, si una relación tiene atributos asociados a ella, es una entidad sin perder su propiedad de vinculo entre entidades. La Fig. III-15 muestra un ejemplo. Note que la notación de Martin no hace diferencia entre los dos tipos de entidades. Sin em- bargo, en la notación de Chen la relación convertida en entidad es notoriamente identificable.

III.3.4. Construcción de un Diagrama Entidad-Relación

Existe un conjunto de pasos los cuales guían el proceso de construcción de un modelo entidad relación, a partir de una lista de eventos, los cuales son descriptos a continuación:

Capítulo III. — Especificación de Procesos 53 3. Identificar relaciones que puedan servir como entidades asociativas Cliente

Cliente Artículo

Artículo pide

pide

Pedido 4. 5.

6. 7. 8. Construir el modelo resultante. Identificar entidades demasiado generales o grupos de entidades demasiado particulares y construir relaciones de especialización. Identificar relaciones de composición. Identificar entidades poco significativas. Completar el modelo de datos. Para cada entidad, cada relación y cada entidad asociativa, completar la correspondiente entrada en el diccionario de datos.

III.4. Especificación de Procesos

Una especificación de procesos describe las actividades a ser desarrolladas para transformar los datos de entrada en datos de salida. Existen diversas herramientas para la especificación de pro- cesos: tablas de decisión, árboles de decisión, lenguajes estructurados, pre/pos condiciones y dia- gramas de Nassi-Shneiderman, entre otras. En general, una herramienta puede ser utilizada para la especificación de procesos si cumple los siguientes dos requisitos: P

P Una especificación de procesos debe ser expresada de forma tal que pueda ser verificada por el usuario y por el analista de sistemas. Por esta razón, no es recomendable utilizar el uso de lenguajes de programación, tampoco es recomendable el uso de lenguaje natural. Una especificación de procesos debe ser expresada de forma tal que pueda ser efectivamente comunicada a la audiencia involucrada. Habitualmente hay una audiencia diversa de usuarios, gerentes, auditores y controladores de calidad, los cuales leerán la especificación. La especificación de procesos es realizada solo para los procesos de los niveles más bajos del diagrama de flujo de datos. Los procesos de un nivel intermedio son definidos por los diagramas de flujos de datos del nivel inferior inmediato. Sin embargo, en otros diagramas como por ejemplo el diagrama de estructura, todos los componentes deben ser especificados.

III.4.1. Lenguaje Estructurado

Un lenguaje estructurado es un subconjunto del lenguaje natural con algunas restricciones en cuanto al tipo de comandos que pueden ser utilizados y la manera en que esos comandos pueden ser utilizados. Los lenguajes estructurados también son conocidos por otros nombres: P P P Lenguaje de Diseño de Programas Lenguaje de Especificación de Problema Pseudo-código

El propósito es obtener un equilibrio razonable entre la precisión de un lenguaje de programa– ción formal y, la informalidad y legibilidad del lenguaje que se utiliza normalmente. Los comandos en estos lenguajes pueden consistir en una ecuación algebraica o en una declaración imperativa sin- tética en un lenguaje natural. Las estructuras de control comúnmente usadas en este tipo de lengua– jes son las descriptas a continuación:

Estructuras de Control Secuencia

Condicional

Repetición S1 S2 . . Sn Si C S1 Si no S2 Fin Si Mientras C S1 Fin S1 S2 … Sn IF C S1 ELSE S2 END IF DOWHILE C S END DO Una secuencia de comandos simples es equivalente (estructural- mente) a un comando simple.

Una construcción Si-Sino (IF-ELSE) simple es considerada estruc- turalmente equivalente a una única sentencia simple. Esta construc- ción puede ser anidada. También se pueden utilizar múltiples sen- tencias condicionales.

Una estructura Mientras (DO WHILE) simple es considerada es- tructuralmente equivalente a una única sentencia simple. Esta es- tructura puede ser anidada. Una especificación de procesos no debe ser muy compleja. Existen tres consejos que pueden ayudar en su construcción: P

P

P Restrinja la especificación de procesos en lenguaje estructurado a una única página de texto. Si una especificación necesita más de una página, el analista de sistemas debe utilizar otra manera de realizar la especificación. Si esto no es posible, probablemente el proceso (o módu- lo) es demasiado complejo y deba ser explotado en un DFD de nivel más bajo (o en más de un módulo en el diagrama de estructuras). No utilice más de tres niveles de anidamiento. Principalmente en el caso de estructuras Si- Sino, más de dos niveles de anidamiento representan un fuerte indicio que sería preferible uti- lizar la herramienta tabla de decisión. Evite confusiones sobre niveles de anidamiento utilizando indentación. III.4.2. Pre/Pos Condiciones

Esta herramienta presenta un modo práctico de describir una función que debe ser ejecutada por un proceso, sin que sea necesario extenderse demasiado sobre el algoritmo o procedimiento. Esta herramienta es particularmente útil cuando: P

P

P El usuario tiene que expresar la política ejecutada por un proceso en términos de un algoritmo especial y particularizado que ha utilizado durante mucho tiempo. El analista de sistemas está razonablemente seguro que existen muchos algoritmos que pue- den ser utilizados. El analista de sistemas quiere dejar que el programador explore algunos algoritmos pero no desea involucrarse personalmente. En la Fig. III-16 se da un ejemplo de aplicación de Pre/Pos Condición. Las pre-condiciones describen todo lo que debe ser verdadero (si hubiese algo) antes de la ejecución del proceso. Muchas veces es práctico imaginar pre-condiciones como un disparador para que un proceso pueda trabajar. También pueden ser consideradas como una garantía de ausencia de errores de datos de entrada cuando un proceso es activado. En general describen: P

54 Qué entradas deben estar disponibles. Estas entradas serán recibidas por medio de un flujo de datos. Puede haber casos en que haya varios flujos llegando a un proceso y uno de ellos sea una pre-condición necesaria para la activación del proceso.

Capítulo III. — Especificación de Procesos

55 P

P

P Una pre-condición puede estipular que exista un registro en un repositorio que tenga alguna componente que coincida con alguna otra componente de un registro de otro repositorio de datos. Las pos-condiciones describen qué debe ser verdadero cuando un proceso termina su tarea. Esto puede ser considerado como una garantía de validación de la función ejecutada por el proceso. Cuando el proceso es terminado, la pos-condiciones deben ser verdaderas. Las pos-condiciones habitualmente describen lo siguiente: P P

P

P Las salidas que son producidas por el proceso. Es la forma más común de pos-condición. Las relaciones que existen entre los valores de salida y los valores originales de entrada. Esto es común en situaciones en que una salida es una función matemática directa de un valor de entrada. La relación que existe entre los valores de salida y los valores de uno o más repositorios de datos. Esto es común cuando debe ser recuperada información de uno o más repositorios para completar la salida del proceso. Las alteraciones que deben ser realizadas en los depósitos. Incorporación de nuevos ítems, modificación o eliminación de ítems existentes. Todos los datos (no locales) deben estar especificados en el diccionario de datos, por ejemplo considérese las siguientes definiciones en el diccionario de datos: Planif-Análisis := * Especificación de la fecha y procedimiento de análisis * @Nro-paciente + @Tipo-Anal. + Fecha_Anal. + Hora-Anal. Análisis Diario-Anal := (Planif-Análisis) := (Fecha-Anal. + Hora-Anal. + (Tipo-Anal. + Datos-Pac.)) La especificación de procesos correspondiente sería la siguiente: Pre-condición Existen Planif-Análisis cuya Fecha es el día siguiente (mañana) Pos-condición Se emite Diario-Anal. del Planif-Análisis

Capítulo III. — Especificación de Procesos ESPECIFICACIÓN DE PROCESO 3.5: Calcular Impuesto Sobre Ventas Pre-Condición 1: Datos-de-Venta ocurre con Tipo-de-Ítem que coincide con Categoría-de-Ítem en Categorías-de-Impuestos Pos-Condición 1: Tasa-Ventas es ajustada en Total-Ventas * Valor-Tasa Pre-Condición 2: Datos-de-Venta ocurre con Tipo-de-Ítem que no coincide con Categoría-de-Ítem en Categorías-de-Impuestos Pos-Condición 2: Mensaje-Error(Ítem inválido) es generado

Fig. III-16: Ejemplo de especificación de proceso utilizando pre/pos condiciones

Qué relación debe existir entre las entradas con su valor. Con frecuencia una pre-condición especificará que deben llegar entradas con campos relacionados. Qué relación debe existir entre entradas y depósitos de datos. Una pre-condición puede esti- pular que exista un registro en un depósito que coincida con algún aspecto de un elemento de entrada. Qué relación debe existir entre diferentes depósitos y el interior de un repositorio de datos.

56 Capítulo III. — Especificación de Procesos Conviene resaltar que suele ser conveniente utilizar términos locales dentro de la especifica- ción de procesos para describir cálculos intermedios o relaciones entre entradas y datos guardados.

III.4.3. Tabla de Decisión

Existen situaciones en las que el lenguaje estructurado o pre/pos condición no son adecuados para realizar una especificación de procesos. Esta situación ocurre cuando la lógica del proceso se basa en decisiones complejas. Si las decisiones se basan en muchas variables y estas variables pue- den asumir varios valores diferentes, la especificación de procesos puede ser realizada utilizando tablas de decisión, como se muestra en el siguiente ejemplo: 1 2 3 4 5 6 7 8 Edad > 21 S S S S N N N N Sexo S S N N S S N N Peso > 90 S N S N S N S N Medición 1 P P P Medición 2 P P Medición 3 P P P Ninguna Medición P P Como se describe en la tabla, una tabla de decisión es construida relacionando las variables interesadas con acciones a ser ejecutadas según alguna combinación particular de los valores de las variables (primera columna). En este ejemplo, todas las variables son booleanas, es decir, sólo pueden tomar uno de dos va- lores: verdadero-falso, femenino-masculino, si-no, etc. Esta es una característica deseable pero no obligatoria. Cuando todas las variables son booleanas la tabla toma la forma de las denominadas usualmente como tabla de condición / acción. Las otras columnas contienen todas las posibles combinaciones de valores de las variables. La parte inferior de la tabla describe la acción a tomar cuando esa combinación es obtenida. Si existen N variables con valores booleanos, entonces habrá 2Ncombinaciones diferentes. Para la creación de una tabla de decisión se deben seguir las siguientes etapas: 1.

2.

3. 4.

5. 6. 7. 8. Identificar todas las condiciones o variables de la especificación. Identificar todos los valores que cada variable puede asumir. Calcular el número de combinaciones de condiciones posibles. Si todas las condiciones fuesen booleanas (o binarias en general), habrá 2Ncombinaciones de N variables. Identificar cada acción posible en la especificación. Crear una tabla de decisiones vacía, relacionando todas las condiciones y acciones en el lado izquierdo, y enumerando las combinaciones de las condiciones en la parte superior de la tabla. Relacionar todas las combinaciones de condiciones, una para cada columna de la tabla. Examinar cada columna e identificar las acciones adecuadas a ser ejecutadas. Identificar todas las omisiones, contradicciones y ambigüedades de la especificación Discutir las omisiones, contradicciones y ambigüedades con el usuario. III.4.4. Árboles de Decisión

Un árbol de decisión sirve para modelar funciones discretas, en las que el objetivo es deter- minar el valor combinado de un conjunto de variables, y basándose en el valor de cada una de ellas, determinar la acción a ser tomada.

Depósito PPedir monto Capítulo III. — Especificación de Procesos 57 ¿Transacción Válida? Si

No Tipo de Transacción Extracción Saldo PPedir monto P Descontar monto a la cuenta P Generar comprobante

P Sumar monto a la cuenta P Generar comprobante

P Obtener saldo P Generar informe P Procesar Mensaje de Error

Fig. III-17: Ejemplo de Árbol de Decisión

Los árboles de decisión son normalmente construidos a partir de la descripción de la narrativa de un problema. Ellos proveen una visión gráfica de la toma de decisión necesaria, especifican las variables que son evaluadas, qué acciones deben ser tomadas y el orden en la cual la toma de deci- sión será efectuada. Cada vez que se ejecute un árbol de decisión, solo un camino será seguido de- pendiendo del valor actual de la variable evaluada. Considérese el siguiente ejemplo: En un cajero automático es posible realizar varias transacciones diferentes. Si el cliente desea realizar una transacción no válida un mensaje de error es generado. El cliente puede realizar las siguientes transacciones: consulta de saldo, extrac- ción o depósito. Si selecciona consulta de saldo se busca el saldo del cliente y se genera un informe el cual es entregado al cliente. Si se desea realizar una extrac- ción o un depósito se pide el monto, se actualiza la cuenta ya sea incrementando o descontando el monto al saldo y se genera un comprobante para el cliente. El árbol de decisión mostrado en la Fig. III-17 corresponde a la lógica del proceso descripto con la narrativa anterior.

III.4.5. Diagramas de Nassi-Shneiderman

El diagrama de Nassi-Shneiderman surge a mediados de los años ’70, cuando la programación estructurada se tornó popular. Ellos adicionan una representación visual de los lenguajes estructura- dos en la forma mostrada en la Fig. III-18. A continuación se describen las estructuras básicas de este tipo de diagrama.

58 Capítulo III. — Diagramas de Transición de Estados (DTE) P P Estado inicial: Antes que ocurra cualquier transición Estado final (uno o más): Fin del comportamiento del sistema. Un tipo de problema comúnmente adecuado para el modelo con DTE, es el diseño de interfa- ces hombre-máquina. La Fig. III-19 muestra un ejemplo. En estos problemas, los estados son, en general, situaciones fácilmente identificables donde el sistema espera por eventos de dispositivos de Sentencia 1 Condición 1 Condición 2 Sentencia 2 v1 Sentencia 2 v2 Sentencia 2 v3 Sentencia 2 v4 Sentencia 2 v5 Sentencia 2 v6 Sentencia 2 f1 Sentencia 2 f2 Condición 3 Sent. 3 v1 Sent. 3 v2 Sent. 3 v3 Sent. 3 f1 Sent. 3 f2 Sent. 3 f3 Fig. III-18: Ejemplo de diagrama Nassi-Shneiderman

III.5. Diagramas de Transición de Estados (DTE)

Los diagramas de transición de estados sirven para el modelamiento de actividades donde un conjunto finito de estados diferentes puede ser reconocido. Ellos modelan los diferentes estados en los que puede estar una actividad, las condiciones de los eventos de transición entre los estados y las acciones que deben ser ejecutadas en el momento de cambiar de estado. Los diagramas de transición de estados tienen una interpretación ejecutable basada en una teo- ría formal: las máquinas de estados finitos.

Una máquina de estados finitos es un mecanismo hipotético que puede estar en una colección discreta de estados, en un punto discreto del tiempo. Ciertos even- tos pueden forzar el cambio de estado de la máquina a otro estado de la colección.

Los eventos de transición de estados ocurren en puntos discretos en el tiempo. No existen cambios lentos y continuos. La ocurrencia de un evento causa una transición instantánea en el esta- do de la máquina. Los eventos pueden ocurrir de modo asincrónico (en cualquier punto en el tiem- po) o de modo sincrónico (en intervalos). Comúnmente, los estados son diseñados como círculos, aunque algunos autores los diseñan con cajas rectangulares [Ward 85]. Las transiciones son diseñadas con flechas que unen dos estados apuntando al estado destinatario de la transición.

III.5.1. Estados

Para el modelamiento usando diagramas de transición de estado, tal vez la actividad más difí- cil es la identificación de los diferentes estados. Si el problema es adecuado para ser modelado con DTE el conjunto de estados debe ser reconocido con relativa facilidad. Un estado representa un modo de comportamiento externamente observable. El nombre del estado es el nombre del comportamiento. Existen dos tipos de estados:

Capítulo III. — Diagramas de Transición de Estados (DTE) 59 Lectura del Valor de Extracción Menú de Operación Cuenta legal P Desplegar Menú “Saldo” P Buscar Saldo de Cuenta P Crear Informe de Saldo de Cuenta Lectura de # de cuenta

Extracción legal ESC P Descontar Valor al Saldo “Extracción” P Desplegar Input Box de Extracción Depósito legal

Lectura del Valor de Depósito P Adicionar Valor al Saldo

“Depósito” P Desplegar Input Box de Depósito Fig. III-19: Modelo de Interfaz de Operaciones en Cuenta Corriente

entrada (teclado, lectores ópticos etc.) o dispositivos apuntadores como el mouse. Múltiples exten- siones a los DTE existen para el modelamiento de este tipo de problema. También son útiles para el modelamiento de problemas complejos de sincronización, por ejemplo en aplicaciones de bases de datos o procesamiento concurrente.

III.5.2. Transiciones

Las transiciones entre estados en un DTE son producidas como resultado de la ocurrencia de un evento en el sistema. Los eventos son producidos cuando una condición es verdadera. En el ejemplo de la Fig. III-19, cuando el sistema está en el estado Lectura del Valor de Extracción y la condición Extracción Legal es verdadera, el estado del sistema cambia a Menú de Operación. También es posible especificar las acciones que deben ser ejecutadas en el momento de la transición. Una acción es una actividad indivisible, no es importante el orden en el cual se realizan las actividades involucradas a menos que una secuencia explícita sea especificada. En el DTE de la Fig. III-19, cuando el sistema esta en el estado Menú de Operación y la condición “Saldo” es ver- dadera (se selecciona la operación “Saldo” desde el menú de operaciones) inmediatamente se eje- cutan las acciones Buscar Saldo de la Cuenta y Crear Informe de Saldo de Cuenta. Una vez ejecutadas las acciones, la transición puede ser completada.

III.5.3. Representación en Tabla de Transición

Los diagramas de transición de estados pueden ser representados en una matriz de transición de estados, bidimensional, que contiene la misma información modelada en la versión gráfica. La tabla siguiente representa una Tabla de Transición del DTE de la Fig. III-19:

60 ? : Transición para el estado E P Acción : Acción asociada a la transición

III.5.4. Representación en Diagramas de Grade

Cuando el problema modelado representa un mecanismo complejo, puede haber muchas tran- siciones entre un número relativamente pequeño de estados y la representación gráfica de un DTE se torna confusa. En estos casos se utiliza un diagrama de grade. Un diagrama de grade es una re- presentación de un DTE donde los estados son representados por líneas verticales y las transiciones por flechas horizontales. La Fig. III-20 muestra el ejemplo de la Fig. III-19 modelado con un dia- grama de grade. Lectura de # de Cuenta Menú de Operación Lectura del Valor de Extracción Lectura del Valor de Depósito “Saldo” P Buscar Saldo P Crear Informe Box de Depósito Extracción Legal P Descontar Valor al Saldo Box de Extracción

“Depósito” P Desplegar Input ESC Depósito Legal P Adicionar Valor al Saldo Cuenta Legal P Desplegar Menú

“Extracción” P Desplegar Input Fig. III-20: Diagrama de Grade para el Modelo de Interfaz de Operaciones en Cuenta Corriente

Capítulo III. — Diagramas de Transición de Estados (DTE)

Capítulo IV. — Diagramas de Transición de Estados (DTE) 61 IV Capítulo IV. ASML: Análisis Estructurado de Sistemas Contenidos

Introducción…………………………………………………………………………………………………………….62 Modelo de Implementación del Usuario…………………………………………………………………….63 Determinación de los Límites de la Automatización…………………………………………………..64 Determinación de la Interfaz del Usuario………………………………………………………………….65 Identificación de Actividades Manuales Complementarias………………………………………………67 Especificación de Restricciones Operacionales………………………………………………………….67 Diagrama de Estructura……………………………………………………………………………………………68 Módulos ……………………………………………………………………………………………………………….69 Relaciones entre Módulos (Invocaciones)…………………………………………………………………69 Comunicación entre Módulos (Cuplas) …………………………………………………………………….70 Absorción……………………………………………………………………………………………………………..71 Estructuras de Control…………………………………………………………………………………………….71 Derivación de los Diagramas de Estructura……………………………………………………………….72 Análisis de Transformaciones………………………………………………………………………………….72 Análisis de la Especificación del Problema …………………………………………………………………….. 72 Identificar el Centro de Transformación…………………………………………………………………………. 73 Estrategia para Determinar el Centro de Transformación…………………………………………………………………………..74 Producir un Primer Diagrama de Estructura (First-Cut)……………………………………………………. 76 Mejorar el Diagrama de Estructura Obtenido ………………………………………………………………….. 76 Garantizar la Funcionalidad del Diseño………………………………………………………………………….. 77 Análisis de Transacción………………………………………………………………………………………….77 Criterios de Validación de Calidad……………………………………………………………………………80 Acoplamiento………………………………………………………………………………………………………..81 Acoplamiento sin Cuplas ……………………………………………………………………………………………… 81 Acoplamiento de Datos………………………………………………………………………………………………… 82 Acoplamiento Estampado …………………………………………………………………………………………….. 83 Acoplamiento de Control……………………………………………………………………………………………… 83 Acoplamiento Híbrido………………………………………………………………………………………………….. 84 Acoplamiento Común ………………………………………………………………………………………………….. 85 Acoplamiento por Contenido (o Patológico)……………………………………………………………………. 85 Cohesión……………………………………………………………………………………………………………….85 Cohesión Funcional……………………………………………………………………………………………………… 86 Cohesión Secuencial ……………………………………………………………………………………………………. 86 Cohesión Comunicacional…………………………………………………………………………………………….. 87 Cohesión Procedural ……………………………………………………………………………………………………. 88 Cohesión Temporal……………………………………………………………………………………………………… 88 Cohesión Lógica………………………………………………………………………………………………………….. 89 Cohesión Coincidencial………………………………………………………………………………………………… 89 Clusters de Información (Cohesión Informacional)………………………………………………………….. 89 Determinación de la cohesión de un módulo …………………………………………………………………… 90 Descomposición (Factoring)……………………………………………………………………………………90 Reducir el Tamaño del Módulo……………………………………………………………………………………… 90

Hacer el Sistema más Claro……………………………………………………………………………………………91 Minimizar la Duplicación de Código ………………………………………………………………………………91 Separar el Trabajo de la ‘Administración’………………………………………………………………………..91 Crear Módulos más Generales………………………………………………………………………………………..91 Fan-Out……………………………………………………………………………………………………………….. 91 Fan-In …………………………………………………………………………………………………………………. 92 Criterios Adicionales de Diseño……………………………………………………………………………… 92 Evitar División de Decisiones………………………………………………………………………………………..92 Forma del Sistema………………………………………………………………………………………………………..92 Sistemas Dirigidos por Entradas Físicas (Physically Input-Driven)……………………………………………………………..93 Sistemas Balanceados……………………………………………………………………………………………………………………………94 Tratamiento de Errores………………………………………………………………………………………………….94 Relación entre Estructuras de Datos y Estructura de Programa …………………………………………..96 Memoria Estática………………………………………………………………………………………………………….96 Módulos de Inicialización y Terminación………………………………………………………………………..97 Edición………………………………………………………………………………………………………………………..97

El diseño estructurado de sistemas se preocupa por la identificación, selección y organización de los módulos y sus relaciones. Se comienza con la especificación resultante del proceso de análi- sis, se realiza una descomposición del sistema en módulos estructurados en jerarquías, con caracte- rísticas tales que permitan la implementación de un sistema que no requiera elevados costos de mantenimiento. La idea original del diseño estructurado fue presentada en la década de los '70, por Larry Constantine [Constantine 74], y continuadas posteriormente por varios autores [Myers 78; Yourdon 78; Stevens 81].

IV.1. Introducción

El diseño estructurado es un enfoque disciplinado de la transformación de qué es necesario para el desarrollo de un sistema, a cómo deberá ser hecha la implementación. La definición anterior implica que: el análisis de requerimientos del usuario (determinación del qué) debe preceder al diseño y que, al finalizar el diseño se tendrá medios para la implementa- ción de las necesidades del usuario (el cómo), pero no se tendrá implementada la solución al pro- blema. Cinco aspectos básicos pueden ser reconocidos: P

P

62 Permitir que la forma del problema guíe a la forma de la solución. Un concepto básico del diseño de arquitecturas es: las formas siempre siguen funciones. Ese concepto debe ser tam- bién utilizado para el diseño de sistemas. Muchas veces, se han escogido formas preconcebi- das para la solución de un problema y forzado a un problema a tomar la misma forma. Un en- foque adecuado debe ser: lograr que, la solución de un problema tenga los mismos componen- tes que los del problema original y respete las relaciones que existen en el problema. El obje- tivo debe ser obtener la mayor aproximación posible a esa idea. Intentar resolver la complejidad de los grandes sistemas a través de la segmentación de un sistema en cajas negras, y su organización en una jerarquía conveniente para la implementa- ción. Además, no es necesario conocer cómo trabajan internamente esas cajas negras, pues su complejidad ya fue resuelta (separadamente de las otras). Para usarlo, solamente se precisa conocer las entradas que deben ser provistas, la funcionalidad que implementa y las salidas que retorna.

Capítulo IV. — Introducción

Capítulo IV. — Modelo de Implementación del Usuario 63 P

P

P Utilizar herramientas, especialmente gráficas, para realizar diseños de fácil comprensión. Un diseño estructurado usa diagramas de estructura (DE) en el diseño de la arquitectura de módu- los del sistema y adiciona especificaciones de los módulos y cuplas (entradas y salidas de los módulos), en un Diccionario de Datos (DD). Ofrecer un conjunto de estrategias para derivar el diseño de la solución, basándose en los resultados del proceso de análisis. Principalmente, ofrece dos heurísticas (Análisis de Trans- formaciones y Análisis de Transacciones) para la derivación de los DE, partiendo de los dia- gramas de flujo de datos (DFD) construidos en el proceso de análisis. Ofrecer un conjunto de criterios para evaluar la calidad de un diseño con respecto al problema a ser resuelto, y las posibles alternativas de solución, en la búsqueda de la mejor de ellas. Permite clasificar varias características de los DE (y de los módulos y cuplas componentes) basado en los problemas potenciales que pueden ocasionar al sistema, una vez implementado. Una identificación de esos problemas, y una subsecuente corrección de errores en la etapa de diseño, disminuyen en gran medida los costos de mantenimiento (sea para corrección de erro- res o incorporación de nueva funcionalidad). El diseño estructurado produce sistemas fáciles de entender y mantener, confiables, fácilmen- te desarrollados, eficientes y que funcionan.

IV.2. Modelo de Implementación del Usuario

Con el Modelo Ambiental y el Modelo Comportamental completamos el desarrollo del Mode- lo Esencial. El modelo esencial contiene una especificación completa del sistema de información de las necesidades del usuario. Específicamente describe: P P P La acción esencial de las funciones que deben ejecutarse. El volumen esencial de los datos usados y guardados por el sistema. El comportamiento esencial necesario para trabajar con las señales y las interrupciones del ambiente externo. Una especificación de la funcionalidad, estructura el comportamiento esencial del sistema, debe ser suficiente para que el diseñador, pueda escoger el mejor hardware, el mejor sistema opera- tivo, el mejor administrador de base de datos, el mejor lenguaje de programación, dentro de las res- tricciones generales de tiempo, dinero y recursos humanos destinados al proyecto de implementa- ción. Descrito así, el trabajo del diseñador parece simple, pero no lo es: hay muchas características en las que ellos necesitan del usuario para que éstas sean definidas. Estas características, incluso las de implementación (sin formar parte del Modelo Esencial) son suficientemente importantes ya que tienen gran impacto en el usuario del sistema, por lo tanto necesitan ser especificadas. El problema de implementación más evidente es el interés del usuario en la Frontera de Automatización, es decir, que parte del modelo esencial se llevara a cabo en la computadora, y que se deja para que sea ejecutada manualmente. El analista, ciertamente, tendrá una opinión en eso, y el diseñador también, pero éste es un problema en el que el usuario tiene la última palabra. También, la interfaz hombre-máquina es de gran interés para el usuario, muchas veces él pa- rece estar más interesado en las interfaces que en las funciones del sistema. Hay muchas teorías desarrolladas respecto a este problema, del factor humano y organización de la información, de la pantalla de la computadora, de la optimización de la comprensión del usuario, de criterios y técnicas acerca de la interacción y estructuración de las interfaces. Sin embargo, el usuario tiene la última palabra porque él es quién las sufre o las aprecia.

Más recientemente varias opciones y posibilidades, aumentaron la importancia de esos pro- blemas de implementación del usuario: P

P

P

P Los usuarios finales muchas veces tienen la oportunidad de usar las computadoras personales (PC) como parte de una red distribuida de computadoras. Esto genera una serie de cuestiones: ¿ Qué partes del modelo esencial estarán disponibles en las computadoras terminales y qué partes en el servidor (mainframe o estaciones RISC)? Esto implica: ¿ A qué datos se tendrá acceso por intermedio del PC, y qué datos serán almacenados en el PC? ¿Qué funcionalidad tendrá que ejecutar el PC? ¿Cuál será el formato de entradas y de salidas en el PC? ¿Qué acti- vidades adicionales de apoyo deben ofrecerse para asegurar que el usuario no dañe despreve- nidamente los datos del PC (o del servidor)? Hay muchas ofertas de administradores de base de datos con lenguajes de cuarta generación que permiten, al usuario, escribir sus propios programas. ¿Con qué partes del sistema ellos pueden interactuar sin riesgos de producir inconsistencia en los datos? Hoy día, en muchas situaciones, el usuario y el analista pueden decidir prototipar el sistema y usar un lenguaje de cuarta generación o un paquete generador de aplicaciones. La prototipa- ción puede hacerse porque el usuario no esta seguro de la acción detallada que en el futuro tendrá que ser descrita en las especificaciones de procesos del modelo esencial; aun así, la mayoría de las veces, la prototipación se usa para la exploración y experimentación con for- matos de entrada, diálogos en línea y formatos de salida para las pantallas e informes. Para muchas aplicaciones de una compañía, una opción es la de adquisición de un paquete de software. En estos casos se generan los mismos problemas de implementación: ¿Qué partes del modelo esencial serán llevados a cabo por el paquete adquirido y qué partes tendrán que ser llevadas a cabo en un sistema separado? ¿Cuáles serán las normas de integración y compa- tibilidad entre el paquete adquirido y el sistema a ser desarrollado? Estos problemas deben ser tratados como parte del Modelo de Implementación del Usuario. La construcción de este nuevo modelo puede obligar a modificaciones en el Modelo Esencial, en ese caso, Yourdon [Yourdon 89] recomienda el mantenimiento de una versión intacta del modelo esencial original. Esto permitirá la experimentación de modelos alternativos del Modelo de Imple- mentación del Usuario. El modelo de Implementación del usuario, en términos generales, incluye los siguientes cua- tro aspectos: P P P P La ubicación dentro del Modelo Esencial de las personas versus las máquinas. Detalles de la interacción hombre/máquina. Actividades manuales suplementarias que pueden ser necesarias. Restricciones operacionales que el usuario quiere imponer al sistema. IV.2.1. Determinación de los Límites de la Automatización

¿Qué funciones y que datos serán manipulados manualmente, y cuáles automatizados? Aun- que pueda haber tenido una versión preliminar y experimental de los límites de la automatización durante el estudio de viabilidad, ellos no son fijos ni definitivos. De hecho, el límite de la automati- zación es casi irrelevante en el modelo esencial, porque aunque las necesidades del usuario sean que nosotros desarrollemos un sistema automatizado, él también necesita una declaración bien elabora- da de requisitos de las funciones y de los datos que estarán fuera de las fronteras de la automatiza- ción. Existen tres casos extremos que tienen que ser considerados: P

64 Al usuario no le debe interesar donde esta la frontera de la automatización: es poco probable que esto ocurra. En la práctica el usuario elige el equipo de implementación. ¿Qué partes del sistema deben ser manuales y cuáles automatizadas? Además del hecho que el usuario nor- malmente tiene gran sensibilidad en ese problema, éste espera que el analista produzca un

Capítulo IV. — Modelo de Implementación del Usuario

Capítulo IV. — Modelo de Implementación del Usuario 65 P

P común, sobre todo en esta era de la automatización, dado que el analista habitualmente tiene interés en informatizar todo lo que sea posible. Sin embargo, esto puede pasar en momentos en que la intención del usuario no sea informatizar, pero si reorganizar la manera en que las actividades están ejecutándose. La Fig. IV-1 presenta algunas posibles alternativas para establecer el límite de un sistema. Es- tas alternativas deben discutirse entre el usuario, el analista y el equipo de implementación, con base en un estudio del costo/beneficio.

IV.2.2. Determinación de la Interfaz del Usuario

Hay varios estudios estadísticos de sistemas interactivos que indican que, entre el 40% y el 60% del código y datos de los programas están dedicados a la implementación de la interfaz hom- Parte Automatizada

Parte Automatizada Parte Manual

Parte Automatizada

Parte Manual Parte Automatizada

Parte Automatizada

Parte Manual Fig. IV-1: Cuatro posibles definiciones de limites de automatización para el mismo sistema.

análisis detallado de costo-beneficio de todo el proyecto. Eso demanda alguna decisión preli- minar acerca de que partes del modelo esencial serán automatizadas y cuales manuales. El usuario puede optar por un sistema completamente automatizado: Esta es una situación muy común, principalmente si el sistema esta desarrollándose para sustituir otro sistema exis- tente. De esta manera, las actividades manuales ya pueden estar fuera del límite del sistema representado en el diagrama de contexto como agentes externos con los que el sistema se co- munica. El usuario puede optar por un sistema completamente manual: Esta es una opción muy poco

66 Capítulo IV. — Modelo de Implementación del Usuario P

P

P

P La elección de dispositivos de entrada y salida (por ejemplo, las terminales alfanuméricas o gráficas, dispositivos de lectura óptica, impresoras de gran velocidad, etc.). Por ejemplo, en algunos casos, un requisito importante es la posibilidad de hacer análisis estadístico del des- empeño de las funciones de algunas de las áreas de organización (como volúmenes de venta de ciertos productos relacionados al periodo anual, o los volúmenes de ventas generales rela- cionados al periodo mensual, etc.), o proyecciones financieras respecto a mercaderías en stock. En esos casos, la elección de una terminal gráfica para la gerencia (de ventas, de stock o financiera) puede ser un requisito fundamental. También, si se identifican volúmenes muy elevados de facturación, una impresora de gran velocidad puede ser muy importante. El formato de las entradas que fluyen de los agentes externos hacia el sistema. Es preciso es- pecificar con gran detalle las características de los datos ingresados y como ellos serán acep- tados. El formato de las salidas que fluyen del sistema hacia los agentes externos. ¿Se representan ellos en la pantalla de la computadora o en informes impresos? Comúnmente el formato de los informes impresos ya es predeterminado y, es común que el usuario quiera mantener estos formatos. Si el agente externo es gubernamental, habitualmente los informes que se desean tienen un formato muy estricto. La secuencia y el escalonamiento de entradas y salidas en el componente en línea. Estos esca- lonamientos deben diseñarse con mucho cuidado. Ellos pueden especificarse con diagramas de transición de estados. El modelo de la interfaz hombre-máquina involucra dos problemas. El primero es el compo- nente estructural, la secuencia y el escalonamiento de entradas y salidas. Ese problema puede pla- nearse con diagramas de transición de estados, las transacciones del sistema se ejecutan en las tran- siciones entre los estados. El segundo problema es el formato y la técnica de interacción para los flujos de datos de entrada, y el formato de presentación de los flujos de datos de salida de las tran- sacciones. En la Fig. IV-2 se puede ver un ejemplo.

1 Bobrow, en su articulo "Expert Systems: Perils and Promise", CACM Vol 23, Nº 9 Sep 86, presenta un análisis de aplicaciones en inteli- gencia artificial de donde se desprenden los resultados citados. Existen también otros estudios que confirman esto, por ejemplo un estudio de Sutton en 1978 (Pedor Szekely, "Separating the User Interfaz from the Functionality of Application Programs", CMU-CS-88-101, Enero de 1988) sobre 16 aplicaciones comerciales el 59% del código estuvo dedicada a la interfaz. Lectura de # Cuenta Lectura de Valor Pedir Saldo de Cuenta Valida Cta.

“Saldo” Esc

Menú de Operación “Depósito” “Retiro” Valor Legal Lectura de Valor Valor Legal Sumar Valor a Sueldo Fig. IV-2: Modelo de Interfaz de Operaciones en cuenta corriente. Interfaz para una transacción de consulta de Saldo de Cuenta, Incrementar Saldo y Descontar Valor a Saldo.

bre-máquina1. Este hecho pone en evidencia la importancia en costos de mantenimiento de un ade- cuado diseño de la interfaz hombre-máquina. La especificación de la interfaz de usuario es, probablemente, la actividad que más tiempo consume y en la que el usuario más interesado esta. Eso involucra cuatro problemas relacionados:

Capítulo IV. — Modelo de Implementación del Usuario 67 IV.2.3. Identificación de Actividades Manuales Complementarias En el modelo esencial, presumimos la existencia de una tecnología perfecta. Entre otras cosas consideramos que nuestra tecno- logía de implementación nunca falla ni come- te errores. Así mismo con el funcionamiento de la tecnología perfecta, los usuarios come- ten errores de operación que, si no fueron considerados apropiadamente, producen da- ños en el sistema. El usuario puede estar trabajando con datos financieros, caso en el que pueden existir exigencias legales (im- puestas porinterventores) para asegurar la integridad de las entradas y salidas de los archivos del siste- ma. En la mayoría de los casos estas actividades complementarias de apoyo serán representadas por nuevos procesos en DFDs del modelo comportamental. La Fig. IV-3 presenta un ejemplo. De una manera general, tendremos que contemplar la posibilidad de fallas tecnológicas en: P

P

P Las entradas y salidas del sistema: Si los datos de entrada han sido introducidos por disposi- tivos de vídeo unidos a las computadoras principales por líneas de telecomunicación, la posi- bilidad de errores en la transmisión es muy grande. También puede tener errores de los me- dios magnéticos como diskettes (o discos blandos). La ejecución de cálculos: una vez introducidos los datos en el sistema, los errores del hardwa- re pueden existir (memoria, procesador, etc.) o de programa. El almacenamiento de datos por periodos largos: la mayoría de los sistemas retienen datos en discos por periodos largos de tiempo. Es posible que, esos datos, sean destruidos debido a los errores del hardware (o software). Lo que debe hacerse con respecto a estas posibles áreas de tecnología defectuosa dependerá mucho de: P P P El nivel estimado de fiabilidad del hardware y del software. La naturaleza y la fiabilidad del usuario. Los costos o multas asociadas a entradas y/o salidas defectuosas. Por la naturaleza de la incertidumbre en la predicción de estos tipos de fallas, la solución más común es la introducción de redundancias: entradas y/o salidas redundantes, procesadores redun- dantes, la redundancia interna en los depósitos de datos, campos redundantes (de control) en las estructuras de datos.

IV.2.4. Especificación de Restricciones Operacionales

El equipo de implementación tendrá que decidir que combinación de hardware, sistema opera- tivo, recursos de comunicación, lenguajes de programación, administradores de base de datos y es- trategias de proyecto llevarán a cabo mejor los requisitos. Pero, será difícil hacerlo sin el estableci- miento de algunas restricciones de operaciones (que el modelo esencial evita deliberadamente). Los problemas principales, normalmente, son: P

P Volúmenes de datos: Necesitamos que el usuario especifique los volúmenes de transacciones de entrada y el tamaño necesario de los depósitos de datos, si el volumen es estable o hay grandes variaciones. Tiempo de respuesta para las entradas: Las restricciones de tiempos de respuesta pueden existir para algunas entradas del sistema. Por ejemplo, todas las transacciones de depósitos de Generar Factura factura

Verificar Error de Salida Ejecución de PC operada por usuario Verificación manual de errores Fig. IV-3: Una actividad de apoyo manual

68 P

P

P clientes deben procesarse por la noche para que de mañana los clientes puedan saber su saldo, o las novedades para los empleados se admiten hasta antes de las 10 horas de la mañana, o la liquidación de haberes que deba estar hecha a las 8 horas del día siguiente. Restricciones políticas en opciones de implementación: El usuario puede, por motivos racio- nales o irracionales, especificar la marca del hardware a ser usado (o a ser evitado), el vende- dor del equipo, y así sucesivamente. O, cuando ya fue comprado el hardware y el problema es que éste no es el que mejor se adapta al problema. O al revés, el problema puede ser respecto al hardware ya existente Restricciones de seguridad y fiabilidad: El usuario puede especificar el tiempo medio entre fallas y el tiempo medio entre paradas para el mantenimiento del sistema. Restricciones de seguridad: El usuario puede especificar la intención de minimizar el uso no autorizado del sistema. Eso puede incluir a usuarios administradores del sistema con claves de acceso. Los usuarios pueden tener el acceso a diferentes niveles (para los diferentes niveles de confidencialidad de información o de riesgo del funcionamiento).

IV.3. Diagrama de Estructura

Los diagramas de estructura (DE) sirven para el modelamiento top-down de la estructura de control de un programa descripto a través de un árbol de invocación de módulos. Fueron presenta- dos en la década de los 70 como la principal herramienta utilizada en diseños estructurados, por autores como Constantine, Myers, Stevens e Yourdon [Constant 74; Yourdon 78; Myers 78; Ste- vens 81]. La Fig. IV-4 muestra un ejemplo. Un diagrama de estructura permite modelar un programa como una jerarquía de módulos. Ca- da nivel de la jerarquía representa una descomposición más detallada del módulo del nivel superior. La notación usada se compone básicamente de tres símbolos: P P P Módulos Invocaciones Cuplas Pago líquido de jornaleros Registro de empleado asalariado Pago líquido de asalariado Número de empleado Nombre de empleado

Pago de empleado Valor hora

Horas trabajadas Pago bruto de jornaleros

Detalle de impuesto Deducciones normales Pago básico

Bonos Pago bruto de asalariados Detalle de impuesto Módulo Invocación

Cupla de Datos Emitir cheques de pago a los Empleados Leer registro de Empleado Calcular salario líquido para jornaleros Calcular salario líquido para asalariados Imprimir cheque de pago Calcular salario bruto para jornalero Calcular deducciones normales Calcular salario bruto para asalariados Cupla de Control Registro de empleado

Fin de archivo Registro de empleado Fig. IV-4: Ejemplo de Diagrama de Estructura

Capítulo IV. — Diagrama de Estructura

Capítulo IV. — Diagrama de Estructura 69 IV.3.1. Módulos

Un módulo es un conjunto de instrucciones que ejecutan alguna actividad, un procedimiento o función en PASCAL, una función en C o un parágrafo en COBOL. Tal vez, la definición más preci- sa es que un módulo es una caja negra, pero como será mostrado a continuación son cajas “casi” negras o grises. Desde un punto de vista práctico, un módulo es una colección de instrucciones de un progra- ma con cuatro características básicas: P P P P Entradas y Salidas: lo que un módulo recibe en una invocación o retorna como resultado. Función: las actividades que un módulo hace con la entrada para producir la salida. Lógica Interna: por la cual se ejecuta la función. Estado Interno: su área de datos privada, datos para los cuales sólo el módulo hace referencia. Las entradas y salidas son, respectivamente, datos que un módulo necesita y produce. Una función es la actividad que hace un módulo para producir la salida. Entradas, salidas y funciones proveen una visión externa del módulo. La lógica interna son los algoritmos que ejecutan una fun- ción, esto es, junto con su estado interno representan la visión interna del módulo. Un módulo es diseñado como una caja, su función es representada por un nombre en el inter- ior y las entradas y salidas de un módulo son representadas por pequeñas flechas que entran y salen del módulo. Existen distinciones entre módulos, la tabla siguiente describe los diferentes tipos de módulos: Módulo M E S Un módulo es una caja negra conteniendo una colección de instrucciones y áreas de datos locales. Los módulos tienen una función, definida por el nom- bre contenido en el interior (M), datos de entrada y datos de salida genera- dos por la aplicación de la función a los datos de entrada. Módulo de Biblioteca M E S Un módulo predefinido o módulo de biblioteca representa un módulo que no tiene que ser especificado porque ya existe en el sistema o en bibliotecas. Frecuentemente, también, se utiliza la misma notación para representar lla- madas al sistema operacional como read o write de archivos. Un módulo de Cluster de Información

Área de Datos Global A B C E de Datos

D biblioteca es verdaderamente una caja negra ya que no son modeladas las actividades que realiza. Un cluster de información es una colección de módulos que trabajan sobre la misma estructura de datos. Son utilizados para modelar tipos abstractos de datos, esto es, encapsulan una estructura de datos y los módulos que la crean y referencian. En la parte inferior del módulo se anota el nombre de la estructura de datos. Es fuertemente recomendable la especificación de áreas de datos globales cuando son utilizadas por los módulos en un diseño. El uso de áreas globales no es una práctica confiable, en muchos diseños no pueden ser evitadas o precisan ser incluidas para mejorar el desempeño del sistema. Una buena especificación de estas áreas permite un mejor análisis de la calidad del dise- ño y disminuye costos de mantenimiento.

IV.3.2. Relaciones entre Módulos (Invocaciones)

En la realidad, los módulos no son realmente cajas negras. Los diagramas de estructura mues- tran las invocaciones que un módulo hace a otros módulos. Estas invocaciones son diseñadas como una flecha que sale del módulo llamador y apunta al módulo llamado. La Fig. IV-5 muestra un ejemplo.

70 Capítulo IV. — Diagrama de Estructura En el ejemplo de la Fig. IV-5 el módulo A invoca (o llama) a los mó- dulos B, C y D. La interpretación de las invocaciones provee información de la estructura interna del módulo llamador, que no concuerda con la idea de caja negra. Una caja negra no permite que se observe su interior y, las invocaciones que un módulo hace son componentes de su estructura interna. De todas formas, se dice que un módulo es una caja casi negra o caja gris porque permite que se observen sólo las invocaciones. Los diagramas de estructura no tienen especificado el orden de invocación de los módulos in- vocados. El orden de dibujo de los módulos B, C, y D (de izquierda a derecha) no debe ser interpre- tado como el orden de invocaciones ejecutado por el módulo A. Ese orden puede ser cambiado, al dibujar, para evitar que se crucen flechas o se dupliquen módulos, como ocurre con el módulo Cal- cular Deducciones Normales en la figura 1. A pesar que el orden de invocación de los módulos del mismo nivel en un diagrama de estructura, no es especificado por el formalismo, se recomienda que siempre que fuese posible, se siga un orden de izquierda a derecha (si esto no produce que se crucen flechas) que se corresponde con el orden de invocación, y permitiendo un orden de lectura que es patrón en la mayoría de los idiomas. Una invocación representa la idea de invocación a funciones o procedimientos en los lengua- jes de programación convencionales. En un diagrama de estructura se pueden modelar varios tipos de invocaciones:

Tipos de Invocación Invocación Estándar

Invocación Concurrente A

B

A El módulo A invoca al módulo B con la semántica de invocación de procedimientos o funciones en los lenguajes de programación conven- cionales (C, Pascal, etc.).

El módulo A comienza dos tareas concurrentes, B y C. Invocación Co- rutina B

A C

B El módulo A invoca al módulo B con una semántica de transferencia de control al punto de entrada de una co-rutina. Transferencia de Control Patológica A B El módulo A hace una transferencia de control (ej.: con un GOTO o JUMP en ASSEMBLER) al interior del módulo B. Claramente es una práctica patológica y no es recomendable en ningún caso. Pero, si una patología existe es preferible que sea mostrada. Referencia Patológica A El módulo A hace referencia a un área de datos local del módulo B. También es una práctica patológica y debe ser evitada. B

IV.3.3. Comunicación entre Módulos (Cuplas)

Cuando una función o un procedimiento, en un lenguaje convencional, es invocado, común- mente un conjunto de argumentos es comunicado y, en el caso de las funciones, también se espera que retorne un resultado. Estos datos comunicados en una invocación son modelados por medio de flechas, sobre el símbolo de invocación, llamadas cuplas. A B C D Módulo llamador

Invocación

Módulo llamado Fig. IV-5: Ejemplo de Invocación

Capítulo IV. — Diagrama de Estructura 71 Como se ve en la Fig. IV-6, existen varios tipos de cuplas, basado en lo que ellas pueden producir en el módulo receptor, las cuales se describen a continuación. Cupla de Datos

Cupla Modificada

Cupla de Control Cupla Híbrida

Cupla sin Tipo IV.3.4. Absorción

En muchos casos en el diseño top-down de un programa, la descomposición realizada con el objetivo de mejorar la interpretación y modela- miento, da como resultado pequeños módulos (apenas una o dos instrucciones o una ecuación matemática). Esta descomposición puede ayudar en la comprensión del programa diseñado pero se tie- ne la certeza que en la implementación el módulo correspondiente no será separado. Este hecho pue- de ser especificado en el diagrama de estructura con el símbolo mostrado en la Fig. IV-7. IV.3.5. Estructuras de Control

Los diagramas de estructura también definen símbolos que posibilitan el modelamiento de es- tructuras de control como repetición o alternativa. A B C D Cupla modificada Cupla de control (flag) Cupla híbrida (datos y control) X Y Z W f h Cupla de datos Cupla sin tipo (o de datos o de control o híbrida) Fig. IV-6: Ejemplo de invocación con cuplas

Tipos de Cuplas Una cupla de datos transporta datos “puros” a un módulo. No es necesario conocer la lógica interna del módulo receptor, para determinar los valores válidos de la cupla (ej.: número de cuenta, saldo, tabla de movimientos). Con una flecha doble (apuntando al modulo llamador y al módulo llamado) se especifica un argumento enviado a un módulo que deberá modificar su valor, fijando un nuevo valor disponi- ble para el módulo llamador (en la implementación, se precisará que el lenguaje posea un me- canismo de pasaje de parámetros por referencia) (ej.: el buffer enviado a un módulo de lectura de un archivo). Una cupla de control transporta un dato indispensable para la toma de una decisión, en la lógica interna del módulo invocado (ej. código de operación).

Una cupla que para algunos módulos transporta datos “puros” y para otros transporta un flag de control es denominada cupla híbrida. Esta cupla representa un híbrido entre una cupla de datos y una cupla de control. La identificación de ellas depende de la lógica definida por el algoritmo de implementación del módulo invocado. Se utiliza para representar que hasta el momento no esta definida o se tienen dudas con respecto a la interpretación que el módulo invocado hace de ella. Informar Promedio deAlumno Dividir entre la cantidad de notas Acumular Notas Presentar Promedio deAlumno Tabla de notas Total Cantidad Promedio Absorción

Fig. IV-7

Repetición

Alternativa A

A Una flecha circular, abarcando un número de invocaciones, especifica que las invocacio- nes que abarca son ejecutadas repetidamente.

Un rombo incluyendo una o más invocaciones especifica la ejecución condicional de ellas. IV.4. Derivación de los Diagramas de Estructura

Para un DFD dado siempre puede ser construido un diagrama de estructura que describe la ar- quitectura de módulos que debe ser desarrollada para implementar la funcionalidad descripta. La creación de los DE puede resultar una actividad muy difícil, principalmente para DFDs con muchos procesos. Sin embargo, el diseño estructurado ofrece dos estrategias para construir rápidamente una primera versión del diseño. Las estrategias para la validación y el refinamiento (que serán presenta- dos más adelante) pueden llevarnos en dirección a obtener un buen diseño. Sin tales estrategias, se tendría, frecuentemente, que efectuar sucesivas modificaciones a los diagramas de estructura y es- perar que la inspiración celestial nos guíe hacia algo bueno. Las dos estrategias de derivación de diagramas de estructura son: P

P Análisis de Transformaciones: provee un vínculo entre el análisis estructurado y un diseño estructurado. Análisis de Transacciones: La estructura general de los sistemas tiende a caer en modelos reconocibles. Uno de los modelos comunes en sistemas comerciales es el llamado sistema de transacciones. El análisis de transacciones es una estrategia específica para diseñar estos tipos de sistemas.

IV.4.1. Análisis de Transformaciones

El principal enfoque del análisis de transformaciones es convertir un DFD, resultado del aná- lisis estructurado, en un diagrama de estructura. La principal ventaja de este enfoque es que, el dia- grama de estructura resultante tiene una forma tal que permite un fácil desarrollo y mantenimiento más barato que la mayoría de los diagramas de estructura que podamos construir ad-hoc. Como será visto mas adelante, cuando los criterios de calidad son aplicados en los diagramas de estructura, el resultado es un DE donde, la mayoría de los módulos son independientes de los dispositivos de en- trada y salida, esto es: describe el diseño de un sistema balanceado. La Fig. IV-8 describe los pasos realizados durante el análisis de transformaciones.

IV.4.1.1. Análisis de la Especificación del Problema Si un diseño estructurado está siendo desarrollado, luego del análisis estructurado, entonces habrá un conjunto de DFDs que describen el problema, para los cuales se debe diseñar una solución. Si el análisis estructurado no precede al diseño, entonces se pueden reconocer dos situaciones muy diferentes: P

72 Un problema muy simple: Si el problema puede ser representado en la memoria de una perso- na [DeMarco 86], es muy simple y no precisa mayor esfuerzo que la especificación. En ese caso las herramientas del Análisis no son necesrias y el DE puede ser desarrollado ad-hoc. Sin embargo, el análisis estructurado ofrece una colección de técnicas y criterios que permiten analizar y especificar un problema cuando es muy complejo para ser comprendido y especifi- cado con una simple declaración narrativa. Según DeMarco [DeMarco 86], un modelo es una maqueta de una realidad donde algunas características son estudiadas y, se construyen dife-

Capítulo IV. — Derivación de los Diagramas de Estructura

Capítulo IV. — Derivación de los Diagramas de Estructura 73 P nuestra memoria principal y diversos modelos deberán ser desarrollados, en el proceso de análisis estructurado, para conseguir una buena comprensión y especificación. En ese caso, será necesario construir algunos DFDs a partir de la narrativa del problema (declaraciones surgidas de las entrevistas con los diversos usuarios involucrados). Para obtener un buen resultado con el análisis de transformaciones, los DFDs no deben llegar a un nivel de detalle en el que se tenga demasiada cantidad de procesos. Si un DFD es muy detalla- do puede ser necesario que se necesite hacer abstracción de algunos procesos (para reducir la canti- dad). El DFD tampoco puede ser demasiado abstracto y ocultar algunas características que el análi- sis de transformaciones debe estudiar. Además, puede ser necesario descender un nivel (describien- do los flujos de datos y los procesos interiores de algunos procesos mostrados en el DFD) para que, el DFD presente todas las transformaciones de datos producidas para llevar los flujos de entrada en dirección de generar los flujos de salida.

IV.4.1.2. Identificar el Centro de Transformación El centro de transformación es la parte del DFD que contiene la funcionalidad principal del sistema y es independiente de la implementación particular de las entradas y salidas. Por ejemplo, considere el DFD de la Fig. IV-9. El diseñador podría considerar al proceso Reunir Movimientos del Cliente como la trans- formación principal del DFD, si un proceso tiene mas flujos de entrada que de salida, la pregunta que deberá ser respondida es: ¿Qué proceso hace el trabajo principal de la funcionalidad que repre- senta el DFD?. Análisis de la especificación del problema Identificación del centro de transformación

Producción de un primer DE (first-cut)

Mejoramiento del DE

Asegurar la funcionalidad del diseño Análisis Estructurado DFDs resultantes del proceso de análisis Especificación del análisis Funcionalmente equivalentes

Diseño de buena calidad Implementación, Testeo, etc. DFDs sin detalles de más y sin ocultar transformaciones de datos

Marcar el centro de transformación, caminos aferentes y eferentes

Centro de transformación = raíz Caminos aferentes = izquierda Caminos eferentes = derecha Cohesión, acoplamiento, etc.

Diseño estructurado de buena calidad (mantenimiento, eficiencia, claridad, etc.) Fig. IV-8: Pasos del análisis de transformaciones

rentes modelos de la misma realidad (cada uno de ellos representando diferentes característi- cas) para estudiar diferentes partes del problema por separado. Un problema complejo: La mayoría de las veces, el problema es mayor que la capacidad de

1.

2.

74 Marcar cada camino aferente partiendo del lado externo del DFD (los flujos provenientes de depósitos de datos, agentes externos o porciones del DFD no incluidas en el Análisis2), y ter- minar en cada flujo eferente alcanzado (los flujos dirigidos para depósitos de datos, agentes externos o porciones de DFD no incluidas en el Análisis). Diseñar una curva que una los puntos de intersección de caminos diferentes. Los procesos incluidos en el interior de la curva son candidatos iniciales para el centro de transformación.

2 El DFD analizado es solamente una porción correspondiente a una transformación identificable. Como separar un DFD proveniente del Analisis en porciones correspondientes a transformaciones es una actividad muy intuitiva, quedará mas claro cuando sea presentado el Analisis de Transaccioness.

Capítulo IV. — Derivación de los Diagramas de Estructura movimientos del Cliente Leer información del Cliente Reunir movimientos del Cliente Formatear encabezado Calcular total Formatear total Formatear línea del informe Imprimir línea Cuenta Corriente Clientes Registro del Cliente Nombre + Dirección Movimiento

Leer # de Cuenta Movimiento Total depósitos + # de Cuenta Movimiento # de Cuenta Tipo de Movimiento + Valor del Movimiento Línea Encabezado Saldo Informe Total extracciones

Fig. IV-9: Generación de informe de movimientos de una cuenta corriente

Claramente, el principal trabajo no es hecho por los procesos: Leer Movimiento del Cliente, Leer Información del Cliente, Calcular Total o Imprimir Línea. Tampoco es hecho por alguno de los procesos: Formatear Encabezado, Formatear Línea del Reporte o Formatear Total por separado. La función que el DFD modela, con certeza, no es Reunir Movimientos del Cliente, podría corres- ponderse con un proceso de abstracción mayor, tal vez llamado Generar Reporte de Movimientos, que incluya los procesos: Formatear Encabezado, Formatear Línea de Reporte y Formatear Total. La elección del centro de transformaciones no es una actividad simple, generalmente requiere una interpretación detallada de la funcionalidad descripta por el DFD, y, en muchos casos, podría incluir mas de un proceso. Para eso existe una estrategia basada en la estructura del DFD, indepen- diente de la interpretación particular de los procesos, que permite obtener una buena aproximación de la porción del DFD que debe incluir el centro de transformaciones. No es un algoritmo, ya que no establece una secuencia de etapas y tampoco garantiza la ob- tención acertada del centro de transformaciones. Una vez identificada la porción del DFD que in- cluye el centro de transformaciones, se debe interpretar detalladamente la función de los procesos incluidos para determinar si alguno de ellos representa la transformación principal del DFD o si una actividad de abstracción mayor deberá ser escogida.

IV.4.1.2.1. Estrategia para Determinar el Centro de Transformación La estrategia intenta identificar la transformación central siguiendo los caminos de datos afe- rentes y eferentes. Este proceso puede ser desarrollado a través de los tres pasos siguientes:

Campo editado camino eferente transacciones Transac- Transacción Transacción sin inválida Transacción editado maestro validación transacción con registro Capítulo IV. — Derivación de los Diagramas de Estructura 75 3. Analizar los límites del centro. Generalmente, en el límite se puede reconocer la finalización del refinamiento de las entradas (para los caminos de entrada o aferentes) y el comienzo del refinamiento de las salidas (para los caminos de salida o eferentes). Si no es así, modifique el contorno, yendo hacia el interior o exterior de forma tal que el interior, incluya solamente da- tos en estado lógico (independientes de las fuentes y destinos y totalmente refinados). En el ejemplo de la Fig. IV-10 se ilustra la actividad descripta arriba. Primero se marcan todos los caminos de datos a través del DFD comenzando por los flujos de comienzo de los caminos afe- rentes y finalizando en los flujos de finalización de los caminos eferentes. En el ejemplo, los flujos de datos Campo y Registro Maestro son flujos de comienzo de caminos aferentes y, Nuevo Registro Maestro y Línea de Informe son flujos de finalización de caminos eferentes. En el segundo paso se hace una curva uniendo los puntos de intersección de caminos. La cur- va reúne los procesos candidatos para centros de transformación, en el ejemplo, reúne los p