Explicación

6.1 Conceptos generales

Replicar un método o proceso científico permite confirmar que los resultados esperados no varían. Por ejemplo, puedes verificar la velocidad de los cuerpos en caída libre por la fuerza de gravedad. Sabes que al aplicar la ecuación de la fuerza de gravedad los resultados serán consistentes e incluso predecibles, hecho que permitió que el hombre pisara la luna. Esa es la misma idea que se aplica a los patrones arquitectónicos: reutilizar diseños de arquitectura que fueron probados en múltiples ocasiones y con resultados exitosos, facilitando el diseño en escenarios diversos.

“El patrón es una descripción del problema y la esencia de su solución, de modo que la solución puede reutilizarse en diferentes configuraciones” (Sommerville, 2011).

A continuación analizarán los conceptos en los que se fundamentan los patrones del software.

Para ejemplificar los niveles de detalle que describen los patrones del diseño del software puedes revisar el siguiente diagrama:

Haz clic en cada concepto para conocer más detalle.

Diagrama adaptado de Welicki, L. (s.f.). Patrones y Antipatrones: una Introducción - Parte I. Recuperado de https://msdn.microsoft.com/es-es/library/bb972242.aspx

GoF o “Gang of four”

La “banda de los cuatro” o GoF por sus siglas en inglés, hace referencia a los cuatro autores del libro Design Patterns: Elements of Reusable Object-Oriented Software, publicado en 1995: Gamma, Helm, Johnson y Vlissides. Este libro se volvió un referente en la industria del software ya que recopila 23 patrones de diseño a modo de catálogo. Para el año 2000, Linda Rising catalogó más de 1000 patrones que habían sido documentados.

“Estoy seguro que sus 1000 (patrones) son sólo una fracción de lo que Rising pudiera encontrar hoy si ella repitiera su esfuerzo” (Hanmer, 2013).

Por otro lado, el antipatrón de diseño describe los errores más comunes que se comenten al diseñar un software que llevan inevitablemente al fracaso, por lo que han de evitarse. La idea es ofrecer información sobre sus características con el fin de reconocerlos a tiempo.

Existen dos formas de agrupar los patrones de diseño:

Haz clic en cada concepto para conocer más detalle.

1. Lenguajes de patrón:

Un lenguaje de patrón describe la interrelación de un conjunto de patrones haciendo uso de un formato estándar. Tienen la ventaja de describir las buenas prácticas de diseño para resolver problemas derivados de un dominio particular.

Pressman (2010) propone el siguiente formato:

Nombre del patrón	Describe la esencia del patrón con un nombre corto.
Problema	Descripción del problema que resuelve.
Motivación	Proporciona un ejemplo del problema
Contexto	Describe el ambiente en el que reside el problema.
Fuerzas	Análisis de las limitaciones y restricciones que deben ser tomadas en cuenta.
Solución	Descripción detallada de la solución propuesta para el problema.
Objetivo	Describe el patrón y lo que hace.
Colaboraciones	Describe la manera en la que otros patrones contribuyen a la solución.
Consecuencias	Describe los intercambios potenciales que deben de ser considerados cuando se implementa el patrón y las consecuencias de uso. Nota: Shalloway y Trott (2005) aclaran que el término consecuencias no tiene una connotación negativa, sino que se refiere al efecto de una causa.
Implementación	Identifica los aspectos especiales que deben considerarse cuando se implementa el patrón.
Usos conocidos	Da ejemplos de usos reales del patrón de diseño en aplicaciones reales.
Patrones relacionados	Menciona referencias a patrones de diseño relacionados.

En la práctica encontrarás que no todos estos atributos son descritos para cada patrón, sin embargo te da una buena idea de la información que puedes esperar al buscar patrones que den solución al diseño del software.

Ejemplo:

Nombre del patrón	Facade
Problema	Necesidad de utilizar un subconjunto de componentes de un sistema más complejo, o se requiere interactuar con el sistema en una forma particular.
Fuerzas	No debe de ser diseñado para proveer información adicional. Nunca debe devolver componentes del subsistema de los métodos de Facade a los clientes.
Solución	El patrón Facade presente una nueva interface para el cliente de un sistema existente.
Colaboraciones	Presenta una interfaz simplificada para el cliente, que es más fácil de usar.
Consecuencias	El patrón Facade simplifica el uso de un subsistema requerido. Sin embargo, dado que Facade no es completo, ciertas funcionalidades podrían no estar disponibles para el cliente.
Implementación	Definir una nueva clase (clases) que tiene la interfaz requerida. Tener esta nueva clase en el sistema existente.
Estructura general	Ejemplo tomado del libro: Shallowar, A y Trot, J (2005). Design patterns explained. (2ª ed.). Addison – Wesley. Sólo para fines educativos.

2. Repositorios de patrones

Es una agrupación de una serie de patrones que permite entender sus relaciones a través del uso de hipervínculos.

6.2 Diseño basado en patrones

En general, el diseño basado en patrones aparece en varias industrias: automotriz, aeronáutica, transformación de bienes, agricultura, minería, medicina, por mencionar algunas, y ha sido una forma de asegurar los resultados y disminuir el riesgo.

Si se sabe que la aplicación de un método ofrece resultados exitosos, por qué no reutilizar el mismo método en lugar de crear una solución desde cero. Esa es la misma idea que se tiene al construir productos de software.

Un ingeniero de diseño software basa su trabajo de las especificaciones de requerimientos del software, después debe buscar alguna técnica de abstraer la información y generar el diseño más adecuado. En esta labor es posible que el ingeniero encuentre un patrón de diseño que se ajuste al problema que se enfrenta y así conducirlo hacia la construcción de un modelo de diseño. Si no encuentra un patrón que se ajuste, hará uso de las herramientas de modelado y generará una solución aplicando métodos y notaciones de diseño.

Este proceso de diseño Pressman (2010), lo describe a través del siguiente diagrama. Observa que incluye los atributos de calidad porque determinan en buena medida las características del diseño del software.

Diseño basado en patrones. Figura tomada del libro: Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico. (7ª ed). México: McGraw Hill. Sólo para fines educativos.

Shalloway y Trott (2005) proponen los siguientes pasos para que un diseñador piense en patrones:

El primer paso en el diseño debe ser comprender el contexto del software a partir del trabajo realizado en la ingeniería de requerimientos. Después identificar los patrones que pudieran servir para resolver el problema que plantea el desarrollo del sistema. Utilizar un patrón de diseño e ir refinando el diseño hasta reconocer que se ha encontrado la solución del problema. Finalmente deberá realizar los ajustes necesarios para mejorar el diseño.

Al utilizar varios patrones en un diseño de software es frecuente que el diseñador pueda perder el control de los patrones seleccionados. Para ello puede hacer uso de una tabla de organización de patrones en la que se pueden ir registrando los problemas identificados y el patrón de diseño utilizado.

Pressman (2010) sugiere hacer uso de una hoja de cálculo con hipervínculos a sitios web que provean de una descripción completa de los patrones de la tabla.

Tabla de organización de patrones. Toma del libro de Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico. (7ª ed). México: McGraw Hill.

Sin lugar a dudas hacer uso de patrones de diseño es una gran ventaja, sin embargo también es posible caer en errores que pueden llevar al diseño a una callejón sin salida. Algunos de los errores comunes en el diseño basado en patrones son los siguientes:

Pensar que el uso de los patrones del diseño resolverá todo el diseño.
No dedicarle tiempo suficiente a entender el contexto y elegir un patrón de forma equivocada.
Tratar de forzar la aplicación del patrón.
Utilizar el patrón tal y como está sin aplicar ajustes.

Pressman (2010) sugiere que para evitar este tipo de errores se busque una segunda opinión a través de técnicas de revisión, en la que compañeros del equipo técnico analicen el diseño y la aplicación de los patrones, corroborando así su aplicación al dominio particular del proyecto.

6.3. Estructura y patrones de diseño

La estructura es un esqueleto de una infraestructura específica que puede complementar un patrón de diseño, permitiendo así describir de manera más completa el diseño del software.

Pressman (2010) afirma que una estructura es una “miniarquitectura reutilizable” y que sirve como base para aplicar uno o varios patrones de diseño, y que es posible adaptarla para resolver un problema de un dominio específico haciendo uso de “puntos de conexión” de los que se pueden integrar otras clases o funciones específicas.

Para entender mejor las diferencias entre un patrón de diseño y una estructura, Pressman (2010) considera lo siguiente:

Patrones de diseño	Estructuras
Son más abstractos que las estructuras.	Son descritas mediante lenguajes de programación que pueden ser ejecutadas y reutilizadas directamente.
Son más pequeños que las estructuras y no pueden contener varias estructuras.	Pueden incluir varios patrones de diseño.
Son menos especializados que las estructuras, por lo que pueden utilizarse en un ámbito más amplio de aplicaciones.	Siempre tienen un dominio particular de aplicación, que para lograr una mayor eficacia deben ser aplicados sin cambios.

Ejemplo de la estructura del patrón de diseño Factory Method haciendo uso del diagrama de clases UML.

Imagen obtenida de http://patronesdediseno.net16.net/. Sólo para fines educativos.

La misma estructura puede ejemplificarse a través del código. En el siguiente ejemplo se muestra una estructura para el patrón de Factory Method en código Java.

Código Factory Method

public interface ProductReader {
public DecodedProduct getDecodedProduct();
}

public class Product1Reader implements ProductReader {
    public DecodedProduct getDecodedProduct() {
       // ...
       return decodedProduct;
    }
}

public class Product2Reader implements ProductReader {
    public DecodedProduct getDecodedProduct() {
       // ...
       return decodedProduct;
    }
}

public class ProductReaderFactory {
public static ProductReader getProductReader(InputStream is) {
int ProductType = determineProductType(is);

       switch (imageType) {
        case ProductReaderFactory.Product1:
            return new Product1Reader(is);
        case ProductReaderFactory.Product2:
            return new Product2Reader(is);
        // etc.
       }
    }
}

A partir de la publicación de GoF se pueden obtener las siguientes clases de patrones orientados a objetos:

Haz clic en cada concepto para conocer más detalle.

Creacionales

Ofrecen patrones que ayudan a tomar la decisión de crear, generar o representar un objeto. Según Pressman (2010), este tipo de patrones facilitan obtener información de las instancias de los objetos y al mismo tiempo restringen la cantidad de objetos creados en un sistema.

Estructurales

Permiten encontrar maneras en las que los objetos y las clases que los describen, forman estructuras más complejas, ya sea combinándolos o integrándolos en estructuras más grandes.

De comportamiento o conductuales

Establecen la forma en cómo se relacionan, se comunican y se asigna responsabilidades entre las clases y los objetos

Los 23 patrones de diseño se clasifican a través de dos criterios: propósito y alcance. El propósito refleja lo que el patrón hace, mientras que el alcance se refiere a si aplica a la clase o a un objeto.

Catálogo de patrones de diseño. Tabla tomada del libro: Gamma, E., Helm, R., Johnson R. y Vlissides J. (1995). Design Patterns, Elements of Reuseable, Object-Oriented Software. EEUU: Addison.Wesley. Sólo para fines educativos