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 la

estrategia 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 los

sistemas. Sin embargo hay numerosas situaciones en las cuales estrategias adicionales
pueden utilizarse para suplementar, y aún reemplazar, el enfoque básico del análisis de
Transformación.

Una de estas estrategias suplementarias principales se conoce como Análisis de

Transacció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