DOCUMENTO Herramientas para el Anlisis y Diseo Estructurado

Cdigo Revisin Fecha Pgina

GEM-MDSI-DO-04 0 15/feb/2007 1 de 11

Herramientas para el Anlisis y Diseo Estructurado Gran parte de la labor que desempean los analistas y diseadores involucra el modelado del sistema que desea el usuario. Los modelos del sistema son representaciones abstractas de lo que al final ser una combinacin de Hardware y Software. Los modelos se construyen para enfatizar ciertas propiedades criticas del sistema, mientras que simultneamente se desacenta otros aspectos. Esto permite la comunicacin con el usuario de una manera enfocada, sin distracciones con asuntos y caractersticas ajenas al sistema. Y si la apreciacin del sistema no es correcta (o el usuario cambia de parecer acerca de sus requerimientos) se pueden hacer cambios en el modelo e inclusive desecharlo y hacer uno nuevo. En el anlisis y diseo se hace uso de modelos, para: Concentrarse en las propiedades importantes del sistema y al mismo tiempo restar atencin a otras menos importantes. Discutir cambios y correcciones de los requerimientos del usuario, a bajo costo y con riesgo mnimo. Verificar que el analista comprenda correctamente el ambiente del usuario y que lo haya respaldado con informacin documentada para que los diseadores de sistemas y los programadores puedan construir el sistema.

Para comprender mejor el contexto del uso de las herramientas para el anlisis y diseo, es necesario introducirnos en las primeras etapas del ciclo de desarrollo de sistemas: Descripcin del problema Recoleccin de informacin (educcin de requisitos) Anlisis del problema Descripcin esttica. Identificando la estructura esttica de los objetos y sus relaciones se obtiene una especie de fotografa que proporciona una imagen esttica del dominio del sistema. Perspectiva dinmica. Se describen aspectos del sistema que cambian con el tiempo, y que, caracterizan los distintos estados que pueden presentar un problema, as como las condiciones y eventos que permiten transitar entre estados. Vista funcional. Se describe como se transforman los datos en el contexto del sistema.

Adems cada sistema puede ser modelado atendiendo a tres perspectivas:

Estas tres perspectivas son complementarias, y juntas proporcionan la posibilidad de construir un modelo del sistema. Diagrama de Flujo de Datos (DFD) Es una herramienta que permite visualizar un sistema como una Red de procesos funcionales, conectados entre s. Describe la transformacin de entradas a salidas en un diagrama. Componentes de un DFD Proceso Sinnimos: Burbujas, funcin o transformacin. El proceso muestra una parte del sistema que transforma entradas en salidas. Grficamente se representa con un circulo. Tambin puede ser un valo o un rectngulo (depende de la escuela: DMarco, Sarson, etc). La burbuja se debe describir con un nombre o frase. Es conveniente la utilizacin de verbos y objetos.

DOCUMENTO Herramientas para el Anlisis y Diseo Estructurado Flujo

Cdigo Revisin Fecha Pgina

GEM-MDSI-DO-04 0 15/feb/2007 2 de 11

Se representa grficamente por una flecha que entra o sale de un Proceso. Se usa para describir el movimiento de bloques o paquetes de informacin de una parte del sistema a otra. Los flujos representan datos en movimientos. En muchos sistemas los flujos representaran datos, caracteres, mensajes, etc., pero los DFD tambin pueden usarse para modelar otros sistemas no computarizados. En estos casos los paquetes representados por los flujos, sern objetos fsicos. La flecha cuenta con puntas que indican la direccin de la misma e indica bsicamente si los datos (material) se estn moviendo hacia adentro o hacia afuera de un proceso (o ambas cosas), este el caso que en el flujo se produce un dialogo. Debe existir la precaucin de nombrar con exactitud los flujos, debido a que dos flujos pueden tener el mismo contenido, pero distinto significado. Los flujos de datos pueden divergir o converger en un DFD. Almacn Se utiliza para modelar una coleccin de paquetes de datos en reposo. Grficamente se representa con dos lneas paralelas. Normalmente la tendencia es asociar el Almacn con Archivo y/o Base de datos. De hecho es as como se implementan los almacenes en un sistema, pero Almacn, tambin puede ser (y de hecho es): tarjetas perforadas, fichero, microfilme. micro-fichas, fichas de papel, una caja de cartn, etc. Los almacenes se conectan por flujos a los procesos. El contexto en que se muestra un Almacn en DFD, son algunos de estos o ambos: Un flujo desde un almacn (lectura) Un flujo hacia un almacn (actualizacin) Se recupera del almacn un solo paquete (registro de un Cliente). Varios paquetes que cumplen con cierta condicin. Una porcin del paquete. Varias porciones de ms de un paquete. Si la etiqueta del flujo es la misma del Almacn, significa que se recupera todo el paquete o (mltiples instancias de uno completo). Si la etiqueta del flujo es diferente del nombre del Almacn, entonces se estn recuperando uno o mas componentes de uno o mas paquetes.

La lectura o acceso al almacn significa:

Convenciones para poder clasificar los casos mencionados:

Para conocer los detalles sobre el flujo que emana de un almacn, se debe examinar los detalles de las especificaciones del proceso al cual se conecta el flujo. Un flujo hacia un almacn se describe como una escritura, una actualizacin y/o eliminacin. Y tiene uno de los siguientes significados: Se guardan uno o ms paquetes nuevos en el almacn. Uno o ms paquetes se estn borrando. Uno o ms paquetes se estn modificando o cambiando (modificar una porcin de un paquete o modificar una porcin o todo de todos los paquetes).

DOCUMENTO Herramientas para el Anlisis y Diseo Estructurado

Cdigo Revisin Fecha Pgina

GEM-MDSI-DO-04 0 15/feb/2007 3 de 11

Un flujo conectado a un almacn slo puede transportar paquetes de informacin que el almacn sea capaz de guardar. El flujo debe estar relacionado con el almacn. Entidad Grficamente se representa con un rectngulo. Comnmente una Entidad es una persona, un departamento, un grupo, que estn dentro o fuera de la organizacin. La entidad puede ser otro sistema con la cual existe una comunicacin (retroalimentacin). Al representar un Entidad se debe tener en cuenta que: La Entidad es externa al sistema que se est modelando. Los flujos que conectan entidades con procesos o almacenes, indican una interfaz entre l y el mundo externo. El analista no puede modificar los contenidos, la organizacin, ni los procedimientos internos asociados con las entidades. Las relaciones que pudieran existir entre las entidades, no se reflejan en un DFD (no son partes del sistema que se est estudiando).

Si la relacin que existe entre entidades es esencial para el analista y ste necesita modelarlas para poder documentar los requerimientos del sistema, entonces, las Entidades son en realidad parte del sistema y debern ser modeladas como Procesos. Diagrama de Entidad-Relacin (DER) Todos los sistemas almacenan y usan informacin acerca del ambiente en el cual interactan; a veces, la informacin es mnima, pero en la mayora de los sistemas actuales es bastante compleja. Es necesario conocer en detalle qu informacin hay en cada almacn, as como conocer la relacin que existe entre almacenes (agregados de datos). Este aspecto del sistema no es resaltado por el DFD, pero si lo hace el DER (diagrama de entidad relacin). El diagrama Entidad-Relacin (DER) es un modelo de red que describe con un alto nivel de abstraccin la distribucin de datos almacenados en un sistema. Componentes de un DER Tipos de Objetos Se representa por medio de una caja rectangular. Representa una coleccin o conjunto de objetos (cosas) de miembros individuales (o instancias). Tienen las siguientes caractersticas: Cada una puede identificar de manera nica por algn medio.- Distinguir los objetos unos de otros. Cada uno juega un papel necesario en el sistema que se construye. Es decir, para que el tipo de objeto sea legitimo, debe poder decirse que el sistema no puede operar sin tener acceso a esos miembros. Cada uno puede describirse por uno o ms datos (atributos). Su existencia no depende fundamentalmente del tiempo.

En los sistemas los tipos de objetos sern la representacin en el sistema de algo material del mundo real. El objeto es algo material del mundo real, y el tipo de objeto es su representacin en el sistema. Sin embargo, un objeto tambin pudiera ser algo no material: horarios, estrategias, clases, etc. Relaciones Los objetos se conectan entre s mediante relaciones. Una relacin representa un conjunto de conexiones entre objetos, y se representan por medio de un rombo.

DOCUMENTO Herramientas para el Anlisis y Diseo Estructurado

Cdigo Revisin Fecha Pgina

GEM-MDSI-DO-04 0 15/feb/2007 4 de 11

La relacin representa un conjunto de conexiones. Cada instancia de la relacin representa una asociacin entre cero o ms ocurrencias del objeto y cero o ms ocurrencias del otro. La relacin representa algo que debe ser recordado por el sistema (no es calculado). La relacin representa la memoria del sistema. Puede existir ms de una relacin entre objetos. Las relaciones en los DER son mltiples-direccionables; pueden leerse siguiendo cualquier direccin, mostrando tanto cardinalidad como ordinalidad. Hay que incluir en el D.D una definicin de todas las relaciones que se muestran en DER y esta debe incluir un significado en el contexto de la aplicacin. Diccionario de Datos (DD) El Diccionario de Datos es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento comn de todas las entradas, salidas, componentes de almacenes y clculos intermedios. El Diccionario de datos define los datos haciendo lo siguiente: Describe el significado de los flujos y almacenes que se muestran en los DFD. Describe la composicin de almacenes (paquetes). Especifica los valores y unidades relevantes de piezas elementales de informacin de los flujos de datos y en los almacenes de datos. Describe los detalles de las relaciones entre almacenes en un diagrama de Relacin- Entidad.

La experiencia nos ensea que podemos describir tres niveles de todo lo que resulte de inters para un analista: Elemento de datos: son parte de datos que no resulta significativo descomponer ms an para nuestro propsito. Estructura de datos: esta formada por elementos de datos, o por otras estructuras de datos, o por combinacin de ambas. Componentes de los diagramas: Procesos, Flujos de Datos, Almacenes y Entidades en un DFD; Entidades y Relaciones en un DER; Mdulos y Parmetros en un DE; y Procesos en un EP.

El DD lo crea el analista durante el desarrollo del modelo de sistema, pero el usuario debe ser capaz de leerlo y entenderlo. Contenido de un Diccionario de Datos Elemento de Datos La informacin mnima necesaria para definir un elemento de datos es su nombre y su descripcin. El nombre debe elegirse de manera tal que tenga la mayor significacin posible para el usuario. La descripcin podr ser un breve esbozo del significado del elemento de datos y puede incluir un tpico ejemplo. Para definir por completo un dato, debe incluir: Significado: dentro del contexto de la aplicacin Composicin: si se compone de partes elementales con significado Tipo de dato.

Adicionalmente se podr registrar:

DOCUMENTO Herramientas para el Anlisis y Diseo Estructurado

Cdigo Revisin Fecha Pgina

GEM-MDSI-DO-04 0 15/feb/2007 5 de 11

Alias de elementos de datos. Aparecen debido a que varios distintas reas de la organizacin denominan a un mismo objeto con nombres diferentes Elementos de datos relacionados. Son elementos de datos que representan distintas caractersticas de un mismo objeto. Rango de los valores y significado de los valores. Son datos continuos cuando el elemento de datos puede tomar cualquier valor dentro de un rango determinado; y datos discretos cuando solo puede tomar determinados valores. Longitud. Especificar la longitud del dato (o posible rango de longitudes). Codificacin. Se debe registrar en el diccionario de datos la forma en que el elemento de datos ser codificado fsicamente en el sistema Otras informaciones de validacin. Rutinas de validacin, consistencia, congruencia, etc.

Estructuras de Datos Las estructuras se construyen en base de elementos y otras estructuras. Se deber especificar: el nombre y quienes la componen (asegurndose que estos estn definidos en el D.D). Para la construccin de estructuras de datos se deber hacer uso de la siguiente simbologa: Las estructuras de datos se definen con base en las siguientes convenciones: Smbolo Descripcin Interpretacin = Est compuesto de Definicin: Se lee como, se define como o simplemente significa + Adicin o conjuncin (and/y) Agrega elemento de datos () Optativo Puede estar o no presente en un dato compuesto {} Iteracin Indica la ocurrencia repetida de un componente (o estructura). Se deber especificar los limites de la ocurrencia. Limite inferior cuando no se describe asume cero, el superior cuando no se describe, asume infinito. [] Seleccin Indica que un dato consiste en exactamente un elemento de entre un conjunto de opciones alternativas. Comentarios Utilizados para aclarar el significado. @ Identificador de clave El elemento de dato identifica a la estructura de datos. ! Separa opciones alternativas en la Cada opcin puede ser u valor, un elemento construccin de datos u otra estructura de datos. Componentes de los diagramas: Se deber registrar el nombre y descripcin de cada elemento identificado en los DFD, DER, DE y EP, con la informacin que permita su comprensin y fcil entendimiento. Debern estar incluidos todos los Procesos, Flujos de Datos, Almacenes y Entidades de un DFD; Entidades y Relaciones de un DER; Mdulos y Parmetros de un DE; y Procesos de un EP. Diagrama de Estructura (DE) El modelo ms comn de organizacin de la actividad en una sola unidad sincronizada es el diagrama de estructura, que muestra la organizacin jerrquica de mdulos dentro de una tarea. Un diagrama de estructura adems de mostrar jerarqua funcional muestra la interfaz de datos entre los componentes. El diagrama de estructura se utiliza intensamente en el diseo de programas. Los diagramas de estructura deben leerse de la siguiente manera:

DOCUMENTO Herramientas para el Anlisis y Diseo Estructurado

Cdigo Revisin Fecha Pgina

GEM-MDSI-DO-04 0 15/feb/2007 6 de 11

El mdulo ejecutivo de nivel superior del sistema consta de varios mdulos Cada modulo contiene varias instrucciones ejecutables, incluyendo las invocan a otros mdulos Cuando se invoca a otro mdulo, la ejecucin del mdulo que invoca se suspende y se ejecuta el mdulo que es invocado, cuando termina regresa al modulo que invoca. Componentes de un DE

Cada mdulo puede pasar o no parmetros al mdulo que invoca o al que es invocado. Mdulo Es un componente, programa o subprograma del sistema y est representado por un rectngulo. Cada modulo (subrutina) est asociado con un proceso o funcin del DFD. Ejecucin La ejecucin de un mdulo se representa por una flecha que conecta dos mdulos. Las flechas que conectan los mdulos representan llamados a ejecucin de otro mdulo. La punta de le flecha indica cual es el mdulo invocado y el origen de la flecha cual es mdulo que invoca la ejecucin. La notacin implica que una subrutina terminara o regresar a donde se llam cuando finalice de realizar su funcin. Parmetros de entrada Conjunto de datos que el mdulo que invoca la ejecucin pasa al mdulo invocado antes de iniciar su ejecucin. Cuando exista la lista de parmetros de entrada se debe colocar a la izquierda de la flecha que representa la ejecucin. Parmetros de salida Conjunto de datos que el mdulo invocado devuelve al mdulo que invoca despus de concluir su ejecucin. Cuando exista la lista de parmetros de salida se debe colocar a la derecha de la flecha que representa la ejecucin. Especificaciones de Procesos (EP) La especificacin de Proceso es la descripcin de lo que sucede en cada burbuja primitiva de un nivel mas bajo de un DFD. Define lo que debe hacerse para transformar entradas en salidas. Cualquier herramienta que se utilice debe satisfacer tres requerimientos: 1. La especificacin de proceso debe expresarse de una manera que puedan verificar tanto el usuario, como el analista. 2. El proceso debe especificarse en una forma que pueda ser comunicada efectivamente al personal involucrado en el proyecto. 3. No debe imponerse decisiones de diseo de implantacin arbitrarias. Independientemente que se elija una de las herramientas para especificar procesos, debe existir la libertad para usar una combinacin de todas o algunas de ellas, con base en: Las preferencias del usuario. Las preferencias del equipo de desarrollo. La naturaleza de los procesos.

DOCUMENTO Herramientas para el Anlisis y Diseo Estructurado Pseudocdigo

Cdigo Revisin Fecha Pgina

GEM-MDSI-DO-04 0 15/feb/2007 7 de 11

Es un lenguaje similar al espaol con estructura, es decir, es un subconjunto de todo el idioma con importantes restricciones sobre el tipo de frases que pueden utilizarse y la manera en la que pueden juntarse dichas frases. Una frase en lenguaje estructurado puede consistir en una ecuacin algebraica. Tambin puede consistir en un Verbo y un Objeto. A las frases que describen las operaciones pueden usarse con prefijos de verbos (CALCULAR, AADIR, IMPRIMIR, etc.). Los verbos deben elegirse de entre un pequeo grupo de verbos orientados a la accin. Por ejemplo PONER, RESTAR, SUMAR, CALCULAR, BORRAR, FIJAR, ORDENAR, etc. Los objetos (frases imperativas sencillas) deben consistir solo en datos que se han especificado en el Diccionario de Datos o se definen explcitamente en una especificacin de proceso individual (son slo relevantes dentro de dicha especificacin). El pseudocdigo permite que se combinen frases similares a la programacin estructurada. La construccin COMIENZA-TERMINA agrupa una o ms frases que se deben realizar en orden secuencial en forma conjunta, como una sola frase. La construccin SI-ENTONCES-OTRO. Describe frases alternativas que se deben realizar segn el resultado de la decisin. La construccin CASO, se utiliza para describir frases alternativas que se ejecutaran basndose en los resultados de una decisin multivaluada. La construccin HACER-MIENTRAS se usa para describir una frase que deber llevarse a cabo repetitivamente hasta que alguna condicin se haga verdadera (o falsa). La prueba de la condicin se hace antes de que se ejecute la frase, por lo cual, si la condicin no se satisface, la frase se ejecuta cero veces (ninguna). La construccin REPITE-HASTA. Esta construccin ejecuta al menos una vez la frase especificada antes de hacer la prueba para verificar si se debe repetir. Se pueden construir frases compuestas a partir de combinaciones de frases sencillas y estructuras sencillas. Con las combinaciones podemos construir arbitrariamente descripciones complejas, siendo esta complejidad la principal desventajas del uso de lenguajes estructurados. Para evitar especificaciones de procesos complejas se debern considerar las siguientes reglas: 1. Restringir las especificaciones de proceso en lenguaje estructurado a una sola pgina, de no lograrlo, cambiar de tcnica, si aun persiste, redefinir la burbuja del DFD. 2. Evitar mas de tres niveles de anidamiento.- Si se presenta el caso de varias estructuras anidadas utilice Tablas de decisin. 3. Clarificar los niveles de anidamiento utilizando sangras El usuario debe poder leer y comprender las especificaciones de proceso, por este motivo el usuario deber repasar una o dos veces las especificaciones para asegurarse de que entiende el formato. El personal involucrado en el proyecto debe evitar referirse a las especificaciones del proceso como lenguaje estructurado. De ser necesario, refirase a ella como una descripcin formal de la poltica de negocios para realizar esta actividad. Adicionalmente deber poner atencin en el formato global y la distribucin de las especificaciones; la sangra de los bloques anidados de lgica es de especial importancia.

DOCUMENTO Herramientas para el Anlisis y Diseo Estructurado PRE/POST Condiciones

Cdigo Revisin Fecha Pgina

GEM-MDSI-DO-04 0 15/feb/2007 8 de 11

La Pre/Post condiciones son una manera de describir la funcin que debe realizar un proceso, sin decir mucho acerca del algoritmo o procedimiento que se utilizar. Es til cuando: El usuario tiene tendencia a expresar la poltica llevada a cabo por la burbuja en trminos de un algoritmo particular que ha estado utilizando durante dcadas. El analista esta razonablemente seguro de que existen distintos algoritmos que pueden usarse. El analista desea que el programador explore varios de estos algoritmos pero no quiere involucrarse personalmente con tales detalles y, sobre todo, no quiere enredarse en discusiones con el usuario acerca del mrito relativo de cada uno.

Existen dos partes principales del proceso precondiciones y postcondiciones. Las precondiciones describen todas las cosas que deben darse antes de que el proceso pueda comenzar a ejecutarse. Tpicamente las precondiciones describirn: Qu entradas se encuentran disponibles. Estas entradas llegan mediante un flujo conectado con un proceso. Puede haber casos en los que diversos flujos entran a un proceso, pero solo uno de ellos es precondicin necesaria para que se active el proceso. Qu relacin debe existir entre las entradas. Una precondicin puede especificar que deben llegar dos entradas con campos que corresponden, o que un componente de un dato de entrada debe estar dentro de cierto intervalo. Qu relaciones deben existir entre entradas y almacenes de datos. Una precondicin puede estipular que exista un registro dentro de un almacn que corresponda con algn aspecto de un dato de entrada. Qu relaciones deben existir entre diferentes almacenes o dentro de un almacn dado. Es decir, la precondicin podra establecer que hay un pedido en el almacn de pedidos cuyo nmero de cuenta del cliente en el almacn de clientes.

De manera similar, las postcondciones describen lo que debe darse cuando el proceso ha concluido. Las postcondciones tpicas describen: Las salidas que generar o producir el proceso. Esta es la forma ms comn. Las relaciones que existirn entre los valores de salida y los valores de entrada. La salida puede ser una funcin matemtica directa de un valor de la entrada. Las relaciones que existirn entre valores de salida y los valores en uno o varios de los almacenes. Cuando la informacin debe recuperarse de un almacn y utilizarse como parte de la salida de un proceso. Los cambios que se hayan dado en los almacenes: Actualizaciones de las instancias.

Cuando se est construyendo una especificacin de pre/post condiciones se debe comenzar por describir las situaciones normales de proceso. Pudieran existir diversas situaciones normales diferentes, cada una de las cuales se expresa como precondicin distinguible e individual. Para cada una de estas precondiciones se debe describir la condicin de la burbuja del proceso cuando se han producido las salidas y se han modificado los almacenes. Despus de haber descrito las situaciones normales de proceso, deben incluirse precondiciones y postcondiciones apropiadas para los casos de error y casos anormales. Aunque el enfoque de pre/post condiciones sea bastante til y tenga un gran nmero de ventajas, hay ocasiones en las cuales puede no ser apropiado. La falta de pasos intermedios entre entradas (precondiciones) y salidas (postcondciones) es deliberada y consciente, pero puede volverse difcil de entender si el lector no visualiza algn tipo de procedimiento que lleve de las entradas a las salidas.

DOCUMENTO Herramientas para el Anlisis y Diseo Estructurado

Cdigo Revisin Fecha Pgina

GEM-MDSI-DO-04 0 15/feb/2007 9 de 11

Adems, si existen relaciones complejas entre entradas y salidas, podra ser ms fcil escribir una especificacin utilizando lenguaje estructurado. Tablas de Decisin Cuando el proceso debe producir alguna salida o tomar alguna accin basada en decisiones complejas, la mejor herramienta son las tablas de decisin. Una tabla de decisiones se crea listando todas las variables relevantes (condiciones) y todas las acciones relevantes (acciones). Las variables pueden ser lgicas, binarias y tambin multivaluadas. Se lista en columnas separadas cada combinacin posible de valores de las variables; cada columna usualmente se conoce como regla. Una regla describe una accin o acciones que deben llevarse a cabo para una combinacin especifica de valores de las variables. Por lo menos debe especificarse una accin para cada regla (esto es, para cada columna de la tabla de decisiones), o el comportamiento del sistema para tal situacin no quedar especificado. Si existe N variables con valores binarios (verdadero-falso), entonces existirn 2n reglas distintas. Debe discutirse cada regla con el usuario para asegurarse de que se ha identificado la accin o acciones correctas para cada combinacin de variables. Una de las ventajas del enfoque de la tabla de decisin es que no implica ningn tipo de implantacin. Es ms, las tablas de decisin se conocen como herramienta de modelado de sistemas que no es de tipo procedimiento, pues no especifica algn algoritmo. Pasos a seguir para la construccin de una tabla de decisin: 1. Identificar todas las condiciones, o variables, de la especificacin y los valores que estas pueden tomar. 2. Calcular el nmero de combinaciones de las condiciones 3. Identificar cada posible accin que se pide en la especificacin 4. Crear una tabla de decisiones vaca, listando todas las condiciones y acciones y numerando las combinaciones de las condiciones en la parte superior de la tabla (reglas). 5. Listar todas las combinaciones de condiciones, una para cada columna de la tabla. 6. Examinar cada columna e identificar las acciones apropiadas que se deben tomar 7. Identificar con el usuario las omisiones, contradicciones o ambigedades. rboles de decisiones Normalmente se los utiliza cundo un proceso de decisin se integra con ramificaciones complejas o cuando es necesario mantener una cadena de decisiones con una secuencia particular. Se dibujan sobre el plano horizontal, con la raz del rbol al lado izquierdo del papel y las ramas hacia la derecha. Esto permite al analista describir las condiciones de acciones sobre las ramas. Cuando se los dibuja es necesario distinguir entre condiciones y acciones. El uso de un nodo cuadrado indica una accin y un circulo representa una condicin. El uso de anotaciones hace ms accesible los rboles de decisiones. Al dibujar el rbol: Identifique todas las condiciones y las acciones, as como el orden y el momento de su ejecucin Comience a construir el rbol de izquierda a derecha, y cuando est seguro de haber anotado todas las alternativas posibles, pase a la derecha.

El rbol de decisin tiene tres ventajas:

DOCUMENTO Herramientas para el Anlisis y Diseo Estructurado

Cdigo Revisin Fecha Pgina

GEM-MDSI-DO-04 0 15/feb/2007 10 de 11

1. Toma la ventaja de la estructura consecutiva de las ramas del rbol de decisiones, de tal forma que se identifica de manera inmediata el orden de verificacin de las condiciones y acciones que se deben llevar a cabo. 2. Las condiciones y las acciones del rbol de decisiones se encuentran en ciertas ramas pero no en otras. 3. Al compararse con otras herramientas de especificaciones, se entienden con mas facilidad y son apropiados como mtodo de comunicacin. Balanceo de Modelos Cuando se modelan tres aspectos distintos de un sistema (funciones, datos y tiempos), adems de modelar las caractersticas detalladas del sistema en un diccionario de datos y un conjunto de especificaciones de procesos, es fcil desarrollar diversas interpretaciones diferentes e inconsistentes de esa misma realidad. Normalmente ocurre cuando los proyectos son muy amplios y/o cuando se involucra personas con muy diferentes preparacin. Otra de las razones para centrarse en la consistencia entre modelos es que los errores de posibles existencia en los sistemas es preferible y conveniente detectarlos en las etapas de anlisis y diseo y no en la de implementacin. El error ms comn de balanceo involucra alguna definicin faltante: algo que se define en un modelo y no se define en otro. El segundo tipo de error es de inconsistencia: la misma realidad se describe de dos maneras diferentes y contradictorias en dos o ms modelos diferentes. Las reglas de balanceo son muy claras pero deben seguirse. Balanceo de DFD y el DD Las reglas de balanceo del diagrama de flujo de datos y el diccionario de datos son las siguientes: Cada flujo de datos y cada almacn de datos deben estar definidos en el diccionario de datos. Si falta la definicin se considera indefinido. De manera inversa, cada dato y cada almacn que se define en el diccionario de datos debe aparecer en alguna parte del DFD. Si no aparece dicho dato es un fantasma.

Balanceo de DFD y EP Las reglas de balanceo del diagrama de flujo de datos y las especificaciones de proceso son las siguientes: Cada burbuja del DFD debe asociarse con un DFD de nivel inferior o con una especificacin de proceso, pero no ambas. Cada especificacin de proceso debe tener una burbuja de nivel inferior asociada en el DFD Las entradas y salidas de los DFD deben coincidir con ingreso y salidas de datos en las Especificaciones de proceso.

Balanceo de EP con DFD y DD Cada referencia de un dato en las especificaciones de proceso debe satisfacer una de las siguientes reglas: Coincide con el nombre de un flujo da datos o almacn conectado a la burbuja descrita por la especificacin de proceso Es un termino local, definido explcitamente en la especificacin de proceso Aparece como componente en una entrada del diccionario de datos para un flujo o almacn conectado con la burbuja.

DOCUMENTO Herramientas para el Anlisis y Diseo Estructurado Balanceo de DD con DFD y EP

Cdigo Revisin Fecha Pgina

GEM-MDSI-DO-04 0 15/feb/2007 11 de 11

El Diccionario de datos es consistente con el resto del modelo si obedece la siguiente regla: Cada entrada del diccionario de datos debe tener referencia en una especificacin de proceso, un diagrama de flujo de datos u otro diccionario de datos.

Balanceo de DER con DFD y EP Existen algunas relaciones que deben darse para que el sistema global sea completo, correcto y consistente: Cada almacn del DFD debe corresponder con un tipo de objeto, una relacin o un tipo de objeto asociativo. Los nombres de objetos en el DER y los nombres de almacenes de datos en el DFD deben coincidir Las entradas del diccionario de datos deben aplicarse tanto al modelo de DFD como al DER.

Conclusiones Con las herramientas anteriormente mencionadas: DFD, DER, DD y EP construidas durante el anlisis en el diseo se utilizar para crear una arquitectura de software, es decir, una jerarqua de mdulos (los que a veces se conocen como subrutinas o procedimientos) para realizar los requerimientos del sistema. Normalmente el diagrama que se utiliza es el diagrama de estructura (DE). Cada modelo grfico descrito se enfoca a un aspecto distinto de un sistema, y teniendo en cuenta el grado de complejidad de los sistemas es que se hace necesario estudiarlos por separado.