El método estructurado en el análisis de sistemas

II. MÉTODO DE ANÁLISIS Y DISEÑO ESTRUCTURADO

Este método es una actividad de construcción de modelos. Mediante una notación que es única, se crean modelos que reflejan el flujo y el contenido de la información (datos y control); el sistema se divide funcionalmente y, según los distintos comportamientos, se establece la esencia de lo que se debe construir.

Surge a mediados de los años 70, y ha ido evolucionando introduciéndose mejoras por varios autores; en los primeros años se centraba en las aplicaciones de sistemas de información, luego a mediados de los 80 se introducen mejoras que proporcionan una notación adecuada para los aspectos de control y de comportamiento de los problemas de tiempo real (Ward y Mellor, Hatley y Pirbhai).

El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o aplicación bien sea nuevo o ya existente. Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento, etc.) sin omitir ningún detalle. Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.

El Diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software. El objetivo del Diseño Estructurado es programas formados por módulos independientes unos de otros desde el punto de vista funcional. La herramienta fundamental del Diseño Estructurado es el diagrama estructurado que es de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo). Los Diagramas Estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él.

2.1 Modelado de Datos 

El modelado de datos estudia los datos independientemente del procesamiento que los transforma.

El modelado de datos responde a:

¿Cuáles son las entidades de datos primarios que va a procesar el sistema.?

¿Cuál es la composición de cada entidad de datos y que atributos la describen.?

¿Cuál es la relación entre las entidades y los procesos que las transforman.?

Para resolver estas cuestiones se realiza el diagrama entidad-relación, donde se representa la red de datos que existe en el sistema dado, indicando los datos que se introducen, se almacenan se transforman y se producen dentro de la aplicación.

2.2 Modelado Funcional y Flujo de Información

Diagramas de flujo de datos (DFD)

Herramienta que nos permite mostrar el sistema como una red de sistemas conectados entre sí por los datos. Representa el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida.

Diagramas de flujo de Control (DFC)

Estas ampliaciones permiten al analista reflejar el flujo de control y el procesamiento de control; muestran como fluyen los sucesos entre los distintos procesos e ilustran como los sucesos externos hacen que se activen los procesos. El DFC contiene los mismos procesos que el DFD, pero muestra el flujo de control en lugar de datos. Esta ampliación se centra menos en la creación de símbolos gráficos adicionales y más en la representación y especificación de los aspectos del software orientados al control.

2.3 Modelado de Comportamiento

El modelado del comportamiento es uno de los principios fundamentales de todos los métodos de análisis de requisitos. El Diagrama de transición de Estado representa el comportamiento de un sistema que muestra los estados y los sucesos que hacen que el sistema cambie de estado.

2.4 Diccionario de Datos  

El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista tengan una misma comprensión de las entradas, salidas, almacenes de datos y cálculos intermedios.

Se podría decir que el modelo de análisis estructurado toma la siguiente forma:

Diccionario de datos: contiene definiciones de todos los objetos de datos consumidos y producidos por el software.

Diagrama entidad-relación: representa las relaciones entre entidades de datos. Los atributos de cada entidad se pueden describir mediante la Descripción de datos.

Diagrama de flujo de datos (DFD): sirve para dos propósitos, indica como se transforman los datos a medida que se avanza en el sistema; y representa las funciones que transforman el flujo de datos. En la Especificación de proceso se encuentra un descripción de cada función representada en el DFD.

Diagrama de transición de estados (DTE): indica como se comporta el sistema como consecuencia de sucesos externos. La Especificación de control detalla mas información sobre los aspectos de control del software.

Algunas metodologías estructuradas, que se han implantado en mayor o menor grado en el ámbito laboral son:

Jackson

Page-Jones

Gane & Sarson

Jourdon / De Marco

Warnier

Chen

Merise

SSADM

Metrica

Eurométodo

2.5 Características del Método Estructurado

Los productos de análisis han de ser de mantenimiento muy sencillo. Esto concierne concretamente al documento final (Especificación de requisitos del software).

Se deben tratar los problemas de gran tamaño mediante algún método efectivo de partición.

Siempre que sea posible, se deben utilizar gráficos.

Se deben diferenciar las consideraciones lógicas (esenciales) y las físicas (de implementación).

2.6 Desventajas del Método Estructurado

Esta metodología clásica presenta ciertos problemas, que han ido haciéndose cada vez más graves, a medida que se construían aplicaciones y sistemas informáticos más complejos, entre los que destacan los siguientes:

Modelo mental anómalo. Nuestra imagen del mundo se apoya en los seres, a los que asignamos nombres sustantivos, mientras la programación clásica se basa en el comportamiento, representado usualmente por verbos.

Es difícil modificar y extender los programas, pues suele haber datos compartidos por varios subprogramas, que introducen interacciones ocultas entre ellos.

Es difícil mantener los programas. Casi todos los sistemas informáticos grandes tienen errores ocultos, que no surgen a la luz hasta después de muchas horas de funcionamiento.

Es difícil reutilizar los programas. Es prácticamente imposible aprovechar en una aplicación nueva las subrutinas que se diseñaron para otra.

Fuente: http://www.oocities.org/es/minneliamoreno/ads/contenido.htm