4€¦ · Web viewLa estabilidad del medio interno es una condición ... de trabajadores...

Instituto Profesional La AraucanaIngeniería Computación e Informática (Int)

Apuntes de Ingeniería de Sistemas: X parteCapitulo 18EL MODELO AMBIENTAL

La estabilidad del medio interno es una condición primaria para la libertad e independencia de ciertos cuerpos vivos en relación con el ambiente que los rodea.

Claude Bernard, Lecons sur les Phenomenes de la Vie Communs auxAnimaux et aux Vegetaux, 1875 - 1879

Para el analista, la labor más difícil en la especificación de un sistema es a menudo determinar qué es parte del sistema y que nó. Cualquier sistema que desarrolle, no importa lo ambicioso ni grandioso, será parte de un sistema aún mayor. Como vimos en el Capítulo 2, casi todos los sistemas con los que tenemos experiencia humana son meramente subsistemas de sistemas mayores: aun si uestra labor fuera “diseñar el mundo”, tendríamos que reconocer que éste es sólo parte del sistema solar, el cual es parte de una galaxia pequeña y obscura, la cual es parte del universo.

Así, el primer modelo importante que se debe desarrollar como analista es uno que no haga más 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 Capítulos 20 y 21.

Además de determinar qué está en el interior del sistema y qué en el exterior (lo que se logra definiendo la frontera entre el sistema y el ambiente), también es críticamente importante definir las interfaces entre el sistema y el ambiente. Se necesita saber qué información entra al sistema desde el ambiente exterior, y qué información produce como salida al ambiente externo.

Desde luego, las entradas y salidas no se producen al azar: ningún sistema de información toma todos los datos disponibles del universo, ni expulsa cosas al azar al ambiente exterior, ningún sistema realista. Los sistemas que construimos son racionales y tienen propósito; específicamente, producen salidas como respuesta a algún acontecimiento, o estímulo, en el ambiente. Así, otro aspecto crítico del modelo ambiental consiste en identificar los acontecimientos que ocurren en el ambiente al cual debe responder el sistema. No para todos los acontecimientos; después de todo, el ambiente en su totalidad genera un número infinito de acontecimientos. Sólo nos preocupan aquellos que (1) ocurren en el ambiente exterior y (2) requieren una respuesta del sistema.

Figura 18.1: La frontera entre el sistema y el ambiente

Observe que la frontera entre un sistema y su ambiente, como ilustra la Figura 18.1, es arbitraria. Puede haberse creado por algún decreto administrativo, como resultado de alguna negociación politica, 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 (1) no está seguro, (2) no había pensado, (3) tenía algunas ideas preconcebidas que está dispuesto a reflexionar o, (4) todas las anteriores.

Por ejemplo, el usuario podría 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

Ingeniería de Sistemas y Modelo de Datos – Sergio Merino M. 1


Apuntes de Ingeniería de Sistemas: X parteambiente, el analista ciertamente debiera considerar el “área gris”, como ilustra la Figura 18.3, de cuentas por pagar, control de inventarios, manejo de efectivo, facturación y entrada de pedidos como perspectiva un tanto más amplia.

Figura 18.2: El área gris entre el sistema y el ambiente

Si el analista escoge una perspectiva demasiado pequeña para un proyecto está condenado al fracaso, pues el usuario puede haber identificado sin darse cuenta el síntoma del problema (por ejemplo, “nuestras cuentas por cobrar están fuera de control”) e 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 situación política bastante más compleja, y estará intentando desarrollar un sistema demasiado grande bajo cualquier circunstancia. Además, pudiera estar tratando asuntos que no le imprtan al usuario o que no se pueden cambiar en los absoluto. Así que es importante dedicar bastante tiempo y tener suficiente participación del usuario en la elección de una frontera apropiada para el sistema.

Figura 18.3: El área gris que rodea a los sistemas de cuentas por cobrar

En un sistema grande se puede tomar en cuenta una cantidad de factores cuando se está escogiendo la perspectiva del proyecto. Entre los más importantes están los siguientes:

El deseo del usuario de lograr una cierta participación en el mercado para el producto, o incrementarla a más 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 automático y los sistemas bancarios en línea). O el usuario podría tratar de aumentar su mercado ofreciendo un mejor y más rápido servicio (por ejemplo, “todos nuestros pedidos se surten en menos de 24 horas, y tenemos un elaborado sistema de rastreo de pedidos para saber dónde se encuentra en todo momento”).

La legislación 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 basándose en edad, sexo, nacionalidad, etc. O podría tenerse que hacer un nuevo sistema para considerar los cambios en las leyes sobre impuestos.

Deseo del usuario por minimizar gastos operativos de algún área de su negocio. Esto era particularmente común en las compañías grandes en los años 60, y sucede con muchos negocios pequeños que están instalando su primera computadora. La mayor parte de las organizaciones que han tenido computadoras



Apuntes de Ingeniería de Sistemas: X parteinstaladas durante 10 años o más ya aprovecharon las oportunidades obvias de reducir el personal de oficina.

Deseo del usuario por lograr alguna ventaja estratégica para la línea de productos o área de negocios que opera. El usuario intenta hacerlo organizando y manejando información sobre el mercado para poder producir artículos de manera más aoportuna y económica. Un buen ejemplo de esto son las líneas áereas (al igual que muchas otras industrias recientemente desreglamentadas) donde mejor información acerca de tendencias del mercado y preferencias de los clientes pueden llevar a costos de pasajes e itinerarios más 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, reorganización y/o automatización), mientras que todo lo que está fuera se queda e 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 apéndices Fy G. En el caso del Sistema de Información de YOURDON Press (Apéndice F), la frontera es un tanto mayor de lo que se esperaría: incluye la facturación y el manejo de recibos que normalmente son parte del departamento de contabilidad (y por tanto estarían fuera de la frontera); de manera similar, el controlador del elevadordel Apéndice G tiene una frontera un tanto menor que lo deseable: se hubiera desarrollado un sistema muy distinto si ls 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. Declaración de propósitos2. Diagrama de contexto3. Lista de acontecimientos

Cada uno se discute a continuación.

18.1.1 La declaración de propósitos

El primer componente del modelo ambiental es una declaración textual breve y concisa del propósito del sistema, dirigida al nivel administrativo superior, la administración de los usuarios, y otros que no están directamente involucrados con el desarrollo del sistema.

El siguiente es un ejemplo de una declaración de propósitos típica:

El propósito del Sistema de Procesamiento de Libros Ajax es manejar todos los detalles de los pedidos de libros de los clientes, además del envío, facturación y cobro retroactivo a clientes con facturas vencidas. La información acerca de los pedidos de libros debe estar disponible para otros sistemas, tales como mercadeo, ventas y contabilidad.

La declaración de propósitos puede constar de una, dos o varias frases. Sin embargo, jamás debe llegar a más de un párrafo, ya que la intención no es proporcionar una descripción completa y detallada del sistema. Tal esfuerzo iría en contra del objetivo: el propósito del resto del modelo ambiental y del modelo de comportamiento es dar todos los detalles.

Como resultado, la declaración de propósitos será deliberadamente vaga en cuanto a muchos detalles. En el ejemplo anterior se podrían hacer preguntas como:

- ¿Exactamente qué tipo de información proporciona a contabilidad, ventas y mercadeo el sistema de pedido de libros?

- ¿Cómo determina el sistema de pedido de libros si un cliente tiene crédito? ¿Lo determina el sistema mismo o por medio del departamenteo de contabilidad?

- ¿Cómo se entera el sistema sobre nuevos libros que se han publicado y están disponibles para la venta?

Estas preguntas detalladas sólo pueden responderse viendo el modelo del comportamiento que se discute en los Capítulos 19 y 20.



Apuntes de Ingeniería de Sistemas: X parte

Aunque el documento de declaración de propósitos 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 nómina? No; prácticamente cualquiera que lea lo anterior estará de acuerdo en que la nómina 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 declaración de propósitos así lo afirma. Podría imaginarse esto como tema de debate entre el departamento de pedidos de libros y el de contabilidad. Por ello es apropiado que se mencione en la declaración de propósitos.

- ¿Es responsable el sistema de pedido de libros del control de inventarios, es decir, de determinar cuándo volver a surtir libros que están a punto de acabarse? No. La declaración de propósitos no hace tal afirmación. Es muy probable que el control de inventarios sea uno de muchos otros sistemas (o departamentos) que usen la información sobre pedido de libros que produce el sistema de pedido.

Muchos analistas sienten también que la declaración de propósitos debe resumir los beneficios tangibles y cuantificables que se logren con el nuevo sistema; por ejemplo, “El propósito del sistema es reducir el tiempo que se requiere para procesar un pedido, de tres días a uno”. Aunque esto puede ser muy útil en proyectos pequeños y muy definidos, no es fácil de lograr en proyectos más grandes. En su lugar suele requerirse un análisis 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 raíz de la declaración de propósitos. El diagrama de contexto es un caso especial del diagrama de flujo de datos, en donde una sola burbuja representa todo el sistema. La Figura 18.4 muestra un diagrama de contexto de un sistema de pedido de libros. En los apéndices F y G se proporcionan ejemplos de diagramas de contexto para dos sistemas reales.

El diagrama de contexto enfatiza varias características 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 envían 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.

Las técnicas para la construcción del diagrama de contexto se discuten en la Sección 18.2.

Figura 18.4: Diagrma de Contexto




18.1.3 La Lista de acontecimientos

La lista de acontecimientos es una lista narrativa de los “estímulos” 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. Un cliente hace un pedido. (F)2. Un cliente cancela un pedido. (F)3. La administración pide un reporte de ventas. (T)4. Llega un pedido de reimpresión de un libro a la bodega. (C)

Figura18.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 flujos es el que se asocia con un flujo de datos; es decir, el sistema se da cuenta de que ha ocurrido el acontecimiento cuando llega algún 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.

Figura 18.6: Diagrama parcial de contexto

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 sólo 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 explícitamente podría pedir entradas a otros terminadores a lo largo de los flujos de datos B y C para poder 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, más precisamente, la indicación de que ha ocurrido), o bien es requerido por el sistema para poder procesar un acontecimiento.

Además de los acontecimientos de tipo flujo, un sistema puede también 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 mañana 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; podría imaginarse que el sistema tiene un reloj interno con el cual puede determinar el paso del tiempo. Sin embargo, tenga en mente también que un acontecimiento temporal podría requerir que el sistema solicite entradas de uno o más terminadores. Por ello, podrían asociarse uno o más flujos de datos con un acontecimiento temporal, aunque los flujos de datos, en sí, no representan el acontecimiento mismo.



Apuntes de Ingeniería de Sistemas: X parteLos acontecimientos de control deben considerarse un caso especial del acontecimiento temporal: un estímulo externo que ocurre en algún 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 de control no indica si presencia con el arribo de datos. Como los muestra la Figura 18.7, un acontecimiento de control se asocia con un flujo de control en el diagrama de contexto.

Figura 18.7: Flujo de control asociado con un acontecimiento de control

El flujo de control puede considerarse como un flujo de datos binario: está encendido o apagado, y puede cambiar de un estado al otro en cualquier momento, señalando así al sistema que se necesita tomar alguna acción inmediata. Los sistemas de información de negocios no suelen tener flujos de control en sus diagramas de contexto; el Sistema de Información de YOURDON Press que se describe en el Apéndice F, por ejemplo, no tiene. Pero los flujos de control son bastante comunes en los sistemas de tiempo real; como ejemplo vea el diagrama de contexto del sistema de control del elevador en el Apéndice 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 declaración de propósitos 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 de entidad – relación de los almacenes externos

Incluso un sistema mediano comúnmente 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 definirán con gran detalle en el modelo de comportamiento (que se discute en el Capítulo 20), podría ser útil comenzar con la construcción del diccionario de datos ahora. Esto puede ser importante si las interfaces entre el sistema y los diversos terminadores están sujetas a cambios y a negociación; entre más pronto se comience a definir formalmente estas interfaces (definiendo la composición y significado de los almacenes), más pronto se podrán finalizar.

De manera similar, se puede construir un diagrama de entidad – relación de los almacenes externos (si hay). Esto puede ayudar a dejar al descubierto las relaciones entre almacenes que de otra manera no serían 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 típicamente incluyen a los usuarios finales del sistema) y al sistema mismo.

18.2 CONSTRUCCIÓN DEL MODELO AMBIENTAL

La discusión anterior probablemente hace que el modelo ambiental parezca simpley directo: después de todo, existe sólo un proceso, unos cuantos flujos de datos y terminadores, una descripción narrativa brece del propósito 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; además, usualmente se desarrolla como una serie de refinamientos iterativos, con datos adicionales que se añaden y refinan.

Una razón 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 fuera. Sin embargo, incluso en este caso, los diversos usuarios individuales internos generalmente sólo están familiarizados con una porción, y sus diversas opiniones a



Apuntes de Ingeniería de Sistemas: X parteveces entran en conflicto. Peor aún, las entrevistas iniciales con la comunidad usuaria tal vez omitan uno o más usuarios importantes cuyas interacciones con los terminadores externos se deben modelar.1

Es importante dedicar una buena cantidad de tiempo y energía 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 llegarán a ver (los únicos con el dinero necesario para contiuar financiando el proyecto, y con el poder para cancelarlo). Después de construído y aprobado lo verá en los pizarrones de avisos, así que es importante que esté correcto.

18.2.1 Construcción 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 continuación.

La parte más fácil 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 acrónimo convenido. En las Figuras 18.9(a) y (b) se muestran ejemplos.

Figura 18.9(a): Nombre típico de proceso para un diagrama de contexto

Figurqa 18.9(b): Otro nombre típico de proceso

Observe que, en el caso extremo, el nuevo sistema podría representar una organización completa; en este cado, el nombre del proceso típicamente sería el de la organización misma, como lo muestra la Figura 18.9(c).2

Figura 18.9(c): Nombre de proceso que representa una organización completa

Los terminadores, como hemos visto, se representan con rectángulos en el diagrama de contexto. Se comunican directamente con el sistema a través de flujos de datos o de control, como muestra la Figura 18.10(a), o a través 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 contecto de la figura 18.11 no es correcto. En realidad, los terminadores sí se comunican entre sí pero, dado que por definición son externos al sistema, la naturaleza y contenido de las interacciones terminador – terminador son irrelevantes para el sistema. Si durante la discusión con los usuarios encuentra que es esencial saber cuándo,

1 Tales usuarios pudieran no ser importantes en términos de jerarquía organizacional; pueden considerarse como humildes oficinistas, secretarias o administradores. No obstante, las funciones que realizan pudieran ser vitales, y ser crucial modelar con precisión las entradas que reciben del mundo exterior y las salidas que mandan. La razón de que el analista de sistemas a menudo olvide hablarles a estas personas es muy sencilla: un usuario de nivel superior (es decir, el jefe) le di´ra al analista con quién hablar. “No moleste a mi gente”, le dirá, “están 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 Capítulo 3, tal vez no haya forma diplomática de evitar esto, pero es crucial revisar el modelo ambiental con cuidado para asegurar que no falta nada.

2 Este es un escenario poco probable para un proyecto de desarrollo de sistemas típicos, pero se da más y más 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 organización requiere para llevar a cabo su propósito. El tema de modelos de empresa se discute en Information Enginneering for the Practitioner, de William Inmon (Englewood Cliffs, N.J.: Prentice-Hall, 1987), así como en Strategic Data Base Modeling, de James Martin (Englewood Cliffs, N.J.: Prentice-Hall, 1985).



Apuntes de Ingeniería de Sistemas: X partepor qué o cómo se comunican entre sí, entoncer los terminadores son parte del sistema, y deben incluirse dentro de la burbuja de proceso del diagrama de contexto.

Figura 18.10(a): Comunicación directa entre terminador y sistema

Figura 18.10(b): Comunicación a traves de un almacén externo

Figura 18.11: Diagrama de contexto incorrecto

Tres aclaraciones más acerca de los terminadores:

1. Algunos terminadores tienen un buen número de entradas y salidas. Para evitar un diagrama innecesariamente atiborrado conviene dibujar el terminador más 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).

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

2. Cuando el terminador es una persona individual, generalmente es preferible indicar el rol que desempeña, más 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 desempeña 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 desempeñar varios papeles distintos en el sistema; en



Apuntes de Ingeniería de Sistemas: X partelugar de mostrar un terminador etiquetado “Juan Pérez” con varios flujos de entrada y salida no relacionados, es más significativo mostrar los diversos papeles que Juan Pérez desempeña, cada uno como terminador separado.

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

Figura 18.13(a): Forma preferente de mostrar un terminador

Figura 18.13(b): Forma menos deseable de mostrar un terminador

Figura 18.14(a): Terminador que muestra la verdadera fuente de los datos

3. Dado que estamos interesados principalmente en desarrollar un modelo esencial del sistema, es importante distinguir entre fuentes y manejadores cuando se dibujan terminadores en el diagrama de contexto. Un manejador es un mecanismo, dispositivo, o medio físico 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 implantación actual de un sistema, existe la tendencia a mostrar el manejador, en lugar de la verdadera fuente de los datos. Sin embargo, puesto que el nuevo sistema generalmente tendrá opción de cambiar la tecnología 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.14(b): Terminador que actúa como manejador

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).

Figura 18.14(c): Terminador que combina la fuente y el manejador



Apuntes de Ingeniería de Sistemas: X parteLos flujos que aparecen en el diagrama de contexto modelan datos que entran y salen del sistema, además de las señales 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 también pueden aparecer en el diagrama de contexto para ilustrar datos que estén 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 implantación que introducen y sacan datos de un sistema. Más aún, no se desea mostrar los mensajes y medios específicos de coordinación que el sistema y los terminadores pasan entre sí para indicar que están 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 implantación que pueden cambiar drásticamente cuando se construye el nuevo sistema.

Figura 18.15(a): Diagrama de contexto con mensajes innecesarios

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 extraños y entradas y salidas orientadas a la implantación, se modela sólo el flujo neto de datos.

Sin embargo, habrá ocasiones en las que un terminador no inicie las entradas pues, aun con tecnología perfecta, el terminador no sabe que el sistema requiere sus entradas. Similarmente, hay ocasiones en la que el sistema no inicia la generación de salidas, debido a que no sabe que el terminador las necesita o desea. En 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 y salida con un flujo de diálogo (una flecha de dos cabezas), como muestra la Figura 18.15(c).3

Figura 18.15(b): Flujos de diálogo para mostrar mensajes esenciales

Figura 18.15(c): Forma alterna de mostrar flujos de diálogo

3 No es necesario usar un flujo de diálogo, pero sí vuelve más legible al diagrama de contexto al empaquetar las entradas y salidas asociadas para hacerlas visibles de inmediato al lector. Además, utilizar ua flecha para mostrar el diálogo, 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 más diferentes interacciones con terminadores externos.



Apuntes de Ingeniería de Sistemas: X parte18.2.2 Construcción 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 la lista de acontecimientos se debe asegurar de distinguir entre un acontecimiento y un flujo relacionado con un acontecimiento. Por ejemplo, lo siguiente probablemente no sea un acontecimiento:

“El sistema recibe el pedido del cliente”

Más 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 más apropiado para el acontecimiento sería:

“El cliente hace un pedido”

Esto pudiera parecer un ejercicio de semántica, pero no lo es. Si describimos el acontecimiento desde el punto de vista del sistema (por ejemplo, desde dentro, viendo hacia fuera), se podrían identificar erróneamente los flujos entrantes que no son acontecimientos por sí mismos, pero que se requieren para poder procesar algún otro acontecimiento. Por ello, siemrep se trata de describir los acontecimientos desde el punto de vista del ambiente (es decir, desde fuera, viendo hacia adentro).

En la mayor parte de los casos, la manera más fácil de identificar los acontecimientos relevantes para un sistema es visualizarlo en acción: 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 desempeñando el papel de terminadores. Sin embargo, debe distinguirse cuidadosamente entre acontecimientos discretos que se han “empaquetado” accidentalmente como si fueran 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 están presentes los datos, y ausentes en otras, podría en realidad haber dos acontecimientos distintos. Por ejemplo, si se ve de cerca el acontecimiento “el cliente hace un pedido”, se encontraría que algunas instancias incluyen el dato “identificación del vendedor” y otros no; y podría encontrarse que la respuesta del sistema es diferente cuando participa un vendedor que cuando no. Por ello, podría ser más apropiado tener dos acontecimientos separados: “el cliente hace un pedido” y “el vendedor tramita el pedido del cliente”.

Además, tenga en mente que la lista de acontecimientos debe incluir no sólo las interacciones normales entre el sistema y sus terminadores sino también 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 señalan Paul Ward y Stephen Mellor en Structured Development for Real-Time Systems (Nueva York: YOURDON Press, 1985).

Puesto que los terminadores están por definición fuera de las fronteras del intento de construcción de sistema representado por el modelo, los realizadores no pueden modificar la tecnología 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 terminadores 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, uestra lista de acontecimientos para el Sistema de Pedido de Libros Ajax (Figura 18.5) incluía un acontecimiento llamado “el pedido de reimpresión de libro llega a la bodega”. Pero ¿qué tal si no llega a tiempo (por ejemplo, una semana después de la fecha prometida por el impresor)? ¿Qué debería hacer el sistema? Probablemente se necesitaría 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 de modelo ambiental y revisen para asegurar que sean consistentes.

Podría encontrarse también hablando con personas enteradas de todo lo que entra y sale del sistema; algunos usuarios pueden proporcionar esta información, o tal vez los programadores encargados del mantenimiento de la versión 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



Apuntes de Ingeniería de Sistemas: X partesistema y la respuesta que esperan que dé. Con ello se puede crear una lista de acontecimientos a partir del diagrama de contexto.

Sin embargo, podría haber una situación en la que el diagrama de contexto no esté disponible. Esto es muy común, sobre todo al comienzo de algunos proyectos de desarrollo de sistemas: tal vez no sea fácil identificar los terminadores de los diversos flujos que entran y salen del sistema. En este caso suele ser más práctico empezar con un DER que muestre los objetos y relaciones. Los acontecimientos candidatos pueden encontrarse a continuación buscando las actividades u operaciones que ocasionan que se creee o eliminen relaciones. La creación de la lista de acontecimientos puede llevar entonces al desarrollo del diagrama de contexto; esto se ilustra en la Figura 18.16.

Figura 18.6: Creación del diagrama de contexto a partir de un DER

Por ejemplo, suponga que se han identificado los objetos CLIENTE y LIBRO en un sistema de publicaciones; el usuario podría también decir que existe una relación “pedidos” entre CLIENTE y LIBRO. Un acontecimiento probable, entonces, sería una acción que crea una instancia de la relación pedidos; otro acontecimiento sería una acción que elimine una instancia de una relación. Esto llevaría 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 investigación para darse cuenta de que “cliente” es un terminador para el sistema (mientras que “libro” no lo es); se podría 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 aontecimiento 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 o bien almacenar los datos que

luego serán salidas (como respuesta o parte de una respuesta a algún otro acontecimiento), o debiera ocasionar un cambio en el estado del sistema (como el diagrama de transición de estados).

18.3 RESUMEN

La construcción de un modelo ambiental es lo primero y más importante en la construcción de un modelo completo de los requerimientos del usuario para un nuevo sistema. Hasta aquí parecería una tarea fácil; después de todo, el diagrama de contexto consiste sólo en una sola burbuja, y la lista de acontecimientos parece una simple lista de transacciones. Pero en u 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 más de cien flujos de datos de entrada y salida. La lista de acontecimientos constituye un gran esfuerzo en los grandes sistemas; puede haber fácilmente cerca de cien acontecimientos que el sistema tiene



Apuntes de Ingeniería de Sistemas: X parteque manejar, y todos necesitan ser identificados. Además, puede ser difícil encontrar una declaración sencilla de por qué debe existir el sistema.

Una vez construído el modelo ambiental debe ser revisado cuidadosamente por todos los representantes clave de los usuarios, además del equipo del proyecto. Entonces se estará preparado para comenzar a construir el modelo de comportamiento, es decir, el modelo del interior del sistema. Esto se discute en los Capítulos 19 y 20.

PREGUNTAS Y EJERCICIOS

1. ¿Cuáles son las tres cosas que define el modelo esencial?

2. ¿Qué tipo de acontecimientos debe modelar el modelo esencial?

3. ¿Cómo determina el analista la frontera entre el sistema y el ambiente?

4. ¿Cuál es la consecuencia probable de que el analista escoja un alcance demasiado pequeño para el proyecto?

5. ¿Cuál es la consecuencia probable de que el analista escoja un alcance demasiado amplio para el proyecto?

6. ¿Qué factores deben tomarse en cuenta cuando se escoge el alcance de un proyecto?

7. ¿Cómo afecta al alcance del proyecto el deseo del usuario de obtener una mayor participación en el mercado?

8. ¿Cómo afecta al alcance del proyecto la legislación impuesta por los diversos cuerpos gubernamentales?

9. ¿Cómo afecta al alcance del proyecto el deseo del usuario de minimizar (o reducir) sus gastos operativos?

10. ¿Cómo afecta al alcance del proyecto el deseo del usuario de obtener ventajas estratégicas sobre la competencia?

11. Proyecto de investigación: Sobre un proyecto de su propia organización, ¿qué factor cree que afecte más en la elección del alcance? ¿Cree que el usuario, el analista y el equipo del proyecto estén conscientes y de acuerdo con ello?

12. En general, ¿cuáles cree que sean los posibles factores clave para los sistemas que se desarrollen en los años 90? Por ejemplo, ¿será más importante minimizar los gastos operativos que los cambios causados por la legislación gubernamental?

13. ¿Cuáles son los tres principales componentes del modelo ambiental?

14. ¿Aproximadamente de qué longitud debe ser un documento de declaración de propósitos?

15. ¿Cuáles cinco caracterpisticas de un sistema muestra un diagrama de contexto?

16. ¿Cuáles son los componentes de un diagrama de contexto?

17. ¿Qué es una lista de acontecimientos?

18. ¿Cuáles son los tres tipos de acontecimientos que debe modelar un diagrama de contexto?

19. ¿Qué relación hay entre flujos y acontecimientos en el diagrama de contexto?

20. ¿Qué es un acontecimiento temporal?

21. ¿Qué componentes adicionales pueden encontrarse en un modelo ambiental además del diagrama de contexto, la lista de acontecimientos y la declaración de propósitos?




22. ¿Por qué suele ser necesario hacer muchas revisiones y refinamientos del modelo ambiental?

23. ¿Por qué es importante asegurar que el modelo ambiental esté correcto?

24. ¿Qué tipo de nombre debiera ponerse dentro de una burbuja en un diagrama de contexto?

25. ¿Qué es un modelo de empresa?

26. ¿Cómo se comunican los terminadores con el sistema?

27. ¿Se comunican los terminadores entre sí en un modelo de sistemas? ¿Por qué?

28. ¿Bajo qué condiciones se dibujaría un terminador más de una vez en un diagrama de contexto? ¿Cómo se mostraría?

29. Si el terminador es un individuo, ¿cómo se mostraría en el diagrama de contexto?

30. ¿Cómo 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é deberían 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 sincronización en un diagrama de contexto?

36. ¿Qué significa el término flujo neto de datos?

37. ¿Bajo qué condiciones no inicia las entradas un terminador en un sistema?

38. ¿Bajo qué considiciones 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. ¿Cuáles 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?



Apuntes de Ingeniería de Sistemas: X parte43. ¿Qué tiene mal el diagrama de contexto siguiente?

44. ¿Qué tiene mal el diagrama de contexto siguiente?

LISTA DE ACONTECIMIENTOS1. El cliente necesita una “a”2. El vendedor necesita la factura3. El vendedor hace un envío4. El cliente hace un pedido

BIBLIOGRAFIA

- YOURDON, Edward. ANÁLISIS ESTRUCTURADO MODERNO. 1ra. Ed. Prentice-Hall Hispanoamericana, S.A.. México 1993. 721 pág. ISBN 968-880-303-0.


4€¦ · Web viewLa estabilidad del medio interno es una condición ... de trabajadores...

Documents

Transcript of 4€¦ · Web viewLa estabilidad del medio interno es una condición ... de trabajadores...