Fundamentos del diseo de software

Fundamentos del diseo de software

El diseo es el primer paso de la fase de desarrollo de cualquier producto o
sistema de ingeniera.

Definicin de diseo segn Taylor

Proceso de aplicar distintas tcnicas y principios con el propsito de definir un

dispositivo, proceso o sistema con los suficientes detalles como para permitir
su realizacin fsica

El diseo de software, al igual que los mtodos de diseo de todas las

ingenieras, cambian continuamente al aparecer nuevos mtodos, mejores
anlisis y ampliar los conocimientos. El problema es que el diseo de software
se encuentra en una etapa relativamente temprana en su evolucin. La idea de
realizar diseo de software en lugar de programar, surgi a principios de los
aos 60, por lo que a las metodologas de diseo les falta la profundidad y la
flexibilidad que tiene el diseo en otras ingenieras. Pero, ya existen tcnicas
de diseo de software para poder evaluar la calidad del software.

El objetivo de este tema es presentar los conceptos fundamentales que se

pueden aplicar a todos los diseos de programas.

1. Ingeniera del software y diseo del software

Una vez que se han establecido los requisitos del software, el diseo es la
primera de tres actividades tcnicas: diseo, codificacin y prueba. Cada
actividad transforma la informacin de forma que al final se obtiene un software
validado.

El diseo es tcnicamente la parte central de la ingeniera del software.

Durante el diseo se desarrollan, revisan y se documentan los refinamientos
progresivos de las estructuras de datos, de la estructura del programa y de los
detalles procedimentales. El diseo da como resultado representaciones cuya
calidad puede ser evaluada.

Mediante algunas metodologas de diseo se realiza el diseo de datos, el

diseo arquitectnico y el diseo procedimental.

El diseo de datos transforma el modelo de campo de informacin,

creado durante el anlisis, en las estructuras de datos que se van a
requerir para implementar el software.
El diseo arquitectnico define las relaciones entre los principales
elementos estructurales del programa.
El diseo procedimental transforma los elementos estructurales en
una descripcin procedimental del software.

A continuacin, se genera el cdigo fuente y, para integrar y validar el software,

se llevan a cabo las pruebas.

1
 Fundamentos del diseo de software

Las fases de diseo, codificacin y prueba absorben el 75% o ms del coste de

la ingeniera del software (excluyendo el mantenimiento). Es aqu donde se
toman las decisiones que afectarn finalmente al xito de la implementacin del
programa, y tambin, a la facilidad de mantenimiento que tendr el software.
Por tanto el diseo es un paso fundamental de la fase de desarrollo.

El diseo es la nica forma mediante la que podemos traducir con precisin los
requisitos del cliente en un producto o sistema acabado. El diseo de software
es la base de todas las partes posteriores del desarrollo y de la fase de prueba,
como muestra la figura 1.

Figura 1. Importancia del diseo

Sin diseo, nos arriesgamos a construir un sistema inestable, un sistema que

falle cuando se realicen pequeos cambios, un sistema que sea difcil de
probar, un sistema cuya calidad no pueda ser evaluada hasta ms adelante,
cuando quede poco tiempo y ya sea haya gastado mucho dinero.

2. El proceso de diseo
El diseo del software es un proceso mediante el que se traducen los requisitos
en una representacin del software, que se acerca mucho al cdigo fuente.

Desde el punto de vista de la gestin del proyecto, el diseo del software se

realiza en dos etapas: el diseo preliminar y el diseo detallado.

El diseo preliminar se centra en la transformacin de los requisitos

en los datos y la arquitectura del software.
El diseo detallado se ocupa del refinamiento y de la representacin
arquitectnica que lleva a una estructura de datos refinada y a las
representaciones algortimicas del software.

Adems del diseo de datos, del diseo arquitectnico y del desarrollo

procedimental, muchas aplicaciones modernas requieren un diseo de la
interfaz.

2
 Fundamentos del diseo de software

Punto de vista gestin

Diseo preliminar Diseo detallado
Diseo de datos * *
Punto de Diseo arquitectnico *
vista tcnico Diseo procedimental *
Diseo de la interfaz * *

Figura 2. Relacin entre los puntos de vista de gestin y tcnicos

2.1. DISEO Y CALIDAD DEL SOFTWARE

A lo largo del proceso de diseo, la calidad del diseo se evala mediante una
serie de revisiones tcnicas formales (RTF) que son una actividad de
garanta del software cuyos objetivos son:

1) Descubrir los errores en la funcin, la lgica o la implementacin de

cualquier representacin del software.
2) Verificar que el software alcanza sus requisitos.
3) Garantizar que el software se ha representado segn los estndares
establecidos.
4) Conseguir un software desarrollado de forma uniforme.
5) Hacer que los proyectos sean manejables.

Cada RTF se lleva a cabo mediante una reunin y slo tendr xito si est bien
planificada, controlada y atendida.

A continuacin, se listan una serie de criterios para determinar la calidad del

software.

1) Un diseo debe tener una organizacin jerrquica.

2) Un diseo debe ser modular, es decir, el software debe estar dividido
en elementos que realicen funciones especficas.
3) Un diseo debe tener representaciones distintas y separadas de los
datos y de los procedimientos.
4) Un diseo debe llevar a mdulos que exhiban caractersticas
funcionales independientes.
5) Un diseo debe conducir a interfaces que reduzcan la complejidad de
las conexiones entre los mdulos y el exterior.
6) Un diseo debe obtenerse mediante un mtodo que sea reproducible
y que est dirigido por la informacin obtenida durante el anlisis de
requerimientos.

Un buen diseo de software no se consigue fcilmente, resultando de la

aplicacin de principios fundamentales de diseo, de una metodologa
sistemtica y de una revisin exhaustiva.

3
 Fundamentos del diseo de software

2.2. CARACTERSTICAS COMUNES DE LAS METODOLOGAS DE DISEO

Independientemente de la metodologa de diseo que se utilice, todas tienen

varias caractersticas comunes:

1) Mecanismo para la traduccin de requisitos en una representacin de

diseo.
2) Notacin para representar los componentes funcionales y sus
interfaces.
3) Heursticas para el refinamiento y la particin.
4) Criterios para la valoracin de la calidad.

Independientemente de la metodologa de diseo que se utilice, el

desarrollador tiene que aplicar una serie de conceptos fundamentales al diseo
de datos, arquitectnico y procedimental.

3. Fundamentos del diseo

Los fundamentos del diseo ayudan al desarrollador de software a responder a
estas preguntas:

Qu criterios puedo utilizar para dividir el software en componentes

individuales?
Cmo se separan los detalles de una funcin o de la estructura de
los datos de la representacin conceptual del software?
Existen criterios uniformes que definan la calidad tcnica de un
diseo de software?

Cita de Michael A. Jackson

El principio de la sabidura de un programador est en reconocer la diferencia

entre obtener un programa que funcione y uno que funcione correctamente.

3.1. ABSTRACCIN

Cuando se considera una solucin modular para cualquier problema, pueden

formularse varios niveles de abstraccin.

En el nivel superior de abstraccin se establece una solucin en trminos

generales, en lenguaje natural. En los niveles inferiores de abstraccin se
utiliza una orientacin ms procedimental. Por ltimo, en el nivel ms bajo de
abstraccin, se establece una solucin, de forma que pueda implementarse
directamente.

Cada paso de los procesos de la ingeniera del software es un refinamiento del

nivel de abstraccin de la solucin software. Conforme nos movemos desde los
preliminares hacia el diseo detallado, se reduce el nivel de abstraccin.
Finalmente, el nivel ms bajo de abstraccin se alcanza cuando se genera el
cdigo fuente.

4
 Fundamentos del diseo de software

Conforme nos movemos por los diferentes niveles de abstraccin, trabajamos

para crear abstracciones de datos y de procedimientos.

Una abstraccin de datos es un conjunto de datos que describen un

objeto, como puede ser el DNI de una persona, que est compuesta
por conjunto de partes de informacin, pero que nos podemos referir
a todos los datos mencionando el nombre de la abstraccin de datos.
Una abstraccin procedimental es una determinada secuencia de
instrucciones que tienen una funcin limitada y especfica, como
puede ser mover objeto, que supone la secuencia de pasos abrir
pinza, mover hasta posicin de destino 1, cerrar pinza, mover
hasta posicin 2, abrir pinza, mover hasta posicin origen, cerrar
pinza.

Estas abstracciones permiten al diseador representar un objeto a diferentes

niveles de detalle.

3.2. REFINAMIENTO

El refinamiento sucesivo es una primera estrategia de diseo descendente

propuesta por Niklaus Wirth. La arquitectura de un programa se desarrolla en
niveles sucesivos de refinamiento de los detalles procedimentales. Se
desarrolla una jerarqua descomponiendo una funcin de forma sucesiva hasta
que se llega a las sentencias del lenguaje de programacin.

Comenzamos con una declaracin de la funcin (o una descripcin de la

informacin) definida a un nivel superior de abstraccin. Es decir, la declaracin
describe la funcin o la informacin conceptualmente, pero no proporciona
informacin sobre el funcionamiento interno de la funcin o sobre la estructura
interna de la informacin, sino que se va a realizando sucesivamente, dando
cada vez ms detalles.

3.3. MODULARIDAD

El software se divide en componentes con nombres y ubicaciones

determinados, que se denominan mdulos y que se integran para satisfacer los
requisitos del proveedor.

El software monoltico (es decir, un programa grande compuesto de un solo

mdulo) no puede ser estudiado fcilmente por un lector, ya que el nmero de
caminos de control, el nmero de variables y la complejidad global haran el
cdigo prcticamente indescifrable.

Mtemticamente, esto se explica de esta forma:

Sea C(x) una funcin que defina la complejidad de un problema x, y E(x) una
funcin que defina el esfuerzo de desarrollo de un problema x.

5
 Fundamentos del diseo de software

Para dos problemas p1 y p2, si

C(p1) > C(p2)
se deduce que
E(p1) > E(p2)

Adems, se cumple que

C(p1 + p2) > C(p1) + C(p2)
y que
E(p1 + p2) > E(p1) + E(p2)

Esto nos lleva a la conclusin divide y vencers, por tanto la modularidad del
software facilita el desarrollo del mismo, pero hasta un cierto lmite, porque si
llegramos a dividir el problema en infinitos mdulos, los mdulos tendran una
complejidad y un esfuerzo mucho menor, pero crecera el coste asociado a la
creacin de interfaces entre los mdulos, tal y como muestra la figura 3.

Figura 3. Modularidad y coste del software

3.4. ARQUITECTURA DEL SOFTWARE

La arquitectura del software se refiere a dos caractersticas importantes del

software:
La estructura jerrquica de los mdulos del software
La estructura de los datos

La arquitectura del software se obtiene mediante un proceso de particin, que

relaciona los problemas del mundo real (definidos en el anlisis de
requerimientos) con las soluciones software para resolver los problemas
software.

Figura 4. Evolucin de la estructura

6
 Fundamentos del diseo de software

Este proceso de transicin entre el anlisis de requerimientos y el diseo se

representa es el que representa la figura 4.

3.5. JERARQUA DE CONTROL

Tambin se le conoce como estructura del programa, y representa la

organizacin jerrquica de los mdulos de un programa e implica una jerarqua
de control.

La representacin de jerarqua se suele representar con diagramas de rbol,

aunque tambin se pueden utilizar otros tipos de notaciones.

La figura 5 muestra un ejemplo de una estructura de un programa.

Figura 5. Estructura de un programa

A continuacin definiremos los algunos trminos relacionados con la figura 5.

Profundidad: Nmero de niveles de control
Anchura: Amplitud global del control
Grado de salida: Nmero de mdulos que controla un mdulo
Grado de entrada: Nmero de mdulos que controlan a un mdulo
Visibilidad: Conjunto de componentes del programa que pueden ser
invocados por un mdulo (Herencia en entornos de POO). Todos los
objetos seran visibles para el mdulo
Conectividad: Conjunto de componentes a los que se invoca
directamente o se utilizan sus datos. (La ejecucin de un mdulo
puede suponer la ejecucin de otro mdulo)

3.6. ESTRUCTURA DE DATOS

La estructura de datos es una representacin de la lgica que existe entre los

elementos individuales de informacin. Debido a que la estructura de la
informacin afectar de forma determinante al diseo procedimiental, la
estructura de datos es tan importante como la estructura del programa en la
representacin de la arquitectura del software.

La estructura de datos dicta la organizacin, los mtodos de acceso, el grado

de asociatividad y las alternativas para el tratamiento de la informacin.

7
 Fundamentos del diseo de software

Las estructuras de datos clsicas son los elementos escalares, los arrays, las
listas y los rboles.

3.7. PROCEDIMIENTOS DEL SOFTWARE

La estructura del programa define la jerarqua de control, independientemente

de las decisiones y secuencias de procesamiento. El procedimiento del
software se centra en los detalles de procesamiento de cada mdulo individual,
como muestra la figura 6.

Figura 6. Procedimiento dentro de un mdulo

El procedimiento debe proporcionar una especificacin precisa del

procesamiento, incluyendo la secuencia de sucesos, los puntos concretos de
decisiones, la repeticin de operaciones e incluso la organizacin/estructura de
los datos.

Como existe una relacin entre la estructura y el procedimiento, ya que el

procesamiento de un mdulo puede suponer la llamada a otros mdulos. A
esto se le conoce como representacin procedimental del software por
capas, como muestra la figura 7

Figura 7. Procedimiento realizado por capas

8
 Fundamentos del diseo de software

3.8. OCULTAMIENTO DE INFORMACIN

El concepto de modularidad nos lleva a esta pregunta: cmo descomponer

una solucin de software en el mejor conjunto de mdulos?

El principio de ocultamiento de la informacin sugiere que los mdulos deben

especificarse de forma que la informacin (procedimientos y datos) contenida
dentro de un mdulo sea inaccesible a otros mdulos que no necesiten tal
informacin.

Por tanto se trata de definir una serie de mdulos independientes que se

comuniquen slo a travs de la informacin necesaria para realizar la funcin
de software.

El uso de ocultamiento de informacin en el diseo facilitar las modificaciones,

prueba y mantenimiento del software, ya que como la mayora de los datos y
de los procedimientos estn ocultos a otras partes del software, ser menos
probable que los errores que se introduzcan durante la modificacin se
propaguen a otros mdulos del software.

4. Diseo modular efectivo

Todos los fundamentos del diseo anteriores sirven para incentivar los diseos
modulares.

Un diseo modular:
Reduce la complejidad
Facilita los cambios
Implementacin ms sencilla
Permite el desarrollo paralelo de partes diferentes de un sistema

4.1. TIPOS DE MDULOS

Para la definicin de mdulos en una arquitectura de software se utiliza la

abstraccin y ocultamiento de informacin. Estos atributos tienen que ser
traducidos a las caractersticas de ejecucin del mdulo, caracterizadas por el
historial de ejecucin, el mecanismo de activacin y el camino de control, y que
describimos a continuacin:
El historial de incorporacin se refiere al momento en que se incluye
el mdulo en la descripcin del software en lenguaje fuente.
El mecanismo de activacin se refiere a la forma en que se invoca a
un mdulo, que puede ser de referencia (mediante una llamada) o
de interrupcin (en aplicaciones en tiempo real, ocurre un evento en
el mundo exterior)
El camino de control de un mdulo describe la forma en que se
ejecuta internamente, y son los que se describen a continuacin.

4.1.1. Mdulos secuenciales

Se ejecutan sin interrupcin aparente por parte del software de la aplicacin, es

decir ejecutan secuencialmente una tarea.

9
 Fundamentos del diseo de software

4.1.2. Mdulos incrementales

Tambin se les conoce como corrutinas, y pueden ser interrumpidos antes de

que terminen por el software de la aplicacin, y restablecerse posteriormente
su ejecucin en el punto en que se interrumpi.

4.1.3. Mdulos paralelos

Un mdulo paralelo se ejecuta a la vez que otro mdulo en entornos

multiprocesadores.

4.2. INDEPENDENCIA FUNCIONAL

La independencia funcional es una derivacin directa de la modularidad, de la

abstraccin y del ocultamiento de informacin.

La independencia funcional se adquiere desarrollando mdulos con una funcin

clara y con pocas relaciones con otros mdulos, de forma que cada mdulo se
centra en una subfuncin especfica de los requerimientos y tenga una interfaz
sencilla.

Esta independencia tiene varias consecuencias positivas como son:

Mdulos independientes fciles de desarrollar
Creacin de interfaces sencillas
Facilidad para la prueba y el mantenimiento
Se reduce la propagacin de errores
Se fomenta la reutilizacin de mdulos.

La independencia se mide con dos criterios cualitativos que son la cohesin y

el acoplamiento.

4.2.1. Cohesin

La cohesin es una extensin del concepto de ocultamiento de informacin. Un

modulo cohesivo ejecuta una tarea sencilla de un procedimiento de software y
requiere poca interaccin con procedimientos que ejecutan otras partes de un
programa.

Dicho de forma sencilla, un mdulo cohesivo slo hace (idealmente) una cosa.

Por tanto el diseador debe comprender lo que es la cohesin y evitar la baja

cohesin en el diseo de los mdulos.

Figura 8. Representacin de la escala de cohesin

10
 Fundamentos del diseo de software

Lo importante es intentar conseguir una cohesin alta y saber reconocer la

cohesin baja, de forma que pueda modificar el diseo del software para tener
de una mayor independencia funcional.

4.2.2 Acoplamiento

El acoplamiento es una medida de la interconexin entre los mdulos de una

estructura de programa.

El acoplamiento depende de la complejidad de las interfaces entre los mdulos

y de los datos que pasan a travs de la interfaz.

En el diseo de software buscamos el acoplamiento ms bajo posible. Una

conectividad sencilla entre mdulos da como resultado un software ms fcil de
comprender y menos propenso al efecto onda (propagacin de errores a lo
largo del sistema).

5. Diseo de datos
El diseo de datos es la primera de las tres actividades de diseo realizadas
durante la ingeniera del software. El impacto de la estructura de datos sobre la
estructura de programa y la complejidad procedimental, hace que el diseo de
datos tenga una gran influencia en la calidad del software.

Los conceptos de ocultamiento de informacin y de abstraccin de datos

conforman la base de los mtodos de diseo de datos.

Segn Wasserman La actividad principal durante la fase de diseo de datos es

la seleccin de las representaciones lgicas de las estructuras de datos,
identificados durante las fases de definicin y especificacin de requerimientos.
Una actividad importante durante el diseo es la de identificar los mdulos de
programa que deben operar directamente sobre las estructuras de datos. De
esta forma, puede restringirse el mbito del efecto de las decisiones concretas
de diseo de datos.

Los datos bien diseados conducen a:

Mejor estructura de programa
Modularidad efectiva
Complejidad procedimental reducida

5.1. PRINCIPIOS PARA LA ESPECIFICACIN DE DATOS

Los principios que se citan a continuacin son la base del mtodo de diseo de
datos, y una definicin clara de la informacin es esencial para el desarrollo de
un buen software.

1. Los principios sistemticos de anlisis aplicados a la funcin y el

comportamiento tambin deben aplicarse a los datos.

Al igual que en la fases de anlisis del sistema, tambin se debe:

11
 Fundamentos del diseo de software

Desarrollar y revisar las representaciones del flujo y del contenido de

los datos.
Identificar las estructuras de datos.
Considerar estructuras de datos alternativas.
Evaluar el impacto de la modelizacin de datos sobre el diseo del
software

Por ejemplo, la especificacin de una lista enlazada circular puede satisfacer

los requerimientos de los datos, pero tambin puede conducir a un diseo del
software difcil de manejar, por lo que deberemos ver si existen otras
estructuras de datos alternativas que lleven a resultados mejores.

2. Se deben identificar todas las estructuras de datos y las operaciones que se

han de realizar sobre cada una de ellas.

El diseo de una estructura eficiente debe tener en cuenta las operaciones que
han de realizarse sobre dicha estructura de datos.

Por ejemplo, la especificacin de un tipo abstracto de datos puede simplificar

considerablemente el diseo del software.

3. Debe establecerse y usarse un diccionario de datos para definir el diseo

de los datos y del programa.

Un diccionario de datos representa explcitamente las relaciones entre los

datos y las restricciones sobre los elementos de una estructura de datos.

4. Se deben posponer las decisiones de diseo de datos de bajo nivel hasta

ms adelante en el proceso de datos.

Para el diseo de datos puede seguirse un proceso de refinamiento sucesivo,

es decir, puede definirse una organizacin global de los datos durante el
anlisis de requerimientos, refinarse durante el diseo preliminar y
especificarse en detalle en el diseo detallado.

5. La representacin de una estructura de datos slo debe ser conocida por

los mdulos que hagan uso directo de los datos contenidos en la estructura.

El concepto de ocultamiento de informacin y el concepto de acoplamiento

asociado proporcionan una valoracin importante de la calidad del diseo del
software.

6. Se debe desarrollar una librera de estructuras de datos tiles y de las

operaciones que se le pueden aplicar.

Se pueden disear las estructuras de datos de forma que sean reusables, de

forma que las estructuras de datos y las operaciones se vean como recursos
para el diseo de software.

12
 Fundamentos del diseo de software

7. El diseo de software y el lenguaje de programacin deben soportar la

especificacin y realizacin de tipos abstractos de datos.

La implementacin de una estructura de datos compleja puede convertirse en

una tarea muy difcil si no hay una forma directa de realizar una especificacin
directa de la estructura de datos.

6. Diseo arquitectnico
El objetivo principal del diseo arquitectnico es desarrollar una estructura de
programa modular y representar las relaciones de control entre los mdulos.

Adems el diseo arquitectnico mezcla la estructura de programas y la

estructura de datos y define las interfaces que facilitan el flujo de los datos a lo
largo del programa.

Se trata de no centrarse en los detalles y cdigo de los procedimientos (tareas

que se realizan ms adelante) sino en centrarse en la arquitectura del software
que permita obtener una visin general del software.

7. Diseo procedimental
EL diseo procedimental se realiza despus de que se ha establecido la
estructura del programa y de los datos. La especificacin procedimental que
define los algoritmos, cabe pensar que se podra especificar en lenguaje
natural, pero debido a la cantidad de ambigedades que este lenguaje acarrea,
es necesario utilizar una forma ms restringida de representacin.

7.1. PROGRAMACIN ESTRUCTURADA

A finales de los 60 se propuso la utilizacin de un conjunto de construcciones

lgicas con las que poda formarse cualquier programa.

Cada construccin tena estructura lgica predecible. Se entra por ella por el
principio, se sale por el final y facilita al lector el seguimiento del flujo
procedimental.

Las construcciones son secuencia, condicin y repeticin, y son fundamentales

en la programacin estructurada.
La secuencia implementa los pasos de procedimiento esenciales de
la especificacin de cualquier algoritmo.
La condicin da la posibilidad de seleccionar un procedimiento
basndose en alguna ocurrencia lgica.
La repeticin proporciona iteracin.

Las construcciones estructuradas se propusieron para limitar el diseo

procedimental del software a un nmero pequeo de operaciones predecibles,
lo que facilita la legibilidad, prueba y mantenimiento del software.

13
 Fundamentos del diseo de software

Adems, la notacin debe facilitar la codificacin, de forma que el cdigo se

obtenga de forma natural a partir del diseo.

7.1.1. Notaciones para la representacin grfica en diseo procedimental

Para evitar desarrollar un software errneo, es fundamental que se utilicen

correctamente las herramientas grficas para el diseo, como son los
diagramas de flujo y los diagramas de cajas.

Diagrama de flujo

Es la representacin grfica que ms se utiliza en el diseo procedimental.

Para representar un paso de procesamiento se utiliza un cuadro, para

representar una condicin se utiliza un rombo, y para representar el flujo de
control se utilizan flechas.

Figura 9. Construcciones de programacin estructurada con diagramas de flujo

Las construcciones estructuradas pueden estar anidadas unas dentro de otras,

cada una de estas puede realizar llamadas a mdulos, teniendo entonces una
disposicin por capas procedimentales en un diagrama de flujo estructurado,
como muestra la figura 10.

Figura 10. Un diagrama de flujo estructurado

14
 Fundamentos del diseo de software

A veces, el restringirse al uso exclusivo de construcciones estructuradas puede

introducir complicaciones en el flujo lgico. Por ejemplo, supongamos que
como parte del proceso i surge una condicin, z, que requiere una bifurcacin
inmediata al proceso j. Una bifurcacin directa violar la construccin lgica,
escapando del dominio funcional de la sentencia repeat-until, de la cual forma
parte el proceso i.

Para implementar la bifurcacin anterior sin violar las caractersticas de las

condiciones estructuradas, sera necesario aadir la condicin z a x7 y a x8.
Estas comprobaciones se realizaran continuamente, incluso aunque no fuese
necesario la ocurrencia de la z. De esta forma, habramos introducido una
condicin adicional y una eficiencia en la ejecucin. Entonces qu podemos
hacer?.

El diseador tiene dos opciones:

Redisear la representacin procedimental, de forma que no sea
necesaria la bifurcacin de escape en una posicin interior del flujo
de control.
Violar las construcciones estructuradas de forma controlada, es decir,
disear una bifurcacin restringida hacia fuera del flujo anidado.

Diagrama de cajas

Esta notacin surgi del deseo de desarrollar una representacin para el

diseo procedimental que no permitiera la violacin de construcciones
estructuradas. Estos diagramas fueron desarrollados por Nassi y
Schneiderman y perfeccionados por Chapin.y tienen las caractersticas
siguientes:
El mbito funcional est bien definido y es claramente visible.
La transferencia de control arbitraria es imposible.
Es fcil determinar el mbito de los datos locales y globales
La recursividad es fcil de representar

La representacin grfica de construcciones estructuradas, usando diagramas

de cajas, se muestra en la figura 11. El elemento fundamental del diagrama de
cajas es la caja.

Figura 11. Construcciones en diagramas de cajas

15
 Fundamentos del diseo de software

Al igual que con los diagramas de flujo, se pueden crear diagramas de cajas
por capas en mltiples pginas. Se puede representar una llamada a un
mdulo subordinado mediante una caja con el nombre del mdulo encerrado
dentro de una circunferencia.

La figura 12 muestra un diagrama de cajas que representa el mismo flujo de

control que el de la figura 10.

Figura 12. Un diagrama de cajas estructurado

Para ver la relativa facilidad con que puede comprenderse el dominio funcional,
puede observarse el bucle repeat-until con la condicin x8. Todas las
construcciones lgicas contenidas dentro del bucle se encuentran fcilmente,
debido a que estn dispuestas en cajas interiores.

7.1.2. Notaciones tabulares de diseo

En muchas aplicaciones de software puede ser necesario que un mdulo

evale una compleja combinacin de condiciones, y de acuerdo con ellas,
seleccione la opcin adecuada.

Las tablas de decisin constituyen una notacin que traduce las acciones y
condiciones a una forma tabular.

Figura 13. Esqueleto de una tabla de decisin

16
 Fundamentos del diseo de software

La figura 13 muestra la organizacin de una tabla de decisin, que est dividida

en cuatro cuadrantes por las lneas gruesas.
El cuadrante superior izquierdo contiene una lista de todas las
condiciones
El cuadrante inferior izquierdo contiene una lista de todas las
acciones que se pueden realizar en funcin de las condiciones
Los cuadrantes de la derecha forman una matriz que contienen las
combinaciones de las condiciones para producir las acciones.

Por tanto, cada columna de la matriz representa una regla de procesamiento.

Los pasos para la creacin de una tabla de decisin son los siguientes:
Listar todas las acciones que se pueden asociar a un mdulo.
Listar todas las condiciones necesarias para la ejecucin de un
procedimiento.
Asociar conjuntos de condiciones especficas a acciones especficas,
eliminando combinaciones imposibles. Desarrollar las posibles
combinaciones de condiciones.
Definir reglas indicando las acciones que ocurren para una serie de
condiciones.

7.1.3. Lenguaje de diseo de programas

Un lenguaje de diseo de programas (LDP), tambin conocido como lenguaje

estructurado o pseudocdigo es un lenguaje que utiliza el vocabulario de un
lenguaje y la sintaxis de otro.

Independientemente de su origen, un LDP tiene que tener las caractersticas

siguientes:
Una sintaxis fija de palabras clave que permitan construir todas las
construcciones estructuradas, declarar datos y establecer
caractersticas de modularidad.
Una sintaxis libre en lenguaje natural para describir las
caractersticas de procesamiento.
Facilidades para la declaracin de datos, incluyendo estructuras de
datos simples y complejas.
Un mecanismo de definicin de subprogramas y de llamada a stos.

17
 Fundamentos del diseo de software

8. Documentacin del diseo

Se puede utilizar un esquema de documento como el siguiente para la
especificacin del diseo.

Especificacin de diseo

1. Ambito
1.1 Objetivos del sistema
1.2 Hardware, software e interfaces humanas
1.3 Principales funciones del software
1.4 Base de datos definida externamente
1.5 Principales restricciones y limitaciones del diseo
2. Documentos de referencia
2.1 Documentacin del software existente
2.2 Documentacin del sistema
2.3 Documentos del vendedor (hardware o software)
2.4 Referencia tcnica
3. Descripcin del diseo
3.1 Descripcin de datos
3.1.1 Revisin del flujo de datos
3.1.2 Revisin de la estructura de datos
3.2 Estructura de programa derivada
3.3 Interfaces dentro de la estructura
4. Mdulos (Para cada mdulo)
4.1 Texto explicativo
4.2 Descripcin de la interfaz
4.3 Descripcin en lenguaje de diseo
4.4 Mdulos utilizados
4.5 Organizacin de los datos
4.6 Comentarios
5. Estructuras de archivos y datos globales
5.1 Estructura de archivos internos
5.1.1 Estructura lgica
5.1.2 Descripcin lgica de los registros
5.1.3 Mtodo de acceso
5.2 Datos globales
5.3 Referencias cruzadas entre archivos y datos (ver figura 14)
6. Referencias cruzadas para los requisitos
7. Provisiones de prueba
7.1 Directrices de prueba
7.2 Estrategia de integracin
7.3 Consideraciones especiales
8. Empaquetamiento
8.1 Provisiones especiales de solapamiento del programa
8.2 Consideraciones de transferencia
9. Notas especiales
10. Apndices

18
 Fundamentos del diseo de software

Figura 14. Referencias cruzadas entre archivos y datos

En la seccin 1 se describe el mbito global del trabajo de diseo. Gran parte

de la informacin de esta seccin se deriva de la especificacin del sistema y
de otros documentos obtenidos en la fase de definicin del software.

La seccin 2 incluye las referencias especficas a la documentacin de soporte.

En la seccin 3, que se desarrolla durante el diseo preliminar, se refinan y

utilizan los DFD y otras representaciones de los datos, desarrollados durante el
anlisis de requerimientos. Puesto que est definido el flujo de la informacin
se pueden desarrollar las descripciones de la interfaz para los elementos del
software.

Las secciones 4 y 5 se realizan durante el paso del diseo preliminar al diseo

detallado. Inicialmente se describen los mdulos mediante una descripcin
procedimental del mdulo en lenguaje natural. Despus se utiliza una
herramienta de diseo procedimental para traducir el texto explicativo a una
descripcin estructurada.

La seccin 5 contiene una descripcin de la organizacin de los datos, se

asignan los datos globales y se establecen referencias cruzadas que conectan
los mdulos individuales con los archivos o datos globales.

La seccin 6 contiene las referencias cruzadas entre los requerimientos y los

mdulos que los implementan y facilita la identificacin de los mdulos que se
corresponden con requerimientos crticos.

La seccin 7 contiene la primera etapa del desarrollo del procedimiento de

prueba. Una vez que se han establecido la estructura y las interfaces del
software podemos desarrollar directrices para la prueba de los mdulos
individuales y de su integracin.

La seccin 8 contiene las restricciones del diseo, tales como las limitaciones
fsicas de memoria o la necesidad de un gran rendimiento del software, y
tambin describe el mtodo que se usar para transferir el software al lugar del
cliente.

Las secciones 9 y 10 contienen datos complementarios como las descripciones

de algoritmos o procedimientos alternativos y otro tipo de informacin
relevante.

19