REPUBLICA BOLIVARIANA DE VENEZUELA

UNIVERSIDAD FERMIN TORO

FACULTAD DE INGENIERIA

CABUDARE ESTADO LARA

Diseño Estructurado y las Técnicas que lo Caracterizan

Alumno: Jonathan Bastidas

C.I. 17.048.561

Cabudare, Noviembre 2012

DISEÑO DE SISTEMAS

Diagramas de estructura:

Son representaciones gráficas de la jerarquía existente entre los módulos de un programa, y las estructuras de programación utilizadas para controlar la operación de esos módulos.

Cada módulo se representa como un rectángulo. Los módulos a su vez se pueden componer de otros, o ser módulos primitivos. Un módulo primitivo se encarga de desarrollar el procesamiento de los datos, mientras que un módulo no primitivo se encarga de administrar a otros módulos.

Conexión entre módulos:

Un sistema está compuesto por módulos organizados jerárquicamente, cooperando y comunicándose entre sí para realizar una tarea. La llamada de un módulo se representa con una flecha

Comunicación entre módulos:

La comunicación intermodular se realiza a través de los datos y los flags. Los datos se procesan; por el contrario, los flags sólo sirven como valores de condición para comunicar condiciones entre los módulos. Otra diferencia es que los datos están relacionados con el problema y son importantes para el mundo exterior, mientras que los flags sólo importan para la comunicación de información.

Estrategias de diseño:

El diseño estructurado ofrece dos estrategias para conseguir una creación rápida de un buen diseño a partir de una ERS:

- Diseño por Transformación: Los datos entran en el sistema mediante caminos que se denominan flujos de entrada. En el núcleo se produce una transformación de los datos, y finalmente, los datos se mueven por caminos que conducen a la salida.

- Diseño por transacción: Existe un centro de transacción que es el centro de flujo, desde el que emanan muchos caminos alternativos de forma exclusiva.

El diseño estructurado permite una transición del DFD a una descripción de diseño de la estructura del programa. Se definen unos pasos que están en función del tipo de flujo de información de que se trate.

Análisis de transformación: 1. Revisión del modelo fundamental del sistema:

-Debe haberse aplicado análisis estructurado (DFD). -Hay que considerar al el DFD expandido (3er nivel).

2. Determinar si el DFD tiene características de transformación o de transacción:

-La mayoría de flujos se representan como transformaciones. -Si existe un proceso con salidas exclusivas entonces se trata de un

problema de transacción.

3. Aislar el centro de transformación, especificando los límites del flujo de llegada y de salida:

-El centro de transformación es la parte del DFD que contiene las funciones esenciales del sistema.

-Los límites están abiertos a interpretación (diseñador) diferentes soluciones de diseño según la localización de los límites del flujo.

4. Realizar el primer corte del diagrama de estructura:

-Primer nivel de factorización del DE: Módulo principal coordinador, controlador de entrada, controlador del centro de transformación, y módulo controlador de salida de datos del sistema.

-Los módulos deben tener nombres significativos. -El nombre del Cm coincide con el nombre del diagrama de contexto.

5. Ejecución del segundo nivel de factorización: -Se empieza en los límites y se dirige hacia fuera. -Las transformaciones se convierten en módulos. -Se introducen módulos predefinidos que proporcionen las diferentes

E/S que necesita/genera el sistema. 6. Refinar la estructura del sistema utilizando medidas y guías de diseño:

-Se pueden aumentar disminuir el nº de módulos para producir una factorización lógica, con buena calidad, fácil de implementar/probar/mantener.

-Refinamientos: están dictados por consideraciones prácticas, sentido común y requisitos del software.

-Reflejar los parámetros: datos=flujos de información del DFD; flags=se obtienen de las descripciones de procesos.

7. Asegurarse del trabajo realizado por el diseño obtenido:

-Se puede revisar el DE comprobando que el orden de ejecución de los

módulos es el correcto.

Análisis de transacción:

-Revisión del modelo fundamental del sistema. -Determinar si el DFD tiene características de transformación o de

transacción. -Identificar el centro de transacción y las características del flujo de

cada camino de acción. La posición del centro de transacción puede descubrirse

inmediatamente a partir del DFD. El centro de transacción está ligado al origen de varios caminos de información que fluyen de él. La exclusividad no se suele reflejar en el DFD, por lo que hay que conocer los requisitos.

Se identifica el camino de llegada, el centro de transacción y los caminos de acción.

-Realizar el primer corte del diagrama de estructuras. -Realizar el segundo nivel de factorización. -Refinar la estructura del programa. -Asegurarse del trabajo realizado por el diseño obtenido.

Atributos de la calidad de un diseño:

En cada proyecto se deben decidir cuáles son los requisitos de calidad a cumplir, y decidir los más importantes.

Para asegurar y evaluar la calidad del software, ésta se debe poder medir. Para ello se emplean las MÉTRICAS del software. Aquí nos centramos en las métricas que miden la calidad estructural:

-Cohesión. -Acoplamiento.

Cohesión: Indica la relación que existe entre los elementos de un mismo módulo.

Es la medida de la relación funcional de los elementos de un módulo.

El objetivo es organizar estos elementos de manera que los que tengan una mayor relación a la hora de realizar una tarea pertenezcan al mismo módulo, y los elementos no relacionados, se encuentren en módulos separados.

Acoplamiento: Es el grado de interdependencia entre los módulos. Un buen diseño se caracteriza por un acoplamiento mínimo, es decir,

unos módulos tan independientes los unos de los otros como sea posible.

Técnica de diseño estructurado

Objetivos de la técnica: -Obtener la estructura modular y los detalles de proceso del sistema,

partiendo solamente de los productos obtenidos en la fase de Análisis del Sistema.

-Cambiar la atención del QUE al COMO. -Obtener un diseño que no sólo funcione, sino que también sea

mantenible, mejore la reutilización y se pueda probar y entender fácilmente. -Utilizar herramientas gráficas (Diagramas de Estructura de Cuadros)

para representar la estructura modular del sistema.

Se trata por tanto, de conseguir que cada módulo de la estructura en árbol que se obtenga cumpla las siguientes características: Módulos de pequeño tamaño:

El impacto de un cambio a realizar puede ser perfectamente aislado. Si el tamaño de los módulos es reducido, una determinada modificación afectará a un número mayor de módulos, sin embargo, la cantidad de código a considerar será menor. Independencia modular:

Cuanto mayor es la independencia de un módulo es más sencillo trabajar con él, por tanto, el diseño debe reducir la compartición de ficheros, de datos, la de dispositivos, las interfaces comunes con el Sistema Operativo y las llamadas, desde o hacia otros módulos.

Características de Caja Negra:

La característica de Caja Negra se aplica a cualquier sistema, programa o módulo, para dar una visión exclusiva de sus entradas y salidas, sin tener

en cuenta los detalles de cómo se realiza el proceso. El uso de la Caja Negra permite una visión más fácil del conjunto, posponiendo la consideración de los detalles para una etapa posterior. Modelización conceptual:

Un sistema será más fácil de mantener si el modelo utilizado en su diseño se ha basado en los conceptos lógicos de la organización, los cuales serán más familiares y comprensibles para el personal de mantenimiento que las descripciones físicas (equipo, organización de la unidad, cómo se realiza el trabajo en la actualidad). Aislamiento de los detalles:

En un sistema existen partes que reflejan la filosofía y otras partes que reflejan los detalles. Debido a que los detalles son más susceptibles de cambiar, ambas partes deben diseñarse por separado para evitar que una variación en los detalles afecte a la filosofía del sistema.

Diseño:

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.

Se considerarán dentro del diseño, dos partes, atendiendo al nivel de detalle: 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 detallada de la lógica del proceso y de las estructuras de datos. Diseño de procesos:

Una vez finalizada la Fase de Análisis del Sistema, se dispondrá, al iniciar la Fase de Diseño de un conjunto de especificaciones funcionales que describan, con términos precisos:

-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 modelo de datos lógico del sistema. -Toda esta información estará almacenada en el diccionario del

proyecto, mediante la descripción de Diagramas de Flujo de Datos, Procesos, Flujos de Datos, Diagramas de Estructuras de Datos, Entidades y Atributos.

Para pasar a construir el nuevo sistema, es necesario convertir toda esta información en especificaciones de programas. Las tareas a realizar son:

-Determinar qué módulos implantarán los procesos terminales obtenidos en la Fase Análisis del Sistema.

-Organizar la estructura de estos módulos y definir las conexiones entre los mismos.

-Describir el pseudocódigo para cada módulo.

Para ello se seguirá el método propuesto por CONSTANTINE: el Diagrama de Estructura de Cuadros, que permite definir cuándo, bajo qué condiciones y cuántas veces se tienen que realizar los tratamientos identificados en los PROCESOS. Los datos se contemplan como la interface entre tratamientos sucesivos.

1. Descripción de la técnica:

El paso de la Fase de Análisis del Sistema al diseño será más fácil si se ha llegado a un nivel de detalle muy bajo en los Diagramas de Flujo de Datos.

La estructura Constantine nos da una visión de Arquitectura del sistema. Se trata pues, de no tener ninguna restricción en cuanto al número de objetos, siempre y cuando el dibujo pueda realizarse en una hoja, para no perder la referencia y, en cualquier caso, poder explosionar aquella función que se descomponga.

2. Herramientas de diseño: diagrama de estructura de Cuadros.

La herramienta más importante utilizada es el DIAGRAMA DE ESTRUCTURA DE CUADROS (Structure Chart).

Este diagrama está compuesto por tres elementos básicos:

-Módulos -Conexiones entre módulos -Comunicación entre módulos

Modulo: El módulo representa un programa, subprograma o rutina,

dependiendo del lenguaje que se vaya a utilizar. Se representa en el Diagrama mediante un rectángulo.

El diseño estructurado NO ha impuesto la restricción de que un módulo tenga que ser compilado independientemente.

Se considera al módulo como aquella parte de código que se puede llamar.

Es, por tanto, algo que admite parámetros de llamada y retorna algún valor, si es preciso.

Conexión:

La conexión entre módulos se representa mediante una línea.

3. Principios del diseño estructurado: Descomposición:

La descomposición es la separación de una función en otras que estuvieran contenidas en la primera.

La descomposición consigue los siguientes objetivos: (a) Reducir el tamaño del módulo. (b) Hacer el sistema más fácil de entender y modificar.

(c) Minimizar la duplicidad de código.

(d) Crear módulos útiles.

4. Estrategias de diseño: El paso de los Diagramas de Flujo de Datos (DFD), obtenidos en la

Fase Análisis del Sistema, a los Diagramas de Estructura de Cuadros (DEC), se puede hacer utilizando una serie de estrategias que ayuden a conseguir una rápida derivación hacia un buen diseño.

Habrá que estudiar la forma del DFD sobre el que se vaya a realizar el diseño y dependiendo de su estructura, utilizar una de las estrategias que se describen a continuación. El uso de una de las dos estrategias no supone que la otra no pueda ser utilizada. Dependerá únicamente de la forma del DFD y del peso de la actividad de los procesos.

A partir de esta primera estructura y utilizando las métricas que se verán en el siguiente apartado, se realizará la evaluación y refinamiento del diseño hecho, consiguiéndose, de esa forma, un diseño con una calidad alta. Estas estrategias son:

-Análisis de Transformación. -Análisis de Transacción. El objeto de estas estrategias es desarrollar una representación global

de la Arquitectura del Sistema. Una vez que se define la estructura, podemos evaluar y refinar esta Arquitectura, viéndola como un todo. Análisis de transformación:

El Análisis de Transformación es una estrategia, no un algoritmo. Si se siguen los pasos de un algoritmo los resultados están asegurados y son correctos, una estrategia consigue resultados buenos, pero no perfectos en una primera aproximación.

El análisis de transformación es un conjunto de pasos que permiten obtener, a partir de un DFD con características de transformación, la estructura del sistema.

El DFD con características de transformación es aquél en el que se pueden distinguir tres zonas:

-Flujo de llegada o entrada. -Flujo de transformación o centro de transformación. -Flujo de salida. Esta división en tres partes va a facilitar que, los datos que necesite el

sistema se recojan por los módulos que se encuentren en la/s rama/s de la izquierda, los datos que se intercambian en esa rama serán ascendentes: información de entrada al sistema.

En las ramas centrales habrá movimiento de información compartida tanto ascendente como descendente porque aquí los módulos elaboran nuevos datos.

En la/s rama/s de la derecha, la información ya será la definitiva y el sentido de los datos debe ser descendente. En algún caso particular puede suceder que alguna de las partes sea vacía, esto es, no exista. Pasos del análisis de transformación:

(a) Aislar el centro de transformación. (b) Realizar el primer nivel de factorización del Diagrama de Estructura

de Cuadros. (c) Elaborar el segundo nivel de factorización. (d) Refinar la estructura del sistema utilizando medidas y guías de

diseño.