Diseño Estructurado

    Hasta ahora las técnicas estaban orientadas a estudiar QUE debe hacer nuestro sistema, ahora vamos a empezar a estudiar (por supuesto tomando como base el análisis realizado hasta ahora) COMO debe hacer nuestro sistema, lo que hemos deducido mediante el análisis con el apoyo de las técnicas vistas
hasta ahora. Debemos obtener como resultado un DISEÑO que no sólo "funcione", sino que también sea fácil de mantener, reutilizar y probar.
    La técnica concreta es el DIAGRAMA de ESTRUCTURA de CUADROS (DEC), mediante el cual vamos a representar la estructura modular del sistema y los detalles del proceso. Dicha estructura modular será en árbol y debe cumplir:
  Organización jerárquica de módulos.
  Módulos pequeños y manejables.
  Los Módulos deben ser como "cajas negras", ante determinadas entradas deben responder con determinadas salidas.
  Aislamiento de funciones, discernir entre los detalles (susceptibles de cambio) y la filosofía del sistema (más perenne).

DEFINICIÓN DE DISEÑO
 
    Según la Asociación Española de Calidad, el diseño del software se define:
 
 "Es el proceso de definición de la arquitectura software: componentes, módulos, interfaces, procedimientos de prueba y datos de un sistema que se crean para satisfacer unos requisitos especificados". 
 
Así pues atendiendo al nivel de detalle, podemos considerar dos partes:
  DISEÑO DE ARQUITECTURA
       Proceso de definición de la colección de componentes del sistema y sus interfaces.
  DISEÑO DETALLADO
       Proceso de descripción más detallado de la lógica del proceso y de las estructuras de datos.

DISEÑO DE PROCESOS

Una vez finalizado el análisis, veamos lo que hemos obtenido:
  Las entradas que suministran al sistema las entidades externas.
  Las salidas aportadas por el sistema a dichas entidades externas.
  Las funciones descompuestas que se han de realizar por ese sistema.
  El esquema lógico de datos del sistema.

    Toda esta información la hemos obtenido mediante las técnicas vistas hasta ahora, recordemos, mediante el DFD (Diagrama de Flujo de Datos) obtuvimos procesos y flujos de datos; mediante el DED (Diagrama de Estructura de Datos) obtuvimos entidades y atributos. Con todo esto vamos a:

  Determinar que módulos implantarán los procesos obtenidos en la fase de análisis.
  Organizar la estructura de los módulos y las conexiones entre ellos.
  Describir el pseudocódigo para cada módulo.

  Para ello utilizaremos la técnica de Diagrama de Estructura de Cuadros, propuesto por Constantine.

DIAGRAMA DE ESTRUCTURA DE CUADROS
  Veamos con que elementos contamos para desarrollar esta técnica:
   MÓDULOS: Representa un programa, subprograma o rutina, admite parámetros de llamada y puede retornar valores. Representado por:

                                         
  CONEXIÓN ENTRE MÓDULOS: Se representa mediante una línea.
                                         
  COMUNICACIÓN ENTRE MÓDULOS:
  Flags de Control, para comunicar control del sistema, errores de proceso, se representa por: 

                                                 

  Datos, información compartida por los módulos, se representa por:

                                     


Ahora vamos a ver como se conectan estos módulos para estructurar el modo de ejecución de los procesos:
  SECUENCIA: Cuando un módulo llama a varios y sólo una vez.

 
 
    El módulo A llama al B, después llama al C y por último al D. Hasta que no termina el módulo llamado no se realiza la llamada al siguiente. La secuencia de ejecución es de izquierda a derecha y de arriba abajo.

  ITERACIÓN: Si además de llamar a varios módulos, cada uno de estos módulos se ejecuta varias veces, se representa :

 
     Los procesos B, C y D se realizan los tres en esa secuencia n veces.

  DECISIÓN: Cuando existe una selección del camino que debe seguir, el módulo superior decide  que módulo llamará. Se representa por:

 

 El módulo A  decide si llama al módulo B, o al C y después llama al módulo D. 

  MODULO PREDEFINIDO: Es un módulo que está disponible en la librería del sistema o en la propia aplicación.
                                             
  ALMACÉN DE DATOS: Es la representación física de dónde van a estar los datos en la realidad.
                                             
  DISPOSITIVO FÍSICO: Es cualquier dispositivo por el cual se puede recibir o enviar información que necesite el sistema.

                                             


ESTRATEGIAS DE DISEÑO
 
    Ya sabemos como podemos representar la estructura modular del sistema, veamos como realizar esta representación utilizando como punto de partida los gráficos obtenidos mediante las técnicas de la fase de análisis. Esto significa que debemos hacer una especie de traducción entre el DFD y el DED
al DEC. El paso de los DFD a los Diagramas de Estructura puede hacerse siguiendo las siguientes estrategias:

ANÁLISIS DE TRANSFORMACIÓN: A partir de un DFD con características de transformación (Flujo de Entrada, Centro de la transformación, Flujo de Salida).

ANÁLISIS DE TRANSACCIÓN: Cuando en un DFD un dato determina la elección de uno o más flujos de información.

    Veamos detalladamente cada una de estas estrategias, debemos de tener en cuenta que se trata de estrategias y no de algoritmos, por lo tanto los resultados pueden no ser perfectos en una primera aproximación.

ANÁLISIS DE TRANSFORMACIÓN

Se deben realizar los siguientes pasos:

Aislar el centro de transformación, es la parte del DFD que contiene las funciones esenciales del Sistema y es independiente de las características particulares de la Entrada/Salida. Los límites de flujo de llegada y salida están abiertos a interpretación.

Realizar el primer nivel de factorización, la estructura del programa debe representar una distribución descendente del control características particulares de la Entrada/Salida. Aparecerán tres módulos subordinados al módulo de control:

  Módulo controlador del proceso de la información de llegada.
  Módulo controlador del centro de transformación.
  Módulo controlador del proceso de la información de salida.

Elaborar el segundo nivel de factorización. Se realiza mediante la conversión de las transformaciones de cada proceso de un DFD en los módulos correspondientes del diagrama de estructura. Se comienza en el centro de transformación y se va hacia afuera a lo largo de los caminos de llegada y salida.

Refinar la estructura del sistema utilizando medidas y heurísticas de diseño.

ANÁLISIS DE TRANSACCIÓN

    El análisis de transacción se aplica cuando un DFD toma una forma en la que un dato determina la elección de uno o más flujos de información. Los pasos a seguir son:

Identificar el centro de transacción. Será el origen de una serie de caminos que fluyen radialmente. Cada camino, tanto de llegada como los de acción, debe evaluarse en función de sus características individuales.

Transformar el DFD en la estructura adecuada al proceso de transacciones. El flujo de transacciones se convierte en una estructura de programa formada por una bifurcación de entrada y una de salida.

Factorizar la estructura de cada camino de acción. La estructura de la bifurcación de entrada se desarrolla de la misma forma que el análisis de transformación. Cada camino del flujo de acción se convierte en una estructura que se corresponde con las características específicas del flujo (Transfor., Transacción). Cada camino de acción estudiado usa los pasos de diseño vistos anteriormente.

Refinar la estructura del sistema utilizando medidas y heurísticas de diseño.
 

EVALUACIÓN DEL DISEÑO

    Para estimar si el diseño de nuestro sistema es todo lo correcto que se precisa para su funcionamiento, vamos a utilizar dos unidades complementarias de medida:

  ACOPLAMIENTO, es el grado de interdependencia entre los módulos, depende del número de parámetros que se intercambian para su comunicación.

  COHESIÓN, es el grado en el que los componentes se un módulo son necesarios y suficientes para realizar una sóla función bien definida.

ACOPLAMIENTO

  En módulos con acoplamiento alto se debe considerar un módulo cuando se modifica el otro. El objetivo es conseguir un diseño con bajo acoplamiento. Nos interesa que la interdependencia entre módulos sea lo más baja posible, para conseguir que los problemas de cualquier módulo afecten lo menos posible al resto del sistema, esto redunda en un mejor funcionamiento del sistema, más fácil mantenimiento y reutilización.

  Los principales factores que afectan al acoplamiento son:
 
  --> Conexión de información entre módulos.

  --> Información que pasa de un módulo a otro.

  --> Entrada y salida al módulo.

  --> Complejidad de la información que se transmite.
 
Existen varios niveles de acoplamiento, de mejor a peor:

Acoplamiento Normal:

  De Datos, entre el módulo que llama y el llamado, ha de establecerse
         al menos una comunicación básica.

  Por estampado, si se pasan datos entre módulos con estructura de
         registro, no es deseable si del registro, el módulo que recibe el
         registro sólo necesita parte de los datos.

  De control, cuando los datos de comunicación son flags de control,
         supone una ruptura en el principio de caja negra, ya que el módulo
         inferior tiene detalles de funcionamiento del superior, esto es malo
         si se cambia el módulo inferior.

  Acoplamiento Común, cuando más de dos módulos hacen referencia a un área  común de datos. Puede dar problemas si los módulos acceden sin demasiado control a ese área común.

  Acoplamiento de contenido, cuando un módulo cualquiera, accede a parte del código de otro rompiendo la jerarquía.
 

COHESIÓN

    Es la medida de la fuerza o relación funcional de los elementos de un módulo, entendiendo por elementos a la sentencia o grupo de sentencias que lo componen, a las definiciones de datos o llamadas a otros módulos. Un módulo coherente sólo debe hacer (idealmente) una cosa. El objetivo es conseguir una alta cohesión, donde cada instrucción es necesaria para llevar a cabo una sola tarea.

  Los distintos niveles de cohesión son de mejor a peor:
  ---> FUNCIONAL, un módulo con cohesión funcional contiene elementos que contribuyen a la realización de una, y sólo una, tarea funcional.
  ---> SECUENCIAL, Un módulo realiza varias tareas en secuencia, de modo que las entradas de cada tarea son las salidas de la anterior.
  ---> COMUNICACIONAL, Un módulo realiza actividades paralelas usando los mismos datos de entrada y salida.
  ---> PROCEDURAL, igual que la secuencial, pero con paso de controles.
  ---> TEMPORAL, las actividades que realiza tienen un matiz temporal.
  ---> LÓGICA, el módulo tiene algo así como partes dentro de sí mismo.
  ---> COINCIDENTAL, el módulo que llama tiene conocimiento de la estructura interna del módulo al que llama.

  Esta evaluación del diseño nos permite efectuar cambios importantes en el diseño si descubrimos errores de cierta importancia. Es el momento de realizar un ajuste fino en el diseño.
 

HEURÍSTICAS DEL DISEÑO

  Son recomendaciones para mejorar la estructura del diseño y mejorar la modularidad.
  Consideramos las siguientes características:
  Tamaño del módulo, entre 10 y 100 sentencias.
  Ámbito de control, el ámbito de control de un módulo es todos los módulos que hay por debajo de él.
  Ámbito de efecto, cualquier módulo afectado por una decisión, debe ser subordinado del módulo que toma la decisión.

CORRECCIÓN DEL DISEÑO

  Reglas de oro para realizar un buen diseño:
  No utilizar variables globales.
  Evitar pasar parámetros, a menos que sea necesario.
  Reducir el número de parámetros que intercambian al máximo.
  NO agrupar las líneas de código aleatoriamente, sino que las agrupamos por funciones.
  Un módulo de un nivel inferior no debe llamar a otro de nivel superior de la misma rama del diagrama, puede dar lugar a bucles sin salida.

DEFINICIÓN DE PROGRAMAS

     Por último deben agruparse todos los módulos que se han definido en programas. Hay dos filosofías diferentes:

  Construir un programa por cada módulo.
  Agrupar los módulos en un programa, asociando cada uno de ellos a un párrafo.
 


UTILIZACIÓN DE LA TÉCNICA EN LA METODOLOGÍA MÉTRICA V.2

FASE 2:     Diseño de Sistemas
  DTS 1:     Diseñar la Arquitectura física del sistema
                     1.1  Diseño de la estructura modular del sistema
                     1.2  Descripción de interfaces entre módulos del
                            sistema         
                            1.3  Descripción deinterfaces con otros sistemas
                     1.5  Definición de componentes del sistema

FASE 3:     Construcción del sistema
  DCS 2.1:  Generación del código de los componentes del sistema

 

                                    Volver a la página principal