leer wikipedia con nuevo diseño

Análisis estructurado

En ingeniería de software , el análisis estructurado (SA) y el diseño estructurado (SD) son métodos para analizar los requisitos comerciales y desarrollar especificaciones para convertir prácticas en programas de computadora , 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 estructurado son herramientas fundamentales del análisis de sistemas . Se desarrollaron a partir del análisis de sistemas clásicos de las décadas de 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 datos y terminología de control representada por diagramas de flujo de datos . El flujo de datos y el control de la burbuja al almacén de datos a la burbuja puede ser difícil de rastrear y la cantidad de burbujas puede aumentar.

Un enfoque es 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 luego hasta que se define el sistema. Las burbujas generalmente se agrupan en burbujas de nivel superior para disminuir 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 gráficos 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 análisis y diseño 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 enfrenta 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 realizó en Cobol y Fortran , luego en C y BASIC . Había poca orientación sobre técnicas de programación y diseño "buenas", y no existían técnicas estándar para documentar los requisitos y diseños. Los sistemas eran cada vez más grandes y complejos, y el desarrollo del sistema de información se hacía cada vez más difícil de lograr ". [4]

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

  • Programación estructurada alrededor de 1967 con Edsger Dijkstra - "Ir a la declaración considerada perjudicial"
  • Diseño de Niklaus Wirth Stepwise en 1971
  • Diagrama de Nassi-Shneiderman en 1972
  • Diagrama de Warnier / Orr en 1974 - "Construcción lógica de programas"
  • HIPO en 1974 - IBM Hierarchy input-process-output (aunque esto realmente debería ser output-input-process)
  • Diseño estructurado alrededor de 1975 con Larry Constantine , Ed Yourdon y Wayne Stevens . [5] [6]
  • Programación estructurada de Jackson alrededor de 1975 desarrollada por Michael A. Jackson
  • Análisis estructurado alrededor de 1978 con Tom DeMarco , Edward Yourdon , Gane & Sarson, McMenamin & Palmer.
  • Técnica de análisis y diseño estructurado (SADT) desarrollada por Douglas T. Ross
  • Método estructurado de Yourdon desarrollado por Edward Yourdon .
  • Análisis estructurado y especificación del sistema publicado en 1978 por Tom DeMarco .
  • Método de diseño y análisis de sistemas estructurados (SSADM) presentado por primera vez en 1983 desarrollado por la Oficina de Comercio Gubernamental del Reino Unido .
  • Análisis de sistemas esenciales , propuesto por Stephen M. McMenamin y John F. Palmer [7]
  • IDEF0 basado en SADT, desarrollado por Douglas T. Ross en 1985. [8]
  • Modelado de Hatley-Pirbhai , definido en "Estrategias para la especificación de sistemas en tiempo real" por Derek J. Hatley e Imtiaz A. Pirbhai en 1988.
  • Modern Structured Analysis , desarrollado por Edward Yourdon, después de que se publicara Essential System Analysis, y se publicó en 1989. [9]
  • Ingeniería de tecnología de la información alrededor de 1990 con Finkelstein y popularizada por James Martin .

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 el 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 del diseñador. Durante la década de 1980, comenzaron a aparecer herramientas que automatizaban el dibujo de los diagramas y realizó un seguimiento de las cosas dibujadas en un diccionario de datos ". [10] Después de que el ejemplo de diseño asistido por ordenador y asistido por ordenador fabricación (CAD / CAM), el uso de estas herramientas fue nombrada la 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 normalmente crea una jerarquía que emplea 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 de manera iterativa 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 entradas y salidas relacionadas 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, ya sea en un único sistema o en niveles empresariales. No está claro descubrir cómo los objetos pueden admitir 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 ve 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 el ocultamiento de la información mediante 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 al 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]

  • Diagrama contextual
  • Diagrama de flujo de datos
  • Especificaciones de proceso
  • Diccionario de datos

De este modo, 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 se puedan entender fácilmente sus funciones. Las primitivas funcionales son procesos que no necesitan descomponerse más. Las primitivas funcionales se describen mediante una especificación de proceso (o mini-especificación). La especificación del 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 por primitivas 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 divididas de arriba hacia abajo. Se pueden hacer referencia a ellos en otras entradas del diccionario de datos y en diagramas de flujo de datos. [12]

Diagrama contextual

Ejemplo de diagrama de contexto de un 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 de / a factores externos.

Este tipo de diagrama según Kossiakoff (2003) generalmente "representa el sistema en el centro, sin detalles de su estructura interior, rodeado por todos sus sistemas, entornos y actividades que interactúan. El objetivo de un diagrama de contexto del sistema es centrar la atención en factores y eventos externos que deben tenerse en cuenta al desarrollar un conjunto completo de requisitos 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 enfrentar. Los diagramas de contexto del sistema pueden ser útiles para comprender el contexto en el que el sistema formará parte de la ingeniería de software .

Diccionario de datos

Diagrama de relación entre entidades , fundamental para el diseño de tablas, extractos y metadatos de bases de datos. [dieciséis]

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, el número de registros en 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 datos reales de la base de datos, solo información contable para su gestión. 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. [dieciséis]

Los usuarios de bases de datos y los desarrolladores de aplicaciones pueden beneficiarse de un documento de diccionario de datos autorizado que cataloga la organización, los contenidos y las convenciones de una o más bases de datos. [17] Esto generalmente 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 dicho documento, 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 describe cómo se codifican los elementos de datos. Una de las ventajas de la documentación del diccionario de datos bien diseñada es que ayuda a establecer la coherencia en 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 los procesos en lugar del hardware de la computadora . Los diagramas de flujo de datos fueron inventados por Larry Constantine , desarrollador de diseño estructurado , basado en el modelo de cálculo del "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 muestre la interacción entre el sistema y las entidades externas. El DFD está diseñado para mostrar cómo se divide un sistema en porciones más pequeñas y para resaltar el flujo de datos entre esas partes. Este diagrama de flujo de datos a nivel de contexto se "amplía" 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 diseño y análisis de sistemas estructurados (SSADM). El patrocinador de un proyecto y los usuarios finales deberán ser informados y 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 operará el sistema, qué logrará el sistema y cómo se implementará. Los diagramas de flujo de datos del sistema antiguo pueden elaborarse y compararse con los diagramas de flujo de datos del nuevo sistema para establecer comparaciones para 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 dónde los datos que ingresan finalmente tienen un efecto sobre la estructura de todo el sistema, desde el orden hasta el envío y la recuperación. La forma en que se desarrolla cualquier sistema se puede determinar mediante un diagrama de flujo de datos.

Diagrama de estructura

Un diagrama de estructura del sistema de configuración. [21]

Un diagrama de estructura (SC) es un diagrama que muestra el desglose del sistema de configuración en los niveles manejables más bajos. [21] Este gráfico se utiliza en 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 gráficos de estructura se utilizan en el análisis estructurado para especificar el diseño o arquitectura de alto nivel de un programa de computadora . Como herramienta de diseño, ayudan al programador a dividir y conquistar un gran problema de software, es decir, dividir de forma recursiva un problema en partes que son lo suficientemente pequeñas como para ser entendidas por un cerebro humano. El proceso se denomina diseño de arriba hacia abajo o descomposición funcional . Los programadores usan un diagrama de estructura para construir un programa de una manera similar a como un arquitecto usa un plano para construir una casa. En la etapa de diseño, el gráfico se dibuja 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 gráfico 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 de módulo e interfaces óptimas, dos principios son cruciales:

  • Cohesión, que "se refiere a la agrupación de procesos relacionados funcionalmente en un módulo particular", [12] y
  • El acoplamiento se refiere al "flujo de información o parámetros que se pasan entre módulos. El acoplamiento óptimo reduce las interfaces de los módulos y la complejidad resultante del software". [12]

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

  • gráficos de estructura
  • especificaciones del módulo
  • Diccionario de datos.

El diagrama de estructura tiene como objetivo mostrar "la jerarquía del módulo 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 del módulo pueden estar compuestas por un pseudocódigo o un lenguaje de diseño de programa. El diccionario de datos es como el análisis estructurado. En esta etapa del ciclo de vida del desarrollo de software , una vez realizado el análisis y el diseño, es posible generar automáticamente declaraciones de tipo de datos ", [25] y plantillas de procedimiento o subrutina. [12]

Criticas

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

  1. Elegir burbujas de forma adecuada
  2. Particionar burbujas de una manera significativa y mutuamente acordada,
  3. Tamaño de la documentación necesario para comprender los flujos de datos,
  4. Los diagramas de flujo de datos son de naturaleza muy 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 asigna el concepto a los flujos de datos y las burbujas.
  7. Los diseñadores deben cambiar la organización de DFD a un formato implementable

Ver también

  • Partición de eventos
  • Programación basada en flujo
  • HIPO
  • Programación estructurada de Jackson
  • Herramienta de análisis estructurado Prosa
  • Metodología de sistemas blandos

Referencias

  1. ^ Tricia Gilbert (2006) Criterio de evaluación de FCS para la evaluación de tecnología. Archivado el 18 de septiembre de 2008 en la Wayback Machine.
  2. ^ Edward Yourdon (1986). Gestión de las técnicas estructuradas: estrategias para el desarrollo de software en la década de 1990 . Yourdon Press. p.35.
  3. ↑ a b FAA (2000). FAA Manual del sistema de seguridad, Apéndice D . 30 de diciembre de 2000.
  4. ↑ a b Dave Levitt (2000). "Introducción al Análisis y Diseño Estructurado". en faculty.inverhills.edu/dlevitt . Consultado el 21 de septiembre de 2008. Ya no está en línea en 2017.
  5. ↑ a b Stevens, Myers y Constantine, 1974 .
  6. ^ a b 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 la palabra de moda en la orientación a objetos Archivado el 20 de octubre de 2008 en Wayback Machine Essential Strategies, Inc.
  11. ^ a b c Grupo de trabajo del marco de arquitectura del DoD (2003). DoDAF 1.5 Volumen 2 , 15 de agosto de 2003.
  12. ^ a b c d e f g Alan Hecht y Andy Simmons (1986) Integración de análisis estructurado automatizado y diseño con entornos de soporte de programación Ada NASA 1986.
  13. ^ Tom DeMarco (1978). Análisis estructurado y especificación del sistema . Yourdon Press, Nueva York, 1978.
  14. ^ Gestión de proyectos de ECM Archivado el 7 de noviembre de 2008 en elsitio web de explotación de datos de Wayback Machine (NPOESS). 2008.
  15. ↑ a b Alexander Kossiakoff, William N. Sweet (2003). Ingeniería de sistemas: principios y prácticas p. 413.
  16. ^ a b c Glosario de integración de datos 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. ^ Resumen de práctica de AHIMA, Directrices para desarrollar un diccionario de datos , Revista de 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. ^ a b "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 del caso . Prentice Hall. p.56.
  23. ^ David Wolber " Diagramas de estructura archivados el 19 de febrero de 2009 en la Wayback Machine : Diagramas de estructura de notas suplementarias e implementación ascendente: versión de Java.
  24. ^ Page-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 págs. 549-661, mayo de 1986.

Otras lecturas

  • Stevens, WP ; Myers, GJ ; Constantine, LL (junio de 1974). "Diseño estructurado". Revista de sistemas de IBM . 13 (2): 115-139. doi : 10.1147 / sj.132.0115 .
  • Yourdon, Edward ; Constantine, Larry L. (1979) [1975]. Diseño estructurado: fundamentos de una disciplina de diseño de sistemas y programas informáticos . Yourdon Press. ISBN 0-13-854471-9.
  • Tom DeMarco (1978). Análisis estructurado y especificación del sistema . Yourdon. ISBN  0-91-707207-3
  • Page-Jones, M (1980), The Practical Guide to Structured Systems Design , Nueva York: Yourdon Press
  • Derek J. Hatley, Imtiaz A. Pirbhai (1988). Estrategias para la especificación del sistema en tiempo real . John Wiley and Sons Ltd. ISBN  0-932633-04-8
  • Stephen J. Mellor y Paul T. Ward (1986). Desarrollo Estructurado para Sistemas en Tiempo Real: Técnicas de Modelado de Implementación: 003 . Prentice Hall. ISBN  0-13-854803-X
  • Edward Yourdon (1989). Análisis estructurado moderno , Yourdon Press Computing Series, 1989, ISBN  0-13-598624-9
  • Keith Edwards (1993). Métodos estructurados en tiempo real, análisis de sistemas . Wiley. ISBN  0-471-93415-1

enlaces externos

  • Wiki de análisis estructurado
  • Tres visiones del análisis estructurado CRaG Systems, 2004.

This page is based on a Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.

  • Terms of Use
  • Privacy Policy