domingo, 12 de octubre de 2014

Modelo Esencial de un Sistema - 3º BTI

Trabajo dual de Plan Optativo - Analisis
  • Realizar una lectura del material. 
  • Hacer un Resumen
  • Dar una opinion dual. 
  • Enviar al correo vccard@gmail.com el trabajo 
 
Modelo Esencial de un Sistema

El Modelo Esencial es un modelo de lo que el sistema debe hacer para satisfacer los requerimientos del usuario, diciendo lo mínimo posible (preferentemente nada) acerca de cómo se implementará, ya que de eso nos ocupamos en la etapa de Diseño. El modelo esencial consiste de dos componentes principales: el Modelo Ambiental y el Modelo de Comportamiento. El Modelo Ambiental define la frontera entre el sistema y el resto del mundo, es decir el ambiente, entorno o contexto en el cual el sistema existe. Consiste de una descripción breve del propósito del sistema, una lista de acontecimientos o eventos y de un diagrama de contexto. El Modelo de Comportamiento describe el comportamiento que el sistema debe tener para que interactúe exitosamente con el entorno. Consiste de la creación de DFDs, un DER, entradas en un Diccionario de Datos y especificaciones de procesos.


La idea del Modelo Ambiental es especificar claramente qué es parte del sistema y qué no. No importa el sistema que estemos desarrollando, siempre será parte de un sistema más grande. Aquí definimos las interfaces que permiten la interacción del sistema con el resto del mundo (el ambiente). Modela la frontera entre el sistema y el exterior. Del modelado del interior (o sea del sistema) se ocupa el modelo de comportamiento. Para modelar las interfaces entre el sistema y el ambiente exterior, es preciso identificar cuáles son los eventos o acontecimientos que ocurren en el ambiente para los cuales el sistema debe responder.


Generalmente el usuario tendrá una idea bastante clara del límite general entre el sistema y el ambiente. Sin embargo, existe frecuentemente una zona gris que se encuentra abierta para negociación. Esta es un área de la cual el usuario no está seguro, o no lo había tenido en cuenta, o tenía algunas ideas preconcebidas al respecto acerca de las cuales debe repensar.


La declaración de propósitos: es una descripción breve y concisa del propósito del sistema. Puede contar con una o más frases, pero no debería ser más de un párrafo. No es la narrativa completa del sistema, ya que los detalles serán cubiertos por el resto de los modelos que construiremos. Por ejemplo, para el sistema de la Asociación de Perros ZZZ del pcp podría ser algo así como lo siguiente: “El propósito del Sistema de Procesamiento de la Asociación de Perros ZZZ es administrar el registro genealógico, el registro de la propiedad y los concursos que organiza la Asociación ZZZ” Está dirigida a los administrativos de nivel superior y no a aquellos que se encuentran involucrados directamente en el desarrollo del sistema.




El diagrama de contexto: Es un caso particular de DFD donde existe una única burbuja que representa todo el sistema. Pone de manifiesto varias características importantes del sistema: Las personas, organizaciones y sistemas con los que se comunica el sistema, conocidos como terminadores o entidades externas. Los datos que el sistema recibe del mundo exterior y que deben procesarse de alguna manera. Los datos que el sistema produce y que se envían al mundo exterior. Los almacenes de datos compartidos con los terminadores (si los hubiere), los cuales se encuentran por afuera del sistema. La frontera entre el sistema y el mundo exterior.


La lista de acontecimientos (o eventos) es una lista narrativa de los “estímulos” que ocurren en el mundo exterior y a los cuales el sistema debe responder llevando a cabo un cierto proceso.

La construcción del modelo de comportamiento involucrará la creación de un modelo de datos (para lo cual usaremos como herramienta el DER) y un modelo de procesos (para el cual construiremos un DFD por niveles) así como de las correspondientes entradas en el DD. Si el sistema que estamos desarrollando tiene características de tiempo real también tendremos DTE ya que un conocimiento detallado del comportamiento del sistema debería ayudar a refinar el modelo. Existen dos enfoques para construir el modelo de procesos. Uno es el conocido como enfoque clásico descendente, utilizado por DeMarco y Gane & Sarson entre otros. El otro es el que seguiremos nosotros, conocido como enfoque de partición por acontecimientos o eventos, que es el propuesto por Yourdon en su libro “Análisis Estructurado Moderno”.

El modelo clásico descendente presupone que ya se construyó el DC. A partir del DC se construye un DFD de nivel superior, conocido como figura 0, en donde cada burbuja representa un subsistema principal. Cada burbuja de la figura 0 se explota en figuras de nivel inferior, y cada una de nivel inferior a su vez se vuelve a explotar hasta obtener burbujas atómicas que no requieran mas descomposición.

El enfoque de partición por acontecimientos no es ni puramente descendente ni puramente ascendente. En cierto sentido, es un enfoque “intermedio”: después de desarrollar el DFD inicial (a partir de la lista de eventos), se requiere una nivelación ascendente, pero podría luego necesitarse alguna partición descendente. Más específicamente, los pasos que vamos a seguir consistirán en: Dibujar un proceso por cada evento en la lista. Nombrar el proceso describiendo la respuesta del sistema al evento. Dibujar las entradas y salidas necesarias para que el proceso pueda dar la respuesta requerida mas los almacenes para la comunicación entre burbujas. Construir una red con todos los mini DFDs, que dará lugar a un DFD inicial, y balancear este DFD inicial con el DC y la lista de eventos. Realizar una nivelación ascendente. Realizar una partición descendente si esto fuera necesario.

Aquí vemos un ejemplo del mini DFD correspondiente a uno de los acontecimientos identificados y listados en la lista de eventos construida en el modelo ambiental. Cada evento en la lista deberá tener su correspondiente mini DFD. Cada uno de estos mini DFDs consistirá de una única burbuja, los flujos de datos necesarios para las entradas y salidas entre los terminadores identificados y el proceso, así como aquellos flujos desde el proceso hacia almacenes cuando sea necesario almacenar algo, o bien desde un almacén hacia el proceso cuando sea necesario recuperar datos del almacén para ser usados por el proceso que da respuesta al evento. En el ejemplo, el AMO provee con el dato Id_Perro que es la clave del almacén PERROS. El proceso se encargará de buscar en el almacén PERROS si el perro está inscripto en la asociación. Luego recuperará todas las competencias que se realizan ese año del almacén CONCURSOS y el amo elegirá en cuál lo quiere inscribir al perro. En base a esa información el proceso buscará en el almacén de COMPETENCIAS si el perro ya no encuentra inscripto en ese concurso, en cuyo caso procederá a realizar la correspondiente inscripción.