Diseño orientado a las estructuras de datos

Roger S. Presuman
Ingeniería de Software un Enfoque practico
DISEÑO ORIENTADO A LAS ESTR UCTURAS DE DATOS
La íntima relación entre software y datos puede ser rastreada hasta los orígenes de la
computación. El concepto original, que estaba detrás del de computadora de programa
almacenado, es el de que los programas podrían ser vistos como datos y los datos
interpretados como programas. La estructura de la información, llamada estructura de
datos, se ha demostrado que tiene un importante impacto en la complejidad y eficiencia de
los algoritmos diseñados para procesar la información.
Conforme evolucionaron los métodos de diseño del software en la pasada década, una
escuela de pensamiento estableció que:
La identificación de las estructuras de datos inherentes (para un sistema basado en
computadora) es vital y la estructura de los datos (entrada y salida) puede usarse
para derivar la estructura (y algunos detalles) de un programa [PET77].
En muchas áreas de aplicación existe una estructura de la información diferenciada y
jerárquica. Los datos de entrada, internamente información almacenada (es decir, una base
de datos), y los datos de salida, pueden tener cada uno una estructura única. El diseño
orientado a la estructura de datos hace uso de estas estructuras como base para el desarrollo
de software.
DISEÑO Y ESTRUCTURA DE LOS DATOS
La estructura de los datos afecta al diseño, tanto en el aspecto estructural, como
procedimental del software. Los datos repetitivos se procesan siempre con software que
tiene facilidades de control para la repetición; los datos alternativos (es decir, información
que puede o no puede estar presente) requieren software con elementos condicionales de
procesamiento; una organización jerárquica de los datos frecuentemente tiene una
extraordinaria semejanza con la estructura del programa que utiliza los datos. De hecho, la
estructura de la información predice muy bien la estructura del programa.
El diseño orientado a la estructura de datos transforma una representación de la estructura
de datos en una representación del software. Como las técnicas orientadas al flujo de datos,
los creadores del diseño orientado a la estructura de datos han de definir un conjunto de
procedimientos de “transformación” que utilizan la estructura de la información (datos)
como guía.
Contribuciones
Los orígenes del diseño orientado a la estructura de datos pueden encontrarse en las
discusiones técnicas sobre los “fundamentos de las estructuras de datos” (p. el., [TRE76I),
algoritmos de computadora [H0R78], la estructura de control y datos [WUL81] y el
concepto de abstracciones de datos [GUT77]. Tratamientos más pragmáticos del diseño del
software y sus relaciones con las estructuras de datos han sido propuestos por Jackson
([JAC75], [JAC83]), Warnier (IWAR74I, [WAR81I] y Orr (IORR81], IHAN83]).
Roger S. Presuman
Ingeniería de Software un Enfoque practico
La metodología de Desarrollo de Sistemas de Jackson parte de que la “paralelización de la
estructura de los datos de entrada y salida (informe) asegurará un diseño de calidad”
[JAC75]. Extensiones más recientes de la metodología se enfocan sobre la identificación de
entidades de información y de acciones que se les aplican y, que son similares en algunos
aspectos, al método de diseño orientado al objeto descrito en el Capítulo 9. Jackson
potencia el aspecto práctico, desarrollando técnicas pragmáticas para transformar los datos
en estructura de programa.
La Construcción Lógica de Programas (CLP), desarrollada por J. D. Warnier [WAR74], da
un método riguroso para el diseño de software. Sobre el esquema de la relación entre
estructura de datos y estructura procedimental, Warnier desarrolla un conjunto de técnicas
que realizan una transformación de la estructura de datos de entrada/salida en una
representación procedimental detallada del software.
El Desarrollo de Sistemas Estructurados de Datos (DSED), también llamado Metodología
de Warnier-Orr ([ORR8 1], {HAN83]), es una extensión de CLP y potencia el análisis, así
como las capacidades de diseño. El método DSED proporciona una flotación y
procedimientos para derivar la estructura de datos, estructura del programa y diseño
procedimental detallado de los componentes del programa (módulos). Además, DSED da
una notación que facilita al diseñador examinar el flujo de datos entre las fuentes y
sumideros de información, y de los procesos que transforman la información.
Una técnica llamada Construcción Lógica de Software [CHA8O9] es una síntesis
representativa de los métodos de diseño orientados al flujo de datos y a la estructura de
datos. Los creadores del método sostienen que “el diseño lógico puede describirse
explícitamente si se ve el software como un sistema de conjuntos de datos y
transformaciones de datos” [C11A80].
Áreas de aplicación
El diseño orientado a la estructura de datos puede aplicarse con éxito a aplicaciones que
tengan una estructura jerárquica, bien definida, de la información. Ejemplos típicos
incluyen:
• Aplicaciones en sistemas de ir4 formación comerciales. La entrada y salida tienen
distinta estructura (p. ej., archivos de entrada, informes de salida); el uso de una
base de datos jerárquica es frecuente.
• Aplicaciones de sistema. La estructura de datos para los sistemas operativos
comprende muchas tablas, archivos y listas que tienen una estructura bien definida.
• Aplicaciones CAD/CAM/CAE. Los sistemas de diseño/fabricación/ingeniería
asistidos por computadoras requieren estructuras de datos sofisticadas para el
almacenamiento, traducción y procesamiento de la información.
Además, el diseño orientado a la estructura de datos puede ser adecuado para aplicaciones
del dominio de la ingeniería y de la ciencia, enseñanza asistida por computadora, resolución
de problemas combinatorios y muchas otras áreas.
Roger S. Presuman
Ingeniería de Software un Enfoque practico
En general, el diseño orientado a la estructura de datos es más difícil de aprender y más
complicado de aplicar que las técnicas orientadas al flujo de datos (Capítulo 7). Sin
embargo, la escuela de diseño orientada a la estructura de datos ofrece un enfoque más rico
y, potencialmente, más poderoso para el diseño de software.
Técnicas de estructura de datos frente a las de flujo de datos
Antes de considerar las diferencias entre diseño orientado al flujo de datos y orientado a la
estructura de datos, es importante observar que ambos comienzan en los pasos de análisis
que conducen a los fundamentos de los siguientes pasos de diseño. Ambos están
conducidos por la información; ambos intentan transformar la información en una
representación del software; ambos se basan en conceptos derivados separadamente del
“buen diseño”.
El diseño orientado a la estructura de datos no hace un uso explícito de un diagrama de
flujo de datos. Por tanto, las clasificaciones de flujo de transformación y de transacción
tienen poca relevancia en el método de diseño orientado a la estructura de datos. Lo más
importante es que el objetivo último de los métodos orientados a la estructura de datos es
producir una descripción procedimcntal del software. El concepto de estructura modular de
programa no se considera explícitamente. Los módulos se consideran un subproducto del
procedimiento y a la idea de independencia de módulos se le da poca importancia.
El diseño orientado a la estructura de datos hace uso de un diagrama jerárquico para
representar la estructura de la información. Por tanto, durante el análisis de requerimientos
del software, el énfasis debe colocarse en estos modos de representación.
Debe observarse que una tercera escuela de pensamiento, la de los métodos de diseño
orientados al objeto (DOO), ha merecido una amplia atención durante los últimos años.
DOO representa una tercera alternativa para el diseño de software, cogiendo ciertas ideas
de los métodos predecesores orientados a estructura y a flujo de datos, aunque añadiendo
muchos conceptos nuevos e importantes.
CONSIDERACIONES SOBRE EL PROCESO DE DISEÑO
El análisis de requerimientos del software permanece como la base del diseño orientado a la
estructura de datos. La descripción del dominio de la información (estructura, contenido y
flujo de datos) contenida en la Especificación de Requerimientos del Software prefigura la
arquitectura del software que ha de desarrollarse durante el diseño. Cada método de diseño
da un Conjunto de “reglas” que facilitan al diseñador la transformación de la estructura de
datos en una representación del software.
Cada método orientado a la estructura de datos tiene su propio conjunto de reglas. Sin
embargo, deben realizarse siempre las siguientes tareas de diseño: 1) evaluar las
características de la estructura de datos; 2) representar los datos en términos de formas
elementales, tales como secuencia, selección y repetición; 3) transformar la representación
de la estructura de datos en una jerarquía de control para el software; 4) refinar la jerarquía
Roger S. Presuman
Ingeniería de Software un Enfoque practico
del software usando los criterios definidos como parte de un método, y 5) desarrollar
finalmente una descripción procedimental del software.
En los métodos orientados a la estructura de datos no está clara la división entre los pasos
de diseño arquitectural y procedimental (se han descrito como parte del proceso del diseño
de software). Jackson, Warnier y Orr van rápidamente hacia la representación
procedimental.
DESARROLLO DEL SISTEMA DE JACKSON
Como la mayoría de las metodologías de diseño de software, el Desarrollo de Sistema de
Jackson (DSJ) es realmente una continuación de los pasos técnicos que soportan el análisis
y diseño de software. Para realizar el DSJ el analista y diseñador han de dar los siguientes
pasos:
• Paso de las acciones y entidades. Usando un método muy similar a la técnica de análisis
orientada al objeto, se identifican las entidades (agentes, objetos u organizaciones que un
sistema necesita para producir o usar la información) y acciones (los sucesos que ocurren
en el mundo real que afectan a las entidades).
• Paso de estructuración de las entidades. Las acciones que afectan a cada entidad se
ordenan en el tiempo y se representan mediante los diagramas de .Jackson.
• Paso de modelación inicial. Las entidades y acciones se representan como un modelo del
proceso; se definen las conexiones entre el modelo y el mundo real.
• Paso funcional. Se especifican las funciones que corresponden a las acciones definidas.
• Paso de temporización del sistema. Se establecen y especifican las características de
planificación del proceso.
• Pacto de implementación. Se especifica el hardware y software como un diseño.
Los primeros tres pasos del DSJ. En resumen, el paso de las acciones y entidades comienza
con una breve declaración en lenguaje natural del problema, del que se eligen las entidades
(nombres) y acciones (verbos). Sólo las entidades y acciones que tengan una relación
directa con la solución software se eligen para una posterior evaluación.
El paso de estructuración de entidades crea un diagrama de Jackson, que describe una
especificación ordenada en el tiempo, de las acciones ejecutadas sobre o por una entidad. El
diagrama de Jackson, descrito en la Figura 5.1 (para el ejemplo de Servicio de Trenes de
Universidad), se crea para cada entidad (las entidades tren y botón en el caso de la Figura
5.1) y se acompaña frecuentemente de un texto explicativo.
Roger S. Presuman
Ingeniería de Software un Enfoque practico
FIGURA 5.1 Diagramas de estructura de Jackson.
El paso de modelación inicial comienza con la construcción de una especificación del
sistema como un modelo del mundo real. La especificación se crea con un diagrama de
especificación del sistema (DES) usando la simbología mostrada en la Figura 5.2. Una
conexión mediante datos se presenta cuando un proceso transmite cierta información (p. ej.,
registros de escrituras) y otro proceso recibe dicha información (p. ej., lee registros). Las
flechas representan la dirección del flujo de información y los círculos representan los
datos, los cuales se supone que han de colocarse en un buffer FIFO de capacidad ilimitada.
Una conexión para vector de estado ocurre cuando un proceso inspecciona directamente el
vector de estado de otro proceso. Las flechas representan la dirección del flujo de
información y los rombos indican el vector de estado. Esta conexión es frecuente en
aplicaciones de control de proceso en las que es necesario comprobar el estado de algún
dispositivo electromecánico. Por convenio, el sufijo 0 representa un proceso del mundo real
y el sufijo 1 representa un proceso del modelo del sistema.
Pasos del Diseño DSJ
Para discutir los pasos del diseño del Desarrollo de Sistema de Jackson, continuamos con el
ejemplo del Servicio de Trenes de la Universidad (STU). Reproduciendo la declaración del
problema:
Una gran universidad está dividida en dos campus, los cuales están separados una
milla. Para ayudar a los estudiantes que deben pasar de un campus a otro, a llegar a
tiempo a las clases, la universidad planea instalar un servicio de trenes.
El servicio de trenes hace uso de un único tren de alta velocidad, el cual recorre la distancia
entre la estación de cada campus. Cada estación tiene un botón de llamada que los
estudiantes pueden usar para solicitar el pasar a la otra estación. Cuando los estudiantes
Roger S. Presuman
Ingeniería de Software un Enfoque practico
llegan a una estación, pulsan el botón de llamada. Si el tren está allí, suben a él y parten
hacia la otra estación. Si el tren está andando, deben esperar a que se pare en la otra
estación, suban los estudiantes (si los hay) y vuelva. Si el tren está en la otra estación, el
tren la deja y viene a recoger a los estudiantes que han pulsado el botón. El tren esperará en
una estación hasta que se solicite un servicio (se pulse un botón).
FIGURA 5.2 Natación DES.
Las entidades se seleccionan examinando todos los nombres de la descripción. Después de
la revisión, se eligen las siguientes entidades candidatas: Universidad, campus, estudiantes,
clases, tren, estación, botón. No estamos directamente interesados en campus, clases,
estudiantes o estación —todas ellas caen fuera de los límites del modelo y se rechazan
como posibles entidades. Universidad es realmente un término colectivo de los dos campus,
por lo que lo rechazamos corno posible entidad. Seleccionamos tren y botón. Usando un
análisis similar, seleccionamos llegar, pulsar y partir como las acciones que afectan a tren y
botón.
El diagrama de estructura de Jackson para tren y botón se muestra en la Figura 5.1. El
diagrama de especificación del sistema para STU se ilustra en la Figura 5.3. Finalmente, el
paso de modelación inicial para UTP se realiza como se describe en la siguiente discusión.
Siempre que sea posible, preferimos conectar los procesos del modelo con entidades del
mundo real mediante datos, de forma que se asegure la correspondencia directa entre el
comportamiento del modelo y el mundo real. En nuestro ejemplo, el botón de llamada
emite un pulso cuando se pulsa. Esto puede transmitirse al proceso botón-1 como una
conexión de datos. Sin embargo, supondremos que los sensores que detectan la llegada o
partida del tren no emiten un pulso sino que cierran un conmutador eléctrico. El estado del
conmutador (encendido/apagado) puede ser accedido. Por tanto, se requiere una conexión
de vector de estado.
Los detalles internos de los procesos del modelo se especifican usando lo que Jackson
llama texto estructurado. El texto estructurado representa la misma información que los
Roger S. Presuman
Ingeniería de Software un Enfoque practico
diagramas de la estructura (Figura 5.4) —secuencia, selección, repetición— pero en un
formato textual. El texto estructurado para botón-1 es:
FIGURA 5.3 Un DES para el STU.
FIGURA 5.4 Notación de los diagramas de estructuras.
Roger S. Presuman
Ingeniería de Software un Enfoque practico
La estructura de BOTON- 1 se corresponde exactamente con la estructura de BOTON-O,
con la adición de las operaciones de lectura que conectan el mundo real al sistema.
Como se observó anteriormente, el proceso TREN-l no puede conectarse a su contrapartida
del mundo real mediante una conexión por datos. En vez de ello, debemos interrogar a los
conmutadores que se ponen a encendido/apagado por la llegada/salida del tren de la
estación. El proceso del sistema debe inspeccionar la entidad del mundo real, lo bastante
frecuentemente, como para asegurar que ninguna acción pueda ocurrir sin ser detectada.
Esto se realiza ejecutando una operación de obtención del vector de estado (getsv), que
obtiene el sector de estado de la entidad del mundo real. Frecuentemente, el proceso del
sistema obtendrá cada valor del vector de estado varias veces antes de que se cambie y el
proceso de modelación puede elaborarse, para que muestre estos valores “de tránsito” de
los vectores de estado. Una descripción del texto de la estructura para TREN- 1 es la
siguiente:
TREN-1 seq
getsv 5V;
CUERPO-ESPERA while ESPERA1
getsv VE;
CUERPO-ESPERA end
PARTIR (1);
CUERPO-TRANSITO1 itr while TRANSITO1
getsv VE
CUERPO-TRANSITO1 end
CUERPO-TREN1 itr
ESTACION seq
LLEGAR (i);
CUERPO-ESPERA itr while ESPERAi
getsv VE;
CUERPO-ESPERA end
PARTIR (i);
CUERPO-TRANSITO ifr while TRANSITOi
getsv VE;
CUERPO-TRANSITO end
ESTACION end
CUERPO-TREN end
Roger S. Presuman
Ingeniería de Software un Enfoque practico
LLEGAR (1);
TREN-1 end
Los valores de estado ESPERA y TRANSITO representan los valores apropiados del
conmutador de llegada y salida. El proceso del mundo real TREN-O produce un cambio del
estado del conmutador ye! proceso del sistema TREN-1 ejecuta operaciones de obtención
del vector de estado para conocer este cambio. La Figura 8.5a ilustra el texto estructurado
de TREN-1 como un diagrama de estructura.
Paso funcional
El propósito del paso funcional del DSJ es expandir el diagrama de especificación del
sistema, mediante la conexión de procesos de funciones, definidas recientemente con los
procesos de modelación por datos o vectores. DSJ reconoce tres tipos de funciones:
• Funciones empotradas. Esta función se adquiere asignando (escribir) operaciones a un
texto estructurado del proceso de modelación.
• Funciones impuestas. Esta función inspecciona el vector de estado del proceso de
modelación y produce los resultados de salida.
• Funciones interactivas. Esta función inspecciona el vector de estado del proceso de
modelación, escribe unos datos que afectan a las acciones del proceso del modelo e incluye
operaciones para escribir resultados.
Las salidas de los procesos funcionales son salidas del sistema y pueden ser informes,
órdenes a dispositivos hardware o cualquier otra información de salida.
Para ilustrar el paso funcional, consideremos el ejemplo de STU y examinemos el modelo
del tren. En el tren hay un panel de luces, que se usan para indicar la llegada a la estación,
iluminando un mensaje de visualización. Las lámparas se encienden y apagan mediante las
órdenes LON(i) y LOFF(i).
Roger S. Presuman
Ingeniería de Software un Enfoque practico
FIGURA 5.5 a) Diagrama de estructura correspondiente al texto estructurado. b) DES
actualizado.
Debe ponerse una función en el modelo del proceso del tren para describir una orden a
LAMP(i) cuando el tren llega a la estación(i); debe generarse otra orden para apagar
lámpara(i) cuando el tren deja la estación(i). Por tanto, mientras el tren está entre las
estaciones, envía unos datos que constan de las órdenes a las lámparas. El DES que
representa esta situación se muestra en la Figura 5.5 b.
Roger S. Presuman
Ingeniería de Software un Enfoque practico
Para implementar las órdenes a las lámparas, se modifica el texto estructurado de TREN- 1
como sigue:
TREN-1 seq LON(1);
getsv ve
CUERPO-ESPERA itr while ESPERA1
getsv VE;
CUERPO-ESPERA end
LOFF(1);
PARTIR (1);
CUERPO-TRANSITO 1 itr while TRANSITO1
getsv VE;
CUERPO-TRANSITO1 end
CUERPO-TREN ¡tr
ESTACION seq
LLEGAR (i);
LON(i)
CUERPO-ESPERA itr while ESPERAi
getsv VE;
CUERPO-ESPERA end
LO FF0);
PARTIR (i);
CUERPO-TRANSITO itr while TRANSITOi
getsv ve;
CUERPO-TRANSITO end
ESTACION end
CUERPO-TREN end
LLEGAR (1);
TREN-1 end
Refiriéndonos al anterior texto estructurado, se envía una orden (LON) para encender la
presentación del mensaje que anuncia a la estación 1 en el panel. Esto ocurre al comienzo
de la vida del tren, antes de que deje la estación 1 por primera vez. Cada vez que los
sensores indican la llegada a una estación, encendemos la lámpara apropiada y cuando el
tren la deja, la lámpara se apaga (LOFF).
Una segunda función es para producir las órdenes del motor, ARRANCAR y PARAR, que
controlarán el movimiento del tren. Estas órdenes se enviarán bajo las siguientes
condiciones:
PARAR cuando los sensores indican la llegada a una estación.
ARRANCAR cuando se pulsa un botón (la primera vez) para pedir el tren y el tren
está esperando en una de las estaciones.
Roger S. Presuman
Ingeniería de Software un Enfoque practico
La necesidad de enviar la orden PARAR esta únicamente determinada por la llegada del
tren a una estación. Sin embargo, la orden ARRANCAR depende de los botones y del tren.
Por tanto, introducimos un proceso de función llamado mcontrol que actúa sobre los datos
recibidos de los procesos TREN- 1 y BOTON y que envía las órdenes ARRANCAR y
PARAR.
La conexión entre el proceso tren- 1 y mcontrol será mediante los datos Si D. Esto significa
que el proceso tren- 1 puede no detectar la llegada del tren, como podría ocurrir si el vector
de estado se inspeccionara periódicamente.
El texto estructurado para el proceso tren-l se reproduce una vez más, esta vez corregido
por el control de la lámpara y el motor:
TREN-1 seq
LON(1)
getsv EV;
CUERPO-ESPERA itr while ESPERA1
getsv VE;
CUERPO-ESPERA end
LOFF(1);
PARTIR (1);
CUERPO-TRANSITO1 itr while TRANSITO1
getsv VE;
CUERPO-TRANSITO1 end
CUERPO-TREN1 itr
STACION seq
LLEGAR ();
write llegar a Si D;
LON(i);
CUERPO-ESPERA ¡tr while ESPERAi
getsv ve;
CUERPO-ESPERA end
LOFF (i);
PARTIR (i);
CUERPO-TRANSITO ¡tr while TRANSITO
getsv VE;
CUERPO-TRANSITO end
ESTACION end
CUERPO-TREN end LLEGAR(1);
write llegar a Si D;
TREN-1 end
Es necesario asegurar que el proceso tren- 1 ejecute las operaciones de obtención del vector
de estado geivs VE, y que mcontrol lea sus registros con la frecuencia suficiente para pasar
a tiempo el tren. Las ligaduras de tiempo, planificación e implementación se consideran en
los pasos de DSJ que siguen.
Roger S. Presuman
Ingeniería de Software un Enfoque practico
Para completar el ejemplo STU, volvamos al modelo de la entidad botón. El modelo
original, botón-l, es una declaración precisa de las acciones de botón, pero es ahora
necesario distinguir entre la primera petición de un viaje y las siguientes veces que se pulsa,
antes de que el viaje realmente comience. Para acomodar estos requerimientos se describe
un nuevo proceso de nivel-2, bot6n 2 y se expresa mediante un diagrama de estructura de
Jackson en la Figura 5.6.
FIGURA 5.6 Servicio de trenes de b universidad —paso funcional
Una función inspecciona el vector de estado de botón-2 para determinar hay una petición
excepcional de un viaje. La función mcontrol informa a cuando se ha servido una petición,
es decir, cuando el tren ha llegado a estación en donde se ha hecho la petición. Hace esto
pasando los registros de llegada recibidos de tren- 1. Así se define una función interactiva
para el proceso botón-2.
El texto estructurado para botón-2 es el siguiente:
BOTON-2 seq
peticion := no;
read MBD and BID;
CUERPO-BOTON itr
GRUPO-PULSAR seq
CUERPO-LLEG-EXTRA itr while (LLEGADA)
read MBD and BiD;
CUERPO-LLEG-EXTRA end
PULSAR-PET seq
petición := sí;
read MBD and BiD;
Roger S. Presuman
Ingeniería de Software un Enfoque practico
PULSAR-PET end
PULSAR-PET-EXTRA itr while
read MBD and BiD;
PULSAR-PET-EXTRA end
LLEGADA seq
petición := no;
read MBD and BiD;
LLEGADA end
GRUPO-PULSAR end
CUERPO-BOTON end
BOTON-2 end
La entrada a botón-2 consta de dos pantallas de datos, mezcladas de forma que se denomina
una mezcla desigual. Una mezcla desigual ocurre cuando el proceso de lectura simplemente
acepta el siguiente registro que se presenta en la pantalla de datos. Por tanto, el orden en el
que se procesen los registros es dependiente de dos procesos de escritura potencialmente
asíncronos. Para este ejemplo, la mezcla desigual es suficiente. Sin embargo, DSJ da otros
tipos de mezclas que podrían introducir menos indeterminación en el sistema [JAC83].
La Figura 5.7 muestra un diagrama de especificación del sistema que refleja todos los
cambios impuestos como pile del paso funcional. Una función empotrada dentro de tren- 1
genera las órdenes de las lámparas y un nuevo proceso de función, mcontrol, impone una
función interactiva en botón-2 y produce las órdenes del motor para el tren. Las dobles
líneas sobre la salida MBD implica una conexión “uno a muchos”. La estructura del
proceso mcontrol se deriva examinando las estructuras de datos de entrada y salida.
Paso de temporización del sistema
En este paso del DSJ, el diseñador especifica las ligaduras de tiempo impuestas en el
sistema. Los primeros pasos de diseño producen un sistema compuesto de procesos
secuenciales que se comunican mediante flujos de datos e inspecciones directas al vector de
estado. La relativa planificación del procesamiento está indeterminada.
Un mecanismo que puede usarse para sincronizar los procesos es el marcador de
granularidad del tiempo (MGT). El MGT es un registro de datos que indica la ocurrencia de
un intervalo particular de tiempo y que puede utilizarse para activar el paso del tiempo, que
afecta a las acciones de un proceso.
Roger S. Presuman
Ingeniería de Software un Enfoque practico
FIGURA 5.7 DES extendido para las funciones 1 y 2.
Las líneas de tiempo para el ejemplo del Servicio de Trenes de la universidad puede incluir:
1. FI tiempo en el que debe enviarse la orden PARAR basándose en la velocidad del
tren y la potencia de frenada.
2. El tiempo de respuesta para la conmutación de las lámparas del panel.
Para el ejemplo STU, no hay necesidad de introducir un mecanismo especial de
sincronización. En algún sentido, el intercambio de datos ha impuesto ya algún grado de
sincronización.
Paso de implementación
El paso de implementación del DSJ tendía, en los primeros trabajos [JAC75], a la
derivación del resto del programa o estructura del proceso, a partir de la estructura de datos
del problema. En esta sección y en la siguiente, se presenta una visión general del enfoque
de diseño de programas de Jackson. Las transformaciones asociadas con este método son la
razón de que esta metodología se haya categorizado como de orientada a la estructura de
datos.
La esencia del paso de implementación puede establecerse parafraseando a Jackson: “Los
problemas deben descomponerse en estructuras jerárquicas de partes que puedan ser
representadas por tres formas estructurales”. Las “formas estructurales” a que Jackson
alude son la secuencia, condición y repetición —en realidad, construcciones
procedimentales (en la terminología de este libro) que son la base de la filosofía de la
programación estructurada.
La notación de la estructura de datos es una variación del diagrama de estructuras de
Jackson y se muestra en la Figura 5.8. Refiriéndonos a esta figura, una colección de datos,
Roger S. Presuman
Ingeniería de Software un Enfoque practico
FIGURA 5.8 Notación de las estructuras de datos.
A, esta compuesta de múltiples ocurrencias (denotadas por un *) de la subestructura de
datos B. B incluye múltiples ocurrencias de C y otra subestructura D que contiene el
elemento de datos E o F (los datos alternativos se denotan por una O). La representación
del diagrama de bloques de Jackson de jerarquía de información, puede aplicarse a
estructuras de base de datos, de entrada o de salida con igual facilidad.
Como un ejemplo más concreto de esta notación, consideremos el software que ha de
desarrollarse para el sistema de contabilidad de tarjetas de crédito (muy simplificado) que
se muestra en la Figura 5.9. Ha de componerse un archivo de pagos, que contiene números
de cliente (NOC), fecha del pago (FECIJA), y cantidad a pagar (CANT) con un archivo
maestro de cliente que contiene NOC y balances excepcionales. El archivo de pagos ha de
estar preordenado en varios grupos de clientes (GRUPO-NOC), de forma que todos los
pagos a un individuo estén contenidos dentro de un registro. La estructura de datos para
ambos archivos, descrita en notación de Jackson, se muestra en la figura.
Roger S. Presuman
Ingeniería de Software un Enfoque practico
FIGURA 5.9 Sistema de facturación de tarjetas de crédito.