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 |
Broker |
Model-View-Controller |
Microkernel |
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 |
Data Source |
Model View Controller |
Remote Façade |
Optimistic Offline Lock |
Client Session State |
Gateway |
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:
.jpg "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:
.jpg "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 |
|---|---|---|
Mini antipatterns
|
Mini antipatterns
|
Mini antipatterns
|
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.