Captulo 5

Anlisis y Diseo Estructurado

5.1 Metodologa AS/DS

Que tipo de Modelo debemos construir ? 1. Construir un modelo de la implantacin del sistema actual ? 2. Construir uno de la implantacin nueva que se propone ? 3. Un modelo independiente de la tecnologa de implantacin ? 4. Las tres cosas ?

5.1.1

El enfoque del Modelo Clsico

Siempre se considero la construccin de cuatro modelos distintos a desarrollar, ellos son: Fsico Actual: el que esta actualmente empleando el usuario (manual, automatizado o mezcla). Lgico Nuevo: requerimientos puros o esenciales del sistema nuevo que el usuario quiere. Lgico Actual: es el modelo de los requerimientos puros o esenciales que realiza el sistema actual del usuario. Fsico nuevo: un modelo que muestre las limitaciones impuestas por el usuario, una de estas limitaciones es la frontera de automatizacin (es decir cuales funciones se automatizaran y cuales se desarrollaran manualmente). El modelo fsico es lo que llamamos modelo de implementacin del usuario. El enfoque clsico supone que: El analista puede no estar familiarizado con el rea de aplicacin o del negocio, por ello es importante que comience con un modelo fsico actual, luego transformar el modelo fsico en modelo lgico. El usuario puede estar renuente o imposibilitado para trabajar con el nuevo modelo lgico al principio. Ejemplo 5.1 Desconfa de la capacidad del analista, o no estar de acuerdo con l. 159

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO

Programa del proyecto
FISICO ACTUAL

160

Mdelo fsico actual

LOGICO ACTUAL

Mdelo lgico actual

LOGICO NUEVO

Mdelo lgico nuevo

FISICO NUEVO

Mdelo fsico nuevo

Figura~5.1: Los cuatro modelos de SA/SD La transformacin de un modelo lgico actual en un modelo lgico nuevo no requiere de mucho trabajo. Estas apreciaciones son correctas, pero normalmente se ignora el peligro de que desarrollar un modelo del sistema actual puede requerir de bastante tiempo y esfuerzo y hace que el usuario se frustre y termine cancelando el proyecto. No se tiene que modelar el Sistema Actual como un n en si mismo, sino como un medio para lograr el sistema de implementacin del usuario. Si existe la posibilidad de evitar el modelo del sistema actual, hay que evitarlo (perdida de tiempo, esfuerzo, etc). El nuevo sistema conocido como el nuevo sistema lgico, lo conocemos aqu como el modelo esencial del Sistema. El modelo esencial, es un modelo de lo que el sistema debe hacer para satisfacer los requerimientos del usuario, diciendo lo mnimo posible de como se har la implementacin.Esto signica que en la construccin del modelo se tiene disponible una tecnologa perfecta y que se puede obtener fcilmente y sin costo. De ninguna manera habra que asociarlo a la implementacin.

5.1.2

Dicultad en su construccin

Resulta muy difcil eliminar todos los detalles de implementacin en el modelo esencial, algunos ejemplos de esos detalles son: Secuenciado arbitrario de las actividades de un modelo de ujo de datos. El nico secuenciado en el diagrama de ujo de datos debe ser el que requieren los datos. Archivos innecesarios, es decir, los almacenes de datos que no se requeriran de existir una tecnologa perfecta. Los archivos temporales se requieren en un modelo

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO

161

de implantacin porque los procesos estn programados para hacer su trabajo en distintos tiempos; tambin se introducen para propsitos de respaldo y recuperacin, porque la Tecnologa de implantacin es propensa a errores, as como las personas que operan las computadoras. Revisin de errores y validacin innecesarias de datos y proceso dentro del sistema.. Dichas actividades de validacin se necesitan en un modelo de implantacin, porque se debe trabajar con procesos propensos a errores y canales ruidosos de datos entre procesos. Datos redundantes o derivados. Estos se incluyen a veces en los almacenes de datos para propsitos de eciencia; aunque esto usualmente es razonable, debe hacerse durante la fase de diseo del proyecto, y no durante el modelado de las funciones y datos esenciales. Tambin, sin darse cuenta, se pueden incluir datos derivables. El modelo esencial posee dos componente 1. Modelo ambiental (frontera entre el sistema y el resto del mundo) 2. Modelo de comportamiento. Describe el comportamiento para que interacte de manera exitosa en el ambiente (DFD, D-E-R., D.D, DTE, EP, etc). Existen circunstancias que es necesario desarrollar un modelo de implantacin (del sistema actual) antes de construir el modelo esencial (se puede deber a que el usuario no este convencido de que se entienda completamente su negocio, o simplemente que el analista necesita estudiar el ambiente actual antes de proponer un sistema nuevo). Una vez desarrollado el modelo de la implementacin actual, su tarea siguiente es denir en trminos lgicos, (eliminar detalles de implantacin) usualmente tiene los siguientes pasos: 1. Buscar y separar ujos esenciales que hayan sido empaquetados de manera arbitraria en el mismo medio. 2. Buscar ujos empaquetados o agregados que se envan a burbujas que no requieren de todos los datos que hay en dichos ujos. 3. Distinguir entre el trabajo esencial realizado por un proceso y la identicacin del procesador que aparece en el modelo de implantacin. 4. Eliminar procesos cuyo nica tarea sea transportar datos de un lugar a otro dentro del sistema. 5. Eliminar proceso cuya labor sea vericar datos que se producen y usan dentro del sistema. 6. Buscar situaciones donde los almacenes esenciales se hayan empaquetado en el mismo almacn.

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO

162

7. Eliminar datos de los almacenes si ningn proceso los utiliza. Eliminar datos de los almacenes que sean derivables o calcular. 8. Eliminar almacenes de datos que solo existan como separadores de tiempo entre procesos y que sean dependientes de la implantacin. Esto incluye archivos intermedios, archivos de reportes, archivos de impresin y otros similares.

5.2

El Modelo Ambiental

Cualquier sistema que se desarrolle ser siempre parte de un sistema mayor, por ello, el primer modelo importante que se debe desarrollar es uno que dena la interfaz entre el Sistema y el resto del Universo (el ambiente), este modelo es lo que conocemos como modelo ambiental., modelo exterior del sistema.

EL AMBIENTE

EL SISTEMA

Figura~5.2: Frontera entre el Sistema y el ambiente As, el primer modelo importante que se debe desarrollar es uno que no haga ms que denir las interfases entre el sistema y el resto del universo, es decir, el ambiente (modela el exterior del sistema). El modelo del interior de sistema se conoce como modelo de comportamiento. Los sistemas que construimos son racionales y tienen propsito; especcamente, producen salidas como respuestas a algn acontecimiento, o estimulo, en el ambiente. As, otro aspecto critico del modelo ambiental consiste en identicar los acontecimientos que ocurren en el ambiente al cual debe responder el sistema. Solo nos debe preocupar aquellos acontecimientos que ocurran en el ambiente exterior y requieren una respuesta del Sistema. La frontera entre el Sistema y su ambiente es arbitraria. A menudo existe una rea gris que esta abierta a negociaciones, un rea sobre el cual el usuario no esta seguro, no haba pensado, tenia algunas idea ya hechas al respecto, o todas las anteriores. Factores a tener en cuenta cuando se escoja la perspectiva del proyecto: El deseo del usuario de lograr una cierta participacin en el mercado para el producto o incrementarlas a mas de su nivel actual. Esto puede hacerse ofreciendo un nuevo producto o una mayor funcionalidad de uno existente ofreciendo un servicio mas rpido y eciente.

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO La legislacin establecida por el Gobierno Federal, Estatal o de la Ciudad.

163

El deseo del usuario por minimizar gastos operativos de algn rea de su negocio. Deseo del usuario por lograr alguna ventaja estratgica para la lnea de productos o rea de negocios que opera. El rea dentro de la frontera del sistema a veces se conoce como el dominio de cambios. Herramientas para denir el ambiente 1. Declaracin de propsitos 2. Diagrama de contexto 3. Lista de acontecimientos

5.2.1

Declaracin de Propsitos

Es una declaracin textual breve y concisa del propsito del Sistema, dirigida al administrativo superior.- Tambin algn analista sugieren que la declaracin de propsito debe incluir un resumen de benecios tangibles y cuanticables a tal vez un anlisis de costobenecios.

5.2.2

El diagrama de contexto

En una solo burbuja se debe representar todo el sistema.

pedido-inmueble pedido-recepcionado LOCATARIO INMOBILIARIA LOCADOR

inmueble-otorgado inmueble_ofertado

Figura~5.3: Diagrama de Contexto Enfatiza las siguientes caractersticas: Las personas, organizaciones y sistemas con los que se comunica nuestro sistema, se conoce como terminadores. Los datos que recibe del mundo exterior. Los datos que el sistema produce y que se envan al mundo exterior. Los almacenes de datos que el sistema comparte con los terminadores. La frontera entre el sistema y el resto del mundo.

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO

164

5.2.3

Lista de acontecimientos

Es una lista narrativa de los estmulos que ocurren en el mundo exterior a los cuales el sistema debe responder. En la lista especicamos con las letra: F: ujo T: temporal C: Control El orientado a ujos es el que se asocia con un ujo de datos; es decir, el sistema se da cuenta de que ha ocurrido el acontecimiento cuando llega algn dato (o varios). No existe una correspondencia uno a uno entre los ujos de datos del diagrama de contexto y los acontecimientos de la lista de acontecimientos. En general, cada ujo de datos es un acontecimiento (o, ms precisamente, la indicacin de que ha ocurrido), o bien es requerido por el sistema para poder procesar un acontecimiento. Los acontecimientos temporales, como su nombre lo indica, arrancan con la llegada de un momento dado en el tiempo. Algunos ejemplos de acontecimientos temporales pudieran ser: Ejemplo 5.2 A las 10:00 Hs de la maanas se requiere que el resguardo de la informacin este completo Ejemplo 5.3 La emisin de chequeras de pago debe estar completo para la semana entrante Los acontecimientos temporales no se inician con ujos de datos de entrada; podria imaginarse que el sistema tiene un reloj interno con el cual puede determinar el paso del tiempo. Estos acontecimientos pueden requerir que el, sistema solicite entradas de uno o mas terminadores. Por ello podran asociarse uno o ms ujos de datos con un acontecimiento temporal, aunque los ujos de datos, en si, no representan el acontecimiento mismo. Los acontecimientos de control deben considerarse un caso especial del acontecimiento temporal. Un estimulo externo que ocurre en algn 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 ujo normal, el de control no indica su presencia con el arribo de datos. El ujo de control puede considerarse como un ujo de datos binario (on-o). Los sistemas de informacin de negocios no suelen tener ujos de control en sus diagramas de contexto. Como componentes adicionales del modelo ambiental tenemos: Los DD iniciales, que dene todos los ujos y almacenes externos Los D E-R de los almacenes externos

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO

165

5.2.4

Construccin del modelo ambiental

A pesar de que el desarrollo del modelo ambiental parezca simple y directa, a menudo resulta que requiere de una gran cantidad de trabajo; adems; usualmente se desarrolla como una serie de renamientos iterativos, con datos adicionales que se aaden y renan. Una razn importante por la cual muchos renamientos y revisiones suelen ser necesarios es que normalmente una sola persona no puede comprender la perspectiva completa del sistema como se deni inicialmente. SI el proyecto involucra un nuevo sistema que remplazara a uno existente, es posible hablar con los usuarios que actualmente llevan a cabo sus funciones. Es importante dedicar una buena cantidad de tiempo y energa 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 echo, a veces es la nica parte del modelo global del sistema que muchos usuarios y administradores de alto nivel llegaran a ver (los que tienen la decisin de continuar o no con el proyecto). El diagrama de contexto consiste en terminadores, ujos de datos y ujos de control, almacenes de datos y un solo proceso que representa a todo el sistema. La parte ms fcil del diagrama de contexto es el proceso, el nombre dentro del proceso suele ser el nombre del sistema completo o un acrnimo convenido. Los terminadores se comunican directamente con el sistema a travs de ujos de datos o de control, o travs de almacenes externos. Los terminadores no se comunican directamente entre si. Algunos terminadores tienen un gran nmero de entradas y salidas, para evitar un diagrama innecesariamente atiborrado conviene dibujar el terminador mas de una vez, en este caso los terminadores duplicados se los identica con asteriscos. Cuando el terminador es una persona conviene o es preferible indicar el rol que desempea, ms que su identidad. Es indispensable distinguir las fuentes y manejadores cuando se dibujan terminadores en el, diagrama de contexto. Un manejador es un mecanismo, dispositivo, o medio fsico usado para transportar datos hacia dentro o fuera del sistema. La tendencia es mostrar al manejador en lugar de la verdadera fuente de los datos. Tendramos que evitar mostrar los manejadores, puesto que el nuevo sistema generalmente tendr opcin de cambiar la tecnologa mediante la cual los datos se introducen y sacan del sistema. Los ujos que aparecen en el diagrama de contexto modelan datos que entran y salen del sistema, adems de las seales de control que recibe o genera. Los ujos 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 para producir una respuesta. Tambin estos ujos pueden aparecer para ilustrar los datos que son transportados entre los terminadores por el sistema. Finalmente, los ujos de datos se muestran en el diagrama de contexto cuando el sistema produce datos para responder a un acontecimiento. Se debe dibujar 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. En los casos que el terminador no inicie las entradas (el terminador no sabe que el sistema requiere sus entradas) y que el sistema no inicie la generacin de salidas debe mostrarse el mensaje como una parte esencial del sistema. La lista de acontecimiento es un listado sencillo de los acontecimientos del ambiente

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO

166

a los cuales debe responder el sistema. Al crear esta lista se debe distinguir entre un acontecimiento y un ujo relacionado con un acontecimiento. La manera ms fcil de identicar los acontecimientos relevantes para un sistema es visualizarlo en accin: examinar cada terminador y preguntar que efecto pueden tener sus acciones sobre el sistema. Debe distinguirse entre acontecimientos discretos que se han empaquetado accidentalmente como si fueran uno solo; esto sucede a menudo con acontecimientos de tipo ujo. Debe examinarse el terminador candidato y preguntar si todas sus instancias involucran los mismos datos, si en algunas instancias estn presentes los datos, y ausentes en otras, podria en realidad haber dos acontecimientos distintos. La lista de acontecimientos debe incluir no solo las interacciones normales entre el sistema y sus terminadores sino tambin situaciones de falla. Dado que se esta 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. Cabra preguntarnos Que se hace primero, el diagrama de contexto o la lista de acontecimientos ?, la respuesta es NO IMPORTA mientras se produzcan ambos componentes del modelo ambiental y se revisen para asegurar que sean consistentes. Cuando se termine con ambos componentes del modelo ambiental ser posible conrmar lo siguiente: El sistema necesita cada ujo 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 ujo de salida debe ser respuesta a un acontecimiento. Cada acontecimiento no temporal de la lista de acontecimientos debe tener entradas a partir de las cuales el sistema puede detectarlo. Cada acontecimiento debe producir salidas inmediatas como respuesta o bien almacenar los datos que luego sern salidas, o debiera ocasionar un cambio en el estado del sistema.

5.3

El Modelo preliminar de comportamiento

Una vez nalizado la consistencia del modelo ambiental y vericado por todos los integrantes del grupo de anlisis, se comienza a construir el modelo de comportamiento o modelo exterior del sistema. Se debe construir el modelo de comportamiento del sistema, es decir el modelo de comportamiento nal que el sistema debe tener para manejar con xito el ambiente, esto involucra el desarrollo de un diagrama de ujo de datos y un diagrama de E-R preliminares , adems de la elaboracin de entradas iniciales del diccionario. Existen tres enfoques en el desarrollo del modelo de comportamiento: 1. El enfoque descendente clsico 2. El ascendente 3. El medio

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO

167

5.3.1

El enfoque clsico

Se procede la nica burbuja del diagrama de contexto a un DFD de nivel Superior (Nivel 0), en donde cada burbuja representa un Subsistema Principal, cada burbuja del nivel 0, se parte a continuacin en guras de nivel inferior u cada burbuja de nivel inferior se parten aun mas, etc, hasta llegar a un nivel de burbujas atmicas (no requiere de mayor descomposicin). Problemas en el presente enfoque: Parlisis del anlisis El fenmeno de un a X -cantidad de analistas Particin fsica arbitraria

5.3.2

El enfoque medio

Este requiere (despus de desarrollar DFD inicial) una nivelacin ascendente y tambin podra necesitarse alguna particin descendente. El enfoque es el siguiente: 1. Se dibuja una burbuja o proceso por cada acontecimiento de la lista. 2. La burbuja se nombra describiendo la respuesta que el sistema debe dar al acontecimiento asociado. 3. Se dibujan las entradas y salidas apropiadas de tal forma que la burbuja pueda dar repuesta requerida y se dibujan los almacenes, como sea apropiado, para la comunicacin entre burbujas. 4. El borrador de DFD que resulta se compara con el diagrama de contexto y la lista de acontecimientos para asegurar que este completo y sea consistente. El primer paso es directo, si existieran 30 acontecimientos en la lista, se deben dibujar 30 burbujas. El segundo paso tambin es directo: a cada burbuja se la da un nombre apropiado, basado en la respuesta requerida. Esto signica que se debe examinar el acontecimiento y preguntarnos que respuesta debe dar el sistema a este acontecimiento?. El tercer paso no es mecnico, pero usualmente es bastante directo, para cada burbuja dibujada, identique las entradas que requiere para efectuar su trabajo. Identique las salidas (si las hay) que cada una produce e identique los almacenes a los que cada burbuja debe tener acceso. Esto se logra entrevistando a los usuarios. En muchos casos el acontecimiento esta determinado por el ujo; esto signica que el sistema detecta la ocurrencia de un acontecimiento por la llegada de algn dato de un terminador externo. Obviamente, esto signica que el ujo de datos apropiado debe estar conectado al proceso requerido para responder a tal acontecimiento. De manera similar, como parte de la respuesta dibuje las salidas adecuadas producidas por el proceso. Esto implicara devolver salidas a los terminadores fuera del sistema, sin

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO

168

embargo, puede tambin involucrar salidas que se envan a los almacenes de datos, para ser usadas como entradas de otros procesos. El cuarto paso es una actividad de vericacin de consistencia, similar a los pasos de balanceo de modelos. Verique que cada entrada del diagrama de contexto para ver se esta asociada con alguna entrada de alguno de los procesos del DFD preliminar; y verique tambin que cada salida producida por algn proceso en el DFD preliminar se envi a un almacn o sea una salida externa incluida en el diagrama de contexto. Existen dos casos especiales: Acontecimientos nicos que causan respuestas mltiples Acontecimientos mltiples que causan la misma respuesta. En todos estos casos ninguno de los procesos en el diagrama de ujo de datos preliminar est conectado con otro: las burbujas no se comunican directamente con otras. En lugar de ello se comunican entre si a travs de otros almacenes de datos. Esto es debido a que las burbujas en el diagrama preliminar representan respuestas a acontecimientos, y los acontecimientos que ocurren en el ambiente externo son no sincronizados y dado que la respuesta a un acontecimiento puede requerir datos producidos por algn otro y, no hay forma de saber cuando ocurrirn los acontecimientos, y debe suponerse, en un modelo esencial, que cada proceso realizara su labor de manera innitamente rpida, y cada ujo de datos acta como conducto que puede transmitir datos con rapidez innita, se sigue que la nica forma de sincronizar mltiples acontecimientos interdependientes es mediante un almacn.

5.3.3

Desarrollo del Modelo Inicial de Datos

Como el D E-R y DFD se desarrollan en paralelo, pueden usarse para revisarse entre si. Adems la lista de acontecimientos es muy til para crear del D E-R y el DFD inicial. El modelo de comportamiento inicial, una vez terminado, no se lo puede presentar al usuario debido a su complejidad (DFD, DER, etc), muchas burbujas, etc, lo que implica que necesitara un renamiento para eliminar y/o aadir objetos. Adems presenta un segundo inconveniente, que el modelo de comportamiento inicial son grcos casi sin ningn apoyo de textos.

5.4
5.4.1

El Modelo de Comportamiento
Terminado del Modelo de Comportamiento

El modelo inicial de comportamiento no puede ser presentado al usuario debido a su complejidad (DFD con 40 o mas burbujas, el DER con deniciones muy gruesas, compuesto bsicamente de gracas y poco apoyo de texto, etc).

5.4.2

Terminado del Modelo de Proceso

Nivelacin del DFD preliminar Reorganizar el DFD (posee muchas burbujas), necesita de nivelacin ascendente, es decir, agrupar procesos relacionados en agregados con signicado.

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO Existen tres reglas al hacer esto:

169

1. Con la agrupacin de procesos deben involucrar respuestas relacionadas cercanamente. 2. Busque oportunidad de esconder o enterrar datos almacenados que aparecen en nivel inferior. Si ve un grupo de procesos en los DFD preliminares que se reeren a un almacn comn, y no hay otros procesos en los DFD preliminares que se reeren a este almacn, entonces puede crear una burbuja de nivel superior para esconderlo. 3. Tenga presente que la persona que ve sus DFD, sea un usuario u otro analista, no quiere ver demasiado a la vez. Por ello, cree agregados o grupos del DFD preliminar que consistan en aproximadamente. Muchas veces necesitan de una nivelacin descendente. Cuando los procesos descriptos en el DFD son muy complejos para describirlos en una especicacin de proceso, tal vez sea necesario una nivelacin descendente, es decir, construir un DFD de nivel inferior. Pasos para llevar a cabo una nivelacin descendente En algunos casos es apropiado un enfoque de descomposicin funcional pura, es decir, si encuentra una burbuja de proceso que realiza una funcin compleja, trate de identicar subfunciones, cada una de las cuales puede se hecha por una burbuja de nivel inferior. En otros casos , los ujos de datos de entradas y salidas proporcionaran la mejor gua para la nivelacin descendente.

5.4.3

Como completar el DD

En esta etapa (terminado del modelo) es necesario llenar la descripcin del signicado de cada dato, tambin se hace necesario dividir los datos complejos en elementos menores. Hay que vericar que este completo y sea consistente (que ninguna parte contradiga a la otra), que este balanceado con los DFD, DER y las EP.

5.4.4

Como completar las especicaciones de procesos

No inicie la escritura de las especicaciones de proceso antes de concluir con el DFD preliminar. Cuando el DFD comience a estabilizarse, cuado ha pasado la prueba de la nivelacin ascendente, entonces puede comenzar a escribir las especicaciones de proceso. Por ultimo, recuerde que las EP deben balancear con los DD y el DER.

5.4.5

Terminado del modelo de datos

De la misma forma que los DFD, se empieza con un DER tosco y luego se rena y se mejora. Tenga en mente que la mayora de las veces el DER se desarrolla al mismo tiempo que el DFD.

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO

170

5.5

El Modelo de Implementacin

Terminamos de desarrollar el Modelo esencial de un sistema de informacin, este tiene una descripcin completa de lo que el sistema debe hacer, especcamente describe: La poltica o lgica esencial de las funciones que se requiere realizar. El contenido esencial de los datos que almacena el Sistema y que se mueven a travs de l. El comportamiento esencial dependiente del tiempo que el sistema debe exhibir para manejar seales e interrupciones del ambiente exterior. Con esta informacin seria suciente para los diseadores y programadores: se les dara el modelo esencial y se les permitira escoger el mejor HARD, sistema operativo, sistema de administracin de base de datos y el lenguaje de programacin, dentro de las restricciones globales del proyecto, en tiempo, dinero y recursos humanos. No obstante seria necesario informacin adicional sobre cuestiones de implementacin. El asunto de implementacin de inters para el usuario es la frontera de automatizacin, es decir, cuales parte del modelo esencial se van a implementar con la computadora y cuales se van a realizar manualmente por personal de la Organizacin. Es de inters para el usuario, mas que las funciones de Sistema, las entradas y salidas del mismo, este inters se va acrecentando por varias opciones y posibilidades que han aumentado la importancia de estas cuestiones de implantacin. Algunas de ellas son: Los usuarios nales tienen oportunidades de usar computadoras personales como parte de una red distribuida de computadoras. Cabra preguntarnos Que parte del modelo esencial se asignaran las PC ? Cuales se compartirn ?. Los usuarios nales tienen oportunidad de escribir sus propios programas en lenguajes de cuarta generacin. Se podria construir un prototipo de porciones del sistema utilizando un lenguaje de cuarta generacin o un paquete de generacin de aplicaciones. Otra opcin es la eleccin y compra de un paquete de software. Que parte de las funciones esenciales las implementar el paquete y cuales tendr que hacer el usuario ?. Todas estas cuestiones deben tratarse como parte del modelo de implementacin del usuario. De manera generalizada, este cubre cuatro puntos: 1. Distribucin del modelo esencial entre personas y maquinas. 2. Detalle de la interaccin humano-maquina. 3. Actividades manuales que se podran requerir. 4. Restricciones operativas que el usuario desea imponer al Sistema.

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO

171

5.5.1

Determinacin de la frontera de automatizacin

Que funciones y que datos se manejaran manualmente y cuales se automatizaran. Esta es la cuestin. Aunque el usuario quiere que se desarrolle un sistema automatizado, tambin necesita una declaracin bien hecha de los requerimientos de las funciones y datos que queden fuera de la frontera de automatizacin. Existen tres casos: 1. Al usuario no le importa donde esta la frontera de automatizacin. 2. El usuario escoge un sistema totalmente automatizado. 3. El usuario escoge un sistema completamente manual.

5.5.2

Determinacin de la interfaz humana

Es la actividad que consume mas tiempo y lo que mas interesa al usuario. Involucra cuatro partes. 1. Eleccin de los tipos de entradas y salidas. 2. El formato de las entradas. 3. El formato de las salidas. 4. La secuencia y los tiempos de I/O en un sistema en lnea. Nota 5.1 Sobre este tema en particular se lo desarrolla completamente en el capitulo 10.

5.5.3

Identicacin de las actividades de apoyo manual adicional

El usuario puede o no aceptar la existencia de una tecnologa perfecta en el modelo esencial o puede decidir que ciertas porciones del sistema automatizado estn bajo su propio control operacional, o pueden existir normas legales que aseguren la integridad de los datos. Cualquiera sea el caso, estas actividades de apoyo adicional se representaran por medios de nuevos procesos en el DFD del modelo de comportamiento. Generalmente tenemos que preocuparnos por la posibilidad de la tecnologa defectuosa en algunas reas principales: Ingreso de datos al sistema Realizacin de los clculos Almacenamiento a largo plazo Salida de datos del sistema Entrada o salidas redundante Tecnologa de procesador redundante Redundancia interna Controles por lote Vericaciones secuenciales

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO

172

5.5.4

Especicaciones de restricciones operacionales

El equipo de implantacin tendr que decidir la combinacin de Hardware, sistema operativo, equipo de telecomunicaciones, lenguajes de programacin y estrategias de diseo para implementar mejor los requerimientos. A continuacin se describen algunas cuestiones tpicas de las restricciones operativas, restricciones que el modelo esencial evita: Volumen de datos Tiempo de respuesta a las diversas entradas Restricciones polticas sobre modalidades de implantacin Restricciones ambientales Restricciones de conabilidad Restricciones de seguridad

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO

173

5.6

Preguntas y Ejercicios de Revisin

1. Enumere y describa las cuatro modelos que propone el SA/SD. 2. Describa los problemas que se presentan en la construccin de los cuatro modelos del SA/SD. 3. Dena Modelo Ambiental. Sus componentes. 4. Enumere y describa los requerimientos para la construccin del Modelo Ambiental. 5. Dena el Modelo Preliminar. Sus enfoques. 6. Dena el Modelo de Comportamiento. Herramientas. 7. Como se debe complementar el Diccionario de Datos en el Modelo de Comportamiento. 8. Como se debe complementar las Especicaciones de Proceso en el Modelo de Comportamiento. 9. Que entiende por Terminado del Modelo de Datos. 10. Dena el Modelo de Implementain. 11. Que entiende poor Frontera de Automatizacin. 12. Que entioende por Determinacin de la Interface Humana. 13. Que entiende por la Identicacin de loas Actividades de Apoyo Manual.

CAPTULO 5. ANLISIS Y DISEO ESTRUCTURADO

174

Referencia Bibliogrcas

[7] E. Yourdon. Anlisis y Diseo Estructurado. Yourden Press, 1980.

Parte III

Anlisis y Diseo Orientado a Objetos

175