1

EL MODELO AMBIENTAL
La estabilidad del medio interno es una condicin primaria para la libertad e independencia de ciertos
cuerpos vivos en relacin con el ambiente que los rodea.
Claude Bernard, Lecons sur les Phenomenes de la Vie Communs aux Animaux
et aux Vegetaux, 1875-1879.

En este capitulo se aprender:

1. Por qu la frontera del sistema es arbitraria pero crtica
2. Cmo dibujar un diagrama de contexto para un sistema.
3. Cmo usar el diagrama de contexto y la lista de acontecimientos para construir
el modelo ambiental.
Para el analista, la labor ms difcil en la especificacin de un sistema es a menudo
determinar qu es para el sistema y qu no. Cualquier sistema que desarrolle, no importa
lo ambicioso y grandioso, ser parte de un sistema an mayor.
Como vimos en el captulo 2, casi todos los sistemas con los que tenemos experiencia
humana son meramente subsistemas mayores: an si nuestra labor fuera disear el
mundo, tendramos que reconocer que ste es solo para el sistema solar, el cual es parte
de una galaxia pequea y obscura, la cual es parte del universo.
As, el primer modelo importante que se debe desarrollar como analista es uno
que no haga ms que definir las interfaces entre el sistema y el resto del universo, es
decir, el ambiente. Por razones obvias, este modelo se conoce como el modelo
ambiental. Modela el exterior del sistema; el modelo del interior del sistema, conocido
como modelo del comportamiento, se discute en los captulos 20 y 21.
Adems de determinar qu est en el interior del sistema y qu en el exterior (lo
que se logra definiendo la frontera entre sistema y el ambiente), tambin es crticamente
importante definir las interfaces entre el sistema y el ambiente. Se necesita saber qu
informacin entra al sistema desde el ambiente exterior, qu informacin produce como
salida al ambiente externo.
Desde luego, las entradas y salidas no se producen al azar: ningn sistema de
informacin toma todos los datos disponibles en el universo, ni expulsa cosas al azar al
ambiente exterior ningn sistema realista. Los sistemas que construimos son racionales
y tienen propsito; especficamente, producen salidas como respuesta a algn
acontecimiento, o estmulo, en el ambiente. As, otro aspecto crtico del modelo
ambiental consiste en identificar los acontecimientos que ocurren en el ambiente al cual
debe responder el sistema. No para todos los acontecimientos; despus de todo, el
ambiente en su totalidad genera un nmero infinito de acontecimientos. Solo nos
preocupan aquellos que (1) ocurren en el ambiente exterior y (2) requieren una
respuesta del sistema.
Observe que la frontera entre un sistema y su ambiente, como ilustra la Figura
18.1, es arbitraria. Puede haberse creado por algn decreto administrativo, como

2
resultado de alguna negociacin poltica, o simplemente por accidente. Y eso es algo
que el analista de sistemas usualmente tiene oportunidad de influenciar.

Generalmente el usuario tendr una buena idea de la frontera general entre el

sistema y el ambiente. Pero, como ilustra la Figura 18.2, a menudo existe un "rea gris"
que est abierta a negociaciones, es decir, un rea sobre la cual el usuario no est
seguro, (2) no haba pensado, (3) tena algunas ideas preconcebidas est dispuesto a
reflexionar o, (4) todas las anteriores.
Por ejemplo, el usuario podra pedirle al analista desarrollar un sistema de
cuentas por cobrar. Aunque esto pudiera representar una frontera firme y bien definida
entre el sistema (conocido como el sistema C/C) y el ambiente, el analista ciertamente
debiera considerar el "rea gris", como ilustra la Figura 18.3, de cuentas por pagar,
control de inventarios, manejo de efectivo, facturacin y entrada de pedidos como
perspectiva un tanto ms amplia.

Si el analista escoge una perspectiva demasiado pequea para un proyecto est

condenado al fracaso, pues el usuario puede haber identificado sin darse cuenta el
sntoma del problema (por ejemplo, "nuestras cuentas por cobrar estn fuera control")
en lugar de la causa del problema. Y si el analista, por exceso de confianza ingenuidad
o exuberancia, escoge una perspectiva demasiado amplia para el proyecto, est
condenado al fracaso, puesto que estar tratando con una situacin poltica bastante ms
compleja, y estar intentando desarrollar un sistema demasiado grande bajo cualquier
circunstancia. Adems pudiera estar tratando asuntos que no le importan al usuario o
que no se pueden cambiar en lo absoluto. As que es importante dedicar bastante tiempo
y tener suficiente participacin del usuario en la eleccin de una frontera apropiada para
el sistema.
En un sistema grande se puede tomar en cuenta una cantidad de factores cuando
se est escogiendo la perspectiva del proyecto. Entre los ms importantes estn los
siguientes:

El deseo del usuario de lograr una cierta participacin en el mercado para el

producto, o incrementarla a ms de su nivel actual. Esto puede hacerse
ofreciendo un nuevo producto o una mayor funcionalidad de uno existente (por
ejemplo, la mayor funcionalidad que ofrecen los sistemas de cajero automtico y
los sistemas bancarios en lnea). O el usuario podra tratar de aumentar su
mercado ofreciendo un mejor y ms rpido servicio (por ejemplo,"todos nuestros
pedidos se surten en menos de 24 horas, y tenemos un elaborado sistema de
rastreo de pedidos para saber dnde se encuentra en todo momento").

La legislacin establecida por el gobierno federal, estatal o de la ciudad. La

mayor parte de tales sistemas son de informes, por ejemplo, que reportan el
empleo (o desempleo) de trabajadores basndose en edad, sexo, nacionalidad,
etc. O podra tenerse que hacer un nuevo sistema para considerar los cambios en
las leyes sobre impuestos.

Deseo del usuario por minimizar gastos operativos de algn rea de su negocio.
Esto era particularmente comn en las compaas grandes en los aos 60, y
sucede con muchos negocios pequeos que estn instalando su primera
computadora. La mayor parte de las organizaciones que han tenido
computadoras instaladas durante 10 aos o ms ya aprovecharon las
oportunidades obvias de reducir el personal de oficina.

Deseo del usuario por lograr alguna ventaja estratgica para la lnea de
productos o rea de negocios que opera. El usuario intenta hacerlo organizando
y manejando informacin sobre el mercado para poder producir artculos de
manera ms oportuna y econmica. Un buen ejemplo de esto son las lneas
areas (al igual que muchas otras industrias recientemente desreglamentadas)
donde mejor informacin acerca de tendencias del mercado y preferencias de los
clientes pueden llevar a costos de pasajes e itinerarios de aerolneas ms
eficientes.

El rea dentro de la frontera del sistema a veces se conoce como el dominio de

cambios. Por esto, simplemente queremos decir que todo lo que est dentro de la
frontera del sistema est sujeto a cambios (por ejemplo, reorganizacin y/o automatizacin), mientras que todo lo que est fuera se queda en su forma actual y no es
investigado por el analista.
Para ver dos ejemplos de fronteras de sistemas, examine los casos de estudio de
los apndices F y G. En el caso del Sistema de Informacin de YOURDON Press
(Apndice F), la frontera es un tanto mayor de lo que se esperara: incluye la facturacin
y el manejo de recibos que normalmente son parte del departamento de contabilidad (y
por tanto estaran fuera de la frontera); de manera similar, el controlador del elevador
del Apndice G tiene una frontera un tanto menor que lo deseable: se hubiera
desarrollado un sistema muy distinto si los paneles de control del elevador se
consideraran parte del ambiente. En ambos casos, las elecciones fueron arbitrarias.
18.1

HERRAMIENTAS USADAS PARA DEFINIR EL AMBIENTE

El modelo del ambiente consta de tres componentes:
1.
2.
3.

Declaracin de propsitos
Diagrama de contexto
Lista de acontecimientos

Cada uno se discute a continuacin.

18.1.1

La declaracin de propsitos

El primer componente del modelo ambiental es una declaracin textual breve y

concisa del propsito del sistema, dirigida al nivel administrativo superior, la administracin de los usuarios, y otros que no estn directamente involucrados con el desarrollo del sistema.
El siguiente es un ejemplo de una declaracin de propsitos tpica:

El propsito del Sistema de Procesamiento de Libros Ajax es manejar todos los

detalles de los pedidos de libros de los clientes, adems del envo, facturacin y cobro
retroactivo a clientes con facturas vencidas. La informacin acerca de los pedidos de
libros debe estar disponible para otros sistemas, tales como mercadeo, ventas y
contabilidad.
La declaracin de propsitos puede constar de una, dos o varias frases. Sin
embargo, jams debe llegar a ms de un prrafo, ya que la intencin no es proporcionar
una descripcin completa y detallada del sistema. Tal esfuerzo ira en contra del
objetivo: el propsito del resto del modelo ambiental y del modelo de comportamiento
es dar todos los detalles.
Como resultado, la declaracin de propsitos ser deliberadamente vaga en
cuanto a muchos detalles. En el ejemplo anterior se podran hacer preguntas como:

Exactamente qu tipo de informacin proporciona a contabilidad, ventas y

mercadeo el sistema de pedidos de libros?

Cmo determina el sistema de pedido de libros si un cliente tiene crdito? Lo

determina el sistema mismo o por medio del departamento de contabilidad?

Cmo se entera el sistema sobre nuevos libros que se han publicado y estn
disponibles para la venta?

Estas preguntas detalladas slo pueden responderse viendo el modelo de

comportamiento que se discute en los Captulos 19 y 20.
Aunque el documento de declaracin de propsitos no responde las preguntas
detalladas sobre el comportamiento, generalmente basta con responder a una serie de
preguntas de alto nivel:

Es responsable el sistema de pedido de libros de las actividades de nmina?

No; prcticamente cualquiera que lea lo anterior estar de acuerdo en que la
nmina queda fuera de la perspectiva del sistema y probablemente est incluida
en el sistema de contabilidad.

Es responsable el sistema de pedido de libros de enviar facturas a los clientes

que piden libros? S; la declaracin de propsitos as lo afirma, Podra
imaginarse esto como lema de debate entre el departamento de pedidos de libros
y el de contabilidad. Por ello es apropiado que se mencione en la declaracin
de propsitos.

Es responsable el sistema de pedido de libros del control de inventarios, es

decir, de determinar cundo volver a surtir libros que estn a punto de acabarse?
No. La declaracin de propsitos no hace tal afirmacin. Es muy probable que
el control de inventarios sea uno de muchos otros sistemas (o departamentos)
que usen la informacin sobre pedido de libros que produce el sistema de
pedido.

6
Muchos analistas sienten tambin que la declaracin de propsitos debe resumir
los beneficios tangibles y cuantificables que se logren con el nuevo sistema; por
ejemplo, "el propsito del sistema es reducir el tiempo que se requiere para procesar un
pedido, de tres das a uno". Aunque esto puede ser muy til en proyectos pequeos y
muy definidos, no es fcil de lograr en proyectos ms grandes. En su suele requerirse un
anlisis de costo-beneficio.
18.1.2

El diagrama de contexto

La siguiente parte del modelo ambiental empieza a contestar algunas de las

preguntas que surgen a raz de la declaracin de propsitos. El diagrama de contexto es
un caso especial del diagrama de flujo de datos, en donde una sola burbuja presenta todo
el sistema. La Figura 18.4 muestra un diagrama de contexto de sistema de pedido de
libros. En los apndices F y G se proporcionan ejemplos de diagramas de contexto
para dos sistemas reales.

El diagrama de contexto enfatiza varias caractersticas importantes del sistema

Las personas, organizaciones y sistemas con los que se comunica el sistema. Se

conocen como terminadores.

Los datos que el sistema recibe del mundo exterior y que deben procesarse de
alguna forma.

Los datos que el sistema produce y que se envan al mundo exterior.

Los almacenes de datos que el sistema comparte con los terminadores. Estos
almacenes de datos se crean fuera del sistema para su uso, o bien son creados en
l y usados fuera.

La frontera entre el sistema y el resto del mundo.

Las tcnicas para la construccin del diagrama de contexto se discuten en la

Seccin 18.2.

7
18.1.3

La Lista de acontecimientos

La lista de acontecimientos es una lista narrativa de los "estmulos" que ocurren

en el mundo exterior a los cuales el sistema debe responder. En la Figura 18.5 se
muestra una lista de acontecimientos para el sistema de pedido de libros.
1.
2.
3.
4.

Un cliente hace un pedido. (F)

Un cliente cancela un pedido. (F)
La administracin pide un reporte de ventas. (T)
Llega un pedido de reimpresin de un libro a la bodega. (C)
Figura 18.5: Lista de acontecimientos

Observe que cada acontecimiento se etiqueta como F, T o C. Con ello se muestra si

es de tipo de flujo, temporal, o de control. El orientado a flujo es el que se asocia con un
flujo de datos, es decir, el sistema se da cuenta que ha ocurrido el acontecimiento
cuando llega algn dato (o posiblemente varios). Como podr imaginarse, esto
corresponder al flujo de datos en el diagrama de contexto.
Sin embargo, no todos los flujos de datos del diagrama de contexto
necesariamente son acontecimientos de tipo flujo. Considere, por ejemplo, el diagrama
de contexto parcial que se muestra en la figura 18.6.

A primera vista, uno pudiera verse tentado a concluir que los flujos de datos A, B
y C son todos indicadores de acontecimientos separados y discretos. Sin embargo,
pudiera resultar que slo el flujo de datos A est asociado con un acontecimiento (por
ejemplo, al flujo de datos lo inicia el terminador). Para procesar un acontecimiento el
sistema explcitamente podra pedir entradas a otros terminadores a lo largo de los flujos
de datos B y C para obtener alguna respuesta.
As que no necesariamente existe una correspondencia uno a uno entre los flujos
de datos del diagrama de contexto y los acontecimientos de la lista de acontecimientos.
En general, cada flujo de datos es un acontecimiento (o, mas precisamente, la indicacin

8
de que ha ocurrido), o bien es requerido por el sistema para poder procesar un
acontecimiento.
Adems de los acontecimientos de tipo flujo, un sistema puede tambin tener
acontecimientos temporales. Como su nombre implica, los acontecimientos temporales
arrancan con la llegada de un momento dado en el tiempo. Algunos ejemplos de
acontecimientos temporales pudieran ser:

A las 9:00 de la maana se requiere un reporte diario de todos los pedidos de

libros.
Las facturas deben generarse a las 3:00 PM.
Se deben generar reportes administrativos una vez por hora.

Observe que los acontecimientos temporales no se inician con flujos de datos de

entrada; podra imaginarse que el sistema tiene un reloj interno con el cual puede
determinar el paso del tiempo. Sin embargo, tenga en mente tambin que a un
acontecimiento temporal podra requerir que el sistema solicite entradas de uno o mas
terminadores. Por ello, podran asociarse uno o mas flujos de datos con un
acontecimiento temporal, aunque los flujos de datos, en si, no representan el
acontecimiento mismo.
Los acontecimientos de control deben considerarse un caso especial del
acontecimiento temporal: un estimulo externo que ocurre en algn momento
impredecible. A diferencia de un acontecimiento temporal normal, el acontecimiento de
control no se asocia con el paso regular del tiempo, por lo que el sistema no puede
anticiparlo utilizando un reloj interno. Y a diferencia de un acontecimiento de flujo
normal, el control no indica su presencia con el arribo de datos. Como lo muestra la
figura 18.7, un acontecimiento de control se asocia con un flujo de control en el
diagrama de contexto.

El flujo de control puede considerarse como un flujo de datos binario: est

encendido o apagado, y puede cambiar de un estado a otro en cualquier momento,
sealando as al sistema que se necesita tomar alguna accin inmediata. Los sistemas de
informacin de negocios no suelen tener flujo de control en sus diagramas de contexto;
el Sistema de Informacin de YOURDON Press que se describe en el Apndice F, por
ejemplo, no tiene. Pero los flujos de control son bastante comunes en los sistemas de

9
tiempo real; por ejemplo vea el diagrama de contexto del sistema de control de elevador
en el Apndice G.
18.1.4

Componentes adicionales del modelo ambiental

En la mayor parte de los proyectos, la lista de acontecimientos, el diagrama de

contexto y la declaracin de propsitos bastan. Sin embargo, pueden ser tiles dos
componentes adicionales, dependiendo de la naturaleza y complejidad del sistema:

El diccionario de datos inicial, que define todos los flujos y almacenes externos
El modelo entidad-relacin de los almacenes externos

Incluso un sistema mediano comnmente tendr unas cuantas docenas de flujos de

datos de entrada y salida; un sistema grande pudiera tener literalmente cientos. Aunque
estos flujos de datos finalmente se definirn con gran detalle en el modelo de
comportamiento (que se discute en el Capitulo 20), podra ser til comenzar la
construccin del diccionario de datos ahora. Esto puede ser importante si las interfaces
entre el sistema y los diversos terminadores estn sujetas a cambios y a negociacin;
entre mas pronto se comience a definir formalmente estas interfaces (definiendo la
composicin y significado de los almacenes), mas pronto se podrn finalizar.
De manera similar, se puede construir un diagrama de entidad-relacin de los
almacenes externos (si hay). Esto puede ayudar a dejar al descubierto las relaciones
entre almacenes que de otra manera no seran evidentes hasta que se desarrollara el
modelo de comportamiento. Al concentrarse en estas relaciones en esta fase temprana se
tiene forma de volver a verificar las interacciones entre los terminadores (que
tpicamente incluyen a los usuarios finales del sistema) y el sistema mismo.
18.2

CONSTRUCCIN DEL MODELO AMBIENTAL

La discusin anterior probablemente hace que el modelo ambiental parezca

simple y directo: despus de todo, existe slo un proceso, unos cuantos flujos de datos y
terminadores, una descripcin narrativa breve del propsito del sistema y una lista de
acontecimientos. A pesar de esto, a menudo resulta que el modelo ambiental requiere de
una gran cantidad de trabajo; adems, usualmente se desarrolla como una serie de
refinamientos iterativos, con datos adicionales que se aaden y refinan.
Una razn importante por la cual muchos refinamientos y revisiones suelen ser
necesarios es que normalmente una sola persona no puede comprender la perspectiva
completa del sistema como se defini inicialmente. Si el proyecto involucra un nuevo
sistema que reemplazar a uno existente, es posible hablar con los usuarios que
actualmente llevan a cabo sus funciones. En cierto sentido, tienen la perspectiva de
quienes desde dentro ven las cosas hacia afuera, como ilustra la Figura 18.8. Sin
embargo, incluso en este caso, los diversos usuarios individuales internos generalmente
slo estn familiarizados con una porcin, y sus diversas opciones a veces entran en
conflicto. Peor an, las entrevistas iniciales con la comunidad usuaria tal vez omitan
uno o ms usuarios importantes cuyas interacciones con los terminadores externos se
deben modelar.1

10

1 Tales usuarios pudieran no ser importantes en trminos de jerarqua organizacional; pueden con siderarse como
humildes oficinistas, secretarias o administradores. No obstante, las funciones que gatean pudieran ser vitales, y ser crucial modelar
con precisin las entradas que reciben del mundo exterior y las salidas que mandan. La razn de que el analista de sistemas a
menudo olvide hablarle a estas personas es muy sencilla: un usuario de nivel superior (es decir, el jefe) le dir al analista con quin
hablar. "No moleste a mi gente, le dir, "estn todos muy ocupados, por eso requerimos el nuevo sistema. Yo le dir todo lo que
necesita saber sobre el sistema. Como se discuti en el Captulo 3, tal vez no haya forma diplomtica de evitar esto, pero es crucial
revisar el modelo ambiental con cuidado para asegurar que no falta nada.

Es importante dedicar una buena cantidad de tiempo y energa al modelo ambiental, pues a menudo es el punto focal de juntas y presentaciones importantes al
comienzo de la vida de un proyecto de desarrollo de sistemas. De hecho, a veces es la
nica parte del modelo global del sistema que muchos usuarios y administradores de
alto nivel llegarn a ver (los nicos con el dinero necesario para continuar financiando
el proyecto, y con el poder para cancelarlo). Despus de construido y aprobado lo ver
en los pizarrones de avisos, as que es importante que est correcto.
18.2.1

Construccin del diagrama de contexto

El diagrama de contexto, como hemos visto, consiste en terminadores, flujos de

datos y flujos de control, almacenes de datos y un solo proceso que representa a todo el
sistema. Se analizan uno por uno a continuacin.
La parte ms fcil del diagrama de contexto es el proceso; como hemos visto,
consiste en una sola burbuja. El nombre dentro del proceso suele ser el nombre del
sistema completo o un acrnimo convenido. En las Figuras 18.9(a) y (b) se muestran
ejemplos.

11

Los terminadores, como hemos visto, se representan con rectngulos en el

diagrama de contexto. Se comunican directamente con el sistema a travs de flujos de
datos o de control, como muestra la Figura 18.10(a), o a travs de almacenes externos,
como se muestra en la Figura 18.10(b).

Observe que los terminadores no se comunican directamente entre s, por lo cual

el diagrama de contexto de la Figura 18.11 no es correcto. En realidad, los terminadores

12
s se comunican entre s pero, dado que por definicin son externos al sistema, la
naturaleza y contenido de las interacciones terminador-terminador son irrelevantes para
el sistema. Si durante la discusin con los usuarios encuentra que es esencial saber
cundo, por qu o cmo se comunican entre s, entonces los terminadores son parte del
sistema, y deben incluirse dentro de la burbuja de proceso del diagrama de contexto.

2 Este es un escenario poco probable para un proyecto de desarrollo de sistemas tpico, pero se ms y ms a medida que
se usan los diagramas de flujo de datos y las otras herramientas descritas en este libro para construir modelos de empresa. Esto se
puede hacer sin pretender computarizar toda la empresa, simplemente para entender lo que ya existe, sobre todo los datos que la
organizacin requiere para llevar cabo su propsito. El tema de modelos de empresa se discute en Information Engineering for the
Practitioner, de William Inmon (Englewood Clifts, N.J.: Prentice-Hall, 1987), as como en Strategio Data Base Modeling, de James
Martin (Englewood Cliffs, N.J.:Prentice-Hall, 1985).

13
Tres aclaraciones ms acerca de los terminadores:
1. Algunos terminadores tienen un buen nmero de entradas y salidas. Para
evitar un diagrama innecesariamente atiborrado conviene dibujar el terminador ms de
una vez, como muestra la Figura 18.12(a). Note que los terminadores duplicados se
marcan con un asterisco; otra posibilidad es representar los terminadores repetidos con
una diagonal, como muestra la Figura 18. 12(b).
2. Cuando el terminador es una persona individual, generalmente es preferible
indicar el rol que desempea, ms que su identidad; as, la Figura 18.13(a) se prefiere a
la Figura 18.13(b). Hay dos razones para ello: primero, la persona que desempea el
papel puede cambiar con el tiempo, y es deseable que el diagrama de contexto
permanezca estable y preciso incluso si hay cambios de personal. Segundo, una misma
persona puede desempear varios papeles distintos en el sistema; en lugar de mostrar un
terminador etiquetado "Juan Prez" con varios flujos de entrada y salida no
relacionados, es ms significativo mostrar los diversos papeles que Juan Prez
desempea, cada uno como terminador separado.
3. Dado que estamos interesados principalmente en desarrollar un modelo
esencial del sistema, es importante distinguir entre fuentes y manejadores cuando se
dibujan termidores en el diagrama de contexto. Un manejador es un mecanismo,
dispositivo, o medio fsico usado para transportar datos hacia dentro o fuera del sistema.
Dado que a menudo dichos manejadores son familiares y visibles para los usuarios de la
implantacin actual de un sistema, existe la tendencia a mostrar al manejador, en lugar
de la verdadera fuente de los datos. Sin embargo, puesto que el nuevo sistema
generalmente tendr opcin de cambiar la tecnologa mediante la cual los datos se
introducen y sacan del sistema, el manejador no debe mostrarse. As, el diagrama de
contexto de la Figura 18.14(a) se prefiere al que se muestra en la Figura 18.14(b).

Figura 18.12(a):Terminadores duplicados en el diagrama de contexto

14
Como compromiso, sobre todo si el usuario insiste, se puede etiquetar un terminador para mostrar tanto la fuente verdadera como al manejador que introduce o saca
los datos del sistema; esto se ilustra en la Figura 18.14(c).
Los flujos que aparecen en el diagrama de contexto modelan datos que entran y
salen del sistema, adems de las seales de control que recibe o genera. Los flujos de
datos se incluyen en el diagrama de contexto si se ocupan para detectar un
acontecimiento en el ambiente al que deba responder el sistema, o si se ocupan (como
datos) para producir una respuesta. Los flujos de datos tambin pueden aparecer en el
diagrama de contexto para ilustrar datos que estn siendo transportados entre
terminadores por el sistema. Finalmente, los flujos de datos se muestran en el diagrama
de contexto cuando el sistema produce datos para responder a un acontecimiento.
Como ya se ha hecho notar, el diagrama de contexto de un modelo esencial evita
(hasta donde sea posible) mostrar los manejadores cercanos a la implantacin que
introducen y sacan datos de un sistema. Ms an, no se desea mostrar los mensajes y
medios especficos de coordinacin que el sistema y los terminadores pasan entre s
para indicar que estn listos para las entradas o salidas. Se desea evitar diagramas de
contexto como el de la Figura 18.15(a) pues incluye suposiciones sobre la implantacin
que pueden cambiar drsticamente cuando se construye el nuevo sistema.

Figura 18.12(b): Forma alternativa de mostrar terminadores duplicados

15

16

17

En lugar de eso, debe dibujarse el diagrama de contexto bajo el supuesto de que las
entradas son causadas e iniciadas por los terminadores, y que las salidas son causadas e
iniciadas por el sistema. Al evitar mensajes extraos y entradas salidas orientadas a la
implantacin, se modela slo el flujo neto de datos.
Sin embargo, habr ocasiones en las que un terminador no inicie las entradas pues, aun
con tecnologa perfecta, el terminador no sabe que el sistema requiere sus entradas.
Similarmente, hay ocasiones en las que el sistema no inicia la generacin de salidas,
debido a que no sabe que el terminador las necesita o desea, ambos casos, el mensaje es
una parte esencial del sistema, y debe mostrarse en el diagrama de contexto; la Figura
18.15(b) tiene un ejemplo. A veces resulta conveniente mostrar el mensaje y el
correspondiente flujo de entrada o salida con un flujo de dilogo (una flecha de dos
cabezas), como muestra la Figura 18.15(c).3
18.2.2

Construccin de la lista de acontecimientos

La lista de acontecimientos, como se vio, es un listado textual sencillo de los

acontecimientos del ambiente a los cuales debe responder el sistema. Al crear lista de
acontecimientos se debe asegurar de distinguir entre un acontecimiento flujo
relacionado con un acontecimiento. Por ejemplo, lo siguiente probablemente no sea un
acontecimiento:

18

3 No es necesario usar un flujo de dilogo, pero s vuelve ms legible al diagrama de contexto al empaquetar las entradas y salidas
asociadas para hacerlas visibles de inmediato al lector. Adems, utilizar una flecha para mostrar el dilogo, en lugar de dos
separadas, logra un diagrama de contexto menos atiborrado. Esto es importante en los grandes sistemas, donde pudiera haber
incluso cien o ms diferentes interacciones con terminadores externos.

"El sistema recibe el pedido del cliente".

Ms bien, probablemente sea el flujo de datos de entrada mediante el cual el sistema se
da cuenta de que ha ocurrido el acontecimiento. Un nombre ms apropiado para el
acontecimiento sera:
"El cliente hace un pedido".

19
Esto pudiera parecer un ejercicio de semntica, pero no lo es. Si describimos el
acontecimiento desde el punto de vista del sistema (por ejemplo, desde dentro, viendo
hacia fuera), se podran identificar errneamente los flujos entrantes que no son
acontecimientos por s mismos, pero que se requieren para poder procesar algn otro
acontecimiento. Por ello, siempre se trata de describir los acontecimientos desde el
punto de vista del ambiente (es decir, desde fuera, viendo hacia dentro).
En la mayor parte de los casos, la manera ms fcil de identificar los acontecimientos
mientes relevantes para un sistema es visualizarlo en accin: examinar cada terminador
y preguntar qu efecto pueden tener sus acciones sobre el sistema. Esto usualmente se
hace en conjunto con los usuarios del sistema desempeando el papel de terminadores.
Sin embargo, debe distinguirse cuidadosamente entre acontecimientos discretos que se
han "empaquetado" accidentalmente como si fuera uno solo; esto sucede a menudo con
acontecimientos de tipo flujo. Debe examinarse el acontecimiento candidato y preguntar
si todas sus instancias involucran los mismos datos; si en algunas instancias estn
presentes los datos, y ausentes en otras, podra en realidad haber dos acontecimientos
distintos. Por ejemplo, si se ve de cerca el acontecimiento "el cliente hace un pedido", se
encontrara que algunas instan incluyen el dato "identificacin del vendedor" y otros no;
y podra encontrarse que la respuesta del sistema es diferente cuando participa un
vendedor que cuando no. Por ello, podra ser ms apropiado tener dos acontecimientos
separados: "el cliente hace un pedido" y "l vendedor tramita el pedido del cliente".
Adems, tenga en mente que la lista de acontecimientos debe incluir no slo las
interacciones normales entre el sistema y sus terminadores sino tambin situaciones de
falla. Dado que se est creando un modelo esencial, no hay que preocuparse por fallas
del sistema; pero se deben tomar en cuenta posibles fallas o errores causadas por los
terminadores. Como sealan Paul Ward y Stephen Mellor en Structured Development
for Real-Time Systems (Nueva York: YOURDON Press, 1985).
Puesto que los terminadores estn por definicin fuera de las fronteras del intento de construccin de
sistema representado por el modelo, los realizadores no pueden modificar la tecnologa de los
terminadores para mejorar su confiabilidad. En lugar de ello, deben construir respuestas para los
problemas de los terminadores en el modelo esencial del sistema. Un enfoque til para modelar respuestas
a los problemas de terminado es construir una lista de acontecimientos "normales" y luego preguntar, para
cada acontecimiento, "Necesita el sistema responder si este acontecimiento deja de ocurrir como se
espera?"

Por ejemplo, nuestra lista de acontecimientos para el Sistema de Pedido de Libros Ajax
(Figura 18.5) inclua un acontecimiento llamado "el pedido de reimpresin de libro llega
a la bodega". Pero qu tal si no llega a tiempo (por ejemplo, una semana despus de la
fecha prometida por el impresor)? Qu debera hacer el sistema? Probablemente se
necesitara un acontecimiento adicional iniciado por el sistema para hacer que se
comunique con el impresor y localice el origen del retraso.
18.2.3

Qu se hace primero, el diagrama de contexto o la lista de

acontecimientos?

Puede empezarse con la lista de acontecimientos o con el diagrama de contexto. En

realidad no importa mientras finalmente se produzcan ambos componentes del modelo
ambiental y se revisen para asegurar que sean consistentes.

20
Podra encontrarse tambin hablando con personas enteradas de todo lo que entra y
sale del sistema; algunos usuarios pueden proporcionar esta informacin, o a la vez los
programadores encargados del mantenimiento de la versin actual del sistema puedan
saber algo al respecto. Esto ofrecer las piezas del diagrama de contexto como punto de
partida. Pueden discutirse entonces las transacciones que los usuarios mandan al sistema
y la respuesta que esperan que d. Con ello se puede crear una lista de acontecimientos
a partir del diagrama de contexto.
Sin embargo, podra haber una situacin en la que el diagrama de contexto no est
disponible. Esto es muy comn, sobre todo al comienzo de algunos proyectos de
desarrollo de sistemas: tal vez no sea fcil identificar los terminadores de los diversos
flujos que entran y salen del sistema. En este caso suele ser ms prctico empezar con
un DER que muestre los objetos y relaciones. Los acontecimientos candidatos pueden
encontrarse a continuacin buscando las actividades u operaciones que ocasionan que se
creen o eliminen relaciones. La creacin de la lista de acontecimientos puede llevar
entonces al desarrollo del diagrama de contexto; esto se lustra en la Figura 18.16.
Por ejemplo, suponga que se han identificado los objetos CLIENTE y LIBRO en un
sistema de publicaciones; el usuario podra tambin decir que existe una relacin
"pedidos" entre CLIENTE y LIBRO. Un acontecimiento probable, entonces, sera una
accin que crea una instancia de la relacin pedidos; otro acontecimiento sera una
accin que elimine una instancia de una relacin. Esto llevara a identificar El cliente
pide un libro" y "El cliente cancela su pedido del libro" como acontecimientos en la lista
de acontecimientos. No hace falta mucha investigacin para darse cuenta de que
"cliente" es un terminador para el sistema (mientras que "libro" no lo es); se podra
entonces comenzar por dibujar el diagrama de contexto.
Cuando se termine con ambos componentes del modelo ambiental ser posible
confirmar lo siguiente:
El sistema necesita cada flujo de entrada del diagrama de contexto para reconocer que
ha ocurrido un acontecimiento; debe necesitarlo para producir una respuesta a un
acontecimiento, o ambas cosas.
Cada flujo de salida debe ser respuesta a un acontecimiento.
Cada acontecimiento no temporal de la lista de acontecimientos debe tener entradas a
partir de las cuales el sistema pueda detectarlo.
Cada acontecimiento debe producir salidas inmediatas como respuesta bien almacenar
los datos que luego sern salidas (como respuesta o te de una respuesta a algn otro
acontecimiento), o debiera ocasionar un cambio en el estado del sistema (como indica el
diagrama de transicin de estados).

21

18.3

RESUMEN

La construccin de un modelo ambiental es lo primero y ms importante en la

construccin de un modelo completo de los requerimientos del usuario para un nuevo
sistema. Hasta aqu parecera una tarea fcil; despus de todo, el diagrama de contexto
consiste slo en una sola burbuja, y la lista de acontecimientos parece una simple lista
de transacciones. Pero en un proyecto grande esto puede involucrar una gran cantidad
de trabajo: la burbuja nica del diagrama de contexto puede interactuar con docenas
de terminadores externos y tener ms de cien flujos de datos de entrada y salida. La
lista de acontecimientos constituye un gran esfuerzo en los grandes sistemas; puede
haber fcilmente cerca de cien acontecimientos que el sistema tiene que manejar, y
todos necesitan ser identificados. Adems, puede ser difcil encontrar una declaracin
sencilla de por qu debe existir el sistema.
Una vez construido el modelo ambiental debe ser revisado cuidadosamente por todos
los representantes clave de los usuarios, adems del equipo del proyecto. Entonces se
estar preparado para comenzar a construir el modelo del comportamiento, es decir, el
modelo del interior del sistema. Esto se discute en los Captulos 19 y 20.

22

PREGUNTAS Y EJERCICIOS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.

Cules son las tres cosas que define el modelo esencial?

Qu tipo de acontecimientos debe modelar el modelo esencial?
Cmo determina el analista la frontera entre el sistema y el ambiente?
Cul es la consecuencia probable de que el analista escoja un alcance demasiado
pequeo para el proyecto?
Cul es la consecuencia probable de que el analista escoja un alcance demasiado
amplio para el proyecto?
Qu factores deben tomarse en cuenta cuando se escoge el alcance de un
Proyecto?
Cmo afecta al alcance del proyecto el deseo del usuario de obtener una mayor
participacin en el mercado?
Cmo afecta al alcance del proyecto la legislacin impuesta por los diversos
cuerpos gubernamentales?
Cmo afecta al alcance del proyecto el deseo del usuario de minimizar (o
reducir) sus gastos operativos?
Cmo afecta al alcance del proyecto el deseo del usuario de obtener ventajas
estratgicas sobre la competencia?
Proyecto de investigacin: Sobre un proyecto de su propia organizacin, qu
factor cree que afecte ms en la eleccin del alcance? Cree que el usuario, el
analista y el equipo del proyecto estn conscientes y de acuerdo con ello?
En general, cules cree que sean los posibles factores clave para los sistemas
que se desarrollen en los aos 90? Por ejemplo, ser ms importante minimizar
los gastos operativos que los cambios causados por la legislacin gubernamental?
Cules son los tres principales componentes del modelo ambiental?
Aproximadamente de qu longitud debe ser un documento de declaracin de
propsitos?
Cules cinco caractersticas de un sistema muestra un diagrama de contexto?
Cules son los componentes de un diagrama de contexto?
Qu es una lista de acontecimientos?
Cules son los tres tipos de acontecimientos que debe modelar un diagrama de
contexto?
Qu relacin hay entre flujos y acontecimientos en el diagrama de contexto?
Qu es un acontecimiento temporal?
Qu componentes adicionales pueden encontrarse en un modelo ambiental
adems del diagrama de contexto, la lista de acontecimientos y la declarador de
propsitos?
Por qu suele ser necesario hacer muchas revisiones y refinamientos del modelo
ambiental?
Por qu es importante asegurar que el modelo ambiental est correcto?
Qu tipo de nombre debiera ponerse dentro de una burbuja en un de contexto?
Qu es un modelo de empresa?
Cmo se comunican los terminadores con el sistema?
Se comunican los terminadores entre s en un modelo de sistema? Por qu?
Bajo qu condiciones se dibujara un terminador ms de una vez en un diagrama
de contexto? Cmo se mostrara?
Si el terminador es un individuo, cmo se mostrara en el diagrama de contexto?

23
30. Cmo puede estar seguro el analista de que ha identificado todos los
terminadores en el diagrama de contexto?
31. Qu es un manejador? Qu diferencia hay entre una fuente y un manejador?
32. Por qu deberan las fuentes, y no tanto los manejadores, aparecer en un
diagrama de contexto?
33. Qu debe hacer el analista si el usuario insiste en mostrar los manejadores en un
diagrama de contexto?
34. Bajo qu condiciones se muestran los flujos en un DFD?
35. Por qu en general no deben mostrarse los mensajes y la sincronizacin en un
diagrama de contexto?
36. Qu significa el trmino flujo neto de datos?
37. Bajo qu condiciones no inicia las entradas un terminador en un sistema?
38. Bajo qu condiciones el sistema no inicia las salidas al terminador?
39. Qu debe desarrollarse primero, el diagrama de contexto o la lista de acontecimientos? Por qu?
40. Cules son las cuatro cosas que deben revisarse para asegurar que el modelo
ambiental es correcto?
41. Qu tiene mal el siguiente diagrama de contexto?

42. Qu tiene mal el diagrama de contexto siguiente?

43. Qu tiene mal el diagrama de contexto siguiente?

44. Qu tiene mal el diagrama de contexto siguiente?

24
LISTA DE ACONTECIMIENTOS
1. El cliente necesita una "a"
2. El vendedor necesita la factura
3. El vendedor hace un envo
4. El cliente hace un pedido