Conceptos básicos de Diseño de Software

Diseño de Software es el es el conjunto de actividades en el que los requerimientos de un producto son transformados, a través de una serie de decisiones, en unas abstracciones que facilitarán al desarrollador la programación y pruebas del software. Estas abstracciones son el diseño y deben incluir,como mínimo:

  • Las Partes principales del producto
  • Cómo es la interacción entre las partes
  • Cómo deben ensamblarse las partes para producir el producto final

Estas abstracciones deben poder ser, por un lado, evaluadas:

  1. contra los requerimientos para ver si se podrán satisfacer en el código.
  2. Evaluadas contra criterios como acoplamiento, cohesión, separación de responsabilidades. Siempre se debe poder justificar una decisión de diseño.

Por otro lado, deben:

  1. estar expresadas en términos no ambiguos y
  2. ser una guía clara para la implementación del producto, esto es, debe producir una especificación precisa y completa de cómo el producto será construido

Los retos del Diseño de Software

La gran mayoría de los proyectos de desarrollo de software son proyectos de una gran incertidumbre en cuanto a muchos factores: los requerimientos, los usuarios, la tecnología, el equipo de desarrollo, etc. Estos proyectos son proyectos de construcción colectiva de conocimiento donde gradualmente se va disminuyendo la incertidumbre. Estos procesos graduales (iterativos, cíclicos) son más complejos que aquellos donde las etapas y los resultados de cada una son claros. Los proyectos de software serían más fáciles si se pudiera tener completa la especificación de los requerimientos en la etapa de análisis y luego un completo diseño en la etapa de diseño y luego la programación y las pruebas sin tener que volver atrás a cuestionar los requerimientos o los diseños. Sin embargo, esto muy rara vez es posible. Lo usual es que los requerimientos sean cambiantes y que estos cambios afecten el diseño o que una vez en la programación descubramos que el diseño no era el adecuado o que la tecnología particular no soporta alguna idea de diseño que se tenía.

Algunos de los retos del Diseño de Software los podemos resumir de la siguiente manera:

  1. Los Requerimientos las definidos o incompletos o cambiantes: Esto hará que el los diseños se deban estar a su vez cambiando, adaptando, manteniendo
  2. Los Diseños no siempre se pueden separar de las tecnologías en las que se implementará la aplicación
  3. La evaluación del diseño, la justificación.
  4. La expresión del diseño (las abstracciones)
  5. La evolución del diseño

Diseño de Software evolutivo

De acuerdo con Martin Fowler en Is Design Dead?, el diseño evolutivo significa que el diseño del sistema crece a medida que el sistema se implementa. El diseño es parte de los procesos de programación y a medida que el programa se desarrolla el diseño sufre cambios. De igual forma, a medida que los requerimientos cambian o se agregan nuevos el diseño sufre cambios. Del mismo artículo, el diseño evolutivo puede fácilmente convertirse en un desastre al convertirse en la agregación de un montón de decisiones no muy justificadas, no muy estudiadas, en últimas sin diseño!.

El proyecto se convierte en la pesadilla "codificar y corregir".

Para evitar que esto suceda, la estrategia principal consiste en que al terminar un ciclo o iteración, se debe hacer una reconstrucción del diseño a partir del código producido, analizar y hacer refactoring en caso de que sea necesario.

Cómo expresar el diseño

“The hard part about object-oriented design is decomposing a system into objects. The task is difficult because many factors come into play: encapsulation, granularity, dependency, flexibility, performance, evolution, reusability, and on and on. They all influence decomposition, often in conflicting ways.” Design Patterns. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Addison Wesley. 1994. Página 11

El resultado del diseño, dependiendo de la metodología utilizada, puede expresarse a través de distintos artefactos: diagrama de clases, de secuencia, de actividades, de procesos, especificaciones formales, simulaciones, etc. Independientemente de la metodología necesitamos un mecanismos de refinamiento, es decir, una visión general del sistema que se va a construir donde podamos definir el sistema en algún conjunto de partes y luego, por cada parte, un diseño más detallado donde podamos expresar soluciones más concretas y específicas a algún problema particular. La visión global, se llama la arquitectura del software.

Patrones básicos de asignación de responsabilidades

Arquitectura de Software

La arquitectura de Sw debe ser un mecanismo de abstracción que permita razonar sobre el sistema que se va a construir o que se va a cambiar (anticipar consecuencias). También debe ayudar a guiar el desarrollo:

  • Dividir trabajo
  • Identificar y evaluar riesgos
  • Determinar si se satisfacen los requerimientos y en especial los de Calidad

Hay muchas definiciones de Arquitectura de software que pueden encontrarse en la literatura y en particular las recopiladas en Definiciones de Arquitectua de sw. Entre ellas se encuentra la siguiente definición que tiene mucho que ver con nuestros elementos básicos de diseño:

”… Software Architecture is the process of reducing coupling and improving cohesion at every level of granularity and from every perspective.” John Carter. Tomado de: Definiciones de Arquitectua de sw.

Si necesitamos una definición de arquitectura que nos sirva para decidir cómo la expresamos podemos utilizar la siguiente:

La arquitectura de software de un sistema es el conjunto de estructuras/vistas necesarias para razonar sobre el sistema, cada una comprende elementos de software, relaciones entre ellos y propiedades de ambos. [Bass et al. Software Architecture Third edition 2012].

Otros Patrones de diseño

Inyección de dependencias, Fábricas

Referencias y Material complementario

  • Fowler Martin. Is Design Dead?
  • Humphrey Watts. Introduction to the Team Software Process. Addison Wesley. 2000. Capítulo 7
  • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns. Addison Wesley. 1994.

results matching ""

    No results matching ""