HERRAMIENTAS CASE UNIDAD 1 : Modelo de comportamiento II DIAGRAMA DE TRANSICION DE ESTADOS CONCEPTO El diagrama de transición de estados, enfatiza el comportamiento dependiente del tiempo del sistema. Importan a aquellos sistemas de tiempo real, sistemas de conmutación telefónica, sistemas de captura de datos de alta velocidad y sistemas de control y mando militares. COMPONENTES Las principales componentes del diagrama son estados, y flechas que representan los cambios de estado. • Los estados : Los estados del sistema se representan con un rectángulo. Cada rectángulo representa un estado en el que se puede encontrar el sistema. Por lo tanto, los estados típicos de un sistema pueden ser : esperar a que el usuario de su contraseña, esperar la siguiente orden, etc. Muchos de estos ejemplos implican que el sistema esta esperando a que algo ocurra, y no se expresan en términos de que la computadora este haciendo algo. Esto se debe a que el DTE se usa para desarrollar un modelo de cómo se comportaría el sistema si hubiera tecnología perfecta. Así cualquier estado observable en el que el sistema se pueda encontrar solo puede corresponder a periodos en los que : • Esta esperando que algo ocurra en el ambiente externo o, • Esta esperando a que alguna actividad que se este dando en ese momento en el ambiente cambie a otra. Un estado representa algún comportamiento del sistema que es observable y que perdura durante algún periodo finito. • Los cambios de estado : un sistema que existió en un solo estado no seria un objeto de estudio muy interesante: seria estático. Los sistemas de información que modelamos pueden tener docenas de estados diferentes. Los cambios de estado se muestran en el DTE conectando pares relevantes de estados con una flecha. Cualquier estado puede llevar a un numero arbitrario de estados sucesores. La mayoría de los sistemas tienen un estado inicial reconocible y un estado final reconocible. El estado inicial típicamente suele ser el que se dibuja en la parte superior del diagrama, aunque no es obligatorio. Lo que lo identifica como inicial es la flecha desnuda que no esta conectada a ningún otro estado. El estado final suele ser el que se dibuja en la parte inferior, pero no es obligatorio. Lo que lo identifica es la ausencia de alguna flecha que salga de el. El sentido común dice que un sistema solo puede tener un estado inicial, sin embargo, puede tener múltiples estados finales. Los diversos estados finales son mutuamente excluyentes. Como consideramos que contamos con tecnología perfecta, podemos suponer que los cambios de estado ocurren instantáneamente. • Condiciones y Acciones : para completar el DTE necesitamos añadir: las condiciones que causan un 1

cambio de estado y las acciones que el sistema toma cuando cambia de estado. Las condiciones y acciones se muestran junto a la flecha que conecta dos estados relacionados. Una condición es un acontecimiento en el ambiente externo que el sistema es capaz de detectar; típicamente es una señal, una interrupción o la llegada de un paquete de datos. Esto hace que el sistema cambie de estado de esperar X a un estado de esperar Y; o de llevar a cabo la actividad X a llevar a cabo la actividad Y. Como parte del cambio de estado, normalmente el sistema hará una o mas acciones. Así que las acciones que se muestran en el DTE son respuestas regresadas al ambiente externo o bien cálculos cuyos resultados el sistema recuerda para poder responder a algún acontecimiento futuro. Diagramas particionados : en un sistema complejo puede haber docenas de estados distintos del sistema; tratar de ponerlos todos en un mismo diagrama seria difícil, si no imposible. Tal como se usaron los niveles y las particiones en los DFD, se pueden usar las particiones con los DTE. En este caso, cualquier estado individual de un diagrama de mayor nivel puede convertirse en un estado inicial para un diagrama de nivel inferior que describe mas a fondo ese estado de mayor nivel; y el o los estados finales en un diagrama de nivel inferior corresponden a las condiciones de salida en el estado asociado de nivel superior. CONSTRUCCION DEL DTE Hay dos enfoques para construir un DTE: • Se puede comenzar por identificar todos los posibles estados del sistema y representar cada uno como una caja separada en una hoja de papel. Luego, se pueden explorar todas las conexiones con significado (es decir, los cambios de estado) entre las cajas. • Se puede comenzar por el estado inicial, y luego metódicamente ir siguiendo un camino hasta el o los estados restantes; luego del o los estados secundarios, proseguir a los terciarios, etc. El enfoque quedara determinado, por el usuario con quien este trabajando, sobre todo si el es el único que esta familiarizado con el comportamiento dependiente del tiempo del sistema VERIFICACION DE LA CONSISTENCIA Cuando se termine de construir el DTE preliminar, deben seguirse las siguientes reglas para verificar la consistencia : • Se han definido todos los estados? • Se pueden alcanzar todos los estados? Se han definido estados que no tengan caminos que lleven a ellos? A todos los estados les llega al menos una flecha. • Se puede salir de todos los estados? Hay una flecha que sale de todos los estados, sino son estados finales? • En cada estado el sistema responde adecuadamente a todas las condiciones posibles? Este es el error mas común : el analista identifica los cambios de estado cuando ocurren condiciones normales, pero no especifica el comportamiento del sistema ante condiciones inesperadas. LA RELACION DEL DTE CON LOS DEMAS COMPONENTES DEL MODELO El DTE puede usarse por si solo como herramienta de modelado. Sin embargo, puede, y en general debiera, ser utilizado en conjunto con otras herramientas. El DTE representa una especificación de proceso para una burbuja de control en un DFD. Note que las condiciones en un DTE corresponden a los flujos de control entrantes en un DFD, y las acciones a los flujos 2

de control de salida en el DFD. Como herramienta de modelado de alto nivel, el DTE puede servir incluso como especificación de proceso para todo el sistema. Si se representa el sistema con un diagrama de una burbuja, puede usarse el DTE para mostrar la secuencia de actividades en el sistema. BALANCEO DE MODELOS Cada una de las herramientas del análisis, se enfoca en un aspecto critico del sistema a modelar. Se desea que el DFD enfoque la atención del lector en las funciones del sistema, el DER se enfoca en las relaciones entre datos y el DTE, en las características de tiempo. Cuando se modelan tres aspectos distintos de un sistema, además de modelar las características detalladas del sistema en un diccionario de datos y un conjunto de especificaciones de proceso, es fácil desarrollar diversas interpretaciones diferentes e inconsistentes de esa misma realidad. Existe otra razón para enfocarse en la consistencia entre modelos, cualesquiera errores que existan tarde o temprano se detectaran, pero se vuelven cada vez mas difíciles y caros cuando mas avanza el proyecto. De una especificación estructurada en la cual todas las herramientas se han verificado entre si para asegurar su consistencia se dice que esta balanceada. Los errores mas comunes son : definiciones faltantes, la misma realidad se describe de dos manera distintas y contradictorias. BALANCEO DEL DFD Y EL DD • Cada flujo de datos y cada almacén de datos deben estar definidos en el DD. Si falta la definición en el DD, el flujo o almacén se considera indefinido. • Cada dato y almacén que se define en el DD debe aparecer en alguna parte del DFD. Si no aparece, dicho dato o almacén es un fantasma. BALANCEO DEL DFD Y LA ESPECIFICACION PROCESO • Cada burbuja del DFD debe asociarse con un DFD de nivel inferior o con una EP, pero no ambos. Si ambas existen, el modelo es innecesario y redundante. • Cada EP debe tener una burbuja de nivel inferior asociada en el DFD. Dado que la EP requiere de mucho trabajo, podría pensarse que es altamente improbable que existan especificaciones de proceso vagabundas. • Las entradas y salidas deben coincidir. El DFD muestra flujos de entrada y salida para cada burbuja, al igual que las conexiones con los almacenes. Esto debe ser evidente en la EP de proceso también. Estos comentarios se aplican específicamente a las burbujas de proceso. Para las burbujas de control en un DFD existe correspondencia entre las burbujas y los DTE. BALANCEO DE LAS EP CON EL DFD Y EL DD Cada referencia de un dato en la especificación de proceso debe satisfacer : • Coincide con el nombre de un flujo de datos o almacén conectado a la burbuja descrita por la especificación de proceso, o • Es un termino local, definido explícitamente en la especificación de procesos, o • Aparece como componente en una entrada del DD para un flujo o almacén conectado con la burbuja. BALANCEO DEL DD CON EL DFD Y EP 3

• Cada entrada del DD debe tener referencia en una especificación de proceso, un DFD, u otro DD. Esto supone, que se esta modelando el comportamiento esencial de un sistema. Un DD complejo y exhaustivo de una implantación existente de un sistema puede contener algunos datos que ya no se usan. También se podría argumentar que el DD se planee de forma tal que permita una expansión futura; es decir, que contenga elementos que no se ocupen hoy pero que pudieran ser útiles en un futuro. BALANCEO DEL DER CON EL DFD Y LAS EP • Cada almacén del DFD debe corresponder con un tipo de objeto, una relación o una combinación de un tipo de objeto y una relación ( una entidad asociativa) en el DER. • Los nombres de objetos en el DER y los nombres de almacenes de datos en el DFD deben coincidir. • Las entradas del DD deben aplicarse tanto al modelo de DFD como al de DER. • Hay reglas que aseguran que el DER sea consistente con la porción de la especificación de proceso del modelo orientado a las funciones. Las reglas son que el conjunto combinado de todas las especificaciones de proceso deben, en su totalidad : • Crear y eliminar instancias de cada tipo de objeto y relación que se muestra en el DER. • Alguna burbuja del DFD define valores para cada dato asignado a cada instancia de cada tipo de objeto, y algún proceso del DFD usa (o lee) valores de cada dato. BALANCEO DEL DFD Y EL DTE • Cada burbuja de control del DFD se asocia con un DTE como su especificación de proceso. De manera similar, cada DTE en el modelo global del sistema debe asociarse con un proceso de control en el DFD. • Cada condición del DTE debe corresponder con un flujo de datos de entrada del DFD asociado. Cada flujo de control que entra en la burbuja de control debe asociarse con una condición apropiada en el DTE. • Cada acción del DTE debe corresponder con un flujo de control de salida del DFD. Cada flujo de control de salida del DFD debe asociarse con una acción apropiada del DTE asociado. MODELO DE IMPLANTACION DEL USUARIO El modelo esencial describe: a) la política, o lógica, esencial de las funciones que se requiere realizar; b) el contenido esencial de los datos que almacena el sistema, y que se mueven a través de el; c) el comportamiento esencial dependiente del tiempo que el sistema debe exhibir para manejar señales e interrupciones del ambiente exterior. Esta información seria suficiente para los diseñadores y programadores, se les daría el modelo esencial y se les permitiría escoger el mejor hardware, SO, sistema de administración de BD y lenguaje de programación, dentro de las restricciones globales del proyecto en tiempo, dinero y recursos humanos. Sin embargo, el usuario insistirá en proporcionar alguna información adicional. Esta información involucra cuestiones de implantación. El asunto de implantación mas obvio de interés para el usuario es la frontera de automatización, cuales partes del modelo serán manuales y cuales implementadas por la computadora. Luego el formato de las entradas y salidas del sistema también son de interés para el usuario. En la actualidad, las siguientes opciones han aumentado la importancia de las cuestiones de implantación : • Los usuarios finales a menudo tienen la oportunidad de usar PC como parte de una red distribuida de 4

computadoras. • Los usuarios finales tienen cada vez mas oportunidades de escribir sus propios programas en lenguajes de cuarta generación. Hay que definir que partes se harán en cuarta generación y cuales en tercera. • El usuario y el analista podrían hacer un prototipo de porciones del sistema utilizando un lenguaje de cuarta generación o un paquete de generación de aplicaciones. • Otra opción es la selección y compra de un paquete de software. El modelo de implantación del usuario a veces se describe como la zona fantasma entre el análisis y el diseño estructurado. DETERMINACION DE LA FRONTERA DE AUTOMATIZACION Que funciones y que datos se manejaran manualmente y cuales automatizados? Hay tres casos extremos: • Al usuario pudiera no importarle donde esta la frontera de automatización. Esto usualmente requerirá de por lo menos una decisión preliminar acerca de cuales partes del modelo esencial se automatizaran y cuales serán manuales. • El usuario podría escoger un sistema totalmente automatizado. Una situación mas común, sobre todo si el sistema que se desarrolla es reemplazo de uno actual y no se cambia la frontera de automatización. • El usuario podría optar por un sistema completamente manual. En aquellas ocasiones en que el usuario solo quiere reorganizar la forma en la que se desempeñan actualmente las actividades en la organización. Basándose en interacciones entre el analista, el usuario y el equipo de implantación se llegara a un compromiso, cuales partes serán manuales y cuales automatizadas. No es labor ni del analista ni del equipo de implantación escoger la frontera de automatización, sino que es responsabilidad del usuario. Una vez escogida la frontera de automatización pudiera ser importante considerar algunas cuestiones ambientales: nivel de ruido, radiación, iluminación, comodidad de la terminal de vídeo y espacio de trabajo, etc. Finalmente, una vez elegida la frontera de automatización , podría ser necesario aumentar el modelo esencial para mostrar como se enciende y apaga el sistema. Así , podría requerirse incluir procesos adicionales (burbujas de DFD), flujos de datos y almacenes que muestren las actividades de inicio y apagado del sistema. DETERMINACION DE LA INTERFAZ HUMANA Probablemente la actividad que consume mas tiempo, y que mas interese al usuario, es la especificación de la interfaz humana. Esto involucra cuatro asuntos : • Dispositivos de Entrada y Salida : la elección de los dispositivos de E/S puede estar determinada por los terminadores fuera del sistema. Los dispositivos que se usan típicamente son :Entrada (teclado, mouse, scanner, reconocedor de voz, lectores ópticos, lectoras magnéticas), salida ( monitor, impresora, sintetizador de voz, plotter) • Formatos de entrada y salida : una vez escogidos los dispositivos E/S, el siguiente paso es determinar los formatos de las E/S del sistema. Esto es la forma en que va a ser introducida o mostrada la información. Hay que ser consistente, las pantallas deben ser iguales. Crear una interfaz amigable con el usuario. Para ello las siguientes reglas sirven de ayuda : • pedido de entradas y producción de salidas en forma consistente; • pedido de información en secuencia lógica; 5

• hacer obvio el tipo de error y su ubicación; • distinguir entre edición de campos y edición de pantallas; • edición y revisión de errores dependiente del usuario; • permiso para cancelar parte o totalidad de la transacción • proporcionar un mecanismo de ayuda conveniente • distinguir entre sistemas guiados por menús y sistemas guiados por ordenes • desplegar mensajes al usuario cuando el sistema esta realizando un proceso largo • proporcionar alternativas por omisión para las entradas standard • aprovechar el color y el sonido pero no abusar. • Formato de salidas : aunque hay muchos estilos diferentes para las formas que pueden tomar las salidas, todas deben contener la siguiente información básica : a) Titulo; b) Instrucciones; c) Cuerpo. Dependiendo de la aplicación, se pueden diseñar formas individuales o de especialidad, las primeras suelen imprimirse en hojas sencillas y son adecuadas en la mayoría de las situaciones, las segundas son mas complejas, el ejemplo mas común es la impresión de facturas con numeración predefinida, remitos, etc. • Códigos de entrada y salida : como parte de la labor de especificar formatos de E/S, el analista muchas veces debe especificar códigos. Un método de codificación debe ser; • Expandible. Debe proporcionar espacio para entradas adicionales que pudieran requerirse. • Preciso. Debe identificar al articulo especifico. • Conciso. Debe ser breve pero describir adecuadamente al articulo. • Conveniente. Debe ser fácil de codificar y decodificar. • Con significado. Debe ser útil para quienes lo manejan. De ser posible debe indicar algunas de las características del articulo. • Operable. Debe ser compatible con los métodos presentes y anticipados de proceso de datos, manual o a maquina. Es común utilizar el código de clasificación, que usa grupos de dígitos dentro del código para identificar clasificaciones mayores, intermedias o menores dentro del articulo que se describe. Finalmente algunos códigos se autoverifican, contienen información adicional que puede usarse para verificar que se haya ingresado correctamente el código. IDENTIFICACION DE LAS ACTIVIDADES DE APOYO MANUAL ADICIONAL En el modelo esencial se supone la existencia de una tecnología perfecta, que significa suponer que la tecnología de implantación nunca se descompondrá y nunca cometerá un error. El usuario podría decidir que ciertas porciones del sistema automatizado estén bajo su propio control operacional. Tal vez trabaje con datos financieros, en cuyo caso podrían existir requisitos legales para asegurar la integridad de las entradas, salidas y archivos del sistema. En la mayor parte de los casos, estas actividades de apoyo manual adicional se representaran por medio de nuevos procesos en el DFD del modelo de comportamiento. Tenemos que preocuparnos por la posibilidad de la tecnología defectuosa en cuatro áreas principales: • Ingreso de datos al sistema • Realización de los cálculos. Una vez ingresados los datos existe la posibilidad remota de que la computadora funcione mal. • Almacenamiento a largo plazo de los datos • Salida de datos del sistema. Para poder controlar estas posibilidades de tecnología defectuosa se puede utilizar alguno de los siguientes métodos: • Entradas o salidas redundantes. 6

• Tecnología de procesador redundante. • Redundancia interna. • Controles por lote (Batch). • Verificaciones secuenciales. ESPECIFICACION DE RESTRICCIONES OPERACIONALES El equipo de implantación tendrá que decidir la combinación de hardware, SO, equipo de telecomunicaciones, lenguaje de programación y estrategia de diseño para implantar mejor los requerimientos. Pero esto será difícil de lograr sin alguna declaración de restricciones operativas, que el modelo esencial deliberadamente evita. Las cuestiones típicas son: • Volumen de los datos. Mayor velocidad a mayor volumen. • Tiempo de respuesta a las diversas entradas. Tiempo que necesita el usuario para que se realicen las operaciones. • Restricciones políticas sobre modalidades de implantación. El usuario pudiera, por motivos racionales o irracionales, especificar la marca de hardware que se usara, el lenguaje de programación, los proveedores de telecomunicaciones que se usaran, etc. • Restricciones ambientales. • Restricciones de seguridad y confiabilidad. El usuario pudiera especificar un tiempo promedio entre fallas, y tiempo promedio necesario para la reparación para el sistema. • Restricciones de seguridad. El usuario puede especificar una variedad de restricciones enfocadas a minimizar el uso no autorizado del sistema. • Sistemas parametrizados de seguridad: sistemas ya establecidos que proponen normas de seguridad, permisos posibles. • Virus : como se arman las redes, como se permite la utilización de los periféricos. UNIDAD 2 : Herramientas CASE QUE ES UNA HERRAMIENTA CASE? Se consideran CASE a un conjunto de herramientas relacionadas que soportan todos los aspectos del ciclo de desarrollo del software, incluyendo aquellas que soportan fases especificas del ciclo de vida, como las herramientas de análisis y diseño, generadores de código y herramientas de testing, y las herramientas que sirven a varias fases del ciclo de vida, como herramientas de manejo de proyectos, administración de la configuración, y herramientas de documentación. Conjunto de herramientas que tratan de optimizar la tarea de trabajar con sistemas. Los problemas por los que aparecieron las Herramientas CASE son: • Recursos insuficientes para desarrollar el nuevo software. Tratar de mejorar la productividad. • Problemas en el software existente: mejorar la calidad del software. • Altos costos de mantenimiento QUE SE ESPERA DE UNA CASE? Las herramientas CASE deberían cumplir las siguiente funciones: • Manejo de metodología de ingeniería de software a la medida de la organización, eso incluye notaciones gráficas y reglas de control. • Manejo de gráficas para múltiples tipos de modelos (DFD, DER, DTE, etc.) • Módulos de revisión de errores para asegurar la precisión de esos modelos, es decir que sean 7

completos e internamente consistentes. • Comparación entre modelos diferentes, tanto en la misma fase o entre diferentes fases del ciclo de vida para comprobar y analizar los errores, comprobar la consistencia y crear referencias cruzadas de toda la información concerniente al sistema. • Acceso bajo una red, a todas las herramientas que automatizan el ciclo de vida del proyecto. • Control sobre las actualizaciones desde los distintos puestos de trabajo. • Facilidades para que el administrador del proyecto efectúe el seguimiento del mismo. • Estadísticas de productividad y métrica de software. • Simulación y pruebas automatizadas. • Creación de modelos de software para los datos y las líneas de código. • Generación automática de líneas de código. • Interfaz a diccionarios y bases de datos de otras herramientas CASE. • Re ingeniería para sistemas ya existentes. • Generación automática de la documentación del sistema. CUANTOS TIPOS DE CASE HAY? Existen tres tipos de productos CASE: • CASE de alto nivel : son productos que cubren las primeras fases del ciclo de vida: Planificación, Análisis, Diseño. Permiten describir los aspectos fundamentales de un sistema, obteniéndose beneficios considerables en la documentación gráfica y en la integración de funciones y relaciones. • CASE de bajo nivel : son productos basados en el uso de la propia maquina a la que se destina la aplicación y están orientados a : generación de bases de datos, generación de programas, soporte de pruebas. Al estar asociados a una plataforma definida ofrecen mejor capacidad de elección. • CASE integrado : comprende todos los elementos de CASE superior e inferior, y, por lo tanto debería cubrir todas las fases del ciclo de vida de forma totalmente compatible y coherente. Los beneficios del CASE integrado incluyen: • La transferencia fluida de información (modelos, programas, documentos, datos) entre herramientas y entre etapas. • La reducción del trabajo requerido para actividades de soporte como la generación de documentos, el control de calidad, etc. • Un aumento en el control de los proyectos que se consigue mediante una mejor planificación, el control de las actividades y la comunicación. • Mejor coordinación entre los miembros del equipo de trabajo en grandes proyectos. CUANDO UNA HERRAMIENTA ES INTEGRADA? Identificamos cinco tipos de integración: • Integración de plataformas : se refiere a una herramienta con un conjunto común de servicios proporcionados por el ambiente operativo. Por ejemplo, el ambiente UNIX. En algunos aspectos, esta es la forma de integración mas baja, porque la integración no es el objetivo directo de la herramienta, sino que es el resultado de las características especiales del SO sobre el que la herramienta trabaja. • Integración de presentación : se refiere a la definición de una interfase de usuario consistente entre las diferentes herramientas. Estandarizar las interfases de usuario aumenta la flexibilidad y simplifica la elección de las herramientas por parte de los usuarios. Las organización intentan lograr desde hace tiempo una integración en los formularios para usuarios y desarrolladores, a fin de conseguir un vocabulario único y un contenido de menús similar en todas sus interfases gráficas. Reduce el costo y tiempo de entrenamiento. • Integración de control : se refiere a la habilidad de las herramientas para informar a otras herramientas 8

de sus acciones y recibir requerimientos de otras herramientas. Que en el momento que se defina una acción en una herramienta de análisis y diseño, se notifique o se acceda a las otras herramientas afectadas. Las organizaciones tienen hace tiempo una forma rudimentaria de integración de control usando scripts que invocan programas según el resultado de distintas condiciones. • Integración de datos : se refiere a la transferencia de información entre herramientas y al establecimiento de las relaciones entre datos utilizando diferentes herramientas. Las formas de transferencia son: 1) las herramientas de forma individual permitan un intercambio de interfases y formato. Son fáciles de implementar pero no permiten una integración efectiva de las relaciones entre datos. 2) tener una base común, con filtros que extraen información y la almacena en bases intermedias. Dependen del mantenimiento de la integración punto a punto y generan redundancia entre la base central y la auxiliar. 3) que haya una BD centralizada donde todas las herramientas guarden su información. La total funcionalidad del repositorio proporciona la capacidad de mantener el contenido semántico de los objetos, lo que permite el trabajo conjunto de varias herramientas. • Integración de procesos : se refiere a la automatización de la secuencia de actividades que la organización ha definido como componentes del ciclo de vida del desarrollo del software. Se usan mecanismos de integración de presentación, control y datos para permitir un alto nivel de integración de procesos, ya que esta es la fase final de integración. QUE FUNCIONES DEBE CUMPLIR UN AMBIENTE INTEGRADO? Las herramientas CASE integradas, fueron diseñadas para procesarse en un entorno dedicado. Un entorno integrado debe: • Suministrar un mecanismo que permita compartir la información a todas las herramientas. Las herramientas se deben diseñar con una estructura de datos y semántica compatibles para que intercambien datos sin necesidad de traducción. • Permitir el acceso simultaneo a herramientas. Plataformas multitarea. • Reflejar los cambios de un elemento de información en todos los elementos relacionados. • Proporcionar un control de versiones y una gestión global de toda la información del sistema. • Permitir el acceso directo, no secuencial, a todas las herramientas del entorno. • Presentar la misma visión consistente de la interfaz hombre−maquina en todas las herramientas. • Permitir la comunicación entre los integrantes del equipo a través de la información que generan. • Realizar mediciones técnicas y de gestión para mejorar el proceso y el producto. A esto se le debe añadir los servicios de portabilidad para que todos los bloques de la arquitectura CASE se unan adecuadamente. QUE SOFTWARE DE BASE USA UNA CASE INTEGRADA? Son necesarios : • Un repositorio, que almacena información • Un sistema de manejo de objetos, para manejar los cambios en la información • Un control de herramientas, para coordinar su utilización • Una interfaz de usuario avanzada, para proporcionar una vía consistente entre el usuario y las herramientas contenidas en el entorno. • Un sistema operativo multitarea, de manera de poder trabajar con varias herramientas simultáneamente. • Una arquitectura de red, como un entorno CASE es una red distribuida, los mecanismos básicos deben poder funcionar en red. En resumen, el software de base mas importante es la Base de datos o repositorio CASE, la red de distribución 9

de datos asociada y el sistema operativo multitarea. REPOSITORIO CASE: es el conjunto de mecanismos y estructuras de datos que permite el almacenamiento en forma inteligente de toda la información que concierne al sistema en desarrollo. DATOS QUE SE ALMACENAN EN UN REPOSITORIO CASE : • El problema a resolver • Información sobre el ámbito del problema • Los modelos que solucionan el problema • Las reglas e instrucciones relacionadas con la metodología • La información concerniente a la gestión del proyecto (recursos, presupuesto, calendario,etc.) SERVICIOS DE UN REPOSITORIO CASE Los servicios que debe proporcionar el gestor de BD de un buen repositorio CASE, son de dos tipos, los normales de cualquier sistema de gestión de base de datos y los específicos del entorno CASE. Los servicios normales son: • Almacenamiento no redundante • Acceso de alto nivel: un único mecanismo de acceso para todas las herramientas. • Independencia de los datos • Control de transacciones • Seguridad • Consulta de los datos y gestión de informes • Apertura: mecanismo sencillo para importar/exportar datos. • Soporte multiusuario Las funciones especiales son: • Integridad de datos: a)Datos − Herramientas: el modelo de datos debe ser accedido por todas las herramientas del entorno I−CASE; b) Datos − Datos : el modelo de datos debe permitir establecer una gran diversidad de relaciones entre los datos que los componen. • Información compartida • Seguimiento de la metodología • Almacenamiento de estructuras sofisticadas de datos.(diagramas,documentos, archivos). METADATOS: los metadatos son la información que la herramienta CASE genera automáticamente acerca de los datos con los que trabaja, es decir, datos sobre sus propios datos. Los datos que genera pueden ser: • Definiciones de objetos ( de que tipo son, que representación gráfica tienen, con que otros objetos se relacionan) • Relaciones y dependencias entre objetos de distinto nivel logico. Por ej: un proceso en un DFD. • Reglas de diseño aplicadas a su propio software, por ej: las distintas formas validas de dibujar y balancear un DFD. METAMODELO: un metamodelo es un modelo de modelos, es un modelo que define los pasos a seguir para construir otro modelo; en este caso modelos de sistemas de información. Es el patrón que rige la generación y almacenamiento de la información del proyecto. CAPACIDAD DE CONTROL : permite que cada herramienta pueda notificar al usuario la ocurrencia de 10

sucesos significativos, y solicitarle que solucione ese problema. Es decir, que tenga la capacidad de generar información y efectuar controles sobre si misma. Que puedo autocontrolarse. Controla que la información sea integra. GESTION DE ENLACES : es la capacidad de identificar y evaluar los efectos de un cambio. Que relacione a todas las herramientas del modelo. SEGUIMIENTO DE LOS REQUISITOS : dado un requisito, una necesidad, que la herramienta me permita ver como se refleja en mi sistema. Y también saber quien realizo tal requisito. GESTION DE LA CONFIGURACION : configurar lo que la herramienta CASE me brinda. Depende de la gestión de enlaces y realiza el seguimiento entre las distintas fases del proyecto. Puede regenerar automáticamente el código destino. TRAYECTORIAS DE AUDITORIA : seguimiento de las tareas efectuadas. Obtener información de cuando, porque y quien realizo cada tarea. QUE VENTAJAS Y DESVENTAJAS TIENEN LAS CASE? Se pueden llegar a obtener las siguientes ventajas: • Menor tiempo de mantenimiento • Mayor independencia entre análisis, diseño y programación • Mayor independencia del análisis y diseño con respecto a un entorno en particular. • Trabajar con tareas de mayor nivel que la codificación pura. • Mejora de la calidad del producto de software • Aplicaciones mas productivas para la empresa. Muchas veces las herramientas CASE no cumplen los objetivos esperados, o simplemente no resultan atractivas para las empresas. Las razones pueden ser muchas, entre ellas: • Dificultades para adaptarse al cambio, pues es un cambio cultural, no solo técnico • Es dificil pasar de un análisis realizado en solitario a la realización del análisis en colaboración con los usuarios o con un equipo. • Muchas empresas no cumplen o no tienen practicas de gestión de software organizadas, sin las cuales la automatización del proceso de análisis y diseño suele resultar ineficaz o imposible. • A veces se cree que las nuevas herramientas son soluciones mágicas, cuando en realidad el resultado se ve a mediano y largo plazo. • Muchos sectores de software están tan atrasados en el cumplimiento de sus trabajos que no disponen de tiempo para pensar en nuevas políticas de desarrollo. • Falsas expectativas creadas por los vendedores que originan desengaños y frustraciones. UNIDAD III: INTRODUCCION El diseño estructurado es un acercamiento disciplinado al diseño de sistemas computarizados, es una respuesta a las fallas del pasado. Es la actividad de desarrollar soluciones computarizadas flexibles y fáciles de mantener para un conjunto de requerimientos de sistemas bien definidos. Tiene los siguientes cinco aspectos:

11

• Usa la definición del problema como guía para la definición de la solución: la razón de esta filosofía es que los diseñadores de sistemas tradicionalmente eligen una forma preconcebida de solución y tratan de forzar al problema para que se adecue a esa forma. El diseño estructurado se resiste a tomar decisiones en como resolver el problema hasta que el que no este determinado. Esto es especialmente cierto cuando el Análisis estructurado lo precede. • Busca eliminar la complejidad de grandes sistemas particionandolos en cajas negras y organizándolas en jerarquías : las características de una caja negra son: a) se conocen las entradas esperadas; b) se conocen las salidas que deben darse; c) se conoce la función que cumple; d) no se necesita saber como realiza la función; Las ventajas de utilizar cajas negras son: • Las cajas negras son fáciles de construir • Estos sistemas son fáciles de testear • Los sistemas son fáciles de corregir • Los sistemas pueden entenderse fácilmente • Pueden modificarse fácilmente El primer paso para controlar la complejidad es particionar al sistema en cajas negras, de esta forma se logran cuatro metas: • cada caja negra debe resolver una pieza bien definida del problema • el sistema debe particionarse de manera que cada caja negra se fácil de entender. • La partición debe hacerse de manera que cada conexión entre cajas existe solo porque el problema así lo requiere. • La partición me asegura que las conexiones entre cajas es lo mas simple posible, para que las cajas sean independientes entre si. La idea de jerarquía, proviene de la idea de que todos los sistemas en el universo se encuentra organizados en jerarquías de unidades estables. A su vez cada unidad esta compuesta de un grupo de unidades mas pequeñas. • Utiliza herramientas, especialmente gráficas para hacer los sistemas mas entendibles : si el análisis estructurado precede al diseño estructurado, entonces el analista le presentara al diseñador una especificación estructurada / funcional, que es la salida del análisis y la entrada para el diseño. Las especificaciones funcionales nos permiten conocer las funciones que van a resolver el problema. Se encuentran expresadas por medio de herramientas del análisis estructurado (DFD,DER,DD,etc). El diseño estructurado utiliza las cartas de estructura, las especificaciones de módulos y el pseudocodigo. • Ofrece un conjunto de estrategias para desarrollar una solución de diseño de un problema bien definido. • Ofrece un conjunto de criterios para evaluar la calidad de una solución de diseño. COMPARACIONES ENTRE ANALISIS ESTRUCTURADO Y DISEÑO ESTRUCTURADO Análisis Estructurado : • Determina que debe hacer el sistema para satisfacer los requerimientos del usuario. 12

• Define los datos que el sistema utiliza y produce. Fase Conceptual. • Ofrece una perspectiva lógica sin las restricciones de la implementación física. Modelo esencial, tecnología perfecta. • Proporciona un lenguaje común y claro a usuarios,analistas y diseñadores. Diseño Estructurado: • Determina como el sistema hará las funciones. • Aplica restricciones al modelo logico. Frontera de Automatización. • Genera el esquema de la BD física. Fase Física. • Planifica las tareas lógicas para especificar las funciones de software y/o hardware. Modelo de Procesador. • Proporciona especificaciones de diseño fáciles de entender, solo para el ambiente técnico. Las especificaciones de diseño es traducir las especificaciones funcionales en como resolver el problema. OBJETIVOS DEL DISEÑO En resumen los objetivos del diseño estructurado son: • Reveer los componentes de las especificaciones funcionales del Análisis estructurado • Proporcionar pasos para verificar esas especificaciones • Introducir paso a paso los procedimientos para hacer la transición del análisis al diseño • Comenzar la fase de diseño físico y las técnicas estructuradas. El diseño estructurado ayuda a producir programas con una razonable relación entre que debe hacer el sistema y como lo debe hacer. FASES DEL DISEÑO FISICO • Diseño de datos : construir estructuras de datos organizadas para recuperar los datos eficientemente (BD) • Diseño de procesos : describir el conjunto de programas cuyos módulos realizaran la aplicación requerida. • Diseño de interfase de usuario : diseñar las E/S del sistema de manera que su manejo se aclaro, consistente y fácil. QUE NO ES DISEÑO ESTRUCTURADO • El diseño estructurado no es programación estructurada. • El DE no es un medio para una mejor especificación del problema. • El DE no es programación modular o diseño top−down • No es un pasaje a la utopía. LOS BASICOS DEL DISEÑO El diseño es el puente entre el análisis y la implementación. Generalmente, las etapas de un clásico sistema computarizado son: • Problema o reconocimiento de la oportunidad : la idea de desarrollar un nuevo sistema ocurre cuando el usuario reconoce que tiene un problema en la forma en que esta llevando su negocio o identifica la oportunidad de mejorarlo. • Estudio de factibilidad : sirve para 1) identificar el ámbito del sistema a estudiar, los problemas y 13

oportunidades no explotadas del sistema actual, objetivos mayores del sistema nuevo; 2) estimar aproximadamente costos, ventajas y desventajas de cada solución posible; 3) obtener las opiniones del usuario y administradores y las modificaciones sobre lo anterior. • Análisis : la información del estudio anterior será el comienzo de un análisis completo. La salida del análisis será : los costos, beneficios y requerimientos de recursos, planes de factibilidad para sistema; requerimientos de configuraciones físicas, requerimientos de conversión. Pero lo mas importante es la especificación funcional, que establece los requerimientos funcionales y de datos para el nuevo sistema. • Diseño : toma la especificación funcional / estructurada junto con la definición de configuración física y desarrolla un diseño detallado por medio de un conjunto de actividades de diseño y de criterios par aun diseño de calidad. • Implementaron : lo que se produjo durante el diseño, especificación de diseño, se codifica. • Pruebas : se prueban partes del sistema, y el sistema completo. • Mantenimiento : una vez que el sistema pasa las pruebas, esta listo para operar. Todo lo que sucede después es mantenimiento del sistema. HERRAMIENTAS DEL DISEÑO ESTRUCTURADO CARTA DE ESTRUCTURA Es la herramienta mas usada en el DE. Gráfica la partición del sistema en módulos mostrando su jerarquía, organización y comunicación. Permite una visión global del sistema. Utiliza el principio de cajas negras, sirve como especificación para que los programadores desarrollen el código. Y ayuda a la documentación y el mantenimiento. Cada carta de estructura es un programa, los módulos se relacionan por medio de flechas jerárquicas. Cada hijo tiene un solo padre, cada padre puede tener varios hijos. La carta de estructura, da ciertas ventajas a la programación como los nombres de los módulos y de los datos que interactuan entre ellos. Acompañando a cada CE debe hacer una descripción de cada modulo y cada dato que aparece en ella. Sus componentes son : módulos, conexiones y comunicación entre módulos. MODULO Un modulo se define como una colección de sentencias ejecutables con cuatro atributos básicos : entradas/salidas, función, mecanismo y datos internos. Las entradas/salidas son la información que el modulo requiere y provee. La función es lo que hace para producir las salidas deseadas en base a las entradas recibidas. El mecanismo es el código logico o procedural con el que el modulo lleva a cabo la función. Los datos internos, son datos que pertenecen al área de trabajo del modulo y solo el hace referencia a ellos. El modulo también tiene como atributos, su nombre y la posibilidad de invocar y ser invocado por otros módulos. En el DE solo nos interesa ver la vista externa del modulo, sin los detalles de codificación y lógica. Se representa como una caja rectangular con su nombre adentro. El nombre establece su función. Un modulo predefinido, se representa con líneas verticales paralelas a los costados, es un modulo al que no hay que escribir porque ya existe. 14

CONEXIONES Un sistema es un conjunto de módulos organizados en una jerarquía, cooperando y comunicándose para lograr un objetivo común. El símbolo que une cada modulo es una flecha indicando la jerarquía. En otras palabras, la flecha muestra una llamada normal a subrutina, con la dirección de la flecha marcando que modulo llama a otro. COMUNICACIONES Se usan dos tipos de flecha. Datos Señales La dirección de la flecha muestra que modulo manda la información. La diferencia entre los dos flujos es: • Los datos son procesados. Las señales no. Una señal es generalmente testeada. • Los datos se relacionan con el problema mismo. Las señales comunican información sobre alguno de los datos tratados. ESPECIFICACIONES DE MODULOS Hay dos métodos para realizar las especificaciones de módulos: • Especificación de la interfaz del modulo : este método permite definir la función del modulo sin entrar en excesivos detalles. Se expresan cuales son las entradas que se proveerán, que salidas se esperan, y la función que se requiere que el modulo lleva a cabo. La función debe estar expresada en una simple sentencia que relacione las entradas y las salidas. • Especificación por pseudocodigo : el pseudocodigo es una forma mas detallada de describir el modulo. Es un lenguaje informal similar al lenguaje estructurado (análisis estructurado). Ya que es mas detallado que el método anterior hay menos margen de error cuando el programador lo traduzca a código. Como se encuentra mas cercano al código, hay menos trabajo para el programador. ESTRATEGIA DE DISEÑO • Crear una primera CE sobre el 1° nivel del diagrama de funciones • Subdividir esa 1° CE por sus mayores funciones • Seleccionar la técnica de análisis de transacciones o la técnica de análisis de transformaciones para producir una CE mas detallada • Refinar la CE detallada según los criterios del diseño estructurado. DESCOMPOSICION • Ampliar la CE escribiendo y evaluando las especificaciones de cada función. • Separa las funciones, crear nuevas funciones • Decidir que secuencia de funciones se debe seguir • Hacer el siguiente nivel de funciones subordinadas a la función original • Nombrar cada función con un nombre que la describa claramente • Continuar el proceso hasta que el menor nivel de funciones contenga una sola función. Transformación : Muchas entradas , una salida. PASOS DE ANALISIS DE TRANSFORMACIONES: 15

• Construir el DFD de un tipo transformación • Buscar las transformaciones centrales • Convertir el DFD en una 1° CE Modulo Control: Controla las funciones básicas del Sistema. Modulo Recolector de Datos : Coordina la entrada de todos los datos que reciben las funciones básicas del sistema. Modulo transformaciones : coordina y ejecuta las funciones básicas del sistema sobre los datos recibidos. Modelo de salida : realiza las transformaciones que requieren los datos de salida. • Seguir cada flujo de entrada desde el exterior del DFD hacia el medio. Marcar el flujo de datos que representa la entrada en su forma mas esencial ( el mismo transformado). • Seguir cada flujo de salida desde el exterior hacia el medio. Marcar el flujo de datos que representa la salida en su forma mas esencial. • Unir las marcas en un circulo • Convertir el DFD en una 1° CE: • Coloque en el mas alto nivel la transf. Central y subordínele todos los otros procesos. • Remueva la flecha de los flujos de datos (sacarle la punta) • Reemplace procesos por funciones. • Agregar las flechas representando las llamadas entre módulos siguiendo la dirección del flujo de datos. • Agregar funciones de lectura y grabación. Transacciones : una entrada, muchas salidas. Ej.: DO CASE PASOS PARA EL ANALISIS DE TRANSACCIONES Función control transacciones: responsable por la coordinación de todos los procesos de transacciones. Control recepción : controla los detalles de las transacciones de recepción. Verifica que lo que ingrese este dentro de los parámetros establecidos. Control despacho : controla las transacciones para activar las rutinas de procesos necesarios. Modulo Control ModuloRec. datos Modulo transfor Modulo salidas Acción 1 Acción 2

16

Acción 3 Control Despacho Control Recepción Control Transacción

17