Articulo de referencia

Técnica de análisis y diseño estructurado

Elemento base del SADT. La técnica de análisis y diseño estructurado ( SADT , por sus siglas en inglés) es una metodología de ingeniería de sistemas e ingeniería de software par...

Elemento base del SADT.

La técnica de análisis y diseño estructurado ( SADT , por sus siglas en inglés) es una metodología de ingeniería de sistemas e ingeniería de software para describir sistemas como una jerarquía de funciones. SADT es un lenguaje de modelado de análisis estructurado , que utiliza dos tipos de diagramas: modelos de actividad y modelos de datos . Fue desarrollado a fines de la década de 1960 por Douglas T. Ross , y se formalizó y publicó como IDEF0 en 1981.

Descripción general

La técnica de análisis y diseño estructurado (SADT) es una notación diagramática diseñada específicamente para ayudar a las personas a describir y comprender sistemas . [1] Ofrece bloques de construcción para representar entidades y actividades, y una variedad de flechas para relacionar cuadros. Estos cuadros y flechas tienen una semántica informal asociada . [2] SADT se puede utilizar como una herramienta de análisis funcional de un proceso dado, utilizando niveles sucesivos de detalles. El método SADT no solo permite definir las necesidades de los usuarios para los desarrollos de TI, que se utilizan a menudo en los sistemas de información industriales, sino también explicar y presentar los procesos y procedimientos de fabricación de una actividad. [3]

Historia

La SADT fue desarrollada y probada en campo durante el período de 1969 a 1973 por Douglas T. Ross y SofTech, Inc. [1] [4] La metodología se utilizó en el proyecto de la Herramienta de Programación Automática (APT) del MIT. Recibió un uso extensivo a partir de 1973 por parte del programa de Fabricación Asistida por Computadora Integrada de la Fuerza Aérea de los EE. UU.

Según Levitt (2000) SADT 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 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. Como una forma de ayudar a administrar software grande y complejo. [5]

El SADT formaba parte de una serie de métodos estructurados similares que habían surgido desde la década de 1960, como:

En 1981 se publicó el formalismo IDEF0 , basado en SADT. [6]

Temas de SADT

Estructura de descomposición de arriba hacia abajo.
Un ejemplo de SADT.

Enfoque de arriba hacia abajo

La técnica de análisis y diseño estructurado utiliza una descomposición con un enfoque descendente . Esta descomposición se lleva a cabo únicamente en el dominio físico desde un punto de vista de diseño axiomático. [7]

Diagramas

El SADT utiliza dos tipos de diagramas: modelos de actividad y modelos de datos . Para construir estos diagramas se utilizan flechas. La representación del SADT es la siguiente:

  • Un cuadro principal donde se especifica el nombre del proceso o la acción
  • En el lado izquierdo de este cuadro, flechas entrantes: entradas de la acción.
  • En la parte superior, las flechas entrantes: datos necesarios para la acción.
  • En la parte inferior del cuadro, flechas entrantes: medios utilizados para la acción.
  • En el lado derecho del cuadro, flechas salientes: resultados de la acción.

La semántica de las flechas para actividades: [2]

  • Las entradas ingresan desde la izquierda y representan datos o consumibles que necesita la actividad.
  • Las salidas salen hacia la derecha y representan datos o productos que son producidos por la actividad.
  • Los controles ingresan desde arriba y representan comandos o condiciones que influyen en la ejecución de una actividad pero no se consumen.
  • Los mecanismos identifican los medios, componentes o herramientas utilizados para realizar la actividad. Representan la asignación de actividades.

La semántica de las flechas para los datos: [2]

  • Las entradas son actividades que producen los datos.
  • Las salidas consumen los datos.
  • Los controles influyen en el estado interno de los datos.

Roles

Según Mylopoulos (2004) en el proceso de desarrollo de software se pueden o deben distinguir múltiples roles: [2]

  • Autor o desarrollador de los modelos SADT
  • Comentaristas, que reseñan el trabajo del autor.
  • Lectores o usuarios de los modelos SADT
  • Expertos, que pueden asesorar a los autores
  • Comité técnico o revisores de los modelos SADT en detalle
  • Bibliotecario del proyecto, que gestiona la documentación del proyecto.
  • Gerente de proyecto, quien gobierna el análisis y diseño del sistema.
  • Monitor o analista jefe para ayudar a los desarrolladores y usuarios de SADT
  • Instructor para capacitar a desarrolladores y usuarios de SADT

Uso

SADT se utiliza como notación diagramática en el diseño conceptual de ingeniería de software e ingeniería de sistemas para esbozar aplicaciones, [2] para un análisis estructurado más detallado, para la definición de requisitos, [8] y el diseño estructurado.

Véase también

Referencias

  1. ^ ab D. Marca, C. McGowan, Análisis estructurado y técnica de diseño, McGraw-Hill, 1987, ISBN  0-07-040235-3
  2. ^ abcde John Mylopoulos (2004). Modelado conceptual III. Técnica de análisis y diseño estructurado (SADT). Consultado el 21 de septiembre de 2008.
  3. ^ SADT en Free-logistics.com. Consultado el 21 de septiembre de 2008.
  4. ^ DT Ross: Análisis estructurado (SA): un lenguaje para comunicar ideas. IEEE Transactions on Software Engineering, SE-3(1), pp. 16-34. Resumen
  5. ^ Dave Levitt (2000): Introducción al análisis y diseño estructurado Archivado el 7 de septiembre de 2006 en Wayback Machine . Consultado el 21 de septiembre de 2008.
  6. ^ Gavriel Salvendy (2001). Manual de ingeniería industrial: tecnología y gestión de operaciones. . p.508.
  7. ^ Nam Pyo Suh (2007). Diseño axiomático: avances y aplicaciones. Nueva York: Oxford University Press, capítulo 5, págs. 239-298.
  8. ^ Ross, Douglas T. y Kenneth E. Schoman Jr. "Análisis estructurado para la definición de requisitos". Ingeniería de software, IEEE Transactions on 1 (1977): 6-15.

Lectura adicional

  • William S. Davis (1992). Herramientas y técnicas para el análisis y diseño de sistemas estructurados . Addison-Wesley. ISBN 0-201-10274-9 
  • Marca, DA y CL McGowan. (1988). SADT: análisis estructurado y técnica de diseño . McGraw-Hill Book Co., Inc.: Nueva York, NY.
  • Jerry FitzGerald y Ardra F. FitzGerald (1987). Fundamentos del análisis de sistemas: uso de técnicas de análisis y diseño estructurado . Wiley. ISBN 0-471-88597-5 
  • David A. Marca y Clement L. McGowan (1988). SADT: Análisis estructurado y técnica de diseño . McGraw-Hill. ISBN 0-07-040235-3 
  • D. Millington (1981). Análisis y diseño de sistemas para aplicaciones informáticas . E. Horwood. ISBN 0-85312-249-0 
  • Robertson y Robertson (1999). Dominar el proceso de requisitos . Addison Wesley.
  • James C. Wetherbe (1984). Análisis y diseño de sistemas: conceptos y técnicas tradicionales, estructurados y avanzados . West Pub. Co. ISBN 0-314-77858-6 
  • El método IDEF0
  • Un curso sobre diagramas SADT
Obtenido de "https://es.wikipedia.org/w/index.php?title=Técnica_de_análisis_y_diseño_estructurado&oldid=1196729551"