Análisis estructurado

El análisis estructurado generalmente crea una jerarquía empleando un único mecanismo de abstracción. El método de análisis estructurado puede utilizar IDEF (véase la figura), se basa en procesos y parte de un propósito y un punto de vista. Este método identifica la función general y la divide iterativamente en funciones más pequeñas, conservando 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 ellas, lo que da lugar a datos estructurados. ^{[ 11 ]}

La descomposición funcional del método estructurado describe el proceso sin delimitar 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 de la popularidad del análisis estructurado es su capacidad intuitiva para comunicar procesos y conceptos de alto nivel, ya sea a nivel de sistema individual o empresarial. Aún no está claro cómo los objetos podrían soportar funciones para el desarrollo orientado a objetos comercialmente predominante . A diferencia de IDEF, UML se basa en interfaces 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 dichos flujos. El análisis estructurado aprovecha la ocultación de información mediante el análisis de descomposición sucesiva (o descendente). Esto permite centrar la atención en los detalles pertinentes y evita la confusión derivada de la observación de detalles irrelevantes. A medida que aumenta el nivel de detalle, se reduce la cantidad de información. El resultado del análisis estructurado es un conjunto de diagramas gráficos, descripciones de procesos y definiciones de datos relacionados. Estos describen las transformaciones necesarias y los datos requeridos para cumplir con los requisitos funcionales del sistema . ^{[ 12 ]}

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

• Diagrama de contexto
• Diagrama de flujo de datos
• Especificaciones del proceso
• Diccionario de datos

Los diagramas de flujo de datos (DFD) son grafos dirigidos. Los arcos representan los datos y los nodos (círculos o burbujas) representan los procesos que transforman los datos. Un proceso puede descomponerse aún más en un DFD más detallado que muestra los subprocesos y los flujos de datos dentro del mismo. Los subprocesos, a su vez, pueden descomponerse aún más con otro conjunto de DFD hasta que sus funciones se comprendan fácilmente. Las primitivas funcionales son procesos que no necesitan descomponerse más. Las primitivas 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 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 se particionan de forma jerárquica. Se pueden referenciar en otras entradas del diccionario de datos y en diagramas de flujo de datos. ^{[ 12 ]}

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

Este tipo de diagrama, según Kossiakoff (2003), generalmente "representa el sistema en el centro, sin detalles de su estructura interna, rodeado por todos sus sistemas interactivos, entorno y actividades. El objetivo de un diagrama de contexto del sistema es centrar la atención en los factores y eventos externos que deben considerarse al desarrollar un conjunto completo de requisitos y restricciones del sistema". ^{[ 15 ]} Los diagramas de contexto del sistema están relacionados con los diagramas de flujo de datos y muestran las interacciones entre un sistema y otros actores con los que el sistema está diseñado para interactuar. 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 .

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 gestió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 de contabilidad para su gestión. Sin embargo, sin un diccionario de datos, un sistema de gestió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 cataloga la organización, el contenido y las convenciones de una o más bases de datos. ^{[ 17 ]} Este documento suele incluir 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 existe un estándar universal en cuanto al nivel de detalle de dicho documento, pero se trata principalmente de una síntesis de metadatos sobre la estructura de la base de datos , no de 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 una documentación de 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 ]}

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 computación de "grafo de flujo de datos" de Martin y Estrin. ^{[ 20 ]}

Es 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 partes más pequeñas y para resaltar el flujo de datos entre ellas. Este diagrama de flujo de datos a nivel de contexto se desglosa posteriormente para mostrar con mayor detalle el 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 del proyecto y los usuarios finales deben ser informados y consultados durante todas las etapas de la evolución del 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 elaborar y comparar con los del nuevo sistema para establecer comparaciones y así implementar un sistema más eficiente. Los diagramas de flujo de datos permiten al usuario final comprender cómo los datos que ingresa afectan la estructura del sistema, desde el pedido hasta el envío y la reprocesamiento. El desarrollo de cualquier sistema se puede determinar mediante un diagrama de flujo de datos.

Un diagrama de estructura (SC) es un diagrama que muestra la descomposición 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 recuadro que contiene el nombre del módulo. 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 arquitectura, de un programa informático . Como herramienta de diseño, ayudan al programador a dividir y conquistar un problema de software complejo, es decir, a descomponer recursivamente un problema en partes lo suficientemente pequeñas como para ser comprendidas por el cerebro humano. Este proceso se denomina diseño descendente o descomposición funcional . Los programadores utilizan un diagrama de estructura para construir un programa de forma similar a como un arquitecto utiliza un plano para construir una casa. En la etapa de diseño, el diagrama se dibuja y se utiliza como medio de comunicación entre el cliente y los distintos diseñadores de software. Durante la construcción del programa (implementación), el diagrama se denomina continuamente plan maestro. ^{[ 23 ]}

El diseño estructurado (DE) 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 e interfaces de módulos óptimas, dos principios son cruciales:

• Cohesión que se refiere a "la agrupación de procesos funcionalmente relacionados en un módulo particular", ^{[ 12 ]} y
• El acoplamiento se refiere al "flujo de información o parámetros que se transmiten entre módulos. Un 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 finales de la década de 1960, luego refinado y publicado con colaboradores en la década de 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 objetos principales  :

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

El diagrama de estructura tiene como objetivo mostrar la jerarquía de módulos o la relación de secuencia de llamadas entre ellos. Existe una especificación para cada módulo que se muestra en el diagrama de estructura. Las especificaciones de los módulos pueden estar compuestas de pseudocódigo o un lenguaje de diseño de programas. El diccionario de datos es similar al del análisis estructurado. En esta etapa del ciclo de vida del desarrollo de software , después de haber 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 ] .}