Principios de Diseño de software

¿Qué es un principio?

Es una ley o regla que se cumple o debe seguirse con cierto propósito

Abstracción y refinamiento

Se trata de ocultar los detalles, es decir no centrarse en detalles concretos del diseño, sino hacer un esquema visual a alto nivel. De esta manera tenemos una visión general de todo, también se utiliza en los microdiseños.

La táctica del refinamiento es justamente lo contrario, es decir, centrarse en los detalles del modelo abstracto dado anteriormente.

La técnica de abstracción se complementa con la de refinamiento, es decir, primero se hace una abstracción del problema y una vez que tenemos un esquema abstracto usamos la técnica del refinamiento para centrarnos en detalles concretos.

Niveles de abstracciónAlto nivel

Bajo nivel

Menos detalle Más detalle

Modularidad

Se basa en el principio de "Divide y Vencerás", que consiste un dividir el problema en varios problemas más pequeños para que el costo de resolverlos sea menor.

Consiste en dividir un sistema en varios subsistemas, cada uno de estos resuelve un problema pequeñito y luego se vuelven a unir.

Esta técnica se puede aplicar a distintas escalas. Esto nos plantea una pregunta: ¿Cómo lo divido? Pues no hay una forma exacta para hacer la división sino que depende de cada problema en particular.

Modularidad

En esta gráfica podemos observar el costo de dividir en módulos frente al costo de unir esos módulos. Si dividimos en muchos módulos el costo disminuye, pero aumenta la integración de los módulos. Hay que buscar la justa medida que está comprendida en la región de costos mínimos.

Acoplamiento

Medida cualitativa del grado en el que un módulo esta conectado a otros y el mundo exterior. El acoplamiento hay que mantenerlo bajo para que cada módulo sea lo más independiente posible. De esta forma si un módulo 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 controlándolo a medida que se diseña hay que estar evaluando el grado de acoplamiento para conseguir que sea lo más bajo posible.

No hay que intentar disminuir el acoplamiento a toda costa, sino que hay que evaluar como hacerlo.

CohesiónEs la medida cualitativa del grado en el que un módulo se enfoca a una sola cosa. Un módulo hace cosas muy parecidas, la cohesión debe ser alta en cada módulo, se trata de conseguir módulos muy cohesivos y que estén poco acoplados. Para mejorar la cohesión lo mejor es dividir en subsistemas. Las clases con muchos métodos son poco cohesivas y habrá que dividir.

La cohesión al igual que el acoplamiento es evolutiva, hay que ir evaluando a la vez que se diseña para aumentar la cohesión.

"Un elemento es altamente cohesivo si todos sus elementos trabajan juntos para proporcionar algún comportamiento bien determinado"

A la cohesión y al acoplamiento se les denomina el Yin y el Yan de el diseño software.

Refactorización

Es el proceso de cambiar un sistema de software de tal forma que no se altere el comportamiento externo de su código (diseño) y aún así se mejora su estructura interna".

La funcionalidad sigue siendo la misma pero mejora la estructura interna del código, es decir, mejorando la cohesión y disminuyendo el acoplamiento, pero siempre hay que tener en cuenta que la funcionalidad no puede cambiar.

En lugar de aplicar la evaluación de la cohesión y el acoplamiento al principio, se hace cuando ya se tiene un poco de código hecho. Existen catálogos de refactorización (http://www.refactoring.com) que ayudan a llevar a cabo una refactorización.

Reutilización

No hay que reinventar la rueda, consiste en utilizar código 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 diseño no nace, se hace

La reutilización puede ser a dos niveles: por un lado poder reutilizar código en forma de componente (por ejemplo usar una base de datos, servicios, bibliotecas, frameworks); por otro lado esta la reutilización de conocimiento que me da ideas de como hacer las cosas.

Descomposición: Axiomas fundamentals de diseño

◦Separación de responsabilidades:◦ Un problema complejo puede ser resuelto de mejor forma expresado por la solución

de problemas independientes cada uno más pequeño

◦Comprensión◦ La mente no puede manipular fácilmente más de 7 cosas al mismo tiempo

◦Simplificar, simplificar, simplificar◦ “La solución más simple es usualmente la más correcta” Rechtin 1991

Descomposición : Principios

Alta cohesión es mejor◦No implemente múltiples responsabilidades no relacionadas en un mismo lugar◦ (Sub) Sistemas monolíticos son DIFÍCILES de entender y sobre todo de

MANTENER

Cohesión: 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.

Descomposición : Principios

Una entidad con baja cohesión: ◦Tiene/Implementa responsabilidades no relacionadas.

◦Son difíciles de entender, reutilizar y mantener.◦Son frágiles (con probabilidades de verse afectadas ante cambios).

Descomposición : 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

Descomposición : Principios

Una entidad con alto acoplamiento:◦Se resiente de los cambios en los elementos relacionados.

◦Son difíciles de entender de manera aislada.

◦Difíciles de reutilizar.

Descomposición : Técnicas

Divide y vencerás◦Divida el problema en partes pequeñas, más manejables y entendibles

Separación de responsabilidades◦Asigne distintas responsabilidades a partes separadas del sistema

Descomposición : Técnicas

‘Ocultamiento’ de información◦Esconda los detalles detrás de las interfaces, las entrañas del componente son secretas y no deben estar disponibles desde el exterior

◦La meta es proteger los clientes del componente evitándoles conocer detalles irrelevantes y

◦Evitar que conozcan cambios internos del componente

Descomposición : Técnicas

Encapsulamiento◦ Solo permita accesos a través de las interfaces, los

clientes deben depender de las especificaciones más no de las implementaciones

Descomposición : Técnicas

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 diseño y aumentar

la reutilización

Abstracción

Lineamientos de identificación

No más hoja de trabajo en blanco!

Inicie con lo que tiene a disposición◦Componentes identificados previamente

◦ Mantenga un catálogo de componentes ‘a la vista’

Identifique componentes candidatos de alto nivel que serán parte de la solución

Lineamientos de identificación

Aplique principios de diseño◦ Cohesión interna alta y bajo acoplamiento

◦ Agrupe piezas de funcionalidad fuertemente relacionadas

◦ Considere el uso de patrones de diseño (tema que será visto más adelante en el curso)

◦ Considere ubicar juntas las piezas sometidas a cambios constantes

Lineamientos de identificación

Si puede cree prototipos no funcionales

Haga modelos

Evalúe alternativas (cuán bien se cubren los requerimientos)

Mantenga actualizado su inventario de componentes

Validación: arquitectura conceptual

Evalúe los componentes según los siguientes criterios:

◦Claridad◦ ¿Cada componente tiene claramente una y solo una responsabilidad definida?

◦Acoplamiento◦ ¿Existen componentes con un número sorprendente de interacciones?

◦Cobertura◦ ¿Todas las funcionalidades han sido asignadas a los componentes?

Referencias

Material de profesor Luis Chavarría

Principios de Diseño de software