Diagramas de Estructura.

 Introducción.

Antes de pasar a introducirnos en los conceptos necesarios para la construcción de Diagramas de Estructura, necesitaremos aclarar lo siguiente:

 ¿En que parte del proyecto estamos?

A estas alturas estamos en la etapa del Diseño Estructurado; hasta aquí habíamos estado trabajando en el Análisis Estructurado, recordemos un poco:

 El Análisis Estructurado.

 Dirigido a la primer etapa del proceso de desarrollo.

 Se basa en construir un modelo de las prácticas administrativas que deben ser realizadas por el nuevo sistema (desde el punto de vista lógico).

 Es crítica en esta fase la determinación y la definición de requerimientos ya que el fracaso de las especificaciones rompen todo el esfuerzo de desarrollo.

 Se busca conocer y especificar lo que se quiere.

 Si no se sabe lo que se desea no se puede esperar éxito.

 Las salidas (output) del análisis estructurado son (especificaciones estructuradas):

Diagrama de Flujo de Datos Nivelado (DFD) o Modelo Lógico del Sistema. Permite identificar los mini sistemas y las interfaces entre ellos.

Diccionario de Datos correspondiente al DFD. Define la composición y organización de las interfaces.

Mini Especificaciones de los Procesos (Primitivas Funcionales) que aparecen en el DFD. Se realizan a través de ingles, castellano estructurado, arboles de decisión o tablas de decisión.

 El Diseño Estructurado.

 Una vez conocido ¿Que? (Análisis Estructurado), el Diseño Estructurado se encarga del ¿Cómo?. Vale decir, como implementar mejor el modelo en términos del costo total de por vida del sistema (Desarrollo y Mantención).

 El diseño estructurado busca establecer la organización interna del software, produciendo sistemas que sean fáciles de entender (y por ende de construir y mantener).

 Las salidas del análisis estructurado son entradas (input) para el diseño estructurado.

 Las salidas (output) del diseño estructurado son:

Diagrama Estructurado (estructura de software).

Especificación de Módulos.

Diccionario de Datos del Sistema.

 

 Construyendo el Modelo Físico (Software).

 En la representación gráfica vemos que está compuesto de:

 Identificar los límites hombre- máquina en el modelo lógico.

 Determinar "Frontera Hombre- Máquina".

  Evaluar los costos- beneficios de la solución. Es necesario identificar el alcance del esfuerzo de desarrollo en computadora.

  Seleccionar opción de entre las alternativas.

 En esta etapa considere las restricciones físicas generales:

  Requerimientos del medio ambiente (por ejemplo gobierno).

  Limitaciones tecnológicas (hardware, software, etc.).

  Recursos Humanos.

Elección de una implementación (o alternativa de Mecanización).

  Decisiones sobre implementación.

¿Qué será automatizado?.

¿Qué estará on- line?.

¿Qué será distribuido?.

¿Qué será implementado primero?.

 Restricciones Físicas.

¿Computadora?.

¿Cuánto dinero se puede gastar?.

¿Cuánto se puede esperar?.

¿Cuántos datos están involucrados?.

¿Cuan crítico es el tiempo de respuesta?.

 Nuevo Modelo Lógico.

 

  

  Como hacer la Parte Automatizada más Física.

 Dibuje el límite de automatización en el nuevo modelo lógico considerando las restricciones físicas.

 Adapte el modelo para mostrar explícitamente funciones divididas a lo largo del límite de automatización.

 Rediseñe los modelos (DFDs) para la nueva figura0 ubicando las funciones como lo requiere el límite de automatización.

 Agregue componentes para transportar datos a través del límite de automatización (agregue componentes transportistas).

 Fiscalice las mini- especificaciones.

 Fiscalice el diccionario.

 

 

 

 

 

 

 

 Diagrama de Estructura.

Estos diagramas muestran tanto jerarquía funcional como las interfaces de los datos entre los componentes.

Los principales componentes son:

 El rectángulo.

 Las flechas.

El rectángulo en un diagrama de estructura no representa una declaración sino que representa un módulo, por ejemplo un procedimiento de Pascal. Las flechas que conectan los módulos no representan declaraciones GOTO sino llamados de sub- rutinas; la notación implica que una sub- rutina terminará o regresará a donde se llamó cuando termine de realizar su función. Además, existen aquí dos tipos adicionales de flechas con un circulo en uno de sus extremos, que representan la transferencia de datos y la transferencia de información de control.

 

Los módulos dan una idea clara y sintética de la función que realiza. La lectura de los diagramas de estructura se realiza de izquierda a derecha y de arriba hacia abajo.

Dependiendo de la herramienta que estemos utilizando para el diseño, se nos permitirán utilizar una u otra simbología; aquí se presentan símbolos que podríamos llamarlos estándar de modelado que se agregan a los anteriores.

Cada Diagrama de Estructura , representa una burbuja del DFD. Por lo tanto es necesario que antes de pasar a confeccionar el diagrama tengamos en cuenta las siguientes consideraciones.

La confección del diagrama de estructura debe confeccionarse luego de haber realizado el modelamiento explicado en la parte introductoria de este capitulo, lo que implica revisión, análisis y confección de los diagramas ya terminados en la etapa de análisis.

Tenga en cuenta que la lógica de cada diseñador se expresa en la confección del diagrama de estructura, por lo tanto irán desde lo más secuenciales hasta los más estructurados; por lo tanto no puedo decir que hay normas estrictas que indican una única forma de realizarse lo importante es que lo mismos sean claros, consistentes y nos representen realmente las rutas que seguirá luego nuestro código del sistema mismo. De esta manera podrá ser entendido por nuestro cliente, aunque este no querrá verlo, pero si debe ser entendido por otro colega nuestro si fuera necesario; al igual que un plano puede ser comprendido por otro arquitecto, esa es la idea.

Seguidamente les presento dos ejemplos de diagrama de estructura, el primero representa la pantalla principal del sistema con su menú principal, el segundo es el diagrama de una opción de menú. Tengamos en cuenta que en el modela do cada opción de nuestro sistema es conocida como pagina.

Ejemplos de diagramas modelado de un Sistema: En el primer caso un diagrama principal refiriéndose a cada opción del sistema como pagina. En el segundo caso un diagrama principal refiriéndose a cada opción del sistema de manera mas especifica. El tercer diagrama especifica una opción completa del sistema.