DISEO

Diseo
I.- Introduccin
II.- El diseo en general
1.- Antecedentes.
2.- Estimaciones brainstorming
III.- Diseo estructurado
1.- Introduccion
2.- Diagramas de estructura
3.- Conversin de dfd en diagrama de estructura
4.- Modularizacin
5.- Criterios de descomposicin modular
5.1.- clausura.
5.2.- independencia.
5.2.1.- acoplamiento.
5.2.2.- cohesin.
6.- Diseo de la interfaz entre dos mdulos
IV.- Mtricas de diseo
V.- Diseo orientado a objetos
Diseo
I.- INTRODUCCIN

PRINCIPIOS DE DISEO
1. Los Datos y los algoritmos que los manipulan deben crearse
como un conjunto de abstracciones interrelacionadas.
2. Los detalles internos del diseo de las estructuras de datos y
los algoritmos deben ocultarse de otros componentes software
que hacen uso de dichas estructuras de datos o algoritmos.
3. Los mdulos deben exhibir independencia.
4. Los algoritmos deben disearse utilizando un conjunto
restringido de constructores lgicos.

Actividades del Diseo de Software
II.- EL DISEO EN GENERAL

El diseo de los datos traduce el modelo de datos creado
durante el anlisis a estructuras de datos que satisfacen las
necesidades del problema.

El diseo de la arquitectura va a depender del punto de vista o
enfoque del diseador: por ejemplo, en un diseo convencional se
crear una arquitectura jerrquica, mientras que en un enfoque
orientado al objeto, se crear una red de mensajes que permite la
comunicacin entre los objetos.
El diseo de la interfaz crea un modelo de implementacin
para la interfaz humano-computador, las interfaces externas del
sistema que le permiten interactuar con otras aplicaciones, y las
interfaces internas que permiten a los datos ser comunicados a
travs de los componentes del software.

El diseo procedural define algoritmos para implementar los
requerimientos de procesamiento de los componentes del
software.

1.- ANTECEDENTES
El diseo es un proceso iterativo cuyo resultado es la
especificacin de un sistema fsico que cumpla con los
requerimientos

Existen diversas tcnicas bsicas:
Diseo estructurado.
Diseo incremental o evolutivo.
Diseo orientado a objetos.

y tcnicas complementarias
Control de calidad del diseo.
Estimacin de costos de diseo.
III.- EL DISEO ESTRUCTURADO

1.- INTRODUCCIN
La tcnica consiste bsicamente en la conversin sistemtica de
los DFD en Diagramas de estructura

2.- OBJETIVOS
Reducir la complejidad de un sistema a travs de la tcnica de
Modularizacin de sus funciones.
Abaratar los costos de construccin a travs de la Reutilizacin
de Mdulos.
Disminuir los costos de construccin a travs de:
Diseos simples de comprender.
Flexibles a cambios.
Eficientes en su operacin.
Fciles de construir.
La tcnica utiliza criterios de evaluacin de la calidad del diseo
respecto del problema que se desea resolver.


La tcnica se apoya en notaciones grficas - los diagramas de
estructura - y en pseudocdigo.
3.- DIAGRAMAS DE ESTRUCTURA
A
B
MODULO
MODULO PREDEFINIDO
B
A
A
B
X,Y Z El modulo A llama al modulo B y pasa los parmetros
X;Y de A a B. El modulo B remite el parmetro Z al
modulo B
A
B B
El modulo A llama a los mdulos B y C.
Los mdulos se colocan de izquierda a derecha
en orden de invocacin.
El modulo B hace referencia a Datos en el A
4.- MODULARIZACIN

El MDULO es el componente bsico de un sistema estructurado

Se puede concebir como un subprograma con una interfaz a
travs de la cual se comunica con otros subprogramas.

Ejemplos
Un programa compilado separadamente.
Una rutina Fortran.
Un subprograma en C o C++.
Un subprograma o unidad en PASCAL.
4.1.- TCNICA DE DISEO ESTRUCTURADO

Se particiona el sistema en una jerarqua de mdulos o
subsistemas que pueden concebirse y construirse en forma
independiente (pueden verse como cajas negras

La idea es que otros mdulos slo necesiten saber QU hace
un determinado mdulo (su funcin) y no CMO lo hace.

Ventajas:

Simplifica la construccin, ya que las decisiones internas
son propias al mdulo y no dependen de otros mdulos.
Simplifica las pruebas como unidad independiente, ya que
se han reducido los efectos laterales y es ms fcil
identificar la fuente de error.
Simplifica la mantencin, especialmente si hay suficiente
independencia de otros mdulos.
5.- CRITERIOS DE DESCOMPOSICIN MODULAR

Las propiedades que deben preservarse al descomponer un
sistema en mdulos son:

Un mdulo es una unidad auto contenida.
Puede probarse en forma separada.
Puede conectarse con otros mdulos slo a travs de su
interfaz.

5.1.- Clausura

Cada mdulo debiera realizar una tarea que constituya
una unidad lgica, debiera ser lo ms conciso posible,
englobando un solo concepto.
5.2.- Independencia

Se busca maximizar la independencia inter mdulos en
base a un bajo acoplamiento y una alta cohesin.

El ACOPLAMIENTO es una medida de qu tan estrecha
es la conexin o interrelacin entre 2 mdulos.

La COHESIN es una medida de la interrelacin entre las
funciones que contienen un mdulo.
5.2.1.- Acoplamiento

Una conexin es una referencia a un objeto o proceso definido
en otro mdulo:

Al minimizar las conexiones entre mdulos, tambin se
minimizan las trayectorias a lo largo de las cuales se propagan
los errores y os cambios.

La propagacin de un error o de un cambio, a travs de una
conexin, provoca efectos de amplificacin, propiciando la
aparicin de nuevos errores.

Con conexiones simples es ms fcil entender mdulos sin
hacer referencia a otros.
Un alto grado de acoplamiento complica la mantencin de un
mdulo ya que debe ser corregido y probado con referencia a
los mdulos conectados

Ejemplo:

Si saca el mdulo X del sistema para hacerle mantencin,
qu otras partes del sistema podrn seguir funcionando?

Factores que afectan el grado de acoplamiento

El grado de acoplamiento de mide en tres dimensiones:

1.- Tamao de la conexin.
2.- Tipo de conexin.
3.- Qu es lo une se enva y recibe.
1.- Tamao de la conexin:

Entre menos datos se pasen entre mdulos, menor ser el
grado de acoplamiento

La medida es la cantidad de datos pasados cada vez que se usa
la interfaz

Se recomienda NO pasar los datos armados dentro de una
estructura, sino que pasarlos individualmente como
parmetros, para as aumentar la claridad.

Comnmente, una interfaz debiera tener 5 + (- 2) parmetros.
2.- Tipo de conexin:

Si un mdulo hace referencia a una variable que est definida
en otro mdulo, entonces el contenido de ese otro mdulo
deber tomarse en cuenta al hacer un cambio o corregir un
error.

Un sistema es ms simple si sus mdulos pueden usarse sin
necesidad de conocer su interior.


3.- Qu es lo que se comunica:

Los mdulos por lo menos debern pasarse datos entre s para
que formen parte de un mismo sistema

Cuando se pasa informacin de control de un mdulo a otro
(switch, flags, etc.) se agrega complejidad al sistema

Siempre existir una estructura alterna que elimine esa
complejidad.


Caracterizacin de las comunicaciones. En orden creciente de
fuente de problemas

Acoplamiento por datos

Es inevitable pero controlable si se da a travs de un nmero
mnimo de parmetros en que se pasan tipos de datos bsicos y
no estructuras complejas o registros

Ejemplo


CALCULO DE
LA FACTURA
CALCULO DEL
CREDITO
Monto
Plazo
Valor
Acoplamiento por registros

Se da cuando dos o ms comparten registros de datos entre s.

Puede darse conexiones entre mdulos que de otra forma no
tendran relacin entre s.

Ejemplo:
A travs de los campos de un registro compartido.

La mantencin del registro debe hacerse en consideracin a
todos los mdulos que lo comparten.
Adems, este acoplamiento puede exponer ms datos que los
necesarios a un mdulo, con posibles consecuencias negativas.


Acoplamiento por control

Se da cuando un mdulo intenta alterar el control de la lgica
de otro mdulo.
es un tipo de acoplamiento potencialmente problemtico.
Suele darse a travs de switches o flags de control.
En estos casos, el mdulo llamado no es visto como una caja
negra sino que parte de su funcionamiento interno se hace
visible y modificable.

COBOL: Perform A through B Varying ...until

(ALTER: excomulgado y proscrito)

Acoplamiento por reas de datos comunes

Se da cuando dos mdulos hacen referencia a una misma zona de
datos

Problemas:

Los datos no se aislan en torno a la funcin que los utiliza sino que
son susceptibles de ser alterados por todas las partes que los
visualizan.
Las reas de datos comunes son susceptibles de ser mal utilizadas
durante la programacin.

Ejemplo: Definir variables globales de propsito mltiple como
switch-1 o Flag-1 para almacenar datos intermedios de funciones
totalmente ajenas entre s.

Los programas con grandes reas de datos comunes son ms
difciles de mantener, ya que es necesario distinguir que dato se
utiliza porqu mdulo
5.2.2.- cohesin

Medida de la interrelacin entre las funciones que contiene un
mdulo, o bien la medida de la fuerza de la asociacin
funcional entre los elementos de un mdulo (instruccin, grupo
de instrucciones o llamadas a otros mdulos)

Se desea que los mdulos tengan ALTA cohesin.

La cohesin es complementaria al acoplamiento y tambin
determina la manera en que se particionan los mdulos y su
nivel de interdependencia.
Escala de cohesin, de peor a mejor o de menor a mayor.

a) Cohesin Coincidental

Los elementos del mdulo contribuyen a actividades que no estn
relacionadas entre s.
Se da cuando se pregunta por qu un grupo de instrucciones estn
en un programa y la respuesta es: por que tenan que estar en
algn lugar

Ejemplo Modulo DeTodoUnPoco
Listar errores
Llenar formularios
Listar cambios
Ordenar resultados
Cambiar Fecha

Para realizar alguna de estas funciones, comnmente se utiliza
algn flag o switch, es decir, se provoca acoplamiento por control.
b) Cohesin Temporal

Estos mdulos se caracterizan porque sus elementos se
relacionan con actividades relacionadas en el tiempo

Normalmente, todos sus elementos se ejecutan en cada llamada
al mdulo.

Ejemplo Modulo TodoDeUnViaje
Abrir Archivo Maestro
Poner contador-maestro en cero
Abrir archivo Cambios
Poner Contador-maestro en cero
Abrir archivo Errores
Poner Contador-maestro en cero

Tambin se utilizan flags de control para ocupar alguna de estas
funciones, especialmente si alguna o varias de ellas se deben
reutilizar en otro momento del proceso



Los siguientes tipos de cohesin son considerablemente
mas fuertes que las anteriores:

Cohesin procedural.
Cohesin por comunicacin.
Cohesin secuencial.
Cohesin funcional.




Cohesin Procedural

Los elementos participan de actividades diferentes y posiblemente
no relacionadas, en las cuales el control fluye de una actividad a
la siguiente.

Lo que relaciona los componentes es el orden de ejecucin y no
el hecho de ser elementos funcionalmente relacionados.

Ejemplo Modulo UnoTrasOtro
Mientras existan datos
Leer orden
procesar orden

Cohesin Por Comunicacin

Los elementos del mdulo se refieren a los mismos datos de
entrada y salida.

Ejemplo: Produccin de grficos o de informes a partir de los
mismos datos de entrada y salida.

Cohesin secuencial

Ocurre cuando la salida de un elemento es usada como entrada
para el siguiente elemento.

Ejemplo leer y editar datos, crear y almacenar registros, resumir e
imprimir resultados.

Modulo Secuencia
leer datos cliente; validar datos del cliente; Imprimir errores
Cohesin Funcional

Una funcin describe la transformacin de datos de entrada en
datos de salida

Si todos los elementos de un mdulo contribuyen a un mismo
objetivo posiblemente el mdulo est ligado funcionalmente.
Todos los elementos del mdulo son esenciales para realizar la
funcin del mdulo.

Una tcnica til para saber si un mdulo tiene cohesin funcional
es describir su funcin y examinar la oracin resultante.

Si la oracin resultante contiene ms de un verbo probablemente
el mdulo desempee ms de una funcin.
Si tiene palabras que tengan que ver con tiempo (primero,
siguiente, cuando, inicio, etc) probablemente el mdulo tenga
cohesin secuencial o temporal.

Si el predicado no contiene un solo objeto especfico,
probablemente hay cohesin lgica.

Palabras como inicializar, limpiar, etc. Implican cohesin
temporal.

Los mdulos con cohesin funcional siempre pueden describirse
en trminos de sus elementos utilizando una oracin.
6.- DISEO DE LA INTERFAZ ENTRE MDULOS

1.- Minimalidad en la Interfaz

La interfaz entre 2 mdulos es el conjunto de supuestos que
cada uno puede hacer del otro

Ejemplo: supuestos acerca de los datos que se usan.

Las interfaces debieran ser lo ms simples posibles, con un
mnimo de parmetros.
2.- Independencia de la interfaz

Un mdulo debiera poder reemplazarse por otro ofrezca la
misma definicin de la interfaz, sin producir efectos nuevos en
el resto del sistema.

3.- Nmero de Parmetros

El nmero de otros mdulos que debe importar un cierto
mdulo debe ser considerado.

Un nmero grande de parmetros puede indicar que el mdulo
debe realizar muchas actividades de coordinacin y decisin.

Si los parmetros son pocos, es posible que se requiera una
mayor descomposicin del problema.
IV METRICAS DE DISEO

1.- INTRODUCCIN

Durante el diseo se registra.
Mdulos: cantidad.
Defectos: Nmero y tipo durante inspecciones; costo de repararlos.
Fuerza de trabajo: nmero y tipo de personas requeridas en cada
mdulo; tiempo requerido.

PRIMERA APROXIMACIN, en general, cada mdulo tiene entre 2 y
7 mdulos subordinados.
Si un mdulo tiene 1 solo subordinado es posible que se haya
extrado una funcin (importante o larga) del mdulo => baja
cohesin.

Si un mdulo tiene muchos subordinados, es posible que, en
esa etapa, el diseo haya sido efectuado hasta un nivel muy
bajo.

2.- ENFOQUE CUANTITATIVO

Utilizacin de herramientas para analizar diseos:

Premisa: en un buen diseo las unidades individuales estn
aisladas unas de otras.

Por lo tanto:

Se considera la modularidad y el acoplamiento como bases de
un sistema de mtricas de complejidad de diseo.

V.- DISEO ORIENTADO A OBJETOS

Objeto
Dentro del software orientado a objeto, un objeto es cualquier
cosa, real o abstracta, acerca de la cual almacenamos datos y
los mtodos que controlan dichos datos.

Un objeto puede estar compuesto por otros objetos. Estos
ltimos a su vez tambin pueden estar compuestos por otros
objetos. Esta intrincada estructura es la que permite construir
objetos muy complejos.
Tipo de Objeto

Los conceptos que poseemos se aplican a tipos determinados
de objetos. Por ejemplo, empleado se aplica a los objetos que
son personas empleadas por alguna organizacin. Algunas
instancias de empleado podran ser Juan Prez, Jos Martnez,
etc. En el anlisis orientado a objetos, estos conceptos se
llaman tipos de objetos; las instancias se llaman objetos.

As, un tipo de objeto es una categora de objeto, mientras
que un objeto es una instancia de un tipo de objeto.
Mtodos

Los mtodos especifican la forma en que se controlan los
datos de un objeto. Los mtodos en un tipo de objeto slo
hacen referencia a la estructura de datos de ese tipo de
objeto. No deben tener acceso directo a las estructuras de
datos de otros objetos. Para utilizar la estructura de datos
de otro objeto, deben enviar un mensaje a ste. El tipo de
objeto empaca juntos los tipos de datos y su
comportamiento.

Un objeto entonces es una cosa cuyas propiedades estn
representadas por tipos de datos y su comportamiento por
mtodos.
Encapsulado

El encapsulado oculta los detalles de su implantacin interna a
los usuarios de un objeto. Los usuarios se dan cuenta de las
operaciones que puede solicitar del objeto, pero desconocen
los detalles de cmo se lleva a cabo la operacin. Todos los
detalles especficos de los datos del objeto y la codificacin de
sus operaciones estn fuera del alcance del usuario.

As, encapsulado es el resultado (o acto) de ocultar los detalles
de implantacin de un objeto respecto de su usuario.

El encapsulado, al separar el comportamiento del objeto de su
implantacin, permite la modificacin de sta sin que se
tengan que modificar las aplicaciones que lo utilizan.
Mensajes

Para que un objeto haga algo, le enviamos una solicitud.
Esta hace que se produzca una operacin. La operacin
ejecuta el mtodo apropiado y, de manera opcional,
produce una respuesta. El mensaje que constituye la
solicitud contiene el nombre del objeto, el nombre de una
operacin y, a veces, un grupo de parmetros.

Los objetos pueden ser muy complejos, puesto que pueden
contener muchos subobjetos, stos a su vez pueden
contener otros, etc. La persona que utilice el objeto no tiene
que conocer su complejidad interna, sino la forma de
comunicarse con l y la forma en que responde.
Clase

El trmino clase se refiere a la implantacin en software de
un tipo de objeto.

El tipo de objeto es una nocin de concepto. Especifica una
familia de objetos sin estipular la forma en que se
implanten. Los tipos de objetos se especifican durante el
anlisis OO.

As, una clase es una implantacin de un tipo de objeto.
Especifica una estructura de datos y los mtodos operativos
permisibles que se aplican a cada uno de sus objetos.

Herencia
Un tipo de objeto de alto nivel puede especializarse en tipos
de objeto de bajo nivel. Un tipo de objeto puede tener
subtipos. Por ejemplo, el tipo de objeto persona puede
tener subtipos estudiante y empleado. A su vez, el tipo de
objeto estudiante puede tener como subtipo estudiante de
pregrado y estudiante de postgrado, mientras que
empleado puede tener como subtipo a acadmico y
administrativo. Existe de este modo una jerarqua de tipos,
subtipos, subsubtipos, etc.

Una clase implanta el tipo de objeto. Una subclase hereda
propiedades de su clase padre; una sub-subclase hereda
propiedades de las subclases; etc. Una subclase puede
heredar la estructura de datos y los mtodos, o algunos de
los mtodos, de su superclase. Tambin tiene sus mtodos
e incluso tipos de datos propios.