Análisis estructurado

El Análisis Estructurado (SA) en ingeniería de software y su técnica aliada, Diseño estructurado (SD), es un conjunto de métodos orientados a analizar y convertir requisitos de negocio dentro de especificaciones y en última instancia, programas informáticos, configuraciones de hardware y procedimientos manuales relacionados.

Ejemplo de un enfoque de Análisis Estructurado.^[1]​

Las técnicas de análisis y diseño estructurados son herramientas fundamentales de análisis de sistemas, y desarrolladas a partir de análisis de sistemas clásicos de los años 1960 y 1970.^[2]​

Objetivos del Análisis Estructurado

El análisis estructurado se hizo popular en la década de 1980 y sigue siendo utilizado por muchos. El análisis consiste en interpretar el concepto del sistema (o situaciones del mundo real) en datos y controlar la terminología representada por el diagrama de flujo de datos. El flujo de datos y el control de la burbuja para el almacén de datos de la burbuja pueden ser muy difíciles de seguir y el número de burbujas puede llegar a ser muy grande. Un enfoque es definir primero los eventos del mundo exterior que requieren que el sistema reaccione, a continuación, asignar una burbuja para ese evento, las burbujas que necesitan interactuar se conectan luego hasta que se defina el sistema. Esto puede ser bastante abrumador y así las burbujas suelen agruparse en burbujas de nivel superior. Se necesitan los Diccionario de datos para describir los flujos de datos y de mando como también se necesita una especificación de proceso para capturar la información de la transacción/transformación.^[3]​

SA y SD fueron acompañados por un método de notación incluyendo los diagrama de estructura compuesta, diagrama de flujo de datos y diagramas de modelo de datos, de los cuales hubo muchas variaciones, incluyendo las desarrolladas por Tom DeMarco, Ken Orr, Larry Constantine, Vaughn Frick, Ed Yourdon, Steven Ward, Peter Chen, y otros.

Estas técnicas se combinaron en varios publicados de procesos para el desarrollo de software, incluyendo el método de análisis y diseño de sistemas estructurados, Información Rentable por Diseño (PRIDE), Análisis Estructurado y diseño Nastec, SDM/70 y la metodología de desarrollo de sistemas de Espectro Estructurado.

Historia

El análisis estructurado es parte de una serie de métodos estructurados, que "representan una colección de técnicas de análisis, diseño y programación que se desarrollaron en respuesta a los problemas que enfrenta el mundo del software desde 1960 hasta la década de 1980. En este marco de tiempo más programación comercial se hizo en Cobol y Fortran, luego en Lenguaje C y BASIC. Hubo poca orientación sobre las "buenas" técnicas de diseño y programación, y no había técnicas estándar para la documentación de requisitos y diseños. Los sistemas fueron cada vez más grandes y más complejos, y el desarrollo de sistemas de información se hicieron más y más difíciles de hacer ".^[4]​ Como una manera de ayudar a manejar un software grande y complejo, surgieron los siguientes métodos estructurados.

Desde finales de la década de 1960 varios Métodos Estructurados surgieron:^[4]​

• La programación estructurada en alrededor de 1967 con Edsger Dijkstra - "La sentencia GOTO considerada perjudicial"
• Niklaus Wirth Diseño paso a paso en 1971
• Diagrama Nassi-Shneiderman en 1972
• Diagrama Warnier/Orr en 1974 - "La construcción lógica de los programas"
• HIPO en 1974 - IBM Jerarquía entrada-proceso-salida (aunque esto debería ser realmente la salida-entrada-proceso)
• Diseño Estructurado en torno a 1975 con Larry Constantino, Ed Yourdon y Wayne Stevens.^[5]​^[6]​
• Programación Estructurada Jackson en torno a 1975 elaborado por Michael A. Jackson
• Análisis Estructurado cerca de 1978 con Tom DeMarco, Yourdon, Gane y Sarson, McMenamin & Palmer.
• Técnica de Análisis y Diseño Estructurado (SADT) desarrollada por Douglas T. Ross
• Método Estructurado Yourdon desarrollado por Edward Yourdon.
• Análisis Estructurado y Especificación del Sistema publicada en 1979 por Tom DeMarco.
• Método de análisis y diseño de sistemas estructurados (AETD) presentado por primera vez en 1983 desarrollado por la Office of Government Commerce del Reino Unido.
• IDEF0 basado en TDAA, desarrollado por Douglas T. Ross en 1985.^[7]​
• Modelado Hatley-Pirbhai, definido en "Estrategias para el Sistema de Especificación de Tiemo Real" por Derek J. Hatley y Imtiaz A. Pirbhai en 1988.
• Ingeniería de la Información en alrededor de 1990 con Finkelstein y popularizada por James Martin.

Según Hay (1999) "La ingeniería de la información era una extensión lógica de las técnicas estructuradas que se desarrollaron durante la década de 1970. La programación estructurada condujo al diseño estructurado, que a su vez condujo a sistemas de análisis estructurado. Estas técnicas se caracterizan por su uso de diagramas: diagramas de estructura para el diseño estructurado y diagramas de flujo de datos para el análisis estructurado, tanto para ayudar en la comunicación entre usuarios y desarrolladores, y para mejorar el análisis de la disciplina y del diseñador. Durante la década de 1980, comenzaron a aparecer herramientas para el dibujo de los diagramas automatizados, y llevaron un registro de las cosas dibujadas en un diccionario de datos".^[8]​ Después del ejemplo de diseño asistido por computadora y la fabricación asistida por computadora (CAD / CAM), el uso de estas herramientas fue nombrada la Herramienta CASE.

Temas de análisis estructurado

Sencillo mecanismo de resumen

 

Imagen:Ejemplo de Análisis Estructurado.^[9]​

El análisis estructurado normalmente crea una jerarquía que emplea un único mecanismo de resumen. El método de análisis estructurado puede emplear IDEF (ver figura), es un proceso conducido, y comienza con un propósito y un punto de vista. Este método identifica la función global y de forma iterativa divide funciones en funciones más pequeñas, entradas conservantes, salidas, controles y mecanismos necesarios para optimizar los procesos. También es conocido como un enfoque de descomposición funcional, se centra en la cohesión dentro de las funciones y de acoplamiento entre las funciones que llevan a los datos estructurados.^[9]​

La descomposición funcional del método estructurado describe el proceso sin delinear el comportamiento del sistema y la estructura del sistema dictados en forma de funciones requeridas. El método identifica las entradas y salidas en relación con las actividades. Una de las razones de la popularidad del análisis estructurado es su capacidad intuitiva para comunicar procesos y conceptos de alto nivel, si los niveles del sistema son sencillos o empresariales. El descubrimiento de cómo los objetos pueden ayudar a las funciones de desarrollo orientado a objetos comercialmente está claro. En contraste con IDEF, el UML está impulsada con múltiples interfaces de mecanismos de resumen útiles para describir las arquitecturas orientadas a servicios (SOAs).^[9]​

Enfoque

El análisis estructurado considera un sistema desde la perspectiva de los datos que fluyen a través de él. La función del sistema es descrita por procesos que transforman los flujos de datos. El análisis estructurado se aprovecha de la ocultación de información a través del análisis de descomposición sucesiva (o de arriba hacia abajo). Esto permite que la atención se centre en los detalles pertinentes y evita la confusión de mirar los detalles irrelevantes. Como el nivel de detalle aumenta, se reduce la amplitud de la información. El resultado del análisis estructurado es un conjunto relacionado de diagramas, gráficas, descripciones de procesos, y las definiciones de datos. Ellos describen las transformaciones que deben llevarse a cabo y los datos necesarios para cumplir con el Requisito funcional de un sistema.^[10]​

 

El enfoque del análisis estructurado desarrolla perspectivas tanto en los objetos del proceso y los datos de los objetos.^[10]​

El enfoque de De Marco^[11]​ consta de los siguientes objetos (véase el gráfico):^[10]​

• Diagrama de contexto de sistema
• Diagrama de flujo de datos
• Especificaciones de los procesos
• Diccionario de datos

Con el diagrama de flujo de datos (DFDs) se dirigen gráficos. Los arcos representan los datos, y los nodos (círculos o burbujas) representan procesos que transforman los datos. Un proceso se puede descomponer además a un DFD más detallado que muestra los subprocesos y los flujos de datos dentro de ella. Los subprocesos pueden a su vez descomponerse aún más con otro conjunto de DFD hasta que sus funciones se pueden entender fácilmente. Las funciones primitivas son procesos que no necesitan ser descompuestas aún más. Estas funciones primitivas se describen por una especificación de proceso (o mini-spec). La especificación del proceso puede consistir en pseudocódigo, diagramas de flujo, o Inglés estructurado. En el modelo de DFD la estructura del sistema es como una red de procesos interconectados compuestos de funciones primitivas. El diccionario de datos es un conjunto de entradas (definiciones) de los flujos de datos, elementos de datos, archivos y bases de datos. Los diccionarios de datos se dividen de una manera de arriba hacia abajo. Estos pueden ser referenciados en otras entradas del diccionario de datos y en los diagramas de flujo de datos.^[10]​

Diagrama de contexto

 

Ejemplo de un diagrama de contexto del sistema.^[12]​

Los Diagrama de contexto de sistema son diagramas que representan los usuarios que fuera de un sistema podrían interactuar con él.^[13]​ Este diagrama es la vista de más alto nivel de un sistema, similar al diagrama de bloques, que muestra, posiblemente un sistema de software basado en entradas y salidas además de sus factores externos.

Este tipo de diagrama según Kossiakoff (2003) por lo general "muestra el sistema en el centro, sin detalles de su estructura interior, rodeado de todos sus sistemas de interacción, medio ambiente y actividades. El objetivo de un diagrama de contexto del sistema es centrar la atención en factores y eventos que deben ser considerados en el desarrollo de un conjunto completo de las propuestas del sistema y las limitaciones externas".^[13]​ El diagrama de contexto del sistema está relacionado con el Diagrama de flujo de datos, y muestran las interacciones entre un sistema y otros usuarios con los que el sistema está diseñado para hacer frente. Un diagrama de contexto del sistema puede ser útil para comprender el contexto en el cual el sistema será parte de la ingeniería de software.

Diccionario de datos

 

Modelo entidad-relación, esencial para el diseño de tablas de bases de datos, extractos y metadatos.

Un diccionario de datos o diccionario de base de datos es un archivo que define la organización básica de una base de datos. Un diccionario de la base de datos contiene una lista de todos los archivos de la base de datos, el número de registros en cada archivo, y los nombres y tipos de cada campo de datos. La mayor parte del sistema de gestión de base de datos mantiene el diccionario de datos ocultos a los usuarios para evitar la destrucción accidental de los contenidos. Los diccionarios de datos no contienen los datos reales de la base de datos, sólo la contabilidad de información para su gestión. Sin un diccionario de datos, sin embargo, un sistema de gestión de base de datos no puede acceder a los datos desde la base de datos.

Los usuarios de bases de datos y desarrolladores de Aplicación informática pueden beneficiarse de un documento del diccionario de datos de una autoridad que cataloga la organización, contenidos, y las convenciones de una o más bases de datos.^[14]​ Esto incluye típicamente los nombres y las descripciones de varias tablas y campos en cada base de datos, además de detalles adicionales, como el tipo y la longitud de cada elemento de datos. No hay un estándar universal para el nivel de detalle en un documento de este tipo, pero es sobre todo una destilación de metadatos acerca de la estructura y diseño de la Base de datos, no los datos en sí. Un documento de diccionario de datos también puede incluir información que describe cómo se codifican los elementos de datos. Una de las ventajas del buen diseño de la documentación del diccionario de datos es que ayuda a establecer la coherencia en una base de datos compleja, a través de una gran colección de bases de datos federada.^[15]​

Diagramas de Flujo de Datos

 

Ejemplo de un Diagrama de flujo de datos.^[16]​

Un diagrama de flujo de datos (DFD) es una representación gráfica del "flujo" de datos a través de un sistema de información. Se diferencia del diagrama de flujo del sistema, ya que muestra el flujo de datos a través de procesos en lugar del Hardware. Los diagramas de flujo de datos fueron inventados por Larry Constantino, promotor del diseño estructurado, basado en el modelo de computación Martin y Estrin "gráfico de flujo de datos".^[17]​

Es una práctica común dibujar un Diagrama de contexto de sistema que primero muestra la interacción entre el sistema y entidades externas. El DFD está diseñado para mostrar cómo un sistema se divide en porciones más pequeñas y para resaltar el flujo de datos entre las partes. Este diagrama de flujo de datos de nivel de contexto se "explotó" para mostrar más detalles del sistema que se está modelando.

Los diagramas de flujo de datos (DFDs) son una de las tres perspectivas esenciales de Método de análisis y diseño de sistemas estructurados (SSADM). El patrocinador de un proyecto y los usuarios finales tendrán que ser informados y consultados en todas las etapas de la evolución de un sistema. Con un diagrama de flujo de datos, los usuarios son capaces de visualizar cómo funcionará el sistema, lo que el sistema va a lograr, y cómo se implementará el sistema. Los diagramas de flujo de datos del viejo sistema se pueden elaborar y comparar con los diagramas de flujo de datos del nuevo sistema para implementar un sistema más eficiente. Los diagramas de flujo de datos se pueden utilizar para proporcionar al usuario final con una idea física de donde los datos de entrada tienen en última instancia un efecto sobre la estructura de todo el sistema para ordenar una reestructuración. Cómo cualquier sistema es desarrollado puede determinarse a través de un diagrama de flujo de datos.

Diagrama de Estructura

 

Una configuración del Diagrama de Estructura del Sistema.^[18]​

Un diagrama de estructura (SC) es un gráfico que muestra la distribución del sistema de configuración de los niveles más bajos y manejables.^[18]​ Esta tabla se usa en la programación estructurada para organizar los módulos de programa en una estructura de árbol. Cada módulo está representado por una caja que contiene el nombre del módulo. La estructura de árbol visualiza las relaciones entre los módulos.^[19]​

En análisis estructurado los diagramas de estructura se utilizan para especificar el diseño de alto nivel, o la arquitectura de un programa de computadora. Como una herramienta de diseño, ayudan al programador a dividir y conquistar un problema de software grande, es decir, de forma recursiva romper un problema en partes que son lo suficientemente pequeños para ser entendido por un cerebro humano. El proceso es llamado Top-down y bottom-up, o de descomposición funcional. Los programadores usan un diagrama de estructura para construir un programa de una manera similar a cómo un arquitecto utiliza un plano para construir una casa. En la etapa de diseño, el diagrama se dibuja y se utiliza como una manera para que el cliente y los diferentes diseñadores de software puedan comunicarse. Durante la construcción real del programa (aplicación), al gráfico se le refiere continuamente como el plan maestro.^[20]​

Diseño Estructurado

El Diseño Estructurado (SD) tiene que ver con el desarrollo de los módulos y la síntesis de estos módulos en una llamada "jerarquía de módulo". ^[21]​ Para el diseño de la estructura del módulo óptimo y las interfaces, estos dos principios son cruciales:

• La cohesión en Diseño estructurado, que es "interés por la agrupación de procesos relacionados funcionalmente en un módulo en particular",^[10]​ y
• Acoplamiento informático, se refiere a "el flujo de información o parámetros que se pasan entre los módulos. El acoplamiento óptimo reduce las interfaces de módulos y la complejidad resultante del software ".^[10]​

El Diseño Estructurado fue desarrollado por Larry Constantino a finales de 1960, luego refinado y publicado con colaboradores en la década de 1970; ^[5]​^[6]​ véase Larry Constantine: Diseño Estructurado para obtener más información Page-Jones (1980) ha propuesto su propio enfoque que consiste en tres principales objetos:

• diagramas de estructura
• Especificaciones del módulo
• diccionario de datos.

El Diagrama de estructura compuesta tiene como objetivo mostrar "la jerarquía del módulo o llamada secuencia de relación de los módulos. Hay un módulo de especificación para cada módulo mostrado en el diagrama de estructura. Los especificaciones del modulo pueden estar compuestas de pseudocódigo o un lenguaje de diseño de programa. El diccionario de datos es como el del análisis estructurado. En esta etapa del Proceso para el desarrollo de software, después de haber realizado el análisis y el diseño, es posible generar automáticamente las declaraciones de tipo de datos ",^[22]​ y de procedimientos o plantillas de subrutinas.^[10]​

Lenguaje de consulta estructurado

El lenguaje de consulta estructurado (SQL) es un lenguaje estandarizado para la consulta de la información de una base de datos. SQL se introdujo por primera vez como un sistema de bases de datos comerciales en 1979 y desde entonces ha sido el lenguaje de consulta favorita para los sistemas de gestión de base de datos que se ejecutan en sistemas grandes y medianos. Cada vez más, sin embargo, SQL está siendo apoyado por los sistemas de bases de datos de PC, ya que soporta las bases de datos distribuidas (véase la definición de base de datos distribuida). Esto permite que varios usuarios en una red informática puedan acceder a la misma base de datos al mismo tiempo. Aunque hay diferentes dialectos de SQL, sin embargo es lo más parecido a un lenguaje de consulta estándar que existe en la actualidad.

Herramientas de software para el análisis estructurado

• Herramienta de Análisis Estructurado

Críticas

Algunos problemas asociados los diagramas de flujo de datos han sido:^[3]​

1. eligiendo apropiadamente burbujas,
2. partición de las burbujas en una significativa y acordada manera,
3. el tamaño de la documentación necesaria para entender los flujos de datos,
4. estando muy funcional en la naturaleza y por lo tanto sujetos a cambios frecuentes,
5. aunque se enfatiza el flujo de "los datos", no es por los "datos" de modelado, por lo que hay poca comprensión acerca del tema del sistema, y
6. no sólo es difícil para el cliente seguir cómo el concepto se hace corresponder a estos flujos y las burbujas de datos, sino que también ha sido muy difícil para los diseñadores que deben cambiar la organización DFD en un formato implementable

Véase también

• Organización de Eventos
• HIPO
• Jackson Programación Estructurada
• Metodología de sistemas blandos
• Método estructurado Yourdon
• Programación basada en flujos

Referencias

1. Tricia Gilbert (2006)
2. Edward Yourdon (1986). Managing the Structured Techniques: Strategies for Software Development in the 1990s. Yourdon Press. p.35.
3. FAA (2000).FAA System Safety Handbook, Appendix D. December 30, 2000.
4. Dave Levitt (2000):. Retrieved 21 Sep 2008.
5. Stevens, Myers y Constantine, 1974.
6. Yourdon y Constantine, 1979.
7. Gavriel Salvendy (2001).Handbook of Industrial Engineering: Technology and Operations Management.. p.508.
8. David C. Hay (1999) Achieving buzzword compliance in Object orientation el 20 de octubre de 2008 en Wayback Machine. Essential Strategies, Inc.
9. DoD Architecture Framework Working Group (2003). , 15 August 2003.
10. Alan Hecht and Andy Simmons (1986) Integrating Automated Structured Analysis and Design with Ada Programming Support Environments NASA 1986.
11. Tom DeMarco Structured Analysis and System Specification. Yourdon Press, New York, 1978.
12. (NPOESS) Data Exploitation web site. 2008.
13. Alexander Kossiakoff, William N. Sweet (2003). Systems Engineering: Principles and Practices p. 413.
14. TechTarget, SearchSOA, Que es un diccionario de datos?
15. AHIMA Practice Brief, , Journal of AHIMA 77, no.2 (February 2006): 64A-D.
16. John Azzolini (2000). Introduction to Systems Engineering Practices. July 2000.
17. W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974.
18. In: IRS Resources Part 2. Information Technology Chapter 27. Configuration Management. Accessed 14 Nov 2008.
19. James Martin, Carma L. McClure (1988). Structured Techniques: The Basis for Case. Prentice Hall. p.56.
20. David Wolber ": Supplementary Notes Structure Charts and Bottom-up Implementation: Java Version.
21. Page-Jones, 1980.
22. Belkhouche, B., and J.E. Urban. (1986). "Direct Implementation of Abstract Data Types from Abstract Specifications". In: IEEE Transactions on Software Engineering pp. 549-661, May, 1986.

• Tom DeMarco (1979). Structured Analysis and System Specification. Prentice Hall. ISBN 0-13-854380-1
• Page-Jones, M (1980), The Practical Guide to Structured Systems Design, New York: Yourdon Press .
• Derek J. Hatley, Imtiaz A. Pirbhai (1988). Strategies for Real Time System Specification. John Wiley and Sons Ltd. ISBN 0-932633-04-8
• Stephen J. Mellor und Paul T. Ward (1986). Structured Development for Real-Time Systems: Implementation Modeling Techniques: 003. Prentice Hall. ISBN 0-13-854803-X
• Edward Yourdon (1989). Modern Structured Analysis, Yourdon Press Computing Series, 1989, ISBN 0-13-598624-9
• Keith Edwards (1993). Real-Time Structured Methods, System Analysis. Wiley. ISBN 0-471-93415-1

Enlaces externos

•   Wikimedia Commons alberga una categoría multimedia sobre Análisis estructurado.
• CRaG Systems, 2004.

•   Datos: Q119727
•   Multimedia: Structured analysis