Unidad 1: Introducción al Diseño Estructurado

Definición: "Diseño es el proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, proceso, o sistema, con los suficientes detalles como para permitir su realización física" (E.S.Taylor, An Interim Report on Engineering Design, Massachusetts Institute of Technology, 1959)

El objetivo del diseñador es producir un modelo de una entidad que se construirá más adelante. El proceso por el cual se desarrolla el modelo combina: la intuición y los criterios en base a la experiencia de construir entidades similares, un conjunto de principios y/o heurísticas que guían la forma en la que se desarrolla el modelo, un conjunto de criterios que permiten discernir sobre calidad y un proceso de iteración que conduce finalmente a una representación del diseño final.

1.1 Qué es diseño estructurado?

Definición: "Diseño estructurado es el proceso de decidir que componentes, y la interconexión entre los mismos, para solucionar un problema bien especificado".

El diseño es una actividad que comienza cuando el analista de sistemas ha producido un conjunto de requerimientos funcionales lógicos para un sistema, y finaliza cuando el diseñador ha especificado los componentes del sistema y las relaciones entre los mismos.

Frecuentemente analista y diseñador son la misma persona, sin embargo es necesario que se realice un cambio de enfoque mental al pasar de una etapa a la otra. Al abordar la etapa de diseño, la persona debe quitarse el sombrero de analista y colocarse el sombrero de diseñador.

 Una vez que se han establecido los requisitos del software (en el análisis), el diseño del software es la primera de tres actividades técnicas: diseño, codificación, y prueba. Cada actividad transforma la información de forma que finalmente se obtiene un software para computadora válido.

En la figura se muestra el flujo de información durante la fase de desarrollo. Los requisitos del sistema, establecidos mediante los modelos de información, funcional y de comportamiento, alimentan el proceso del diseño. Mediante alguna metodología (en nuestro caso, estructurada basada en el flujo de información) se realiza el diseño estructural, procedimental, y de datos.

 El diseño de datos transforma el modelo del campo de información, creado durante el análisis, en las estructuras de datos que se van a requerir para implementar el software.

 El diseño estructural define las relaciones entre los principales elementos estructurales del programa. El objetivo principal del diseño estructural es desarrollar una estructura de programa modular y representar las relaciones de control entre los módulos.

 El diseño procedimental transforma los elementos estructurales en una descripción procedimental del software. El diseño procedimental se realiza después de que se ha establecido la estructura del programa y de los datos. Define los algoritmos de procesamiento necesarios.

Concluido el diseño se genera el código fuente y para integrar y validar el software, se llevan a cabo pruebas de testeo.

 

Las fases del diseño, codificación y prueba absorben el 75% o más del coste de la ingeniería del software (excluyendo el mantenimiento). Es aquí donde se toman decisiones que afectarán finalmente al éxito de la implementación del programa y, con igual importancia, a la facilidad de mantenimiento que tendrá el software. Estas decisiones se llevan a cabo durante el diseño del software, haciendo que sea un paso fundamental de la fase de desarrollo.

La importancia del diseño del software se puede sentar con una única palabra: calidad. El diseño es el proceso en el que se asienta la calidad del desarrollo del software. El diseño produce las representaciones del software de las que puede evaluarse su calidad.

El diseño sirve como base para todas las posteriores etapas del desarrollo y de la fase de mantenimiento. Sin diseño nos arriesgamos a construir un sistema inestable, un sistema que falle cuando se realicen pequeños cambios, un sistema que pueda se difícil de probar, un sistema cuya calidad no pueda ser evaluada hasta más adelante en el proceso de ingeniería de software, cuando quede poco tiempo y se haya gastado ya mucho dinero.

1.2 Objetivos Del Diseño Estructurado

"El diseño estructurado, tiende a transformar el desarrollo de software de una práctica artesanal a una disciplina de ingeniería".  

Eficiencia
Mantenibilidad
Modificabilidad
Flexibilidad
Generalidad
Utilidad

"Diseño" significa planear la forma y método de una solución. Es el proceso que determina las características principales del sistema final, establece los límites en performance y calidad que la mejor implementación puede alcanzar, y puede determinar a que costos se alcanzará.

El diseño se caracteriza usualmente por un gran número de decisiones técnicas individuales. En orden de transformar el desarrollo de software en una disciplina de ingeniería, se debe sistematizar tales decisiones, hacerlas más explícitas y técnicas, y menos implícitas y artesanales.

Un ingeniero no busca simplemente una solución, busca la mejor solución, dentro de las limitaciones reconocidas, y realizando compromisos requeridos en el trabajo del mundo real.

En orden de convertir el diseño de sistemas de computadoras en una disciplina de ingeniería, previo a todo, debemos definir objetivos técnicos claros para los programas de computadora como "sistemas". Es esencial además comprender las restricciones primarias que condicionan las soluciones posibles.

Para realizar decisiones concisas y deliberadas, debemos identificar los puntos de decisión .

Finalmente necesitamos una metodología que nos asista en la toma de decisiones.

Dadas estas cosas: objetivos, restricciones, decisiones reconocidas, y una metodología efectiva, podemos obtener soluciones de ingeniería, y no artesanales.

 

Diseño estructurado y calidad del software

Un concepto importate a clarificar es el de calidad. Desafortunadamente, muchos diseñadores se conforman con un sistema que "funcione" sin reparar en un buen sistema.

Una corriente de pensamiento estima que un programa es bueno si sus algoritmos son astutos y no obvios a otro programador; esto refleja la "inteligencia" del programador.

Otra escuela de pensamiento asocia calidad con incremento de la velocidad de ejecución y disminución de los requerimientos de memoria central. Estos son aspectos de un concepto más amplio: eficiencia. En general, se busca diseños que hagan un uso inteligente de los recursos. Estos recursos no incluyen solamente procesador y memoria, también incluyen almacenamiento secundario, tiempo de periféricos de entrada salida, tiempo de líneas de teleproceso, tiempo de personal, y más.

Otra medida de calidad es la confiabilidad. Es importante notar que si bien la confiabilidad del software puede ser vista como un problema de depuración de errores en los programas, es también un problema de diseño. La confiabilidad se expresa en como MTBF (mean time between fairules: tiempo medio entre fallas).

Un concepto muy relacionado a la confiabilidad y de suma importancia es el de mantenibilidad. Podemos definir la mantenibilidad como:

Mantenibilidad del sistema = ____MTBF___
MTBF + MTTR

donde:

MTBF: tiempo medio entre fallas (mean time between fairules)

MTTR: tiempo medio de reparación (mean time to repair)

Diremos que un sistema es mantenible si permite la detección, análisis, rediseño, y corrección de errores fácilmente.

En tanto la mantenibilidad afecta la viabilidad del sistema en un entorno relativamente constante, la modificabilidad influye en los costos de mantener un sistema viable en condiciones de cambio de requerimientos. La modificabilidad es la posibilidad de realizar modificaciones y extensiones a partes del sistema, o agregar nuevas partes con facilidad (no corrección de errores).

En estudios realizados se determinó que las organizaciones abocadas al procesamiento de datos invierten aproximadamente un 50% del presupuesto en mantenimiento de los sistemas, involucrando esto corrección de errores y modificaciones, razón por la cual la mantenibilidad y la modificabilidad son dos objetivos primarios en el diseño de software.

 

La flexibilidad representa la facilidad de que el mismo sistema pueda realizar variaciones sobre una misma temática, sin necesidad de modificaciones.

La generalidad expresa el alcance sobre un determinado tema.

Flexibilidad y generalidad son dos objetivos importantes en el diseño de sistemas del tipo de propósitos generales.

La utilidad o facilidad de uso es un factor importante que influye en el éxito del sistema y sus aceptación por parte del usuario. Un sistema bien diseñado pero con interfaces muy "duras" tiende a ser resistido por los usuario.

 

Finalmente diremos que eficiencia, mantenibilidad, modificabilidad, flexibilidad, generalidad, y utilidad, son componentes de la calidad objetiva de un sistema.

En términos simples también diremos que nuestro objetivo primario es obtener sistemas de costo mínimo. Es decir, es nuestro interés obtener sistemas económicos para desarrollar, operar, mantener y modificar.

1.3 Restricciones, compromisos, y decisiones del Diseño

Podemos ver los objetivos técnicos del diseño como constituyendo una "función objetivo" de un problema de optimización, la cual se desea maximizar, sujeta a ciertas restricciones.

Como regla, las restricciones sobre un proceso de diseño de un sistema, caen en dos categorías: restricciones de desarrollo y restricciones operacionales.

Las restricciones de desarrollo son limitaciones al consumo de recursos durante el período de desarrollo, y pueden ser expresadas en términos generales o descomponerla en su partes como ser tiempo de máquina y horas-hombre. Dentro de las restricciones de desarrollo, entran también las restricciones de planificación. Estas se refieren a metas y plazos a ser cumplidos ("el módulo X debe terminarse para Febrero").

Las restricciones operacionales pueden ser expresadas en términos técnicos, como ser máximo tamaño de memoria disponible, máximo tiempo de respuesta aceptable, etc.

El carácter de muchas decisiones de diseño no fija límites rígidos, si no un intervalo de tolerancia, dentro del cual el diseñador puede moverse a costa de variaciones en otros aspectos del sistema. Por ejemplo se puede priorizar eficiencia, en detrimento de facilidad de mantenimiento, o velocidad de ejecución contra tamaño de memoria utilizada.

La esencia del diseño en el mundo real y las decisiones inherentes al mismo es obtener una solución de compromiso.

El diseño total es el resultado acumulativo de un gran número de decisiones técnicas incrementales.

1.4 Principios utilizados por el diseño estructurado

1.4.1 Abstracción

La noción psicológica de abstracción permite concentrarse en un problema al mismo nivel de generalización, independientemente de los detalles irrelevantes de bajo nivel. El uso de la abstracción también permite trabajar con conceptos y términos que son familiares al entorno del problema, sin tener que transformarlos a una estructura no familiar.

Cada paso de un proceso de ingeniería de software es un refinamiento del nivel de abstracción de la solución de software.

Conforme nos movemos por diferentes niveles de abstracción, trabajamos para crear abstracciones de datos y de procedimientos. Una abstracción procedural es una determinada secuencia de instrucciones que tienen una función limitada y específica.

Una abstracción de datos es una determinada colección de datos que describen un objeto.

La abstracción, para mi, es cercana a palabras como "teórico", "esotérico", "académico", e "impráctico". Pero en un sentido en particular, significa la separación de los aspectos más importantes de un determinado problema, del detalle. Este es el único camino que tengo para abordar con mi mente finita cualquier tema complejo.

Alan Cameron Wills - (Object Expert Jan/Feb 1996)

 

1.4.2 Refinamiento sucesivo

El refinamiento sucesivo es una primera estrategia de diseño descendente propuesta por Niklaus Wirth. La arquitectura de un programa se desarrolla en niveles sucesivos de refinamiento de los detalles procedimentales. Se desarrolla una jerarquía descomponiendo una declaración macroscópica de una función de una forma sucesiva, hasta que se llega a las sentencias del lenguaje de programación.

 

1.4.3 Modularidad

La arquitectura implica modularidad, el software se divide en componentes con nombres y ubicaciones determinados, que se denominan módulos, y que se integran para satisfacer los requisitos del problema.

 

1.4.4 Arquitectura del software

La arquitectura del software se refiere a dos características importantes del software de computadoras:

  1. la estructura jerárquica de los componentes procedimentales (módulos)
  2. la estructura de datos

 

1.4.5 Jerarquía de control

La jerarquía de control, también denominada estructura de programa, representa la organización (frecuentemente jerárquica) de los componentes del programa (módulos) e implica una jerarquía de control. No representa aspectos procedimentales del software, tales como secuencias de procesos, o la repetición de operaciones.

 

1.4.6 Estructura de datos

La estructura de datos es una representación de la relación lógica existente entre los elementos individuales de datos. Debido a que la estructura de la información afectará invariablemente al diseño procedimental final, la estructura de datos es tan importante como la estructura del programa en la representación de la arquitectura del software.

 

1.4.7 Procedimientos del software

La estructura del programa define la jerarquía de control, independientemente de las decisiones y secuencias de procesamiento. El procedimiento del software se centra sobre los detalles de procesamiento de cada módulo individual.

El procedimiento debe proporcionar una especificación precisa del procesamiento, incluyendo la secuencia de sucesos, los puntos concretos de decisiones, la repetición de operaciones, e incluso la organización/estructura de los datos.

 

1.4.8 Ocultamiento de la información

El principio de ocultamiento de la información sugiere que los módulos se han de caracterizar por decisiones de diseño que los oculten unos a otros. Los módulos deben especificarse y diseñarse de forma que la información (procedimientos y datos) contenida dentro de un módulo sea accesible a otros módulos únicamente a través de las interfaces formales establecidas para cada módulo.

 

WB01344_.gif (1348 bytes) WB01345_.gif (616 bytes)