Roger S.

Presuman
Ingeniera de Software un Enfoque practico
DISEO ORIENTADO A LAS ESTR UCTURAS DE DATOS
La ntima relacin entre software y datos puede ser rastreada hasta los orgenes de la
computacin. El concepto original, que estaba detrs del de computadora de programa
almacenado, es el de que los programas podran ser vistos como datos y los datos
interpretados como programas. La estructura de la informacin, llamada estructura de
datos, se ha demostrado que tiene un importante impacto en la complejidad y eficiencia de
los algoritmos diseados para procesar la informacin.
Conforme evolucionaron los mtodos de diseo del software en la pasada dcada, una
escuela de pensamiento estableci que:
La identificacin 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 aplicacin existe una estructura de la informacin diferenciada y
jerrquica. Los datos de entrada, internamente informacin almacenada (es decir, una base
de datos), y los datos de salida, pueden tener cada uno una estructura nica. El diseo
orientado a la estructura de datos hace uso de estas estructuras como base para el desarrollo
de software.
DISEO Y ESTRUCTURA DE LOS DATOS
La estructura de los datos afecta al diseo, tanto en el aspecto estructural, como
procedimental del software. Los datos repetitivos se procesan siempre con software que
tiene facilidades de control para la repeticin; los datos alternativos (es decir, informacin
que puede o no puede estar presente) requieren software con elementos condicionales de
procesamiento; una organizacin jerrquica de los datos frecuentemente tiene una
extraordinaria semejanza con la estructura del programa que utiliza los datos. De hecho, la
estructura de la informacin predice muy bien la estructura del programa.
El diseo orientado a la estructura de datos transforma una representacin de la estructura
de datos en una representacin del software. Como las tcnicas orientadas al flujo de datos,
los creadores del diseo orientado a la estructura de datos han de definir un conjunto de
procedimientos de transformacin que utilizan la estructura de la informacin (datos)
como gua.
Contribuciones
Los orgenes del diseo orientado a la estructura de datos pueden encontrarse en las
discusiones tcnicas 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 ms pragmticos del diseo 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
Ingeniera de Software un Enfoque practico
La metodologa de Desarrollo de Sistemas de Jackson parte de que la paralelizacin de la
estructura de los datos de entrada y salida (informe) asegurar un diseo de calidad
[JAC75]. Extensiones ms recientes de la metodologa se enfocan sobre la identificacin de
entidades de informacin y de acciones que se les aplican y, que son similares en algunos
aspectos, al mtodo de diseo orientado al objeto descrito en el Captulo 9. Jackson
potencia el aspecto prctico, desarrollando tcnicas pragmticas para transformar los datos
en estructura de programa.
La Construccin Lgica de Programas (CLP), desarrollada por J. D. Warnier [WAR74], da
un mtodo riguroso para el diseo de software. Sobre el esquema de la relacin entre
estructura de datos y estructura procedimental, Warnier desarrolla un conjunto de tcnicas
que realizan una transformacin de la estructura de datos de entrada/salida en una
representacin procedimental detallada del software.
El Desarrollo de Sistemas Estructurados de Datos (DSED), tambin llamado Metodologa
de Warnier-Orr ([ORR8 1], {HAN83]), es una extensin de CLP y potencia el anlisis, as
como las capacidades de diseo. El mtodo DSED proporciona una flotacin y
procedimientos para derivar la estructura de datos, estructura del programa y diseo
procedimental detallado de los componentes del programa (mdulos). Adems, DSED da
una notacin que facilita al diseador examinar el flujo de datos entre las fuentes y
sumideros de informacin, y de los procesos que transforman la informacin.
Una tcnica llamada Construccin Lgica de Software [CHA8O9] es una sntesis
representativa de los mtodos de diseo orientados al flujo de datos y a la estructura de
datos. Los creadores del mtodo sostienen que el diseo lgico puede describirse
explcitamente si se ve el software como un sistema de conjuntos de datos y
transformaciones de datos [C11A80].
reas de aplicacin
El diseo orientado a la estructura de datos puede aplicarse con xito a aplicaciones que
tengan una estructura jerrquica, bien definida, de la informacin. Ejemplos tpicos
incluyen:
Aplicaciones en sistemas de ir4 formacin comerciales. La entrada y salida tienen
distinta estructura (p. ej., archivos de entrada, informes de salida); el uso de una
base de datos jerrquica 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 diseo/fabricacin/ingeniera
asistidos por computadoras requieren estructuras de datos sofisticadas para el
almacenamiento, traduccin y procesamiento de la informacin.
Adems, el diseo orientado a la estructura de datos puede ser adecuado para aplicaciones
del dominio de la ingeniera y de la ciencia, enseanza asistida por computadora, resolucin
de problemas combinatorios y muchas otras reas.

Roger S. Presuman
Ingeniera de Software un Enfoque practico
En general, el diseo orientado a la estructura de datos es ms difcil de aprender y ms
complicado de aplicar que las tcnicas orientadas al flujo de datos (Captulo 7). Sin
embargo, la escuela de diseo orientada a la estructura de datos ofrece un enfoque ms rico
y, potencialmente, ms poderoso para el diseo de software.
Tcnicas de estructura de datos frente a las de flujo de datos
Antes de considerar las diferencias entre diseo orientado al flujo de datos y orientado a la
estructura de datos, es importante observar que ambos comienzan en los pasos de anlisis
que conducen a los fundamentos de los siguientes pasos de diseo. Ambos estn
conducidos por la informacin; ambos intentan transformar la informacin en una
representacin del software; ambos se basan en conceptos derivados separadamente del
buen diseo.
El diseo orientado a la estructura de datos no hace un uso explcito de un diagrama de
flujo de datos. Por tanto, las clasificaciones de flujo de transformacin y de transaccin
tienen poca relevancia en el mtodo de diseo orientado a la estructura de datos. Lo ms
importante es que el objetivo ltimo de los mtodos orientados a la estructura de datos es
producir una descripcin procedimcntal del software. El concepto de estructura modular de
programa no se considera explcitamente. Los mdulos se consideran un subproducto del
procedimiento y a la idea de independencia de mdulos se le da poca importancia.
El diseo orientado a la estructura de datos hace uso de un diagrama jerrquico para
representar la estructura de la informacin. Por tanto, durante el anlisis de requerimientos
del software, el nfasis debe colocarse en estos modos de representacin.
Debe observarse que una tercera escuela de pensamiento, la de los mtodos de diseo
orientados al objeto (DOO), ha merecido una amplia atencin durante los ltimos aos.
DOO representa una tercera alternativa para el diseo de software, cogiendo ciertas ideas
de los mtodos predecesores orientados a estructura y a flujo de datos, aunque aadiendo
muchos conceptos nuevos e importantes.
CONSIDERACIONES SOBRE EL PROCESO DE DISEO
El anlisis de requerimientos del software permanece como la base del diseo orientado a la
estructura de datos. La descripcin del dominio de la informacin (estructura, contenido y
flujo de datos) contenida en la Especificacin de Requerimientos del Software prefigura la
arquitectura del software que ha de desarrollarse durante el diseo. Cada mtodo de diseo
da un Conjunto de reglas que facilitan al diseador la transformacin de la estructura de
datos en una representacin del software.
Cada mtodo orientado a la estructura de datos tiene su propio conjunto de reglas. Sin
embargo, deben realizarse siempre las siguientes tareas de diseo: 1) evaluar las
caractersticas de la estructura de datos; 2) representar los datos en trminos de formas
elementales, tales como secuencia, seleccin y repeticin; 3) transformar la representacin
de la estructura de datos en una jerarqua de control para el software; 4) refinar la jerarqua

Roger S. Presuman
Ingeniera de Software un Enfoque practico
del software usando los criterios definidos como parte de un mtodo, y 5) desarrollar
finalmente una descripcin procedimental del software.
En los mtodos orientados a la estructura de datos no est clara la divisin entre los pasos
de diseo arquitectural y procedimental (se han descrito como parte del proceso del diseo
de software). Jackson, Warnier y Orr van rpidamente hacia la representacin
procedimental.
DESARROLLO DEL SISTEMA DE JACKSON
Como la mayora de las metodologas de diseo de software, el Desarrollo de Sistema de
Jackson (DSJ) es realmente una continuacin de los pasos tcnicos que soportan el anlisis
y diseo de software. Para realizar el DSJ el analista y diseador han de dar los siguientes
pasos:
Paso de las acciones y entidades. Usando un mtodo muy similar a la tcnica de anlisis
orientada al objeto, se identifican las entidades (agentes, objetos u organizaciones que un
sistema necesita para producir o usar la informacin) y acciones (los sucesos que ocurren
en el mundo real que afectan a las entidades).
Paso de estructuracin 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 modelacin 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 temporizacin del sistema. Se establecen y especifican las caractersticas de
planificacin del proceso.
Pacto de implementacin. Se especifica el hardware y software como un diseo.
Los primeros tres pasos del DSJ. En resumen, el paso de las acciones y entidades comienza
con una breve declaracin en lenguaje natural del problema, del que se eligen las entidades
(nombres) y acciones (verbos). Slo las entidades y acciones que tengan una relacin
directa con la solucin software se eligen para una posterior evaluacin.
El paso de estructuracin de entidades crea un diagrama de Jackson, que describe una
especificacin 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 botn en el caso de la Figura
5.1) y se acompaa frecuentemente de un texto explicativo.

Roger S. Presuman
Ingeniera de Software un Enfoque practico

FIGURA 5.1 Diagramas de estructura de Jackson.

El paso de modelacin inicial comienza con la construccin de una especificacin del
sistema como un modelo del mundo real. La especificacin se crea con un diagrama de
especificacin del sistema (DES) usando la simbologa mostrada en la Figura 5.2. Una
conexin mediante datos se presenta cuando un proceso transmite cierta informacin (p. ej.,
registros de escrituras) y otro proceso recibe dicha informacin (p. ej., lee registros). Las
flechas representan la direccin del flujo de informacin y los crculos representan los
datos, los cuales se supone que han de colocarse en un buffer FIFO de capacidad ilimitada.
Una conexin para vector de estado ocurre cuando un proceso inspecciona directamente el
vector de estado de otro proceso. Las flechas representan la direccin del flujo de
informacin y los rombos indican el vector de estado. Esta conexin es frecuente en
aplicaciones de control de proceso en las que es necesario comprobar el estado de algn
dispositivo electromecnico. Por convenio, el sufijo 0 representa un proceso del mundo real
y el sufijo 1 representa un proceso del modelo del sistema.
Pasos del Diseo DSJ
Para discutir los pasos del diseo del Desarrollo de Sistema de Jackson, continuamos con el
ejemplo del Servicio de Trenes de la Universidad (STU). Reproduciendo la declaracin del
problema:
Una gran universidad est dividida en dos campus, los cuales estn 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 estacin de cada campus. Cada estacin tiene un botn de llamada que los
estudiantes pueden usar para solicitar el pasar a la otra estacin. Cuando los estudiantes

Roger S. Presuman
Ingeniera de Software un Enfoque practico
llegan a una estacin, pulsan el botn de llamada. Si el tren est all, suben a l y parten
hacia la otra estacin. Si el tren est andando, deben esperar a que se pare en la otra
estacin, suban los estudiantes (si los hay) y vuelva. Si el tren est en la otra estacin, el
tren la deja y viene a recoger a los estudiantes que han pulsado el botn. El tren esperar en
una estacin hasta que se solicite un servicio (se pulse un botn).

FIGURA 5.2 Natacin DES.

Las entidades se seleccionan examinando todos los nombres de la descripcin. Despus de
la revisin, se eligen las siguientes entidades candidatas: Universidad, campus, estudiantes,
clases, tren, estacin, botn. No estamos directamente interesados en campus, clases,
estudiantes o estacin todas ellas caen fuera de los lmites del modelo y se rechazan
como posibles entidades. Universidad es realmente un trmino colectivo de los dos campus,
por lo que lo rechazamos corno posible entidad. Seleccionamos tren y botn. Usando un
anlisis similar, seleccionamos llegar, pulsar y partir como las acciones que afectan a tren y
botn.
El diagrama de estructura de Jackson para tren y botn se muestra en la Figura 5.1. El
diagrama de especificacin del sistema para STU se ilustra en la Figura 5.3. Finalmente, el
paso de modelacin inicial para UTP se realiza como se describe en la siguiente discusin.
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 botn de llamada
emite un pulso cuando se pulsa. Esto puede transmitirse al proceso botn-1 como una
conexin 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 elctrico. El estado del
conmutador (encendido/apagado) puede ser accedido. Por tanto, se requiere una conexin
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 informacin que los

Roger S. Presuman
Ingeniera de Software un Enfoque practico
diagramas de la estructura (Figura 5.4) secuencia, seleccin, repeticin pero en un
formato textual. El texto estructurado para botn-1 es:

FIGURA 5.3 Un DES para el STU.

FIGURA 5.4 Notacin de los diagramas de estructuras.

Roger S. Presuman
Ingeniera de Software un Enfoque practico

La estructura de BOTON- 1 se corresponde exactamente con la estructura de BOTON-O,

con la adicin 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 conexin 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
estacin. El proceso del sistema debe inspeccionar la entidad del mundo real, lo bastante
frecuentemente, como para asegurar que ninguna accin pueda ocurrir sin ser detectada.
Esto se realiza ejecutando una operacin de obtencin 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 modelacin puede elaborarse, para que muestre estos valores de trnsito de
los vectores de estado. Una descripcin 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
Ingeniera 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 obtencin
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 propsito del paso funcional del DSJ es expandir el diagrama de especificacin del
sistema, mediante la conexin de procesos de funciones, definidas recientemente con los
procesos de modelacin por datos o vectores. DSJ reconoce tres tipos de funciones:
Funciones empotradas. Esta funcin se adquiere asignando (escribir) operaciones a un
texto estructurado del proceso de modelacin.
Funciones impuestas. Esta funcin inspecciona el vector de estado del proceso de
modelacin y produce los resultados de salida.
Funciones interactivas. Esta funcin inspecciona el vector de estado del proceso de
modelacin, 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 informacin 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 estacin,
iluminando un mensaje de visualizacin. Las lmparas se encienden y apagan mediante las
rdenes LON(i) y LOFF(i).

Roger S. Presuman
Ingeniera de Software un Enfoque practico

FIGURA 5.5 a) Diagrama de estructura correspondiente al texto estructurado. b) DES

actualizado.
Debe ponerse una funcin en el modelo del proceso del tren para describir una orden a
LAMP(i) cuando el tren llega a la estacin(i); debe generarse otra orden para apagar
lmpara(i) cuando el tren deja la estacin(i). Por tanto, mientras el tren est entre las
estaciones, enva unos datos que constan de las rdenes a las lmparas. El DES que
representa esta situacin se muestra en la Figura 5.5 b.

Roger S. Presuman
Ingeniera de Software un Enfoque practico
Para implementar las rdenes a las lmparas, 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
Refirindonos al anterior texto estructurado, se enva una orden (LON) para encender la
presentacin del mensaje que anuncia a la estacin 1 en el panel. Esto ocurre al comienzo
de la vida del tren, antes de que deje la estacin 1 por primera vez. Cada vez que los
sensores indican la llegada a una estacin, encendemos la lmpara apropiada y cuando el
tren la deja, la lmpara se apaga (LOFF).
Una segunda funcin es para producir las rdenes del motor, ARRANCAR y PARAR, que
controlarn el movimiento del tren. Estas rdenes se enviarn bajo las siguientes
condiciones:
PARAR cuando los sensores indican la llegada a una estacin.
ARRANCAR cuando se pulsa un botn (la primera vez) para pedir el tren y el tren
est esperando en una de las estaciones.

Roger S. Presuman
Ingeniera de Software un Enfoque practico
La necesidad de enviar la orden PARAR esta nicamente determinada por la llegada del
tren a una estacin. Sin embargo, la orden ARRANCAR depende de los botones y del tren.
Por tanto, introducimos un proceso de funcin llamado mcontrol que acta sobre los datos
recibidos de los procesos TREN- 1 y BOTON y que enva las rdenes ARRANCAR y
PARAR.
La conexin 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 podra ocurrir si el vector
de estado se inspeccionara peridicamente.
El texto estructurado para el proceso tren-l se reproduce una vez ms, esta vez corregido
por el control de la lmpara 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 obtencin 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, planificacin e implementacin se consideran en
los pasos de DSJ que siguen.

Roger S. Presuman
Ingeniera de Software un Enfoque practico
Para completar el ejemplo STU, volvamos al modelo de la entidad botn. El modelo
original, botn-l, es una declaracin precisa de las acciones de botn, pero es ahora
necesario distinguir entre la primera peticin 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 funcin inspecciona el vector de estado de botn-2 para determinar hay una peticin
excepcional de un viaje. La funcin mcontrol informa a cuando se ha servido una peticin,
es decir, cuando el tren ha llegado a estacin en donde se ha hecho la peticin. Hace esto
pasando los registros de llegada recibidos de tren- 1. As se define una funcin interactiva
para el proceso botn-2.
El texto estructurado para botn-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
peticin := s;
read MBD and BiD;

Roger S. Presuman
Ingeniera de Software un Enfoque practico
PULSAR-PET end
PULSAR-PET-EXTRA itr while
read MBD and BiD;
PULSAR-PET-EXTRA end
LLEGADA seq
peticin := no;
read MBD and BiD;
LLEGADA end
GRUPO-PULSAR end
CUERPO-BOTON end
BOTON-2 end
La entrada a botn-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
asncronos. Para este ejemplo, la mezcla desigual es suficiente. Sin embargo, DSJ da otros
tipos de mezclas que podran introducir menos indeterminacin en el sistema [JAC83].
La Figura 5.7 muestra un diagrama de especificacin del sistema que refleja todos los
cambios impuestos como pile del paso funcional. Una funcin empotrada dentro de tren- 1
genera las rdenes de las lmparas y un nuevo proceso de funcin, mcontrol, impone una
funcin interactiva en botn-2 y produce las rdenes del motor para el tren. Las dobles
lneas sobre la salida MBD implica una conexin uno a muchos. La estructura del
proceso mcontrol se deriva examinando las estructuras de datos de entrada y salida.
Paso de temporizacin del sistema
En este paso del DSJ, el diseador especifica las ligaduras de tiempo impuestas en el
sistema. Los primeros pasos de diseo producen un sistema compuesto de procesos
secuenciales que se comunican mediante flujos de datos e inspecciones directas al vector de
estado. La relativa planificacin 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
Ingeniera de Software un Enfoque practico

FIGURA 5.7 DES extendido para las funciones 1 y 2.

Las lneas 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 basndose en la velocidad del
tren y la potencia de frenada.
2. El tiempo de respuesta para la conmutacin de las lmparas del panel.
Para el ejemplo STU, no hay necesidad de introducir un mecanismo especial de
sincronizacin. En algn sentido, el intercambio de datos ha impuesto ya algn grado de
sincronizacin.
Paso de implementacin
El paso de implementacin del DSJ tenda, en los primeros trabajos [JAC75], a la
derivacin del resto del programa o estructura del proceso, a partir de la estructura de datos
del problema. En esta seccin y en la siguiente, se presenta una visin general del enfoque
de diseo de programas de Jackson. Las transformaciones asociadas con este mtodo son la
razn de que esta metodologa se haya categorizado como de orientada a la estructura de
datos.
La esencia del paso de implementacin puede establecerse parafraseando a Jackson: Los
problemas deben descomponerse en estructuras jerrquicas de partes que puedan ser
representadas por tres formas estructurales. Las formas estructurales a que Jackson
alude son la secuencia, condicin y repeticin en realidad, construcciones
procedimentales (en la terminologa de este libro) que son la base de la filosofa de la
programacin estructurada.
La notacin de la estructura de datos es una variacin del diagrama de estructuras de
Jackson y se muestra en la Figura 5.8. Refirindonos a esta figura, una coleccin de datos,

Roger S. Presuman
Ingeniera de Software un Enfoque practico

FIGURA 5.8 Notacin de las estructuras de datos.

A, esta compuesta de mltiples ocurrencias (denotadas por un *) de la subestructura de
datos B. B incluye mltiples 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 representacin
del diagrama de bloques de Jackson de jerarqua de informacin, puede aplicarse a
estructuras de base de datos, de entrada o de salida con igual facilidad.
Como un ejemplo ms concreto de esta notacin, consideremos el software que ha de
desarrollarse para el sistema de contabilidad de tarjetas de crdito (muy simplificado) que
se muestra en la Figura 5.9. Ha de componerse un archivo de pagos, que contiene nmeros
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 estn contenidos dentro de un registro. La estructura de datos para
ambos archivos, descrita en notacin de Jackson, se muestra en la figura.

Roger S. Presuman
Ingeniera de Software un Enfoque practico

FIGURA 5.9 Sistema de facturacin de tarjetas de crdito.