EL DISEÑO EN LA INGENIERIA DE SOFTWARE

El diseño de software es la primera de tres actividades técnicas: 1. Diseño 2. Codificación 3. Prueba

Mediante alguna de las metodologías existentes para el diseño se realizan tres tipos de diseño: a) Diseño de Datos. Transforma el modelo del campo de la información en las estructuras de datos que se van a requerir para implementar el software. b) Diseño Arquitectónico. Define las relaciones entre los principales elementos estructurales del programa. c) Diseño Procedimental Transforma los elementos estructurales en una descripción procedimental del software. d) Diseño de la Interfaz. Establece la disposición y los mecanismos para la interacción Hombre-Máquina.

DISEÑO DE DATOS

El diseño de datos es la primera de las tres actividades de diseño, los datos bien diseñados pueden conducir a una

Mejor estructura de programa, a una modularidad efectiva y a una complejidad procedimental reducida.

Por ejemplo:

La utilización de una lista enlazada multicelular puede satisfacer los requisitos de datos, pero puede también

Conducir a un diseño de software difícil de manejar. Una organización o estructura de datos alterna puede llevar a mejores resultados.

PRINCIPIOS PARA EL DISEÑO DE DATOS.

1.- Deben identificarse todas las estructuras de datos y las operaciones que se han de realizar sobre cada una de ellas.

2.- Debe establecerse y usarse un diccionario de datos para definir el diseño de los datos del programa.

3.- El diseño de datos de bajo nivel debe realizarse hasta el diseño detallado.

4.- El lenguaje de programación debe soportar la especificación y la realización de tipos abstractos de datos.

DISEÑO ARQUITECTONICO

El objetivo principal del diseño arquitectónico es desarrollar una estructura de programa modular y representar las relaciones de control entre los módulos.

Los métodos de diseño disponibles para realizar el diseño arquitectónico son:

a) Diseño orientado al flujo de datos (estructurado)

b) Diseño orientado a los objetos

c) Diseño orientado a los datos

Porque es importante su definición facilita la comunicación entre los diferentes participantes en el desarrollo.

Resalta las decisiones de diseño que se puedan tener un gran impacto en el todo el proceso de desarrollo posterior

Aporta una visión de cómo se estructura el sistema y sus componentes trabajan juntos

FLUJO DE TRANSFORMACION

La información debe introducirse y obtenerse del software en forma de mundo exterior,

la información entra en el sistema a lo largo de caminos que transforman los datos

externos a un formato interno. Estos caminos se identifican como flujo de entrada. La

información entrante se pasa a través de un centro de transformación y empieza a

moverse a lo largo de caminos que ahora conducen hacia fuera del software. Los datos

que se mueven a lo largo de este camino se denominan flujo de salida.

ANALISIS DE TRANSFORMACIONES

El análisis de las transformaciones es un conjunto de pasos de diseño que permite

convertir un DFD, con características de flujo de transformación, en un estilo

arquitectónico especifico.

A continuación se presentara un ejemplo de un sistema de seguridad “Hohar Seguro”, el

cual es representativo de muchos productos y sistemas basados en computadora, este

sistema interactúa con el usuario a través de una serie de entradas por teclado y

visualizaciones alfanuméricas. En la siguiente figura se aprecia el nivel 0 del DFD de

Hogar Seguro.

PASOS DEL DISEÑO DE TRANSFORMACION

Basándonos en el ejemplo anterior se ilustrara cada paso en el análisis de las

transformaciones. Los pasos empiezan con una reevaluación del trabajo hecho durante

el análisis de requisitos y después evoluciona hacia el diseño de la arquitectura del

software.

Paso 1. Revisar el modelo fundamental del sistema. El modelo fundamental del sistema

comprende el DFD de nivel 0 y la información que lo soporta.

Paso 2. Revisar y refinar los diagramas de flujo de datos del software. La información

obtenida de los modelos de análisis contenidos en la Especificación de Requisitos del

Software se refina para obtener mayor detalle.

Paso 3. Determinar si el diagrama de flujo tiene características de flujo de

transformación o de transición. En este paso, el diseñador selecciona la característica

general del flujo (de la amplitud del software) basándose en la propia naturaleza del

DFD. Además, se aíslan regiones locales de flujo de transformación o de transacción.

Estos subflujos pueden usarse para refinar la estructura del programa obtenida por la

característica general que prevalece.

Paso 4. Aislar el centro de transformación especificado los límites de los flujos de

entrada y salida. Los diseñadores pueden elegir puntos ligeramente diferentes como

límites de flujo.

Paso 5. Realizar una descomposición de primer nivel. La descomposición en partes

provoca una estructura de programa en la que los módulos del nivel superior realizan la

toma de decisiones y los módulos del nivel inferior realizan la mayoría de trabajo de

entrada, cálculos y salida y los módulos de nivel intermedio realizan algún control y

cantidades moderadas de trabajo

Paso 6. Realizar descomposición de segundo nivel. La descomposición de segundo

nivel se realiza mediante la conversión de las transformaciones individuales de un DFD

en los módulos correspondientes dentro de la arquitectura. El siguiente diagrama nos

ilustra la descomposición del flujo de datos del segundo nivel.

Ejemplo de un controlador principal denominado Gestor de monitorización de sensores

que sirve para coordinar una serie de funciones de control subordinadas.

Paso 7. Refinar la estructura inicial de la arquitectura usando heurística para mejorar la

calidad. Una primera e3structura de arquitectura siempre puede refinarse aplicando los

conceptos de independencia de módulos. Los módulos se incrementan o reducen para

producir una descomposición razonable, buena cohesión, acoplamiento mínimo y lo

más importante, una estructura que se pueda implementar sin dificultad, probarse sin

confusión y mantenerse sin problemas

El objetivo de los siete puntos anteriores es desarrollar una representación general de

software. Es decir, una vez que se ha definido la estructura, podemos evaluar y refinar la

arquitectura del software viéndola en su conjunto.

Análisis de Transacción

En el último capítulo exploramos la estrategia del análisis de transformación como laestrategia principal para el diseño de programas y sistemas bien estructurados.

En verdad, el análisis de transformación, servirá de guía en el diseño de la mayoría de lossistemas. Sin embargo hay numerosas situaciones en las cuales estrategias adicionalespueden utilizarse para suplementar, y aún reemplazar, el enfoque básico del análisis deTransformación.

Una de estas estrategias suplementarias principales se conoce como Análisis deTransacción.

El análisis de transacción es sugerido por un DFD del siguiente tipo:

Fuentes de consulta.

http://www.itlalaguna.edu.mx/academico/carreras/sistemas/ingsofware1/UNIDAD6.pdf

http://www.mitecnologico.com/Main/Dise%F1oArquitecturaDelSoftware

http://exa.unne.edu.ar/informatica/anasistem2/public_html/apuntes/de1.pdf