You are on page 1of 30

Diseo Estructurado

Qu es Diseo ?
Es el proceso de aplicar distintas
tcnicas y principios con el propsito de
definir un dispositivo, un proceso o un
sistema con suficiente detalle como
para permitir su realizacin fsica.
Diseo Estructurado
Diseo de Datos: diseo de archivos / tablas
Diseo Arquitectnico: define una estructura
modular
Diseo de Interfaz: define cmo el software
se comunica consigo mismo, con los
sistemas que operan con l y con los
operadores que lo emplean
Diseo de las funciones: diseo de los
algoritmos.
Principios del Diseo
El principio de la sabidura de un ingeniero de
software es reconocer la diferencia entre
conseguir que funcione un programa y hacerlo
bien. Jackson
El proceso de diseo implica la seleccin de la
mejor alternativa
Un buen Diseo est formado por decisiones
justificadas.Se tiene que poder fcilmente recorrer
las etapas (traceability: marcar una traza, seguir un
rastro) o sea que un requerimiento debe estar
expresado en el diseo de alguna forma. Las
decisiones de diseo deben estar soportadas por un
requerimiento o una conveniencia de Diseo.
Principios del Diseo
No inventar la rueda. Reusar mdulos (funciones)
El diseo debe ser uniforme. Tiene que parecer
hecho por una persona. Definir normas de estilo y de
formato.
Debe ser integrado, buena definicin de los
acoplamientos entre los mdulos.
Disear no es escribir cdigo, ni escribir cdigo no
es disear. El nivel de abstraccin del diseo es
diferente al de la codificacin y las decisiones de
diseo no se deben hacer en la etapa de
codificacin; solamente se deben tomar decisiones
de implementacin.

Principios del Diseo
Se debera valorar la calidad del diseo
mientras se crea no una vez que se a
finalizado.
En la etapa de diseo es ms importante
centrarse en las caractersticas esenciales
de la arquitectura que en la finalizacin de
todos los detalles.
Se debera estructurar para admitir
cambios
Minimizar la distancia intelectual

Abstracciones
Manejar con flexibilidad y homogeneidad los
diferentes niveles de abstraccin.
La realidad se la conceptualiza en
abstracciones de datos, de procesos y
control (mecanismo interno del programa).
En la etapa de diseo la abstraccin de
procesos es el mdulo.
Refinamiento
En la etapa de diseo se refina el modelo de anlisis
realizando la siguiente transformacin:
Incorporando ms niveles de detalle.
Incorporando las caractersticas delambiente de
inplementacin
El modelo de datos hay que hacerlo evolucionar hasta tener
con detalle la definicin de los archivos (todos los atributos,
tipo de atributo y longitud, ndices).
Los procesos hasta definir la Arquitectura de mdulos.
La lgica de los procesos: la descripcin de los algoritmos
El control en la estructura de control de un programa.

Lmite del Refinamiento
Se debe describir el sistema de tal
forma que el programador pueda
codificarlo, realizando el menor nmero
de consultas.
La documentacin tiene que servir tanto
en la etapa de mantenimiento perfectivo
como correctivo.
Sirve de base para la confeccin de los
manuales de usuarios.
Modularidad
La Arquitectura del software implica
modularidad. Se divide el software en
componentes identificacles y tratables
por separado, denominados mdulos,
que estn integrados para satisfacer los
requisitos del programa.
Modularidad es el atributo del software
que permite a un programa ser
manejable intelectualmente
Modularidad
C(x) una funcin que define la complejidad percibida de
un problema
E(x) una funcin que defina el esfuerzo (en tiempo )
requerido para solucionar el problema x
p1, p2 dos problemas
C(p1) > C(p2) se sigue
E(p1) > E(p2)
C(p1+p2) > C(p1) +C(p2)
E(p1+p2) > E(p1) +E(p2)

Modularidad
Fig. 13.2















El esfuerzo en costo para desarrollar un mdulo de software individual
disminuye a medida que crece el nmero de mdulos
aumenta con el esfuerzo de integracin

Modularidad Criterios (Meyer)
Capacidad de descomposicin modular
Capacidad de ensamblar componentes
modulares existentes
Capacidad de interpretacin de un mdulo
como una unidad en s
Capacidad de acotar los cambios a
mdulos puntuales
Capacidad de acotar el efecto de un error
al mbito de un mdulo
Modularidad Principios
(Meyer)
Deben corresponder a unidades sintcticas del
lenguaje usado (se debe compilar en forma
separada)
Se debe comunicar con la menor cantidad de
mdulos
Si se comunican, deben intercambiar la menor
cantidad de datos posibles
Las interfaces deben ser explcitas
Toda la informacin de un mdulo debe ser privada,
a menos que se declare pblica
Jerarqua de Control
Estructura del programa, representa la organizacin
(Jerrquica) de componentes del programa
(mdulos) e implica una jerarqua de control.
No presenta aspectos procedimentales del software
tales como secuencia de procesos, ocurrencia/orden
de decisiones o repeticin de operaciones.
Profundidad y anchura: nivel de control y mbito
Grado de entrada: cantidad de mdulos controlan
directamente a un mdulo dado.
Grado de salida: cantidad de mdulos que son
controlados directamente por otro mdulo.
Representa visibilidad y conectividad
Jerarqua de Control
Fig. 13.3
Jerarqua de Control
Estructura del programa deber partirse de la siguiente
forma:
particin horizontal: Los mdulos de control se
usan para coordinar la comunicacin entre ellos y la
ejecucin de las funciones del programa (Entrada /
Proceso / Salida).
Ventajas:
los cambios tienden a ser menos complejos y
las ampliaciones del sistemas tienden a provocar menos
efectos secundarios.
Desventaja
Provoca (negativamente el paso de ms datos entre las
diferentes interfaces
Jerarqua de Control
Estructura del programa deber partirse de la siguiente
forma:
particin vertical o factoring (descomposicin en
factores), sugiere que el control y el trabajo se
distribuyan en forma descendente en la arquitectura
del programa.
Los mdulos del nivel superior deberan realizar funciones
de control y poco trabajo de procesamiento.
Los mdulos del nivel inferior deberan realizar todas las
tareas de entrada, clculo y salida.
Se define de esta forma para localizar los cambios
en los mdulos inferiores.
Ocultamiento de la informacin
Parnas: sugiere que los mdulos se caractericen por
decisiones de diseo que haga que cada uno se
oculte de los dems.
Implica que se puede conseguir una modularidad
eficaz definiendo un conjunto de mdulos
independientes que comunican entre ellos slo la
informacin necesaria para realizar cada uno su
funcionalidad.
El ocultamiento de la informacin como criterio de
diseo para sistemas modulares proporciona sus
mayores beneficios cuando se requiere hacer
modificaciones durante las pruebas o ms tarde
durante el mantenimiento del software.
Diseo Modular Efectivo
Caractersticas:
reduce la complejidad
facilita los cambios
hace ms fcil la implementacin porque
se puede trabajar en paralelo
Aspectos conceptuales bsicos:
Independencia funcional
Cohesin
Acoplamiento
Independencia funcional
Se consigue desarrollando mdulos con una funcin
nica y una disminucin de la interaccin entre los
mdulos.
Tendemos a definir mdulos que trate una
subfuncin especfica de los requisitos y tenga una
sencilla interfaz.
Se mide usando dos criterios:
Cohesin: es una medida de la fuerza relativa
funcional de un mdulo
Acoplamiento: es una medida de la
interdependencia relativa entre los mdulos
Cohesin
IEEE 1983: el grado por el cual las tareas
realizadas por un mdulo de programa
simple estn funcionalmente relacionadas.
Un mdulo con cohesin realiza una sola
tarea dentro de un procedimiento de
software, requiriendo poca interaccin con
los otros mdulos.
Un mdulo con cohesin alta debera hacer
una sola funcin.
El espectro con la que se presenta la
cohesin no es lineal. Se busca maximizar la
cohesin. En la prctica no se busca
categorizar la cohesin sino evitar niveles
bajos de cohesin.
Cohesin
Figura 13.6



coincidente: tareas poco relacionadas unas con otras
lgica: se da cuando un mdulo contiene actividad de la misma
categora,
temporal: Un mdulo tiene cohesin temporal cuando sus elementos o
tareas se ejecutan a un mismo tiempo.
Procedimental. Los elementos de procesamiento de un mdulo estn
relacionados y deben ejecutarse en un orden especfico.
Comunicacin: cuando todos los elementos de procesamiento se
concentran en una misma rea de datos.
Funcional: una nica tarea.

Acoplamiento
Es la medida de la interconexin entre los
mdulos de una estructura de programa.
El acoplamiento depende de la complejidad
de la interfaz entre los mdulos, la decisin
que hace referencia a otro mdulo y los datos
que pasan a travs de la interfaz.
Buscamos minimizar el acoplamiento.
Evitando el efecto onda en la propagacin
de errores.
Acoplamiento
Fig. 13.7



sin acoplamiento directo: sin invocacin directa
datos: pasa una lista simple de argumentos, elementos de datos
de marca: pasa como argumento una estructura de datos
de control: pasa un indicador de control, una variable que controla las
decisiones en un mdulo subordinado o superior
externo: necesario pero hay que tratar de centralizarlo en pocos mdulos
normal / comn: varios mdulos hacen referencia a un rea global de datos
de contenido: un mdulo hace uso de datos o de informacin de control
mantenidos dentro de los lmites de otros mdulos, apunta al interior de otro
mdulo. Debe evitarse.


Acoplamiento
Fig. 13.8


Heurstica de diseo para una
modularidad efectiva
Evaluar el primer planteo de la grfica
de control para reducir el acoplamiento
y mejorar la cohesin
Intentar minimizar las estructuras con
mucho grado de salida; intentar
concentrar a medida que aumenta la
profundidad.
Heurstica de diseo para una
modularidad efectiva
Fig. 13.9
Heurstica de diseo para una
modularidad efectiva
Mantener el alcance del efecto de un
mdulo dentro del alcance del control
de ese mdulo.
El mbito del efecto de un mdulo e, son
todos los mdulos afectados por la
decisin que se toma en e
El alcance de control son todos los
mdulos subordinados a l.
Heurstica de diseo para una
modularidad efectiva
Evaluar las interfaces de los mdulos para
reducir la complejidad, la redundancia y
mejorar la consistencia.
Definir mdulos cuya funcin sea predecible
(caja negra).
Intentar conseguir mdulos de entrada
controlada, evitando conexiones patolgicas
Empaquetar el software basndose en las
restricciones del diseo y los requisitos de
portabilidad.

You might also like