Método de Yourdon 1. Modelo Esencial 1.1. Modelo Ambiental

Presentación del tema: "Método de Yourdon 1. Modelo Esencial 1.1. Modelo Ambiental"— Transcripción de la presentación:

1 Método de Yourdon 1. Modelo Esencial 1.1. Modelo Ambiental
1.2. Modelo de Comportamiento ANALISIS Esta transparencia muestra un cuadro resumido de los distintos modelos del Análsis que debemos construir de acuerdo a Yourdon (“Análisis Estructurado Moderno”, “Just Enough Structured Analysis”) .

2 El Modelo Esencial Modelo de lo que el sistema debe hacer (Análisis).
Se compone: Modelo Ambiental Frontera Descripción de propósito Lista de eventos Diagrama de Contexto Modelo de Comportamiento DFD DER DTE Diccionario de Datos Especificaciones de procesos Diccionario de Datos 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, DTEs (si el sistema tiene carcterísticas de necesario), , entradas en un Diccionario de Datos y especificaciones de procesos.

3 Modelo Esencial - El Modelo Ambiental
Qué es parte del sistema y qué no. Frontera. Interfaces, previo determinar eventos. El Ambiente Modelo Ambiental 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 cuales son los eventos o acontecimientos que ocurren en el ambiente para los cuales el sistema debe responder. El Sistema Modelo de Comportamiento

4 Modelo Esencial - El Modelo Ambiental
El Ambiente El Sistema Zona gris Negociable 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.

5 Modelo Esencial - El Modelo Ambiental
El Ambiente Sistema CtasCobrar facturación Control de inventario Thus, for example, the user may ask the systems analyst to develop an accounts receivable system. While this may represent a well-defined, firm boundary between the system (known as the A/R system) and the environment, the systems analyst should certainly consider the “gray area,” as illustrated by Figure of accounts payable, inventory control, cash management, invoicing, and order entry as a somewhat larger scope.

6 El Modelo Ambiental I.- La declaración de propósitos
“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” 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.

7 El Modelo Ambiental Pone de manifiesto:
II.- El diagrama de contexto (DFD particular) Pone de manifiesto: Personas, organizaciones y sistemas con los que se comunica el sistema, conocidos como terminadores. Datos que el sistema recibe del mundo exterior y que deben procesarse de alguna manera. Datos que el sistema produce y que se envían al mundo exterior. 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. 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.

8 El Modelo Ambiental II.- El diagrama de contexto Sistema
Asociación Perros ZZZ AMO ASOCIACION Entradas AMO-Sistema Entradas ASOCIACION-Sistema Respuestas ASOCIACION-Sistema Respuestas AMO-Sistema En esta transparencia vemos un ejemplo de Diagrama de Contexto para el sistema de la Asociación de Perros ZZZ del práctico de aula. Como podemos apreciar se han usado dos diálogos para representar las interfaces entre el sistema y el mundo exterior. Estos flujos de datos deberán encontrarse definidos en el diccionario de datos. Muy posiblemente los dos flujos de entrada sean flujos divergentes, mientras que los dos de salida sean convergentes. Otra alternativa válida para representar el diagrama de contexto es mostrar explícitamente todos los flujos de entrada y de salida, descomponiendo los flujos divergentes y convergentes.

9 El Modelo Ambiental III.- La lista de acontecimientos Lista narrativa de “estímulos” que ocurren en el ambiente y a los cuales el sistema debe dar una respuesta. Ejemplo: El amo inscribe un perro en la asociación. La asociación requiere un reporte mensual de los nacimientos producidos durante el mes. La asociación solicita listado de hembras. … 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.

10 El Modelo Ambiental Tipos de acontecimientos:
III.- La lista de acontecimientos Tipos de acontecimientos: de flujo (F), temporales (T) de control (C). Sistema Asociación Perros ZZZ AMO ASOCIACION Entradas AMO-Sistema Entradas ASOCIACION-Sistema Respuestas ASOCIACION-Sistema Respuestas AMO-Sistema Existen tres tipos diferentes de acontecimientos: de flujo, temporales y de control, los que se etiquetan F, T y C. Los eventos de tipo flujo se encuentran asociados a un flujo de datos en el diagrama de contexto. Por ejemplo, para el evento “El amo inscribe un perro en la asociación”, existirá un flujo de datos que compondrá el flujo “Entradas AMO-Sistema” del DC para describir los datos del evento. Sin embargo, la inversa no siempre ocurre, es decir, no todo flujo de datos en el diagrama de contexto corresponde a un evento de flujo en la lista. Podría ser por ejemplo que un flujo de datos A esté asociado con un evento (por ejemplo el flujo de datos es iniciado por un terminador). Sin embargo, para procesar el evento pude resultar necesario que el sistema solicite de forma explícita a otros terminadores otras entradas B y C para poder así producir la respuesta adecuada. “El amo inscribe un perro en la asociación. (F)” “La asociación solicita listado de hembras. (F).”

11 El Modelo Ambiental Tipos de acontecimientos:
III.- La lista de acontecimientos Tipos de acontecimientos: de flujo (F), temporales (T) de control (C). “La asociación requiere un reporte mensual de los nacimientos producidos durante el mes. (T)” Otra razón por la cual no existe una correspondencia uno a uno entre los flujos de entrada en el diagrama de contexto y los eventos de la lista de acontecimientos es por la existencia de eventos temporales. Los eventos temporales no se inician con flujos de datos, sino con la llegada de un momento dado en el tiempo. Sin embargo, un evento temporal podría hacer que el sistema solicite entradas a uno o más terminadores. Es por esto, entonces, que podrían asociarse cero o mas flujos de datos con un acontecimiento temporal. Por ejemplo, el evento “La asociación requiere un reporte mensual de los nacimientos producidos durante el mes” es un evento temporal ya que el sistema dará respuesta a este evento por medio de un proceso que se iniciará con la llegada de, por ejemplo, el último día hábil del mes.

12 “El sensor de sobrecarga del ascensor detectó sobrepeso (C).”
El Modelo Ambiental III.- La lista de acontecimientos Tipos de acontecimientos: de flujo (F), temporales (T) de control (C). sobrecarga Sensor de sobrecarga Sistema Controlador de Ascensor Los eventos de control son un caso especial de evento temporal. La diferencia está en que ocurren en un momento impredecible y en consecuencia el sistema no puede anticiparlo por medio de un reloj interno, y como cualquier evento temporal, no indica su presencia por medio de un arribo de datos al sistema (flujo de entrada), sino que se asocia con un flujo de control en el DC. Un flujo de control pude considerarse como un flujo de datos binario: está encendido o apagado y puede pasar de un estado a otro en cualquier momento, indicando de ese modo al sistema que debe realizar alguna acción inmediata. Los sistemas de información de negocios no suelen tener flujos de control en sus diagramas de contexto. Estos son comunes en los sistemas de tiempo real. Por ejemplo el flujo “sobrecarga” representa la señal o interrupción enviada por el sensor de sobrecarga al sistema para que éste actúe de acuerdo a este evento. “El sensor de sobrecarga del ascensor detectó sobrepeso (C).”

13 El Modelo Ambiental III.- La lista de acontecimientos Punto de vista del ambiente vs. punto de vista del sistema. Descubrir eventos examinando efecto de terminadores sobre el sistema. No “empaquetar” eventos (“el cliente hace un pedido” vs. “el vendedor tramita un pedido del cliente”). ¿Toda instancia = datos? Debe incluir no solo las interacciones normales sino las de falla debidas a terminadores. A los eventos siempre es conveniente describirlos desde el punto de vista del ambiente y no del sistema, es decir, con una visión de afuera hacia adentro y no al revés. Por ejemplo, no diremos “La inscripción de un perro es recibida por el sistema” sino que diremos “El amo inscribe un perro”. Esto es para evitar confundir los flujos de datos que no son eventos por si mismos sino que son requeridos para procesar algún otro evento. Una manera fácil de identificar los eventos relevantes del sistema es visualizar al sistema en acción: examinamos cada terminador y nos preguntamos qué efecto pueden tener sobre el sistema las acciones del terminador. Sin embargo, hay que tener cuidado de no “empaquetar” eventos, es decir, evitar tratar eventos separados como si fueran uno sólo. Para evitar esta situación es conveniente preguntarse si todos las instancias del evento involucran los mismos datos. Por ejemplo, el evento “el cliente hace un pedido” podría encontrarse que algunas instancias incluyen el dato identificación del vendedor y otras no; y además que el sistema responde de manera diferente en un caso que en el otro. Por eso, sería mas apropiado tener dos acontecimientos separados: “el cliente hace un pedido” y “el vendedor tramita el pedido del cliente”. La lista de eventos 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 las fallas del sistema pero sí por las de los terminadores. Por ejemplo, en un sistema de pedido de libros tenemos el acontecimiento “un pedido de re-impresión llega a la bodega”, pero ¿qué pasa si el pedido no llega antes de la fecha prometida por el impresor? ¿Qué debería hacer el sistema? Probablemente se necesitaría de un evento adicional iniciado por el sistema que ocasione que el sistema se comunique con el impresor y vea a qué se debe la demora.

14 El Modelo Ambiental ¿Qué primero, la lista o el DC?
Cualquiera de los dos. Consistentes! Usuarios con buen conocimiento sobre E/S o existencia de versión actual de DC, DC => LE. DC sistema actual no disponible, DER => LE => DC. Empezar construcción de DD. Puede comenzarse a construir cualquiera de los dos. Lo que importa es que al finalizar el modelo esencial tanto el diagrama de contexto (DC) así como la lista de eventos (LE) hayan sido producidos y sean consistentes entre sí. Cuando contamos con un sistema actual, para el cual existe documentación y hasta posiblemente un DC, o existen usuarios con conocimiento claro acerca de cuáles son las entradas y salidas esperadas del sistema, podemos arrancar por construir el DC del nuevo sistema, para luego crear una LE a partir del DC analizando los terminadores en acción. Pero cuando no se cuenta con un DC, caso común en el comienzo de desarrollos de sistemas, tal vez no resulte fácil identificar cuáles son los terminadores y los diversos flujos que entran y salen al sistema. En este caso puede resultar conveniente comenzar con un Diagrama Entidad-Relación (DER) que muestre los objetos y sus relaciones. A partir de este DER podemos derivar una lista de eventos: los eventos pueden identificarse a partir de las operaciones que crean o eliminan relaciones y objetos. Luego, a partir de la creación de la LE podemos construir el DC. Al finalizar la construcción del modelo esencial, debemos contar con una versión preliminar del diccionario de datos (DD) en la cual ya se encuentren definidos todos los flujos de entrada y salida del diagrama de contexto, así como los almacenes externos al sistema (si es que los hubiere).

15 El Modelo Esencial El Modelo de Comportamiento
Modelo de Procesos (DFD) Especificaciones de procesos Modelo de Datos (DER) Modelo de comportamiento (DTE), posiblemente. Completado del DD Enfoques para Construcción del Modelo de Procesos: Clásico descendente (top-down) Partición por acontecimientos (o eventos) 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”.

16 El Modelo de Comportamiento Enfoque Clásico Descendente
SISTEMA E1 E2 E3 a b c Diagrama de Contexto 1 PA 2 PB 4 PD 3 PC a z b y x c w v Figura 0: EL SISTEMA 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. .

17 El Modelo de Comportamiento Enfoque de Partición por Acontecimientos
No es ni puramente descendente ni puramente ascendente. 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. Controlar completitud y consistencia entre DFD inicial (red de mini DFDs), DC, DD y lista de eventos. Nivelación ascendente. Posible partición descendente. 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.

18 El Modelo de Comportamiento Enfoque de Partición por Acontecimientos
Ejemplo de mini DFD Evento 5: “El amo inscribe un perro en un concurso”. INSCRIBIR CONCUR- SANTE AMO CONCURSOS PERROS COMPETENCIAS Id_Perro Respuesta_Inscripción Datos_Concurso 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.

19 El Modelo de Comportamiento Balanceo de modelos
Una vez que construyó el DFD inicial (red de mini DFDs resultante de la unión de los mini DFDs correspondientes a cada evento) debemos balancearlo con el DC. Es decir, controlar que el número de flujos de entrada y salida coincidan en ambos modelos. Esto debemos hacerlo con la ayuda del DD ya que en el DC podemos tener flujos compuestos los cuales corresponden a múltiples flujos en de los mini DFDs. También deberemos controlar que todos los eventos de la lista de eventos tengan su correspondiente mini DFD creado, con todos los datos definidos. Versión inicial del DFD Diagrama de Contexto

20 El Modelo de Comportamiento Nivelación ascendente del DFD inicial
1 1.1 1.2 1.3 E2* E1* E1 E2 Resultado de la nivelación ascendente DFD preliminar Almacén local Almacén local quedó oculto en la burbuja 1 Una vez que contamos con un DFD inicial, resulta evidente que el DFD inicial no es un modelo que pueda ser presentado al usuario para su validación debido a su complejidad. Será entonces necesario reorganizar este DFD inicial, que consiste de un solo nivel y demasiadas burbujas. Para ello realizamos una nivelación ascendente del DFD. Esto significa agrupar procesos relacionados en una burbuja en un diagrama de nivel superior. Esto puede verse en el ejemplo de la figura. Al nivelar hacia arriba, debemos tratar de: Agrupar procesos que manejen datos en común, enterrando almacenes que aparecen en el nivel inferior. Agrupar en DFDs de 7 ± 2 bloques de información (1 proceso y sus flujos relacionados se consideran 1 bloque). Por supuesto, esta última es una sugerencia y no una regla aritmética a seguir a rajatabla; no significa que debamos conducir la actividad de nivelación ascendente de manera tal que todos los DFDs tengan siempre 7 burbujas!. De hecho, lo que debe primar es la búsqueda de oportunidades para esconder almacenes en común (almacenes locales) y no alguna regla aritmética. Este número aparentemente arbitrario (7 ± 2) es una regla para controlar la complejidad en una variedad de situaciones de solución de problemas. Se basa en la obra de George Miller, quién por primera vez observó la dificultad de manejar trozos múltiples de información, en un trabajo clásico titulado “The magical number seven, plus minus two: some limits on our capacity for processing information” (Psychological Review, vol.3, pp 81-97, 1956). Agrupar procesos que manejen datos en común, ocultado almacenes locales que aparecen en el nivel inferior. Agrupar en DFDs de 7±2 bloques de información (1 proceso y sus flujos relacionados se consideran 1 bloque).

21 El Modelo de Comportamiento Posible nivelación descendente del DFD inicial
Figura 0 (3 burbujas) 1er resultado de nivelación ascendente (9 burbujas) DFD preliminar (63 burbujas) Nótese que también podría ser necesaria realizar una nivelación descendente del DFD inicial. Esto sucede cuando existen procesos iniciales (responsables de dar respuesta a un evento particular) que no son primitivos, es decir, resultan muy complejos de describir en especificación de proceso de una página. Muchas veces esto se vuelve evidente cuando se analiza el proceso con cuidado o se desea escribir la especificación del proceso y esta resulta demasiado extensa. Resultado de la nivelación descendente de la burbuja 3.2.2 Burbuja 3.2.2

22 El Modelo de Comportamiento Modelo de Datos
DER. En paralelo con DFD inicial (red de mini DFDs) y DD. Usar uno como apoyo para construir el otro y viceversa. En paralelo con la construcción de los mini DFDs también vamos desarrollando el modelo de datos si es que ya no lo hicimos antes. Para ello usamos como herramienta el DER. Es probable que durante la construcción de uno usemos el otro para revisarse mutuamente ya que los almacenes que sugerimos en los mini DFDs pueden usarse para sugerir objetos en el DER y los objetos identificados en el DER pueden ser usados para sugerir almacenes en el DFD inicial. Por supuesto, no nos tenemos que olvidar de ir construyendo en todo momento en paralelo el DD.

23 El Modelo de Comportamiento Especificaciones de Procesos
Es una mala idea dedicar tiempo a escribir las especificaciones de procesos hasta que no se haya concluido con el DFD inicial. Idealmente, después de nivelación ascendente. Indeed, it is often a bad idea to devote any time to the writing of process specifications until the preliminary DFD has been finished, because the initial development of the DFD is subject to many changes, corrections, and revisions. Bubbles may appear, disappear, and be moved around and renamed. When the preliminary DFD begins to settle down, and when it has stood the test of upward leveling (i.e., if that activity does not uncover any major flaws in the model), then you can begin writing the process specifications. This will often be a lengthy, time-consuming effort, because each of the bottom-level bubbles in the DFD set requires a process specification. Thus, it may be possible for a group of two or three systems analysts to draw a few dozen DFDs; but it may take a larger group of analysts to complete all the process specifications in a timely fashion. As the process specifications are completed, they should be balanced and cross-checked against the data dictionary and ERD.

24 El Modelo de Comportamiento Modelo de Datos: DER

25 El Modelo Esencial Resumido
Diagrama de contexto Lista de eventos Declaración de propósito Conjunto completo de DFDs por niveles. Diagrama de Entidad-Relación completo. Conjunto completo de DTE. Diccionario de Datos completo. Conjunto completo de especificaciones de procesos de nivel inferior. Al finalizar el modelo esencial, si hemos seguido todos los pasos deberíamos tener un modelo completo y detallado de todo lo que el sistema debe hacer para satisfacer los requerimientos del usuario. Contendrá lo siguiente: Diagrama de contexto Lista de eventos Declaración de propósito Conjunto completo de DFDs por niveles. Diagrama de Entidad-Relación completo. Conjunto completo de DTE, si el sistema tiene características de tiempo real. Diccionario de Datos completo. Conjunto completo de especificaciones de procesos (una por cada proceso de nivel inferior).

26 Bibliografía “Just Enough Structured Analysis”de Edward Yourdon Cap. 17: Punto 3; Cap. 18; Cap. 19; Cap. 20 Descarga del libro : Wiki del libro: “Análisis Estructurado Moderno”, de Edward Yourdon, Prentice Hall, 1989.