PATRONES

LOS PATRONES (PATTERNS) PUEDEN CONSIDERARSE COMO UNOS ENTIDADES DESTINADAS A SOPORTAR, DOCUMENTAR Y TRANSMITIR LA EXPERIENCIA EN LA RESOLUCION DE PROBLEMAS TIPO Q PUEDEN APARESER EN DIFERENTES CONTEXTOS. CUANDO EL CONTEXTO DE LOS DNOMINADOS PATRONES SOFTWARE. EL IBJETIVO Q SE PERSIGUE CON LOS PATRONES DEL MUNDO DEL DESARROLLO DEL SFTWARE ES ESTABLECER UN CATAGOLO DE REFERENCIA PARA AYUDAR A LOS INGENIEROS DE SOFTWARE A SOLUCIONAR O A OFRONTAR PROBLEMAS DE INGENIERIA DEL SOFTWARE, DANDO LUGAR A UN LENGUAJE COMUN EN EL Q COMUNICAR LA EXPERIENCIA Y LOS TRUCOS ENTORNO A DOCHOS PROBLEMAS Y A SU SOLUCION.

El concepto de patrón como elemento reutilizable de experiencia y conocimiento ha calado profundamente en el área del desarrollo de aplicaciones software, teniendo su caldo de cultivo más activo en la comunidad de orientación a objeto.
De este hecho se deriva el término patrón software y más concretamente el de patrón de diseño para hacer referencia al uso de patrones en el Diseño Orientado a Objeto (DOO). La serie de artículos, que sobre patrones software se inicia con el presente trabajo, tiene como objetivo familiarizar al lector con el uso de patrones en el diseño de sus aplicaciones software, consiguiendo un mayor grado de fiabilidad y flexibilidad en sus diseños al reutilizar estructuras ya probadas en otros contextos, siendo además los sistemas software construidos más sencillos de comprender y mantener al estar documentados sobre la base de un conjunto de patrones ampliamente conocidos y
difundidos.

No obstante, antes de empezar a trabajar con los patrones en el campo del DOO, y de cara a evitar mal entendidos, mitos o creencias en panaceas que den soluciones a todos los males del software, se va a realizar una primera aproximación

1 a los patrones en la
que se va a explicar su origen, su evolución hacia el mundo del software, su significado, la terminología que introducen, así como un conjunto de referencias (tanto bibliográficas como direcciones web) que permitan a los lectores profundizar más en este interesante campo.

ORIGEN E HISTORIA DE LOS PATRONES
El concepto de patrón software, más concretamente el concepto de patrón de diseño, se hizo popular dentro del mundo del desarrollo del software en 1995 con la publicación del libro Design Patterns: Elements of Reusable Object-Oriented Software [12] cuyos autores son Erich Gamma, Richard Helm, Ralph Jonhson y John Vlissides (normalmente referenciados como la Banda de los Cuatro The Gang of Four o simplemente por GoF). Este libro presenta un conjunto de 23 patrones de diseño de software bajo el paradigma de la orientación a objeto, que van a suponer la aceptación definitiva del concepto de patrón de diseño en el mundo del software y el inicio de una importante comunidad de personas trabajando e investigando en esta área.

CONCEPTO INTUITIVO DE PATRON

Antes de entrar a definir de una forma más concreta lo qué es un patrón, puede ser interesante realizar una primera aproximación informal a este concepto con el fin de clarificar más su significado en el mundo del software. Según el diccionario de la Real Academia Española un patrón es: «DECHADO Q SIRVE DE MUESTRA PARA SACAR OTRA CSA IGUAL», estando esta definición muy cercana a la idea que se persigue con los patrones software, donde los patrones, en lugar de servir como muestra física, sirven para almacenar y documentar soluciones recurrentes a problemas tipo.

Como ejemplo ilustrativo supóngase un problema típico que se repite en el diseño de bases de datos de bibliotecas, al intentar modelar la relación existente entre los libros y los ejemplares que existen de cada libro. Para solucionar este problema de modelado se puede establecer un sencillo patrón, como se muestra en la Figura 1. Este patrón puede ser reutilizado en todo diseño en el que intervengan ambas entidades.

DEFINICION DE PATRON DE SOFTWARE

Una vez que se ha realizado una primera aproximación al concepto de patrón software, es más sencillo comprender las diversas definiciones que de patrón aparecen en la literatura. Como sucede con la mayoría de los términos propios de la Ingeniería del
Software, no existe una definición estándar para el término patrón, así se pueden encontrar varias en la literatura, de las cuales se van a recoger algunas de las más representativas, aunque parafraseando a James Coplien se puede decir que: Alexander podría haber escrito una frase de definición de lo qué es un patrón, pero en su lugar él escribió un libro de 550 páginas para hacerlo porque el concepto es difícil .
Así, para Trigve Reenskaug, padre del método OOram, un patrón es una descripción en un formato fijo de cómo solucionar un cierto tipo de problemas [17]. Para Brad Appleton un patrón es una unidad de información instructiva con nombre que captura la estructura esencial y la comprensión de una familia de soluciones exitosas probadas para un problema recurrente que ocurre dentro de un cierto contexto y de un sistema de fuerzas [5]. Sin embargo, para James Coplien cada patrón es una regla constituida por tres partes, la cual expresa una relación entre un cierto contexto, un cierto sistema de fuerzas que ocurren repetidamente en ese contexto, y una cierta configuración software que permite a estas fuerzas resolverse así mismas [8].

La definición de James Coplien nos va a servir para introducir una serie de términos que configuran la terminología propia de los patrones. En primer lugar nos encontramos con el término SISTEMA DE FUERZAS, el cual hace referencia a que un problema se refiere a un conjunto de fuerzas. La noción de fuerza generaliza el tipo de criterios que los ingenieros del software utilizan para justificar los diseños y las implementaciones. En el caso de los patrones, éstos casan con conjuntos de objetivos y restricciones que se encuentran en el desarrollo de cada elemento que se vaya a crear. Estas fuerzas son grandes, difíciles de medir y conflictivas. También es interesante resaltar el término CONFIGURACION SOFTWARE en el sentido de un diseño en una forma canónica o un conjunto de reglas de diseño que alguien puede aplicar para solucionar las fuerzas del problema.Como se desprende de las definiciones anteriores, un patrón involucra una descripción general de una solución recurrente para un problema recurrente repleto de diferentes objetivos y restricciones. Pero un patrón hace algo más que identificar una solución, explica el porqué se necesita la solución. Debe tenerse presente que no cualquier solución, algoritmo, máxima de diseño o heurística constituye un patrón. Es más, aunque algo parezca tener todos los ingredientes necesarios para ser un patrón, no será considerado como tal hasta que verifique ser un fenómeno recurrente (preferiblemente en al menos tres sistemas existentes; esto es lo que se denomina la regla de los tres)
.
Un patrón que se encuentra a la espera de ser considerado como tal se denomina protopatrón.
Es un buen criterio no denominar a nada patrón hasta que no haya sido sometido a algún tipo de examen o revisión por parte de otras personas. Para James Coplien [8] un buen patrón debe cumplir los siguientes requisitos:
·

Debe solucionar un problema:

Los patrones capturan soluciones, no sólo principios abstractos o estrategias.
·

Son conceptos probados:

Los patrones capturan soluciones que han sido probadas, no teorías o especulaciones.
·

La solución no es obvia:

La mayoría de las técnicas de resolución de problemas (tales como métodos de diseño) intentan derivar soluciones partiendo de principios básicos. Los mejores patrones generan una solución para un problema indirectamente, una aproximación necesaria para los problemas de diseño más complejos.
·

Describe una relación:

Los patrones no deben describir módulos, sino que deben describir sistemas, estructuras o mecanismos más profundos.
·

El patrón debe tener un componente humano importante:

Todo software sirve para el confort humano o para la calidad de vida; los mejores patrones recurren explícitamente a la estética y a la utilidad.

COMPONENTES ESENCIALES DE UN PATRON DE SOFTWARE

Existen diferentes formatos para describir los patrones, sin embargo hay una serie de elementos que se consideran esenciales y que deben compartir todas las representaciones de los patrones, indicados por Christopher Alexander en [4]: un patrón es una regla que establece una relación entre un contexto, un sistema de fuerzas que aparecen en el contexto y una configuración que permite que las fuerzas se resuelvan dentro del contexto. Después la literatura especializada en patrones software ofrece diferentes variantes de los elementos considerados esenciales, pero todas ellas contienen los tres apartados indicados por el Dr. Alexander, que en un lenguaje más coloquial podían denominarse:
contexto, problema y solución.
Así, en el libro de GoF [12] se indica que un patrón debe contar con cuatro elementos

esenciales:
· El nombre del patrón: Un descriptor manejable del problema. Debe ser corto (una palabra o dos). Amplía el vocabulario de diseño.
· El problema: Describe cuando aplicar el patrón. Explica el problema y su contexto.
· La solución: Describe los elementos que forman el diseño, sus relaciones, responsabilidades y colaboraciones. No describe un diseño o una implementación concreta, sino que ofrece una descripción abstracta de un problema.
· Las consecuencias: Son los resultados de aplicar un patrón. Son necesarias para evaluar alternativas de diseño, así como para evaluar los costes y beneficios de su aplicación.
Otros autores [14, 18] difieren en cuanto al número de elementos propios de un patrón, pero en esencia coinciden con las ideas de Alexander y al final vienen a representar la misma información que los patrones del libro de GoF.

DESCRIPCION DE LOS PATRONES DE SOFTWARE

Los patrones se describen utilizando formatos consistentes. Un formato es una plantilla dividida en secciones. La plantilla ofrece una uniformidad en la estructura de los patrones que hace que éstos sean más sencillos de aprender, de comparar y de utilizar. Existen diferentes formatos de descripción de patrones, entre los que cabe destacar el formato utilizado por Christopher Alexander en su trabajo que es denominado

TIPOS DE PATRONES DE SOFTWARE

Debido al éxito alcanzado por el libro del Gof [12], existe una cierta tendencia a que cada vez que se menciona el término patrón se relaciona con los patrones presentados en este libro. Dichos patrones son patrones de diseño orientado a objeto, pero existen muchos otros tipos de patrones aparte de los patrones de diseño. Se pueden citar como ejemplos de patrones no de diseño los patrones de análisis [11], o los patrones de organización5 de los que existe un website especializado administrado por James Coplien (http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns). Además, los patrones enviados a las ediciones del PLoP cubren la mayoría de los campos de la Ingeniería del Software.
Así, en [6] se distinguen tres tipos de patrones, marcando de una forma muy clara tres niveles conceptuales. Estos tipos son:
·

Patrones arquitectónicos:

Expresan una organización estructural fundamental para un sistema software. Normalmente expresa un conjunto de subsistemas predefinidos, especifica sus responsabilidades e incluye reglas y guías para organizar las relaciones entre ellos.
·

Patrones de Diseño:

Ofrecen esquemas para refinar subsistemas y componentes de un sistema software, o las relaciones entre ellos. Describe normalmente una estructura de comunicación recurrente entre componentes, que sirve para resolver un problema general de diseño dentro de un contexto particular.

·

Idioms:

Un idiom es patrón de bajo nivel, específico de un determinado lenguaje deprogramación. Describen como implementar aspectos particulares de los componentes, o de las relaciones entre ellos, utilizando las características de un determinado lenguaje. Como ejemplo de un idiom se tiene la siguiente construcción en C++ para copiar cadenas de caracteres: while (*destino++ = *src++); Centrando de nuevo la atención en los patrones de diseño, en el libro de GoF [12] se distinguen tres tipos de patrones de diseño: patrones de creación, patrones
estructurales y patrones de comportamiento.
Además, en cada una de las categorías se distinguen dos subtipos, patrones que trabajan con clases y patrones que trabajan con objetos.
·

Patrones de Creación:

Los patrones de creación abstraen el proceso de instanciación de objetos. Tienen la misión de permitir construir sistemas independientes de la forma en que se crean, se componen o se representan los objetos. Un patrón de creación de clases utiliza la herencia para variar la clase que es instanciada, mientras que un patrón de creación de objetos delega la instanciación 5 Describen las estructuras y las prácticas de las organizaciones humanas. en otro objeto. Como ejemplo de patrón de creación de clases se tiene el Factory Method, y como ejemplo de patrón de creación de objetos se puede citar al patrón Builder
.
·

Patrones Estructurales:

Se cuidan de cómo las clases y los objetos se componen para formar estructuras mayores. Un patrón estructural de clases utiliza la herencia para componer interfaces o implementaciones, por ejemplo el patrón Adapter
. Un patrón estructural de objetos describe la forma en que se componen objetos para obtener nueva funcionalidad, además se añade la flexibilidad de cambiar la composición en tiempo de ejecución, lo cual no es posible con la composición de clases estáticas, como ejemplo de este tipo de patrones se puede mencionar al patrón Composite
.
·

Patrones de Comportamiento:

Este tipo de patrones está relacionado con algoritmos y la asignación de responsabilidades entre objetos. Describen, además de los patrones de objetos y clases, los patrones de comunicación entre ellos. Los patrones de comportamiento de clases utilizan la herencia para distribuir el comportamiento entre las clases, como ejemplo se puede citar al patrón Template
Method. Por su parte los patrones de comportamiento de objetos utilizan la composición de objetos en lugar de la herencia, por ejemplo como un grupo de objetos interconectados cooperan para realizar una tarea que un solo objeto no puede hacer por sí mismo, como representante de este tipo de patrones se puede
mencionar al patrón Observer
.

PATRONES Y RIENTACION A OBJETO

Hasta el momento se ha intentado dejar patente en este artículo que un patrón es algo independiente de un determinado paradigma, de una metodología concreta o de un lenguaje particular. Aunque también debe señalarse que la mayor actividad en la comunidad de los patrones software ha venido de la mano de la tecnología de objetos. La razón de por la que los patrones han tenido tan buena acogida en el seno de la orientación a objeto se tiene en que la programación orientada a objeto se adapta muy bien a las metáforas arquitectónicas propuestas por el Dr. Alexander. Los objetos pueden ensamblarse en estructuras más complejas, tal y como hace la Arquitectura, añadiendo además una dimensión temporal que recoge el intercambio de mensajes entre objetos.
Por otra parte, la orientación a objeto soporta muy bien el modelado del mundo real, teniendo una importancia capital el diseño de las aplicaciones software. Pero, aunque las teorías de Christopher Alexander encajan muy bien en la orientación a objeto, debe reconocerse la importancia capital del libro del GoF [12] para la difusión del concepto de patrón de diseño dentro de la orientación a objeto, influencia que por otra parte puede haber influido a pensar que los patrones son un concepto exclusivo de la orientación a objeto.

RELACION ENTRE LOS PATRONES SOFTWARE Y LA REUTILIZACION

La inmadurez de la Ingeniería del Software como disciplina ingenieril queda plasmada cada vez que se reinventa la rueda para afrontar un nuevo proyecto software, en lugar de recurrir a la guía de soluciones ya existentes como sucede en otras ingenierías. Este problema de falta de madurez se hace más patente cuanto mayor es la organización, donde los proyectos caminan independientes resolviendo una y otra vez problemas similares (por no decir idénticos en un alto porcentaje de los casos) a los ya resueltos en otros proyectos.

Los patrones software, y en general la noción de patrón, constituyen una forma flexible y adecuada que favorece la reutilización de la experiencia embebida en los procesos que representan soluciones a problemas software, con independencia de su nivel de abstracción (análisis, diseño o implementación). Dentro de los patrones software, los más útiles desde el punto de vista de aportación a la reutilización del software son los patrones que se denominan generativos, esto es, aquellos que son activos y dinámicos, que no se limitan a mostrar las características de los sistemas que se consideran adecuados, sino que enseñan a construirlos.