stringtranslate.com

Análisis estructurado

Ejemplo de un enfoque de análisis estructurado. [1]

En ingeniería de software , el análisis estructurado (SA) y el diseño estructurado (SD) son métodos para analizar los requisitos del negocio y desarrollar especificaciones para convertir prácticas en programas de computadora , configuraciones de hardware y procedimientos manuales relacionados.

Las técnicas de análisis y diseño estructurado son herramientas fundamentales del análisis de sistemas . Se desarrollaron a partir del análisis de sistemas clásico 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 todavía se utiliza en la actualidad. [ cita requerida ] El análisis estructurado consiste en interpretar el concepto del sistema (o situaciones del mundo real) en terminología de datos y control representada por diagramas de flujo de datos . El flujo de datos y control desde la burbuja al almacén de datos y a la burbuja puede ser difícil de rastrear y la cantidad de burbujas puede aumentar.

Un enfoque consiste en definir primero los eventos del mundo exterior que requieren que el sistema reaccione y luego asignar una burbuja a ese evento. Las burbujas que necesitan interactuar se conectan entonces hasta que se define el sistema. Las burbujas suelen agruparse en burbujas de nivel superior para reducir la complejidad. Se necesitan diccionarios de datos para describir los flujos de datos y comandos, y se necesita una especificación de proceso para capturar la información de transacción/transformación. [3]

SA y SD se muestran con diagramas de estructura , diagramas de flujo de datos y diagramas de modelos de datos , de los cuales hubo muchas variaciones, incluidos los desarrollados por Tom DeMarco , Ken Orr , Larry Constantine , Vaughn Frick , Ed Yourdon , Steven Ward, Peter Chen y otros.

Estas técnicas se combinaron en varias metodologías de desarrollo de sistemas publicadas , incluido el método de diseño y análisis de sistemas estructurados , información rentable por diseño (PRIDE), análisis y diseño estructurados de Nastec, SDM/70 y la metodología de desarrollo de sistemas estructurados Spectrum.

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 enfrentó el mundo del software desde la década de 1960 hasta la de 1980. En este período de tiempo, la mayor parte de la programación comercial se hacía en Cobol y Fortran , luego en C y BASIC . Había poca orientación sobre técnicas "buenas" de diseño y programación, y no había técnicas estándar para documentar requisitos y diseños. Los sistemas se estaban volviendo más grandes y complejos, y el desarrollo de sistemas de información se volvió cada vez más difícil de hacer". [4]

Como una forma de ayudar a gestionar software grande y complejo, desde finales de la década de 1960 surgieron los siguientes métodos estructurados: [4]

Según Hay (1999) " la ingeniería de la información fue 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 al análisis de sistemas estructurados. Estas técnicas se caracterizaron 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, como para mejorar la disciplina del analista y el diseñador. Durante la década de 1980, comenzaron a aparecer herramientas que automatizaban el dibujo de los diagramas y realizaban un seguimiento de las cosas dibujadas en un diccionario de datos ". [10] Siguiendo el ejemplo del diseño asistido por computadora y la fabricación asistida por computadora (CAD/CAM), el uso de estas herramientas se denominó ingeniería de software asistida por computadora (CASE).

Temas de análisis estructurado

Mecanismo de abstracción único

Ejemplo de análisis estructurado. [11]

El análisis estructurado generalmente crea una jerarquía empleando un único mecanismo de abstracción. El método de análisis estructurado puede emplear IDEF (ver figura), está impulsado por procesos y comienza con un propósito y un punto de vista. Este método identifica la función general y divide iterativamente las funciones en funciones más pequeñas, preservando las entradas, salidas, controles y mecanismos necesarios para optimizar los procesos. También conocido como enfoque de descomposición funcional , se centra en la cohesión dentro de las funciones y el acoplamiento entre funciones que conducen a datos estructurados. [11]

La descomposición funcional del método estructurado describe el proceso sin delinear el comportamiento del sistema y dicta la estructura del sistema en forma de funciones requeridas. El método identifica las entradas y salidas en relación con las actividades. Una razón para la popularidad del análisis estructurado es su capacidad intuitiva para comunicar procesos y conceptos de alto nivel, ya sea en sistemas individuales o en niveles empresariales. No está claro cómo los objetos podrían respaldar las funciones para el desarrollo orientado a objetos comercialmente predominante . A diferencia de IDEF, el UML está impulsado por una interfaz con múltiples mecanismos de abstracción útiles para describir arquitecturas orientadas a servicios (SOA). [11]

Acercarse

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 se describe mediante procesos que transforman los flujos de datos. El análisis estructurado aprovecha la ocultación de la información mediante el análisis de descomposición sucesiva (o de arriba hacia abajo). Esto permite centrar la atención en los detalles pertinentes y evita la confusión derivada de mirar detalles irrelevantes. A medida que aumenta el nivel de detalle, se reduce la amplitud de la información. El resultado del análisis estructurado es un conjunto de diagramas gráficos relacionados, descripciones de procesos y definiciones de datos. Describen las transformaciones que deben tener lugar y los datos necesarios para cumplir con los requisitos funcionales de un sistema . [12]

El enfoque de análisis estructurado desarrolla perspectivas tanto sobre objetos de proceso como sobre objetos de datos. [12]

El enfoque de De Marco [13] consta de los siguientes objetos (ver figura): [12]

Los diagramas de flujo de datos (DFD) son gráficos dirigidos. Los arcos representan datos y los nodos (círculos o burbujas) representan procesos que transforman los datos. Un proceso se puede descomponer aún más en un DFD más detallado que muestra los subprocesos y los flujos de datos dentro de él. Los subprocesos a su vez se pueden descomponer aún más con otro conjunto de DFD hasta que sus funciones se puedan entender fácilmente. Los primitivos funcionales son procesos que no necesitan descomponerse más. Los primitivos funcionales se describen mediante una especificación de proceso (o miniespecificación). La especificación de proceso puede consistir en pseudocódigo, diagramas de flujo o inglés estructurado. Los DFD modelan la estructura del sistema como una red de procesos interconectados compuestos de primitivos funcionales. El diccionario de datos es un conjunto de entradas (definiciones) de flujos de datos, elementos de datos, archivos y bases de datos. Las entradas del diccionario de datos están particionadas de manera descendente. Se puede hacer referencia a ellas en otras entradas del diccionario de datos y en los diagramas de flujo de datos. [12]

Diagrama de contexto

Ejemplo de un diagrama de contexto del sistema. [14]

Los diagramas de contexto son diagramas que representan a los actores externos a un sistema que podrían interactuar con ese sistema. [15] Este diagrama es la vista de nivel más alto de un sistema , similar al diagrama de bloques , que muestra un sistema, posiblemente basado en software , como un todo y sus entradas y salidas desde/hacia factores externos.

Este tipo de diagrama según Kossiakoff (2003) usualmente "representa el sistema en el centro, sin detalles de su estructura interna, rodeado por todos sus sistemas, ambiente y actividades interactuantes. El objetivo de un diagrama de contexto del sistema es enfocar la atención en factores y eventos externos que deberían ser considerados al desarrollar un conjunto completo de requerimientos y restricciones del sistema". [15] Los diagramas de contexto del sistema están relacionados con el diagrama de flujo de datos , y muestran las interacciones entre un sistema y otros actores a los que el sistema está diseñado para enfrentarse. Los diagramas de contexto del sistema pueden ser útiles para entender el contexto en el que el sistema será parte de la ingeniería de software .

Diccionario de datos

Diagrama de relación de entidades , esencial para el diseño de tablas de bases de datos, extractos y metadatos. [16]

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 . [16] Un diccionario de base de datos contiene una lista de todos los archivos de la base de datos, la cantidad de registros de cada archivo y los nombres y tipos de cada campo de datos. La mayoría de los sistemas de administración de bases de datos mantienen el diccionario de datos oculto a los usuarios para evitar que destruyan accidentalmente su contenido. Los diccionarios de datos no contienen ningún dato real de la base de datos, solo información contable para administrarla. Sin embargo, sin un diccionario de datos, un sistema de administración de bases de datos no puede acceder a los datos de la base de datos. [16]

Los usuarios de bases de datos y los desarrolladores de aplicaciones pueden beneficiarse de un documento de diccionario de datos autorizado que catalogue la organización, el contenido y las convenciones de una o más bases de datos. [17] Esto normalmente incluye los nombres y 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 existe un estándar universal en cuanto al nivel de detalle en un documento de este tipo, pero es principalmente una destilación de metadatos sobre la estructura de la base de datos , no los datos en sí. Un documento de diccionario de datos también puede incluir información adicional que describa cómo se codifican los elementos de datos. Una de las ventajas de la documentación de diccionario de datos bien diseñada es que ayuda a establecer la coherencia en toda una base de datos compleja o en una gran colección de bases de datos federadas . [18]

Diagramas de flujo de datos

Ejemplo de diagrama de flujo de datos. [19]

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 en que muestra el flujo de datos a través de procesos en lugar de hardware informático . Los diagramas de flujo de datos fueron inventados por Larry Constantine , desarrollador del diseño estructurado , basándose en el modelo de cálculo de "gráfico de flujo de datos" de Martin y Estrin. [20]

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

Los diagramas de flujo de datos (DFD) son una de las tres perspectivas esenciales del método de análisis y diseño de sistemas estructurados (SSADM). El patrocinador de un proyecto y los usuarios finales deberán recibir información y ser consultados durante todas las etapas de la evolución de un sistema. Con un diagrama de flujo de datos, los usuarios pueden visualizar cómo funcionará el sistema, qué logrará y cómo se implementará. Los diagramas de flujo de datos del sistema anterior se pueden dibujar y comparar con los diagramas de flujo de datos del nuevo sistema para establecer comparaciones que permitan implementar un sistema más eficiente. Los diagramas de flujo de datos se pueden utilizar para proporcionar al usuario final una idea física de cómo los datos que ingresan tienen un efecto en última instancia sobre la estructura de todo el sistema, desde el pedido hasta el envío y la reutilización. La forma en que se desarrolla cualquier sistema se puede determinar a través de un diagrama de flujo de datos.

Diagrama de estructura

Diagrama de estructura de un sistema de configuración. [21]

Un diagrama de estructura (SC) es un diagrama que muestra el desglose del sistema de configuración hasta los niveles más bajos manejables. [21] Este diagrama se utiliza en la programación estructurada para organizar los módulos del programa en una estructura de árbol. Cada módulo está representado por un cuadro que contiene el nombre de los módulos. La estructura de árbol visualiza las relaciones entre los módulos. [22]

Los diagramas de estructura se utilizan en el análisis estructurado para especificar el diseño de alto nivel, o la arquitectura, de un programa informático . Como herramienta de diseño, ayudan al programador a dividir y conquistar un gran problema de software, es decir, a descomponer recursivamente un problema en partes lo suficientemente pequeñas como para que las entienda un cerebro humano. El proceso se denomina diseño de arriba hacia abajo o descomposición funcional . Los programadores utilizan un diagrama de estructura para crear un programa de forma similar a cómo un arquitecto utiliza un plano para construir una casa. En la etapa de diseño, se dibuja el diagrama y se utiliza como una forma de comunicación entre el cliente y los distintos diseñadores de software. Durante la construcción real del programa (implementación), el diagrama se denomina continuamente plan maestro. [23]

Diseño estructurado

El diseño estructurado (SD) se ocupa del desarrollo de módulos y la síntesis de estos módulos en una denominada "jerarquía de módulos". [24] Para diseñar una estructura y unas interfaces óptimas de los módulos, son fundamentales dos principios:

El diseño estructurado fue desarrollado por Larry Constantine a finales de los años 1960, y luego refinado y publicado con colaboradores en los años 1970; [5] [6] véase Larry Constantine: diseño estructurado para más detalles. Page-Jones (1980) ha propuesto su propio enfoque que consta de tres objetivos principales:

El diagrama de estructura tiene como objetivo mostrar "la jerarquía de módulos o la relación de secuencia de llamadas de los módulos. Hay una especificación de módulo para cada módulo que se muestra en el diagrama de estructura. Las especificaciones de módulo pueden estar compuestas de pseudocódigo o un lenguaje de diseño de programas. El diccionario de datos es como el del análisis estructurado. En esta etapa del ciclo de vida del desarrollo de software , después de que se hayan realizado el análisis y el diseño, es posible generar automáticamente declaraciones de tipos de datos", [25] y plantillas de procedimientos o subrutinas. [12]

Críticas

Los problemas con los diagramas de flujo de datos incluyen los siguientes: [3]

  1. Elegir las burbujas de forma adecuada
  2. Dividir las burbujas de una manera significativa y mutuamente acordada,
  3. Tamaño de la documentación necesaria para comprender los flujos de datos,
  4. Los diagramas de flujo de datos son de naturaleza fuertemente funcional y, por lo tanto, están sujetos a cambios frecuentes.
  5. Aunque se enfatiza el flujo de "datos", no se hace hincapié en el modelado de "datos", por lo que hay poca comprensión del tema del sistema.
  6. Los clientes tienen dificultades para seguir cómo se plasma el concepto en flujos y burbujas de datos.
  7. Los diseñadores deben cambiar la organización DFD a un formato implementable

Véase también

Referencias

  1. ^ Tricia Gilbert (2006) Criterios de evaluación del FCS para la evaluación de tecnología Archivado el 18 de septiembre de 2008 en Wayback Machine.
  2. ^ Edward Yourdon (1986). Gestión de técnicas estructuradas: estrategias para el desarrollo de software en los años 1990. Yourdon Press. p.35.
  3. ^ ab FAA (2000). Manual de seguridad del sistema de la FAA, Apéndice D. 30 de diciembre de 2000.
  4. ^ de Dave Levitt (2000). "Introducción al análisis y diseño estructurados". en Faculty.inverhills.edu/dlevitt . Consultado el 21 de septiembre de 2008. Ya no está disponible en línea desde 2017.
  5. ^ por Stevens, Myers y Constantine 1974.
  6. ^ desde Yourdon y Constantine 1979.
  7. ^ McMenamin, Stephen M.; Palmer, John F. (1984). Análisis de sistemas esenciales . Yourdon Press. ISBN 978-0-13-287905-7.
  8. ^ Gavriel Salvendy (2001). Manual de ingeniería industrial: tecnología y gestión de operaciones. . p.508.
  9. ^ Yourdon, Edward (1989). Análisis estructurado moderno. Prentice-Hall. ISBN 978-0-13-598632-5.
  10. ^ David C. Hay (1999) Lograr el cumplimiento de las palabras de moda en la orientación a objetos Archivado el 20 de octubre de 2008 en Wayback Machine Essential Strategies, Inc.
  11. ^ Grupo de trabajo sobre el marco de arquitectura del Departamento de Defensa (2003). DoDAF 1.5, volumen 2, 15 de agosto de 2003.
  12. ^ abcdefg Alan Hecht y Andy Simmons (1986) Integración de análisis y diseño estructurado automatizado con entornos de soporte de programación Ada NASA 1986.
  13. ^ Tom DeMarco (1978). Análisis estructurado y especificación de sistemas . Yourdon Press, Nueva York, 1978.
  14. ^ Gestión de proyectos NDE Archivado el 7 de noviembre de 2008 en el sitio web de Explotación de datos de Wayback Machine (NPOESS). 2008.
  15. ^ de Alexander Kossiakoff, William N. Sweet (2003). Ingeniería de sistemas: principios y prácticas, pág. 413.
  16. ^ Glosario de integración de datos abc Archivado el 18 de febrero de 2012 en Wayback Machine , Departamento de Transporte de EE. UU., agosto de 2001.
  17. ^ TechTarget, SearchSOA , ¿Qué es un diccionario de datos?
  18. ^ AHIMA Practice Brief, Pautas para el desarrollo de un diccionario de datos, Journal of AHIMA 77, n.º 2 (febrero de 2006): 64A-D.
  19. ^ John Azzolini (2000). Introducción a las prácticas de ingeniería de sistemas. Julio de 2000.
  20. ^ W. Stevens, G. Myers, L. Constantine, "Diseño estructurado", IBM Systems Journal, 13 (2), 115-139, 1974.
  21. ^ ab "Gestión de la configuración" En: Recursos del IRS Parte 2. Tecnología de la información Capítulo 27. Gestión de la configuración . Consultado el 14 de noviembre de 2008.
  22. ^ James Martin , Carma L. McClure (1988). Técnicas estructuradas: la base para el análisis de casos . Prentice Hall. pág. 56.
  23. ^ David Wolber "Gráficos de estructura Archivado el 19 de febrero de 2009 en Wayback Machine : Notas complementarias Gráficos de estructura e implementación de abajo hacia arriba: versión Java.
  24. ^ Página-Jones 1980.
  25. ^ Belkhouche, B. y JE Urban. (1986). "Implementación directa de tipos de datos abstractos a partir de especificaciones abstractas". En: IEEE Transactions on Software Engineering , pp. 549-661, mayo de 1986.

Lectura adicional

Enlaces externos