Patrones y Antipatrones: una Introducción - Parte II

Por León Welicki

Artículos relacionados

Patrones y Antipatrones: una Introducción - Parte I

Contenido

 Patrones de arquitectura
     Categorías de los patrones de arquitectura
         Categorías de POSA
         Categorías de PEAA
     Ejemplo: El patrón Modelo-Vista-Controlador
         Patrones de diseño en el MVC
 Antipatrones
         Por qué estudiar antipatrones
         Categorías de antipatrones
 Otros tipos de patrones...
 ¡Patrones en todas partes!

 Referencias

Patrones de arquitectura

Los patrones de arquitectura expresan el esquema fundamental de organización para sistemas de software. Proveen un conjunto de subsistemas predefinidos; especifican sus responsabilidades e incluyen reglas y guías para organizar las relaciones entre ellos. Los patrones de arquitectura representan el nivel más alto en el sistema de patrones propuesto en Pattern Oriented Software Architecture - Volume 1, reflejado en la la Figura 1 de la Parte I de este artículo. Ayudan a especificar la estructura fundamental de una aplicación. Cada actividad de desarrollo es gobernada por esta estructura; por ejemplo, el diseño detallado de los subsistemas, la comunicación y colaboración entre diferentes partes del sistema, etc. Cada patrón de arquitectura ayuda a conseguir una propiedad específica en el sistema global; por ejemplo, la adaptabilidad de la interfaz de usuario. Los patrones que dan soporte a características similares se agrupan en una misma categoría.

Categorías de los patrones de arquitectura

A continuación analizaremos la categorización utilizada en 2 de los sistemas de patrones de arquitectura más extendidos y celebrados: el de Pattern Oriented Software Architecure - Volume 1[Buschmann96] (en adelante, POSA) y el de Pattern of Enterprise Application Architecture [Fowler03] (en adelante, PEAA).

Categorías de POSA

En POSA, libro de referencia de patrones de arquitectura, se divide a los patrones en las siguientes categorías:

  • From Mud to Structure: los patrones en esta categoría ayudan a evitar un “mar” de componentes u objetos. En particular, soportan una descomposición controlada de una tarea del sistema en subtareas que cooperan.

  • Distributed Systems

  • Interactive Systems

  • Adaptable Systems

La Tabla 2 muestra la distribución de los patrones de POSA en las categorías enunciadas anteriormente:

From Mud to Structure

Distributed Systems

Interactive Systems

Adaptable Systems

Layers
Pipes and Filtres
Blackboard

Broker

Model-View-Controller
Presentation-Abstraction-Control

Microkernel
Reflection

Tabla 2: Clasificación de patrones de arquitectura de POSA. Volver al texto .

Categorías de PEAA

En PEAA, Martin Fowler describe una gran cantidad de patrones orientados a la arquitectura de aplicaciones empresariales. La visión de Fowler es más pragmática y está alineada a la definición de arquitectura que establece en el Capítulo 1 de esa obra:

“...1) deconstrucción de más alto nivel de un sistema en sus partes componentes; 2) aquellas cosas que resulta difícil cambiar...”

En PEAA se definen las siguientes categorías de patrones:

  • Layering: Patrones para dividir un sistema en capas.

  • Organización de la lógica del dominio: Formas de organizar los objetos del dominio.

  • Mapping to Relational Databases: Se relaciona con la comunicación entre la lógica del dominio y los repositorios de datos. Incluye el mapeo entre modelos de objetos y bases de datos relacionales. En la actualidad, se consume mucho tiempo de desarrollo en la realización de estas tareas debido a las diferencias de impedancia entre SQL y los lenguajes orientados a objetos tales como C#, C++, Java, etc.

  • Presentación Web: La presentación Web es uno de los desafíos que han tenido que sortear en los últimos años las aplicaciones empresariales. Los clientes delgados Web proveen muchas ventajas, siendo una de las principales la facilidad de distribución (no es necesario instalar software en los equipos cliente). Esta categoría incluye una serie de patrones para gestionar la presentación Web.

  • Concurrencia: Manejo de la concurrencia. Las aplicaciones actuales basadas en tecnologías Web tienen grandes necesidades de gestión de la concurrencia.

  • Estado de sesión: Patrones para el manejo de la sesión en servidores Web.

  • Estrategias de Distribución: Distribución de objetos en múltiples emplazamientos, basada en conocimientos empíricos en clientes.

En la tabla a continuación se muestra la distribución de los patrones definidos en “Patterns of Enterprise Application Architecture” en las categorías mencionadas arriba:

La tabla Tabla 3 muestra la distribución de los patrones definidos en Patterns of Enterprise Application Architecture en las categorías mencionadas anteriormente:

Domain Logic Pattern

Mapping toRelational Databases

Web Presentation Patterns

Distribution Patterns

Offline Concurrency Patterns

Session State Patterns

Base Patterns

Transaction Script
Domain Model
Table Module
Service Layer

Data Source
Architectural Patterns
Table Data Gateway
Row Data Gateway
Active Record
Data Mapper
Object Relational
Behavioral Patterns
Unit of Work
Identity Map
Lazy Load
Object Relational
Structural Patterns
Identity Field
Foreign Key Mapping
Association Table
Mapping
Dependent Mapping
Embedded Value
Serialized LOB
Single Table
Inheritance
Class Table
Inheritance
Table Inheritance
Concrete Inheritance
Inheritance Mappers
Object-Relational Metadata Mapping Patterns
Metadata Mapping
Query Object
Repository

Model View Controller
Page Controller
Front Controller
Template View
Transform View
Two Step
 View
Application Controller

Remote Façade
Data Transfer Object

Optimistic Offline Lock
Pesimistic Offline Lock
Coarse-Grained Lock
Implicit Lock

Client Session State
Server Session State
Database Session State

Gateway
Mapper
Layer Supertype
Separated Interface
Registry
Value Object
Money
Special Case
Plugin
Service Stub
Record Set

Tabla 3: Clasificación de patrones de arquitectura de aplicaciones empresariales de PEEA. Volver al texto .

Un detalle interesante para destacar de este libro es que se provee código fuente en Java y/o C# de todos los patrones.

Ejemplo: El patrón Modelo-Vista-Controlador

El Model-View-Controller (Modelo-Vista-Controlador, en adelante MVC) fue introducido inicialmente en la comunidad de desarrolladores de Smalltalk-80. MVC divide una aplicación interactiva en 3 áreas: procesamiento, salida y entrada. Para esto, utiliza las siguientes abstracciones:

  • Modelo (Model): Encapsula los datos y las funcionalidades. El modelo es independiente de cualquier representación de salida y/o comportamiento de entrada.

  • Vista (View): Muestra la información al usuario. Obtiene los datos del modelo. Pueden existir múltiples vistas del modelo. Cada vista tiene asociado un componente controlador.

  • Controlador (Controller): Reciben las entradas, usualmente como eventos que codifican los movimientos o pulsación de botones del ratón, pulsaciones de teclas, etc. Los eventos son traducidos a solicitudes de servicio (“service requests” en el texto original) para el modelo o la vista. El usuario interactúa con el sistema a través de los controladores.

Las Vistas y los Controladores conforman la interfaz de usuario. Un mecanismo de propagación de cambios asegura la consistencia entre la interfaz y el modelo. La separación del modelo de los componentes vista y del controlador permite tener múltiples vistas del mismo modelo. Si el usuario cambia el modelo a través del controlador de una vista, todas las otras vistas dependientes deben reflejar los cambios. Por lo tanto, el modelo notifica a todas las vistas siempre que sus datos cambien. Las vistas, en cambio, recuperan los nuevos datos del modelo y actualizan la información que muestran al usuario. La Figura 2 muestra la estructura del patrón MVC:

Bb972251.art235-img02-543x280(es-es,MSDN.10).jpg
Figura 2: Diagrama de clases de MVC, tomado de [Buschman96].Volver al texto .

Este patrón es muy popular y ha sido portado a una gran cantidad de entornos y frameworks como entre los que se encuentran WinForms, ASP .Net, etc. Las herramientas de programación visual como Visual Basic, Visual Studio .Net, etc., siguen también alguna variante de este esquema. El MVC es un patrón ampliamente utilizado en múltiples plataformas y lenguajes. Algunos de sus principales beneficios son:

  • Menor acoplamiento

    • Desacopla las vistas de los modelos

    • Desacopla los modelos de la forma en que se muestran e ingresan los datos

  • Mayor cohesión

    • Cada elemento del patrón esta altamente especializado en su tarea (la vista en mostrar datos al usuario, el controlador en las entradas y el modelo en su objetivo de negocio)

  • Las vistas proveen mayor flexibilidad y agilidad

    • Se puede crear múltiples vistas de un modelo

    • Se puede crear, añadir, modificar y eliminar nuevas vistas dinámicamente

    • Las vistas pueden anidarse

    • Se puede cambiar el modo en que una vista responde al usuario sin cambiar su representación visual

    • Se puede sincronizar las vistas

    • Las vistas pueden concentrarse en diferentes aspectos del modelo

  • Mayor facilidad para el desarrollo de clientes ricos en múltiples dispositivos y canales

    • Una vista para cada dispositivo que puede varias según sus capacidades

    • Una vista para la Web y otra para aplicaciones de escritorio

  • Más claridad de diseño

  • Facilita el mantenimiento

  • Mayor escalabilidad

Patrones de diseño en el MVC

Un patrón de arquitectura puede contener varios patrones de diseño. A modo de ejemplo, citaremos el caso del patrón de arquitectura Model-View-Controller (analizado en el apartado anterior) que contiene (o puede contener) los siguientes patrones de diseño:

  • Observer: Para el mecanismo de publicación y suscripción que permite la notificación de los cambios en el modelo a las vistas.

  • Composite: para la creación de vistas compuestas. Utilizando este patrón podemos crear una jerarquía de vistas y tratar a cada vista compuesta igual que una a una vista normal.

  • Strategy: En la relación entre las vistas y los controladores. Utilizando este patrón podemos cambiar dinámicamente o en tiempo de compilación los algoritmos del controlador mediante los cuales responde a su entorno.

  • Factory Method: Para especificar la clase controlador predeterminada de una vista.

  • Decorator: Para añadir capacidades adicionales a una vista (por ejemplo, scroll).

  • Proxy: Para distribuir la arquitectura (Modelo y Vista-Controlador) en diferentes emplazamientos.

Para obtener más detalles sobre este caso particular de composición de patrones, consulta el Capítulo 1 del libro del GoF o de POSA.

Antipatrones

Los antipatrones son soluciones negativas que presentan más problemas que los que solucionan. Son una extensión natural a los patrones de diseño. Comprender los antipatrones provee el conocimiento para intentar evitarlos o recuperarse de ellos. El estudio de los antipatrones permite conocer los errores más comunes relacionados con la industria del software. La obra de referencia en este campo es AntiPatterns: Refactoring Software , Architectures and Projects in Crisis [BMMM98], publicada en 1998.

Los antipatrones se documentan con cierto cinismo, lo cual los hace bastante graciosos y fáciles de recordar. Los nombres siempre aluden al problema que tratan con humor. Se documentan mediante una plantilla (como los patrones de diseño) que incluye secciones para documentar la solución orígen (que es la causa del problema), el contexto, las fuerzas en conflicto y las soluciones correctas propuestas (para más detalles sobre la plantilla, ver el Capítulo 3 de Antipatterns). Un buen antipatrón explica por qué la solución original parece atractiva, por qué se vuelve negativa y cómo recuperarse de los problemas que ésta genera.

Según James Coplien, un antipatrón es...

“...algo que se ve como una buena idea, pero que falla malamente cuando se la implementa.”

La Figura 3 muestra una comparación entre patrones y antipatrones:

Bb972251.art235-img03-568x360(es-es,MSDN.10).jpg
Figura 3: Patrones y antipatrones [McCormick98].Volver al texto .

Nota cómo en los antipatrones se parte desde una solución (que es la que genera el problema), mientras que en los patrones se parte de un problema a resolver.

Por qué estudiar antipatrones

Un antipatrón (antipattern, en inglés) es una forma literaria que describe una solución común a un problema que genera decididamente consecuencias negativas. Según el libro AntiPatterns: Refactoring Software , Architectures and Projects in Crisis, los antipatrones...:

  • Son un método eficiente para vincular una situación general a una clase de solución específica.

  • Proveen experiencia del mundo real para reconocer problemas recurrentes en la industria del software, ofreciendo también una solución para sus implicaciones más comunes.

  • Establecen un vocabulario común para identificar problemas y discutir soluciones.

  • Soportan la resolución holística de conflictos, utilizando recursos organizacionales a diferentes niveles.

Categorías de antipatrones

En el libro de antipatrones, éstos se dividen en 3 grandes categorías a las cuales se denominan “puntos de vista”:

  • Desarrollo de Software: Se centran en problemas asociados al desarrollo de software a nivel de aplicación.

  • Arquitectura de Software: Se centran en la estructura de las aplicaciones y componentes a nivel de sistema y empresa.

  • Gestión de Proyectos de Software: En la ingeniería del software, más de la mitad del trabajo consiste en comunicación entre personas y resolver problemas relacionados con éstas. Los antipatrones de gestión de proyectos de software identifican algunos de los escenarios clave donde estos temas son destructivos para el proceso de software.

La Tabla 4 muestra la distribución de los antipatrones definidos en el libro en las categorías mencionadas anteriormente:

Desarrollo de software

Arquitectura

Gestión

  • The Blob

  • Lava Flow

  • Functional Decomposition

  • Poltergeists

  • Golden Hammer

  • Spaghetti Code

  • Cut and Paste Programming

Mini antipatterns

  • Continuous Obsolescence

  • Ambiguous Viewpoint

  • Boat Anchor

  • Dead End

  • Input Kludge

  • Walking through a Minefield

  • Mushroom Management

  • Stovepipe Enterprise

  • Vendor Lock-in

  • Architecture by Implication

  • Design by Committee

  • Reinvent the Wheel

Mini antipatterns

  • Autogenerated Stovepipe

  • Jumble

  • Cover your Assets

  • Wolf Ticket

  • Warm Bodies

  • Swiss Army Knife

  • The Grand Old Duke of York

  • Analysis Paralysis

  • Death by Planning

  • Corncob

  • Irrational Management

  • Project Missmanagement

Mini antipatterns

  • Blowhard Jamboree

  • Viewgraph Engineering

  • Fear of Success

  • Intellectual Violence

  • Smoke and Mirrors

  • Throw it over the wall

  • Fire Drill

  • The Feud

  • E-Mail is Dangerous

Tabla 4: Clasificación de antipatrones. Volver al texto .

En este mismo libro se plantea un modelo de referencia teórico que va más allá de estas divisiones. Para más detalles sobre el modelo, consulta los Capítulos 2, 3 y 4 de esta obra.

Otros tipos de patrones...

Los patrones pueden encontrarse en todas las áreas de la ingeniería informática. A continuación, enumeraremos una serie de áreas donde existen patrones aceptados y conocidos en la industria:

  • Idiomas: Son específicos del lenguaje de programación. Describen cómo implementar ciertos aspectos de un problema utilizando las características de un lenguaje de programación.

  • Patrones de Análisis: Los patrones enumerados en el libro Analysis Patterns: Reusable Object Models [Fowler97] provienen de diversos dominios, incluyendo las áreas de la salud, servicios financieros y contabilidad. Cada uno de los patrones se describen en forma textual y con una simple notación pre-UML.

  • Patrones de Integración de Aplicaciones: Patrones para integración de aplicaciones. La obra más popular al respecto es Enterprise Integration Patterns [Hophe03], de Gregor Hophe y Bobby Woolf.

  • Patrones de UI: Patrones referentes a interfaces de usuarios. Existen distintas categorías bien diferenciadas: algunas se encargan de detalles relacionados con la cognición, memoria a corto plazo y mejoras en la experiencia del usuario, mientras que otros describen técnicas de ingeniería para crear interfaces de usuario.

  • Patrones de Pruebas: Patrones para diseñar y realizar pruebas.

¡Patrones en todas partes!

Al momento de escribir este trabajo, una búsqueda de la palabra “pattern” en los principales buscadores retorna más de 20.000.000 resultados. Evidentemente no todos los resultados se refieren a patrones de software, pero en la primera página de resultados aparecen sitios emblemáticos sobre  patrones de software como Hillside, Portland Pattern Repository y PatternLanguage.com.

Actualmente, hay disponible una amplia literatura sobre patrones. De hecho, las principales casas de software tienen sus publicaciones sobre patrones que pueden implantarse directamente sobre sus tecnologías.

Referencias

[Alexander79]

Alexander, Christopher: A Timeless Way of Building, Oxford University Press, 1979.

[AIX77]

Alexander, Christopher et al.: A Pattern Language, Oxford University Press, 1977.

[BMMM98]

Brown, W., Malveau, R., Mc Cormick III, H., Mowbray, T.: Antipatterns: Refactoring Software , Architectures and Project in Crisis, Wiley and Sons, 1998.

[Buschman96]

Buschmann, Frank et al.: Pattern Oriented Software Architecture, Volume 1: A System of Patterns, Willey & Sons, 1996.

[Cueva04]

Cueva Lovelle, Juan Manuel: Tecnología de Objetos: Patrones de Diseño, 2004.

[Evitts00]

Evitts, Paul: A UML Pattern Language, SAMS Publishing, 2000.

[Fowler03]

Fowler, Martin: Enterprise Application Architecture Patterns, Addison Wesley, 2003.

[Fowler97]

Fowler, Martin: Analysis Patterns: Reusable Object Models, Adisson Wesley, 1997.

[Fowler99]

Fowler, Martin: Refactoring: Improving the Design of Existing Code, Adisson Wesley, 1999.

[Gall75]

Gall, John: Systemantics: How Systems Work and Especially How They Fail, New York, Quadrangle, 1975.

[GoF95]

Gamma E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley, 1995.

[Hillside03]

Hillside Group: Home of the Patterns Library, 2003 <en línea> http://hillside.net/.

[Hophe03]

Hophe, Gregor, Woolf, Robert: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Addisson Wesley, 2003.

[Kerievsky04]

Kerievsky, Joshua: Refactoring to Patterns, Addison-Wesley, 2004.

[McCormick98]

McCormick, Hays: Antipatterns Tutorial, 1998 <en línea> http://www.antipatterns.com/briefing/sld001.htm.

[Microsoft03]

Microsoft Corp: Enterprise Solution Patterns, Microsoft Press, 2003.

[Microsoft04]

Microsoft Corp: Enterprise Development Reference Architecture, Microsoft Press, 2004.

[PPR04]

C2 WikiWikiWeb: Portland Pattern Repository <en línea> http://c2.com/ppr/.

[ST01]

Shalloway, Alan; Trott James: Design Patterns Explained: A New perspective on Object Oriented Design, Pearson Education, 2001.

[Vlissides98]

Vlissides, John: Pattern Hatching: Design Patterns Applied, Addison Wesley, 1998.

León Welicki es Profesor Asociado de Ingeniería Web en el Máster en Ingeniería del Software de la Universidad Pontificia de Salamanca, Madrid, España; donde actualmente está realizando el Doctorado en Ingeniería Informática, su tesis doctoral trata sobre las Arquitecturas de Software y Paradigmas No Convencionales para Ingeniería Web. Trabaja como Arquitecto de Software. Cuenta con más de 12 años de experiencia profesional en diversas áreas de la Ingeniería del Software.

Mostrar: