Fase de análisis
1.Obtener y escribir una descripción inicial del problema.
2.Construir un modelo de objetos:
· Identificar las clases (y objetos).
· Comenzar a crear un diccionario de datos que contenga descripciones de las clases,
sus atributos y sus asociaciones.
· Añadir las asociaciones (y agregaciones) entre las clases.
· Añadir los atributos de los objetos y sus uniones.
· Organizar y simplificar las clases usando herencias.
· Probar que los accesos son correctos, usando escenarios e iterando los pasos
siguientes como sea necesario.
· Agrupar las clases en módulos, basándose en su proximidad y función.
3.Construir un modelo dinámico:
· Preparar los escenarios para las secuencias de interacción típicas entre los usuarios y
el sistema.
· Identificar los eventos que se dan entre objetos y preparar una traza de eventos para
cada escenario.
· Preparar un DTE para el sistema, y una traza de eventos para cada escenario.
· Construir un diagrama de estado para cada clase que tenga un marcado
comportamiento dinámico.
· Chequear la consistencia (y que están todos) de los eventos que aparecen en los
diagramas.
4.Contruir un modelo funcional: (*)
· Identificar los valores de entrada y de salida.
· Usar DFDs cuando sea necesario para mostrar las dependencias funcionales.
· Describir qué hace cada función.
· Identificar las restricciones.
· Especificar criterios de optimización.
(*) Este modelo ha sido bastante criticado, por no seguir los principios del AOO. Desde
1995 se recomienda que este modelo consista en una descripción detallada de las
operaciones del sistema, y solo usa DFDOO cuando estas operaciones impliquen a varios
objetos. Conviene, para cada operación especificar las siguientes cosas: Nombre,
Responsabilidades, Entradas, Salidas, Objetos modificados, Precondiciones y
Postcondiciones.
5.Verificar, iterar y refinar los tres modelos:
· Añadir las operaciones claves que fueron descubiertas durante la preparación del
modelo funcional al modelo de objetos. No mostrar todas las operaciones durante el
análisis, sólo mostrar las más importantes.
· Verificar que las clases, asociaciones, atributos y operaciones son consistentes y
completas al nivel elegido de abstracción. Compara los tres modelos con la definición
del problema y probar los modelos mediante el uso de escenarios.
· Desarrollar escenarios más detallados (incluyendo condiciones que den errores) como
variaciones de los escenarios básicos. Usar estos escenarios “y si...” para verificar en
el futuro los tres modelos.
· Iterar los pasos anteriores cuanto sea necesario para completar el análisis.
7.2 Herramientas de análisis.
HERRAMIENTAS DEL ANÁLISIS ESTRUCTURADO
El Diagrama de Flujo de Datos (DFD) es una técnica gráfica que representa el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida.
Se puede usar el DFD para representar un sistema o un software a cualquier nivel de abstracción. Un DFD de nivel 0 o modelo fundamental del sistema o modelo del contexto, representa al elemento de software completo como una sóla burbuja con datos de entrada y salida. Al partir el DFD/0 para mostrar más detalles, aparecen representados procesos (burbujas) y caminos de flujo de información adicionales.
Una entidad externa, es decir, un elemento del sistema u otro sistema, es quien produce la información a ser transformada por el sistema o recibe información del sistema y que reside fuera de los límites del sistema a ser modelado. Un círculo representa un proceso o transformación que se aplica a los datos y los cambia de alguna forma y que reside dentro de los límites del sistema a modelar. Todas las flechas en un DFD deben estar debidamente etiquetadas y representan un elemento de datos o una colección de elementos de datos, indicando la dirección de los datos. Una línea doble representa un almacén de información que es almacenada y manejada por el sistema, por uno o más procesos.
El diagrama no representa secuencia de procesamiento. Se puede refinar cada una de las burbujas en distintos niveles para mostrar un mayor detalle, aunque se debe mantener la continuidad del flujo de información o equilibrio, es decir, que la entrada y salida de cada refinamiento debe ser la misma.
Un DFD representa el flujo de la información sin representación explícita de la lógica de procesamiento. La notación básica que se utiliza para desarrollar un DFD no es suficiente en sí misma para describir los requerimientos del sistema, ya que no se dice nada acerca del contenido de los datos implicados en las flechas o en los almacenes de datos. Para ello, es necesario otro componente del análisis estructurado: el Diccionario de Datos, que representa qué información se transforma. Se necesita, además, una narrativa para describir cada proceso o burbuja del DFD. Esta Especificación de Proceso describe la entrada del proceso, el algoritmo que se aplica a la entrada y, la salida que produce, además de indicar las restricciones y limitaciones impuestas al proceso, etc. Y describe cómo se transforma las información.
Muchas aplicaciones de software son dependientes del tiempo y procesan más información orientada al control que a datos. Un sistema en tiempo real debe interactuar con el mundo real en marcos temporales que vienen dados por el mundo real. Como el DFD no es capaz de representar estos sistemas, se necesita una ampliación del análisis estructurado para adaptarse a las necesidades de estos sistemas:
Flujo de información que es recogido o producido de forma continua en el tiempo, representado por una flecha con doble punta.
Información de control que pasa por el sistema y el procesamiento de control asociado, representados por una flecha discontinua y una burbuja de trazo discontinuo.
Instancias múltiples de la misma transformación que se encuentran a menudo en situaciones de multitarea, representados por una burbuja sombreada.
Estados del sistema y mecanismos que producen cambios de estado en el sistema.
Almacenes de información de control representados por una doble línea discontinua.
La modelización del comportamiento es uno de los principios fundamentales de todos los métodos de análisis de requisitos. El Diagrama de Transición de Estados (DTE) representa el comportamiento de un sistema que muestra los estados y los sucesos que hacen que el sistema cambie de estado. Además, el DTE indica qué acciones se llevan a cabo como consecuencia de un determinado cambio de estado.
La notación básica para el análisis estructurado va bien cuando la información que fluye a través de una serie de procesos es relativamente sencilla. Sin embargo, para representar una serie de relaciones complejas entre colecciones de datos, es necesario incluir un componente de modelización de datos.
La modelización de datos responde a una serie de preguntas específicas para cualquier aplicación de procesamiento de datos. ¿Cuáles son los objetos de datos principales que ha de procesar el sistema? ¿Cuál es la composición de cada objeto de dato y qué atributos describen ese objeto? ¿Dónde se encuentran en ese momento los objetos? ¿Cuáles son las relaciones entre los objetos y los procesos que los transforman?
Para responder a estas preguntas se hace uso del Modelo de Entidad - Relación (E-R), que permite identificar objetos de datos y sus relaciones, usando una notación gráfica. En el contexto del análisis estructurado, el DER proporciona un entendimiento adicional sobre los detalles de los almacenes de datos y complementa la información del DD.
Con la utilización de estas herramientas de modelado, el analista es capaz de crear una jerarquía de módulos (subrutinas o procedimientos) para realizar los requerimientos del sistema. Una herramienta gráfica para representar esta jerarquía es el Diagrama de Estructuras, en el que cada rectángulo representa un módulo. Las flechas que conectan los módulos representan las invocaciones de los módulos. El diagrama representa los parámetros de entrada que se le dan a cada módulo invocado y, los parámetros de salida devueltos por cada módulo cuando termina su labor y devuelve el control al que lo llama. No se debe enseñar al usuario ya que modela un aspecto de la implementación del sistema, no de sus requerimientos.
Cada modelo gráfico describe un aspecto distinto del sistema: el DFD resalta las funciones del sistema; el DER resalta las relaciones entre datos; el DTE resalta el comportamiento dependiente del tiempo del sistema. Estos tres aspectos deben ser consistentes y compatibles entre sí.
RESUMEN
Las especificaciones funcionales deben ser:
Gráficas: compuestas por una gran variedad de diagramas, apoyadas con material textual detallado.
Particionadas: de tal manera que puedan leerse independientemente porciones individuales de la especificación.
Mínimamente redundante: de tal manera que los cambios en los requerimientos del usuario puedan incorporarse normalmente en sólo una parte de la especificación.
HERRAMIENTAS CASE
Debido a las características específicas del ciclo de vida y, sobre todo, debido a la gran cantidad de información que se debe generar en cada etapa, comienzan a introducirse herramientas y entornos automatizados de producción, organización, edición y gestión de dicha información, que facilitan, o en muchos casos posibilitan el uso de metodologías formales de forma cómoda y eficiente. Por tanto, la tecnología CASE sustituye el papel y el lápiz por el ordenador para hacer del desarrollo del software un proceso más productivo. El objetivo fundamental del CASE es proporcionar un conjunto de herramientas que automaticen los trabajos de desarrollo y mantenimiento del software. Algunas de las facilidades ofrecidas por este tipo de herramientas son:
Soporte a la gestión para aumentar el control y la coordinación por parte de la dirección.
Diseño de diagramas estructurados y creación de especificaciones gráficas.
Prototipado de las pantallas de usuario.
Centralización de la información del sistema en un diccionario en el que se pueden almacenar, obtener informes y consultar.
Verificación de la consistencia y la corrección de las especificaciones del sistema.
Mantenimiento: re-documentación, reestructuración y análisis del sistema diseñado.
Eliminar errores fácilmente.
Dado que la modelización es una actividad gráfica, se pueden conseguir DFD, DFC, DER y DTE más eficientemente y conseguir resultados más estéticos con herramientas CASE. A medida que se refina cada nivel del modelo de flujo, la herramienta CASE construye una jerarquía interna, de forma que cada burbuja "padre" está asociada con sus burbujas "hijas" y, éstas con él.
Aunque la gestión del DD está presente en todas las herramientas CASE, la mayoría también ofrecen otra serie de utilidades como son la normalización de las estructuras de datos, la generación de las bases de datos a partir de las especificaciones de diseño, la generación de código fuente a partir de las especificaciones funcionales, la elaboración de prototipos que permitirán al usuario observar cómo funcionará el sistema una vez implantado, etc. Según la capacidad de la herramienta CASE, podemos hacer la siguiente clasificación:
CASE Superior: denominada también Planificación Asistida por Ordenador, se basa en la utilización de software que permita automatizar las tareas de planificación empresarial, por ejemplo, lo que concierne a la gestión de proyectos de desarrollo de Sistemas de Información.
CASE Intermedia: se refiere a la automatización del análisis y diseño de Sistemas de Información.
CASE Inferior: pretende la asistencia del computador en la construcción (programación o generación de código) de los Sistemas de Información.
Se realiza teniendo en cuenta los siguientes objetivos:
Identificar las necesidades del cliente.
Evaluar la viabilidad del sistema.
Realizar un análisis técnico y económico.
Asignar funciones al software, al hardware, a la gente, a la base de datos y a otros elementos del sistema.
Establecer restricciones de coste y tiempo.
Crear una definición del sistema que sea la base para todo el trabajo posterior de ingeniería.
Gran parte de la labor que desempeñará el analista involucra el modelado del sistema que desea el usuario. un Modelo es una representación de una parte de la realidad, como p.e. un mapa, un globo terráqueo, un diagrama de flujo, etc. Se construyen los modelos para enfatizar ciertas propiedades críticas del sistema, mientras que simultáneamente se desacentúan otros aspectos. Esto permite comunicarnos con el usuario de una manera enfocada, sin distraernos en asuntos y características ajenas al sistema.. se pueden hacer cambios en el modelo o desecharlo y hacer uno nuevo en caso de ser necesario. Por esta razón, se hace uso de herramientas de modelado para:
Concentrarse en las propiedades importantes del sistema y al mismo tiempo restar importancia a otras menores.
Discutir cambios y correcciones de los requerimientos de usuario, a bajo coste y riesgo mínimo.
Verificar que el analista comprende correctamente el ambiente del usuario y que lo haya respaldado con información documental para que los diseñadores de sistemas y los programadores puedan construir el sistema.
ANÁLISIS ESTRUCTURADO
Es una actividad de construcción de modelos. A medida que fluye la información por un sistema basado en computadora, se transforma. El sistema acepta entradas en una gran variedad de formas, aplica los elementos de hardware, software y humanos para transformar la entrada en salida y produce salidas en una gran variedad de formas. El análisis estructurado es una técnica de modelización del flujo y del contenido de la información. Las herramientas en las que se apoya el análisis estructurado son:
