Category Archives: Arquitectura

Patrones de Diseño Arquitectónicos de Programación. (Por Raúl Ivan)

Todos en alguna ocasión hemos escuchado el término “patrón de diseño” pero ¿Qué es un patrón de diseño?, ¿Para qué nos sirve?, pues bien a continuación la respuesta a estas y más preguntas sobre los patrones de diseño.Los patrones de diseño pretenden:
  • Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
  • Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
  • Formalizar un vocabulario común entre diseñadores.
  • Estandarizar el modo en que se realiza el diseño.
  • Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

Aunque si bien los patrones de diseño son muy útiles, no es obligatorio utilizarlos, solo es aconsejable en el caso de tener el mismo problema o uno similar al que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable.

Ya sabemos para que nos sirven pero, ¿Qué es un “Patrón”?

Un “patrón” ha sido definido como “una idea que ha sido útil en un contexto práctico y probablemente será útil en otros.” [M.Fowler, "Analysis Patterns - Reusable Object Models, Addison Wesley, ISBN 0-201-89542-0].

Ahora bien un “patrón de diseño” se define como: La base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Varios formatos diferentes se usan en la literatura para describir los patrones, y no hay un formato único que haya logrado la aceptación total. Sin embargo, existe un amplio acuerdo sobre los tipos de cosas que un patrón debe contener. Las cuales son:

  • Nombre: Una significativa y memorable forma de referirse al patrón, por lo general una sola palabra o frase corta.
  • Problema: Una descripción del problema indicando la intención de aplicar el patrón – los objetivos previstos  que deben alcanzarse en el contexto (tal vez con alguna indicación de sus prioridades).
  • Las condiciones de contexto: Las condiciones previas bajo las cuales  el patrón se aplica – una descripción del estado inicial antes de que el patrón sea aplicado.
  • Fuerzas: Una descripción de las fuerzas y limitaciones, cómo interactúan entre sí y con los objetivos previstos. La descripción debe aclarar las complejidades del problema y hacer explícito el tipo de compensaciones que deben ser considerados. (La necesidad de tales concesiones es lo que normalmente hace al problema difícil, y genera la necesidad del patrón) La noción de “fuerza” es igual en muchos aspectos a las “cualidades” que los arquitectos buscan optimizar, y las preocupaciones que tratan de abordar, en el diseño de arquitecturas (sistemas)
    • Por ejemplo:
      • Seguridad, robustez, fiabilidad, tolerancia a fallas.
      • Administración.
      • Eficiencia,  rendimiento, requisitos de ancho de banda, utilización del espacio.
      • Escalabilidad de crecimiento (incremento en la demanda).
      • Que sea extensible, mantenimiento.
      • Modularidad, independencia, reutilización, portabilidad.
      • Exhaustivo y correcto.
      • Facilidad de construcción.
      • Facilidad de uso.
  • Solución: Una descripción, utilizando texto y / o gráficos, de cómo lograr los objetivos previstos. La descripción debe identificar la estructura estática, tanto de la solución como de su  comportamiento dinámico – la gente y los actores computacionales, y sus colaboraciones. La descripción puede incluir directrices para la aplicación de la solución. Variantes o especializaciones de la solución también puede ser descritos.
  • Contexto Resultante: Las condiciones posteriores después de que el modelo ha sido aplicado. La aplicación de la solución requiere normalmente el intercambio entre las fuerzas de la competencia. Este elemento describe las fuerzas que se han resuelto y cómo, y cuales siguen sin resolverse. También puede indicar otros patrones que puedan ser aplicables en el nuevo contexto.
  • Ejemplos: Una o más aplicaciones de ejemplo del patrón que ilustran cada uno de los otros elementos: un problema específico, el contexto, y un conjunto de fuerzas, cómo se aplica el patrón, y el contexto resultante.
  • Justificación: Una explicación o justificación de la estructura en su conjunto, o de los componentes individuales dentro de ella, lo que indica cómo el modelo realmente funciona,  – ¿Cómo y por que las fuerzas trabajan para lograr los objetivos deseados?,  y por qué es “bueno”. El elemento  solución de un patrón describe la estructura externa y el comportamiento de la solución.
  • Patrones relacionados: Las relaciones entre este modelo y otros. Estos pueden ser los patrones predecesor, cuyos contextos resultante corresponden al contexto inicial de éste, o los patrones sucesor, cuyos contextos iniciales corresponden los resultantes de éste, o modelos alternativos, que describen una solución diferente para el mismo problema, pero en virtud de las diferentes fuerzas, o patrones de cooperación, que pueden / deben aplicarse conjuntamente con este patrón.
  • Usos conocidos: Las aplicaciones conocidas del patrón dentro de los sistemas existentes, verificando que el patrón efectivamente describe una solución probada a un problema recurrente. Estos también pueden servir como ejemplos.

Los patrones también pueden comenzar con un resumen proporciona una visión general del modelo y que indica los tipos de problemas que aborda.

Aunque los patrones de diseño han sido el foco de interés generalizado en la industria de software por varios años, especialmente en los modelos orientados a objetos, es sólo recientemente que ha habido un interés creciente en los patrones de la arquitectura.

La documentación técnica relativa a este ámbito es complicada por el hecho de que muchas personas en el campo del software utilizan el término “arquitectura” para referirse a software, y muchos patrones descritos como “los patrones de la arquitectura” son patrones de software de alto nivel de diseño. Esto simplemente hace que sea aún más importante para ser más precisos en el uso de la terminología.

El término “patrón de diseño” se usa a menudo para referirse a cualquier patrón que se ocupa de cuestiones de arquitectura de software, diseño, programación o ejecución. En el libro  Pattern-Oriented Software Architecture: A System of Patterns , por F. Buschmann, R. Meunier, H. Rohnert, P.Sommerlad, and M. Stal, John Wiley and Sons, 1996, ISBN 0-471-95869-7, los autores definen estos tres tipos de patrones de la siguiente manera:

  • Un patrón arquitectónico expresa una organización estructural fundamental o esquema para los sistemas de software. Proporciona un conjunto de subsistemas predefinidos, especifica sus responsabilidades, e incluye las normas y directrices para la organización de las relaciones entre ellos.
  • Un patrón de diseño proporciona un esquema para refinar los subsistemas o componentes de un sistema de software, o las relaciones entre ellos. En él se describe comúnmente la estructura de comunicación de los componentes que resuelve un problema de diseño general, en un contexto particular.
  • Un Idioma es un patrón de bajo nivel específico para un lenguaje de programación. Un idioma se describe cómo implementar aspectos particulares de los componentes o las relaciones entre ellos utilizando las características del lenguaje dado.

Estas distinciones son útiles, pero es importante señalar que “los patrones arquitectónicos” en este contexto sigue se refiere exclusivamente a la arquitectura de software.

En el siguiente post de la serie: Principales patrones GoF