Principios de

Diseo de software

Qu es un principio?
Es una ley o regla que se cumple o
debe seguirse con cierto propsito

Abstraccin y refinamiento
Se trata de ocultar los detalles, es decir no centrarse en detalles concretos del
diseo, sino hacer un esquema visual a alto nivel. De esta manera tenemos una
visin general de todo, tambin se utiliza en los microdiseos.
La tctica del refinamiento es justamente lo contrario, es decir, centrarse en
los detalles del modelo abstracto dado anteriormente.

La tcnica de abstraccin se complementa con la de refinamiento, es decir,

primero se hace una abstraccin del problema y una vez que tenemos un
esquema abstracto usamos la tcnica del refinamiento para centrarnos en
detalles concretos.

Niveles de abstraccin
Alto nivel
Bajo nivel

Menos detalle

Ms detalle

Modularidad
Se basa en el principio de "Divide y Vencers", que consiste un dividir el
problema en varios problemas ms pequeos para que el costo de
resolverlos sea menor.
Consiste en dividir un sistema en varios subsistemas, cada uno de estos
resuelve un problema pequeito y luego se vuelven a unir.
Esta tcnica se puede aplicar a distintas escalas. Esto nos plantea una
pregunta: Cmo lo divido? Pues no hay una forma exacta para hacer la
divisin sino que depende de cada problema en particular.

Modularidad

En esta grfica podemos observar el costo de dividir en mdulos frente al costo de unir esos
mdulos. Si dividimos en muchos mdulos el costo disminuye, pero aumenta la integracin de los
mdulos. Hay que buscar la justa medida que est comprendida en la regin de costos mnimos.

Acoplamiento
Medida cualitativa del grado en el que un mdulo esta conectado a otros y el
mundo exterior. El acoplamiento hay que mantenerlo bajo para que cada
mdulo sea lo ms independiente posible. De esta forma si un mdulo cambia,
su cambio afecta lo menos posible al resto de sistema. Nunca se puede dar el
acoplamiento 0.
El acoplamiento es un principio evolutivo, tenemos que ir controlndolo a
medida que se disea hay que estar evaluando el grado de acoplamiento para
conseguir que sea lo ms bajo posible.
No hay que intentar disminuir el acoplamiento a toda costa, sino que hay que
evaluar como hacerlo.

Cohesin
Es la medida cualitativa del grado en el que un mdulo se enfoca a una sola
cosa. Un mdulo hace cosas muy parecidas, la cohesin debe ser alta en cada
mdulo, se trata de conseguir mdulos muy cohesivos y que estn poco
acoplados. Para mejorar la cohesin lo mejor es dividir en subsistemas. Las
clases con muchos mtodos son poco cohesivas y habr que dividir.
La cohesin al igual que el acoplamiento es evolutiva, hay que ir evaluando a la
vez que se disea para aumentar la cohesin.
"Un elemento es altamente cohesivo si todos sus elementos trabajan juntos
para proporcionar algn comportamiento bien determinado"

A la cohesin y al acoplamiento se les denomina el Yin y el Yan de el diseo

software.

Refactorizacin
Es el proceso de cambiar un sistema de software de tal forma que no se altere el
comportamiento externo de su cdigo (diseo) y an as se mejora su estructura
interna".
La funcionalidad sigue siendo la misma pero mejora la estructura interna del
cdigo, es decir, mejorando la cohesin y disminuyendo el acoplamiento, pero
siempre hay que tener en cuenta que la funcionalidad no puede cambiar.
En lugar de aplicar la evaluacin de la cohesin y el acoplamiento al principio, se
hace cuando ya se tiene un poco de cdigo hecho. Existen catlogos de
refactorizacin (http://www.refactoring.com) que ayudan a llevar a cabo una
refactorizacin.

Reutilizacin
No hay que reinventar la rueda, consiste en utilizar cdigo que se sabe que
funciona bien, en vez de hacerlo nosotros de nuevo. Buscar qu hay que
resuelva mi problema y adaptarlo a mi caso.
-El diseo no nace, se hace
La reutilizacin puede ser a dos niveles: por un lado poder reutilizar cdigo en
forma de componente (por ejemplo usar una base de datos, servicios,
bibliotecas, frameworks); por otro lado esta la reutilizacin de conocimiento que
me da ideas de como hacer las cosas.

Descomposicin:

Axiomas fundamentals de diseo

Separacin de responsabilidades:
Un problema complejo puede ser resuelto de mejor forma expresado por la solucin
de problemas independientes cada uno ms pequeo

Comprensin
La mente no puede manipular fcilmente ms de 7 cosas al mismo tiempo

Simplificar, simplificar, simplificar

La solucin ms simple es usualmente la ms correcta Rechtin 1991

Descomposicin :
Principios
Alta cohesin es mejor
No implemente mltiples responsabilidades
no relacionadas en un mismo lugar
(Sub) Sistemas monolticos son DIFCILES de entender y sobre todo de
MANTENER
Cohesin: es la medida donde un componente se dedica a realizar solo la
tarea para la cual fue creado delegando las tareas complementarias a
otros componentes.

Descomposicin :
Principios
Una entidad con baja cohesin:
Tiene/Implementa responsabilidades no
relacionadas.
Son difciles de entender, reutilizar y mantener.
Son frgiles (con probabilidades de verse afectadas
ante cambios).

Descomposicin :
Principios
Bajo acoplamiento es mejor
Implemente una responsabilidad en un nico lugar

El acoplamiento es la medida donde los cambios de

un componente tienden a implicar la necesidad de
cambios en otros componentes.
Evite las estructuras spaghetti

Descomposicin :
Principios
Una entidad con alto acoplamiento:
Se resiente de los cambios en los
elementos relacionados.
Son difciles de entender de manera
aislada.
Difciles de reutilizar.

Descomposicin : Tcnicas
Divide y vencers
Divida el problema en partes
pequeas, ms manejables y
entendibles

Separacin de
responsabilidades
Asigne distintas responsabilidades a
partes separadas del sistema

Descomposicin :
Tcnicas
Ocultamiento de informacin
Esconda los detalles detrs de las interfaces, las
entraas del componente son secretas y no deben estar
disponibles desde el exterior
La meta es proteger los clientes del componente
evitndoles conocer detalles irrelevantes y
Evitar que conozcan cambios internos del componente

Descomposicin :
Tcnicas
Encapsulamiento
Solo permita accesos a travs de las interfaces, los
clientes deben depender de las especificaciones
ms no de las implementaciones

Descomposicin :
Tcnicas
Contratos
Si se desea hacer cumplir el encapsulamiento se deben proveer contratos
de interfaz bien definidos, completos y sobre todo accesibles

Factoring
Factorice los elementos comunes para simplificar el diseo y aumentar
la reutilizacin

Abstraccin

Lineamientos de identificacin
No ms hoja de trabajo en blanco!
Inicie con lo que tiene a disposicin
Componentes identificados previamente
Mantenga un catlogo de componentes a la vista

Identifique componentes candidatos de

alto nivel que sern parte de la solucin

Lineamientos de identificacin
Aplique principios de diseo
Cohesin interna alta y bajo acoplamiento
Agrupe piezas de funcionalidad fuertemente relacionadas
Considere el uso de patrones de diseo (tema que ser visto
ms adelante en el curso)
Considere ubicar juntas las piezas sometidas a cambios
constantes

Lineamientos de identificacin
Si puede cree prototipos no funcionales
Haga modelos
Evale alternativas (cun bien
se cubren los requerimientos)
Mantenga actualizado su inventario de componentes

Validacin: arquitectura conceptual

Evale los componentes segn los siguientes criterios:
Claridad
Cada componente tiene claramente una y solo una responsabilidad definida?

Acoplamiento
Existen componentes con un nmero sorprendente de interacciones?

Cobertura
Todas las funcionalidades han sido asignadas a los componentes?

Referencias
Material de profesor Luis Chavarra

Principios de
Diseo de software