Trabajos Pràcticos (Realizados en Clase)

martes, 6 de abril de 2010

Construcción del modelo ambiental

Construcción del diagrama de contexto

El diagrama de contexto 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 la figuras siguiente se muestra un ejemplo.


Nombre tipico de proceso para un diagrama de contexto

Los terminadores 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 siguiente,

Comunicación directa entre terminado y sistema

o a través de almacenes externos, como se muestra en la figura siguiente.


Comunicación a traves de un almacen externo

Los terminadores no se comunican entre sí. En realidad, los terminadores si 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.

Hay que tomar tres punto mas en consideración 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. Los terminadores duplicados se marcan con un asterisco.

  2. Cuando el terminador es una persona individual, generalmente es preferible indicar el rol que desempeña, más que su identidad.

  3. Dado que estamos interesados en desarrollar un modelo esencial del sistema, es importante distinguir entre fuente y manejadores. Un manejador es un mecanismo, dispositivo, medio físico usado para transportar datos hacia 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 al manejador, en lugar de la verdadera fuente de los datos.

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


Construcción de la lista de acontecimiento

La lista de acontecimiento es un listado textual sencillo de los acontecimientos del ambiente a los cuales debe responder el sistema. Al crear la lista de acontecimiento 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"

Mas bien, 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"

La manera más fácil de identificar los acontecimientos para un sistema es visualizarlo en acción: examinar cada terminador y preguntar qué efecto pueden tener sus acciones sobre el sistema.

La lista de acontecimiento debe incluir no sólo las interacciones normales ente el sistema y sus terminadores sino también situaciones de falla. Como señalan Paul Ward y Stephen Mellor en Structured Development for Real-Time System :

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, nuestra lista de acontecimiento para el Sistema de Pedido de Libros Ajax 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?, Por lo que se necesitaría un acontecimiento adicional iniciado por el sistema para hacer que se comunique con el impresor y localice el origen del retraso.

No hay comentarios:

Publicar un comentario