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]
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.
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).
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]
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 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]
.svg/1280px-NDE_Context_Diagram_(vector).svg.png)
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 .
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 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 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]
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.
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]
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]
Los problemas con los diagramas de flujo de datos incluyen los siguientes: [3]
