Análisis y Diseño Estructurado

Transcripción

1 Capítulo 5 Análisis y Diseño Estructurado 5.1 Metodología AS/DS Que tipo de Modelo debemos construir? 1. Construir un modelo de la implantación del sistema actual? 2. Construir uno de la implantación nueva que se propone? 3. Un modeloindependientede latecnología deimplantación? 4. Las tres cosas? El enfoque del Modelo Clásico Siempre se considero la construcción de cuatro modelos distintos a desarrollar, ellos son: Físico Actual: el que esta actualmente empleando el usuario (manual, automatizado o mezcla). Lógico Nuevo: requerimientos puros o esenciales del sistema nuevo que el usuario quiere. Lógico Actual: es el modelo de los requerimientos puros o esenciales que realiza el sistema actual del usuario. Físico nuevo: un modelo que muestre las limitaciones impuestas por el usuario, una de estas limitaciones es la frontera de automatización (es decir cuales funciones se automatizaran y cuales se desarrollaran manualmente). El modelo físicoes loque llamamos modelo de implementación del usuario. El enfoque clásico supone que: ² El analista puede no estar familiarizado con el área de aplicación o del negocio, por ello es importante que comience con un modelo físico actual, luego transformar el modelofísicoen modelológico. ² El usuario puede estar renuente o imposibilitado para trabajar con el nuevo modelo lógico al principio. Ejemplo 5.1 Desconfía de la capacidad del analista, o no estar de acuerdo con él. 159

2 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 160 Programa del proyecto FISICO ACTUAL Módelo físico actual LOGICO ACTUAL Módelo lógico actual LOGICO NUEVO Módelo lógico nuevo FISICO NUEVO Módelo físico nuevo Figura~5.1: Los cuatro modelos de SA/SD ² La transformación deun modelológicoactual en un modelo lógiconuevo norequiere de mucho trabajo. Estas apreciaciones son correctas, pero normalmente se ignora el peligro de que desarrollar un modelodel sistema actual puede requerir de bastante tiempo y esfuerzoy 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 implementación del usuario. Si existelaposibilidad deevitarel modelodel sistemaactual, hayqueevitarlo (perdida de tiempo, esfuerzo, etc). El nuevo sistema conocido como el nuevo sistema lógico, 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 mínimo posibledecomo se harála implementación.- Esto signi ca que en la construcción del modelo se tiene disponible una tecnología perfecta y que se puede obtener fácilmente y sin costo. De ninguna manera habría que asociarlo a la implementación Di cultad en su construcción Resulta muy difícil eliminar todos los detalles de implementación 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 requerirían de existir unatecnologíaperfecta. Los archivostemporales serequieren en un modelo

3 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 161 de implantación porque los procesos están programados para hacer su trabajo en distintos tiempos; también seintroducen parapropósitos derespaldoyrecuperación, porque la ² Tecnología de implantación es propensa a errores, así como las personas que operan las computadoras. ² Revisión de errores y validación innecesarias de datos y proceso dentro del sistema.. Dichas actividades de validación senecesitan en un modelo de implantación, porque sedebe trabajar con procesospropensos aerrores y canales ruidososdedatos entre procesos. ² Datos redundantes oderivados. Estos se incluyen aveces en los almacenesdedatos para propósitos de e ciencia; aunque esto usualmente es razonable, debe hacerse durante la fase de diseño del proyecto, y no durante el modelado de las funciones y datos esenciales. También, sin darsecuenta, sepueden 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 interactúe de manera exitosa en el ambiente (DFD, D-E-R., D.D, DTE, EP, etc). Existen circunstancias que es necesario desarrollar un modelo de implantación (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 vezdesarrolladoel modelode laimplementación actual, su tareasiguiente es de - nir en términos lógicos, (eliminar detallesde implantación) usualmente tienelos siguientes pasos: 1. Buscary separar ujosesenciales quehayan sidoempaquetadosdemaneraarbitraria en el mismo medio. 2. Buscar ujos empaquetadosoagregados que seenvían aburbujas que norequieren de todos los datos que hay en dichos ujos. 3. Distinguir entre el trabajo esencial realizado por un proceso y la identi cación del procesador que aparece en el modelo de implantación. 4. Eliminarprocesoscuyoúnicatareaseatransportardatos de un lugar aotrodentro del sistema. 5. Eliminar proceso cuya labor sea veri car datos que se producen y usan dentro del sistema. 6. Buscar situaciones donde los almacenes esenciales se hayan empaquetadoen el mismo almacén.

4 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO Eliminardatos delosalmacenes si ningún procesolos utiliza. Eliminar datosde los almacenes quesean derivables ocalcular. 8. Eliminaralmacenesde datos quesoloexistan comoseparadoresde tiempoentre procesos y que sean dependientes delaimplantación. Esto incluyearchivosintermedios, archivos de reportes, archivos de impresión 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 de na 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 más que de nir 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 propósito; especí camente, producen salidas como respuestas a algún acontecimiento, o estimulo, en el ambiente. Así, otro aspecto critico del modelo ambiental consiste en identi car los acontecimientos que ocurren en el ambiente al cual debe responder el sistema. Solonosdebepreocuparaquellos acontecimientosqueocurran en el ambienteexterior 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 había 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 ciertaparticipación en el mercado para el producto o incrementarlas a mas desu nivel actual. Estopuedehacerseofreciendo un nuevo producto o una mayor funcionalidad de uno existente ofreciendo un servicio mas rápido y e ciente.

5 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 163 ² La legislación establecida por el Gobierno Federal, Estatal o de la Ciudad. ² El deseo del usuario por minimizar gastos operativos de algún área de su negocio. ² Deseo del usuario por lograr alguna ventaja estratégica para la línea de productos o área de negocios que opera. El áreadentro delafrontera del sistemaaveces se conocecomoel dominio decambios. Herramientas para de nir el ambiente 1. Declaración de propósitos 2. Diagrama de contexto 3. Lista de acontecimientos Declaración de Propósitos Es una declaración textual breve y concisa del propósito del Sistema, dirigida al administrativo superior.- También algún analista sugieren que la declaración de propósito debe incluir un resumen de bene cios tangibles y cuanti cables a tal vez un análisis decostobene cios El diagrama de contexto En una solo burbuja se debe representar todo el sistema. pedido-inmueble LOCATARIO INMOBILIARIA pedido-recepcionado LOCADOR inmueble-otorgado inmueble_ofertado Enfatiza las siguientes características: Figura~5.3: Diagrama de Contexto ² 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 envían al mundo exterior. ² Los almacenes de datos que el sistema comparte con los terminadores. ² La frontera entre el sistema y el resto del mundo.

6 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO Lista de acontecimientos Es una lista narrativa de los estímulos que ocurren en el mundo exterior a los cuales el sistema debe responder. En lalistaespeci camoscon 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 algún 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, más precisamente, laindicación de queha ocurrido), obien es requerido por el sistema para poder procesar un acontecimiento. Los acontecimientos temporales, como su nombre lo indica, arrancan con lallegada de un momento dado en el tiempo. Algunos ejemplos de acontecimientos temporales pudieran ser: Ejemplo 5.2 A las 10:00Hs de lamañanas se requiere que elresguardo de lainformación este completo Ejemplo 5.3 La emisión 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 podrían asociarse uno o más ujos de datos con un acontecimiento temporal, aunque los ujos dedatos, en si, no representan el acontecimiento mismo. Los acontecimientos decontrol deben considerarse un caso especial del acontecimiento temporal. Un estimuloexterno que ocurreen algún momentoimpredecible. 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 noindica su presencia con el arribo de datos. El ujo de control puede considerarse como un ujo de datos binario (on-o ). Los sistemas de información de negocios nosuelen tener ujos de control en sus diagramas de contexto. Como componentes adicionales del modelo ambiental tenemos: ² Los DD iniciales, que de ne todos los ujos y almacenes externos ² Los D E-R de los almacenes externos

7 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO Construcción 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; además; usualmente se desarrolla comounaseriedere namientositerativos, con datos adicionalesqueseañaden yre nan. Una razón importante por lacual muchos re namientos y revisiones suelen ser necesarios es que normalmente una sola persona no puede comprender la perspectiva completa del sistema como se de nió 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 energía 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 únicaparte del modelo global del sistema que muchos usuarios y administradores de alto nivel llegaran a ver (los que tienen la decisión 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 más fácil del diagrama de contexto es el proceso, el nombre dentro del proceso suele ser el nombre del sistema completo o un acrónimo convenido. Losterminadoressecomunican directamentecon el sistemaatravés de ujosdedatoso decontrol, otravésdealmacenesexternos. Losterminadoresnosecomunican directamente entre si. Algunos terminadores tienen un gran número deentradas y salidas, paraevitar un diagrama innecesariamente atiborrado conviene dibujar el terminador mas de unavez, en este caso los terminadores duplicados se los identi ca con asteriscos. Cuando el terminador es una persona conviene o es preferible indicar el rol que desempeña, más que su identidad. Es indispensabledistinguirlasfuentesy manejadorescuandosedibujan terminadores en el, diagramadecontexto. Un manejador es un mecanismo, dispositivo, o medio físico usado paratransportar datos hacia dentroo fuera del sistema. La tendencia es mostrar al manejador en lugar de la verdadera fuente de los datos. Tendríamos que evitar mostrar los manejadores, puesto queel nuevo sistemageneralmente tendrá opción de cambiar la tecnología 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, además de las señales 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. También estos ujos pueden aparecer parailustrarlos 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 generación 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

8 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 166 a los cuales debe responder el sistema. Al crear esta lista se debe distinguir entre un acontecimientoy un ujorelacionadocon un acontecimiento. La manera más fácil de identi car los acontecimientos relevantes para un sistema es visualizarlo en acción: 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 susinstanciasinvolucran los mismos datos, si en algunas instancias están 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 también situaciones de falla. Dado que se esta creando un modelo esencial, no hay que preocuparse por fallas del sistema; pero se deben tomar en cuentaposiblesfallas oerrores causadas por los terminadores. Cabría preguntarnos Que se hace primero, el diagrama de contexto o la lista de acontecimientos?, larespuesta es NOIMPORTA 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 con rmar 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 ujodesalida debeser respuestaaun acontecimiento. ² Cada acontecimientonotemporal de la lista de acontecimientos debe tener entradas a partir de las cuales el sistema puede detectarlo. ² Cadaacontecimientodebeproducir salidas inmediatascomorespuestaobien almacenar losdatosque luegoserán salidas, odebieraocasionar un cambioen el estado del sistema. 5.3 El Modelo preliminar de comportamiento Una vez nalizado la consistencia del modelo ambiental y veri cado por todos los integrantes del grupo de análisis, 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, además de la elaboración de entradas iniciales del diccionario. Existen tres enfoques en el desarrollo del modelo de comportamiento: 1. El enfoque descendente clásico 2. El ascendente 3. El medio

9 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO El enfoque clásico 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 continuación en guras denivel inferior u cada burbuja de nivel inferior se parten aun mas, etc, hasta llegar a un nivel de burbujas atómicas (no requiere de mayor descomposición). Problemas en el presente enfoque: ² Parálisis del análisis ² El fenómenodeun ax -cantidad deanalistas ² Partición físicaarbitraria El enfoque medio Este requiere (después de desarrollar DFD inicial) una nivelación ascendente y también podríanecesitarse algunapartición 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 comunicación entreburbujas. 4. El borrador de DFD que resultasecompara con el diagrama decontexto ylalista 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 también es directo: a cada burbuja se la da un nombre apropiado, basado en la respuestarequerida. Estosigni ca que se debe examinar el acontecimiento y preguntarnos que respuesta debe dar el sistema a este acontecimiento?. El tercer paso no es mecánico, pero usualmente es bastante directo, para cada burbuja dibujada, identi que las entradas que requiere para efectuar su trabajo. Identi que las salidas (si las hay) que cadaunaproduceeidenti quelos almacenesalosquecadaburbuja debe tener acceso. Esto se logra entrevistando a los usuarios. En muchos casos el acontecimiento esta determinado por el ujo; esto signi ca que el sistema detecta la ocurrencia de un acontecimiento por la llegada de algún dato de un terminador externo. Obviamente, esto signi ca 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 implicaradevolver salidas a los terminadores fuera del sistema, sin

10 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 168 embargo, puede también involucrar salidas que se envían a los almacenes de datos, para ser usadas como entradas de otros procesos. El cuarto paso es una actividad de veri cación de consistencia, similar a los pasos de balanceo de modelos. Veri que que cada entrada del diagrama de contexto para ver se estaasociadacon algunaentradadealgunodelos procesos del DFD preliminar; y veri que también que cada salida producida por algún proceso en el DFD preliminar se envié a un almacén oseaunasalidaexternaincluidaen el diagramadecontexto. Existen dos casos especiales: ² Acontecimientos únicosquecausan respuestas múltiples ² Acontecimientos múltiples que causan la mismarespuesta. En todosestoscasosningunodelosprocesos en el diagramade ujodedatospreliminar está conectado con otro: las burbujas no se comunican directamente con otras. En lugar de ello se comunican entre si a través de otros almacenes de datos. Esto es debido a que las burbujas en el diagrama preliminar representan respuestas a acontecimientos, y los acontecimientos queocurren en el ambiente externo son no sincronizados y dado que la respuesta a un acontecimiento puede requerir datos producidos por algún otro y, no hay forma de saber cuando ocurrirán los acontecimientos, y debe suponerse, en un modelo esencial, que cada proceso realizara su labor de manera in nitamente rápida, y cada ujo de datos actúa como conducto que puede transmitir datos con rapidez in nita, se sigue que la única forma de sincronizar múltiples acontecimientos interdependientes es mediante un almacén Desarrollo del Modelo Inicial de Datos Como el D E-R y DFD se desarrollan en paralelo, pueden usarse para revisarse entre si. Además 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 quenecesitaraun re namiento paraeliminary/oañadir objetos. Además presenta un segundo inconveniente, que el modelo de comportamiento inicial son grá cos casi sin ningún apoyo de textos. 5.4 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 de niciones muy gruesas, compuesto básicamente de gra cas y poco apoyo de texto, etc) Terminado del Modelo de Proceso Nivelación del DFD preliminar Reorganizar el DFD (posee muchas burbujas), necesita de nivelación ascendente, es decir, agrupar procesos relacionadosen agregados con signi cado.

11 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 169 Existen tres reglas al hacer esto: 1. Con la agrupación 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 re eren a un almacén común, y no hay otros procesos en los DFD preliminares que sere eren a este almacén, entonces puede crear una burbuja de nivel superior para esconderlo. 3. Tenga presente que la personaque ve sus DFD, seaun usuario u otroanalista, no quiere ver demasiadoa lavez. Por ello, creeagregados ogrupos del DFD preliminar que consistan en aproximadamente. Muchas vecesnecesitan deunanivelación descendente. Cuandolosprocesos descriptos en el DFD son muy complejos para describirlos en una especi cación de proceso, tal vez sea necesario una nivelación descendente, es decir, construir un DFD de nivel inferior. Pasos para llevar a cabo una nivelación descendente En algunos casos es apropiado un enfoque de descomposición funcional pura, es decir, si encuentra una burbuja de proceso que realiza una función compleja, trate de identi car 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 guía paralanivelación descendente Como completar el DD En esta etapa (terminado del modelo) es necesario llenar la descripción del signi cado de cadadato, también sehacenecesario dividir los datos complejos en elementos menores. Hay que veri car que este completo y sea consistente (que ninguna parte contradiga a la otra), que este balanceado con los DFD, DER y las EP Como completarlas especi caciones de procesos No inicie la escritura de las especi caciones de proceso antes de concluir con el DFD preliminar. Cuando el DFD comience a estabilizarse, cuado ha pasado la prueba de la nivelación ascendente, entonces puede comenzar a escribir las especi caciones de proceso. Por ultimo, recuerde que las EP deben balancear con los DD y el DER Terminado del modelo de datos De la misma forma que los DFD, se empieza con un DER tosco y luego se re na y se mejora. Tenga en mente quela mayoríade las veces el DER sedesarrollaal mismo tiempo que el DFD.

12 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO El Modelo de Implementación Terminamos dedesarrollar el Modeloesencial de un sistemadeinformación, este tieneuna descripción completa de lo que el sistema debe hacer, especí camente describe: ² La política o lógica esencial de las funciones que se requiere realizar. ² El contenido esencial de los datos que almacenael Sistema y quese mueven a través de él. ² El comportamiento esencial dependientedel tiempoqueel sistema debeexhibirpara manejar señales e interrupciones del ambiente exterior. Con esta información seria su ciente para los diseñadores y programadores: se les daría el modelo esencial y se les permitiría escoger el mejor HARD, sistema operativo, sistema de administración de base de datos y el lenguaje de programación, dentro de las restricciones globales del proyecto, en tiempo, dinero y recursos humanos. No obstante seria necesario información adicional sobre cuestiones de implementación. El asunto de implementación de interés para el usuario es lafrontera de automatización, es decir, cuales parte del modeloesencial se van a implementar con la computadora y cuales se van a realizar manualmente por personal de la Organización. Es de interés para el usuario, mas que las funciones de Sistema, las entradas y salidas del mismo, este interés se va acrecentando por varias opciones y posibilidades que han aumentado la importancia de estas cuestiones de implantación. Algunas de ellas son: ² Los usuarios nales tienen oportunidades de usar computadoras personales como parte deuna red distribuidade computadoras. Cabríapreguntarnos Que parte del modelo esencial se asignaran las PC? Cuales se compartirán?. ² Losusuarios nalestienen oportunidad deescribirsuspropiosprogramasen lenguajes de cuarta generación. Se podria construir un prototipo de porciones del sistema utilizando un lenguaje de cuartageneración oun paquete degeneración deaplicaciones. Otra opción es la elección 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 implementación del usuario. De manera generalizada, este cubre cuatro puntos: 1. Distribución del modelo esencial entre personas y maquinas. 2. Detalledela interacción humano-maquina. 3. Actividadesmanuales quesepodrían requerir. 4. Restricciones operativas que el usuario desea imponer al Sistema.

13 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO Determinación de lafrontera de automatización Que funciones y que datos se manejaran manualmente y cuales se automatizaran. Esta es la cuestión. Aunque el usuario quiere que se desarrolleun sistema automatizado, también necesita unadeclaración bien hechadelos requerimientos delas funciones ydatos quequeden fuera de la frontera de automatización. Existen tres casos: 1. Al usuario no le importa donde esta la frontera de automatización. 2. El usuario escoge un sistema totalmente automatizado. 3. El usuario escoge un sistema completamente manual Determinación de lainterfaz humana Eslaactividad queconsumemas tiempoyloquemasinteresaal usuario. Involucracuatro partes. 1. Elección delos tipos deentradasy salidas. 2. El formato de las entradas. 3. El formato de las salidas. 4. Lasecuenciay los tiemposde I/Oen un sistemaen línea. Nota 5.1 Sobre este tema en particular se lo desarrolla completamente en el capitulo Identi cación de las actividades de apoyo manual adicional El usuario puede o no aceptar la existencia de una tecnología perfectaen el modelo esencial opuededecidir que ciertas porcionesdel sistemaautomatizadoestén bajosu propiocontrol operacional, opueden existir normaslegales que aseguren la integridad de los datos. Cualquierasea el caso, estas actividades de apoyoadicional se representaran por medios denuevos procesosen el DFD del modelode comportamiento. Generalmente tenemos que preocuparnospor laposibilidad delatecnologíadefectuosaen algunas áreas principales: ² Ingreso de datos al sistema ² Realización deloscálculos ² Almacenamiento a largo plazo ² Salida de datos del sistema ² Entrada o salidas redundante ² Tecnología de procesador redundante ² Redundancia interna ² Controles por lote ² Veri caciones secuenciales

14 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO Especi caciones de restricciones operacionales El equipo de implantación tendrá que decidir lacombinación de Hardware, sistema operativo, equipodetelecomunicaciones, lenguajes deprogramación yestrategiasdediseñopara implementar mejor los requerimientos. A continuación se describen algunas cuestiones típicas de las restricciones operativas, restricciones que el modelo esencial evita: ² Volumen dedatos ² Tiempo de respuesta a las diversas entradas ² Restricciones políticas sobre modalidades de implantación ² Restricciones ambientales ² Restricciones de con abilidad ² Restricciones de seguridad

15 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO Preguntas y Ejercicios de Revisión 1. Enumere y describa las cuatro modelos que propone el SA/SD. 2. Describa los problemas que se presentan en la construcción de los cuatro modelos del SA/SD. 3. De na Modelo Ambiental. Sus componentes. 4. Enumerey describa losrequerimientospara laconstrucción del ModeloAmbiental. 5. De na el Modelo Preliminar. Sus enfoques. 6. De na el Modelo de Comportamiento. Herramientas. 7. Como se debe complementar el Diccionario de Datos en el Modelo de Comportamiento. 8. Comosedebe complementar las Especi caciones de Proceso en el ModelodeComportamiento. 9. Que entiende por Terminado del Modelo de Datos. 10. De na el Modelo de Implementaión. 11. Que entiende poor Frontera de Automatización. 12. Queentioendepor Determinación de lainterfacehumana. 13. Queentiende por laidenti cación deloasactividades deapoyo Manual.

16 CAPÍTULO 5. ANÁLISIS Y DISEÑO ESTRUCTURADO 174 Referencia Bibliográ cas [7] E. Yourdon. Análisis y Diseño Estructurado. Yourden Press, 1980.

17 Parte III Análisis y Diseño Orientado a Objetos 175