Tema 6 - Principios de diseño

 

 

 

El Camino

 

 

Introduccion

 

Según M.A. Jackson (1975) "El comienzo de la sabiduría para un ingeniero de software es reconocer la direfencia entre hacer que un programa funcione y conseguir que lo haga del modo correcto".

 

Los principios de diseño son aplicables a todos los niveles del diseño del software, desde la arquitectura a la microarquitectura, además todos estos principios se relacionan entre si.

  

Principios de diseño

 

Los principios de diseño a estudiar son los siguientes:

-Abstracción y refinamiento.

-Modularidad.

-Variaciones protegidas.

-Acoplamiento.

-Cohesión.

-Refactorización

-Reutilización.

 

     1º) 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 tactica del refinamiento es justamente lo contrario, es decir, centrarse en los detalles del modelo abstracto dado anteriormente.

 

La técnica de abstración y refinamiento 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.

 

 

     2º)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 coste 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.

 

 

 

 

 

En la siguiente gráfica podemos observar el coste de dividir en módulos frente al coste de unir esos módulos. Si dividimos en muchos módulos el coste disminiye, pero aumenta la integración de los módulos. Hay que que buscar la justa medida que esta comprendida en la región de costes minimos.

 

 

     3º) VARIACIONES PROTEGIDAS: hay que tener claros dos conceptos: punto de variación y punto de evolución.

 

          *Punto de variación: es un requisito del sistema que tiene caracteristicas variables y puede cambiar, por tanto tengo que soportarlo en mi aplicación.

 

          *Punto de evolución: es cuando nosotros preveemos que se puede convertir en un punto de variación.

 

En el desarrollo del software todo lo que sea cambion es un problema, hay que prestar atención a estos puntos que cambián, la idea es proteger al sistema de los cambios en los puntos de variación y en los puntos de evolución.

Cuando detecte un punto de variación y/o punto de evolución tengo que diseñarlo de forma que los cambios que se produzcan en el sistema afectan a lo minimo posible.

 

David Parnas (1972) dijo: "...proponemos en lugar de eso (dividir en módulos) que uno comience con una lista de desiciones de diseño difíciles o con altas probabilidades de cambio. Cada módulo se diseña entonces para ocultar dichas desiciones a otros (módulos)..."

 

Para hacer estos se puede usar alguno de los siguientes métodos:

     -Encapsulación: por ejemplo lo que hacen las clases en Java, ocultan los atributos y solo mustran los métodos.

     -Interfaces: por ejemplo lo que es una interfaz en Java, una misma interfaz puede tener distintas implementaciones.

     -Datos externos: tener datos de configuración fuera de el sistema (ficheros de configuración...).

     -Ocultación de la estructura: un sistema no tiene necesidad de conocer los otros subsistemas, para ello estan los interfaces internas.

 

¡CUIDADO! El coste de diseñar la protección de un punto de variación o de evolución es superior que resolver un diseño simple. No hay que usar la sobreingeniería.

 

  

     4º)ACOPLAMIENTO: medida cualitativa del grado en el que un módulo esta conectado a otros y el mundo exterior. El acoplamiento hay que mantenerlos 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 controlandolo a medida que se diseña hay que estar evaluando el grado de acoplamiento para conseguir que sea lo más bajo posible

 

Hay que ser cautelar, es decir, no hay que intentar disminuir el acoplamiento a toda costa, sino que hay que evaluar como hacerlo.

 

  

     5º)COHESIÓN: es 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 esten 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 trabajar 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.

 

  

     6º)REFACTORIZACIÓN: según Martin Fowler (1999) "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 evalucaión de la cohesión y el acoplamiento al principio, lo hago cuando ya tengo un poco de código hecho. Existen cátalogos de refactorización (http://www.refactoring.com) que nos puede ayudar a llevar a cabo una refactorización.

 

  

     7º)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 que hay que resuelva mi problema y adaptarlo a mi caso.

 

   -El diseño no nace, se hace

   -¿Qué diferencia hay entre los diseñadores expertos y nosotros? Los diseñadores expertos han hecho las cosas muchas veces y las hacen bien porque tienen experiencia en hacerlas, en cambio nosotros no tenemos esa experiencia.

 

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 como Idioms.

 

   *Componentes, Servicion y Bibliotecas: tienen una funcionalidad empaquetada y diseñada para ser reutilizada. TAWs, manejo de periféricos, gráficos, gestión de documentos XML tienen funcionalidad lista para ser utilizada a través de una interfaz bien definida. Tienes una interfaz bajo/local en el diseño de la aplicación cliente. Una cuestión clave en el diseño de estos elementos reside en conseguir facilidad de uso para el máximo número de escenas sin complicar la interfaz ni reducir el rendimiento.

 

   *Frameworks: conjunto de clases parcialmente funcional (no es una aplicación) para un dominio de aplicación, es algo cuya funcionalidad no esta definida, un frameworks no tiene un ejecutable, le falta algo de la aplicación, por ejemplo. Junit es un frameworks. Los frameworks tienen una gran influencia en el diseño de la aplicación del cliente.

Esta basado en el principio de Hollywood "Don't call us, we'll call you!" que significa "No nos llames, nosotros te llamaremos".

 

-Ventajas del framework: reutilización de diseño y código,hay que tener en cuenta la experiencia del diseñador del framework, se reducen los costes de producción porque ya esta hecho.

-Inconvenientes: encontrar el frameworks apropiada para nuesto caso, usar más de un frameworks al mismo tiempo (temas de incompatibilidad entre los frameworks usados), son dificiles de construir y de aprender a usar.

 

   *Idioms: una forma de utilizar un Lenguaje de Programación, patrón de bajo nivel, es especifico de un Lenguaje de Programación. Describen soluciones a problemas de implementación de un determinado Lenguaje de Programación por ejemplo la gestión de memorias en C++.

   *Antipatrones: se aprede de los errores más que de los aciertos, nos dan recetas de cosas que no hay que hacer.

   *Patrones de diseño: "Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno. También describe el núcleo de la solución al problema, de forma que puede utilizar un millón de veces sin hacer dos veces lo mismo".

   *Patrones arquitectónicos: definen la estructura general del software, indican las relaciones entre los subsistemas y los componentes del software y definen las reglas para especificar las relaciones entre los elementos de la arquitectura.

 

  

Conclusiones

 

-Los principios de diseño nos porporcionan las claves para desarrollar la actividad de diseño.

 

  

Bibliografia

 

Ingeniería del Software. Un enfoquepráctico. Roger S. Pressman. Mc GrawHill (6ªed.) [Capítulo 9].

Ingeniería del Software. Ian Sommerville. Pearson Addison Wesley (7ªed.) [Capítulo 11].

UML y Patrones, Craig Larman(1999).