Patrones de arquitectura

Los patrones de arquitectura expresan el esquema fundamental de organizacin para sistemas de software. Proveen un conjunto de subsistemas predefinidos; especifican sus responsabilidades e incluyen reglas y guas para organizar las relaciones entre ellos. Los patrones de arquitectura representan el nivel ms 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 artculo. Ayudan a especificar la estructura fundamental de una aplicacin. Cada actividad de desarrollo es gobernada por esta estructura; por ejemplo, el diseo detallado de los subsistemas, la comunicacin y colaboracin entre diferentes partes del sistema, etc. Cada patrn de arquitectura ayuda a conseguir una propiedad especfica en el sistema global; por ejemplo, la adaptabilidad de la interfaz de usuario. Los patrones que dan soporte a caractersticas similares se agrupan en una misma categora. Categoras de los patrones de arquitectura A continuacin analizaremos la categorizacin utilizada en 2 de los sistemas de patrones de arquitectura ms 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).
Categoras de POSA

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

From Mud to Structure: los patrones en esta categora ayudan a evitar un mar de componentes u objetos. En particular, soportan una descomposicin controlada de una tarea del sistema en subtareas que cooperan. Distributed Systems Interactive Systems Adaptable Systems

La Tabla 2 muestra la distribucin de los patrones de POSA en las categoras enunciadas anteriormente: From Mud to Structure Layers Pipes and Filtres Blackboard Distributed Systems Broker Interactive Systems Model-View-Controller Presentation-AbstractionControl Adaptable Systems Microkernel Reflection

Tabla 2: Clasificacin de patrones de arquitectura de POSA. Volver al texto .

Categoras de PEAA

En PEAA, Martin Fowler describe una gran cantidad de patrones orientados a la arquitectura de aplicaciones empresariales. La visin de Fowler es ms pragmtica y est alineada a la definicin de arquitectura que establece en el Captulo 1 de esa obra:

...1) deconstruccin de ms alto nivel de un sistema en sus partes componentes; 2) aquellas cosas que resulta difcil cambiar... En PEAA se definen las siguientes categoras de patrones:

Layering: Patrones para dividir un sistema en capas. Organizacin de la lgica del dominio: Formas de organizar los objetos del dominio. Mapping to Relational Databases: Se relaciona con la comunicacin entre la lgica 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 realizacin de estas tareas debido a las diferencias de impedancia entre SQL y los lenguajes orientados a objetos tales como C#, C++, Java, etc. Presentacin Web: La presentacin Web es uno de los desafos que han tenido que sortear en los ltimos aos las aplicaciones empresariales. Los clientes delgados Web proveen muchas ventajas, siendo una de las principales la facilidad de distribucin (no es necesario instalar software en los equipos cliente). Esta categora incluye una serie de patrones para gestionar la presentacin Web. Concurrencia: Manejo de la concurrencia. Las aplicaciones actuales basadas en tecnologas Web tienen grandes necesidades de gestin de la concurrencia. Estado de sesin: Patrones para el manejo de la sesin en servidores Web. Estrategias de Distribucin: Distribucin de objetos en mltiples emplazamientos, basada en conocimientos empricos en clientes.

En la tabla a continuacin se muestra la distribucin de los patrones definidos en Patterns of Enterprise Application Architecture en las categoras mencionadas arriba: La tabla Tabla 3 muestra la distribucin de los patrones definidos en Patterns of Enterprise Application Architecture en las categoras mencionadas anteriormente: Mapping toRelational Databases Data Source Architectura l Patterns Table Data Transactio Gateway n Script Row Data Domain Gateway Model Active Table Record Module Data Mapper Service Object Layer Relational Behavioral Patterns Unit of Work Domain Logic Pattern Web Offline Session Distributio Base Presentatio Concurrenc State n Patterns Patterns n Patterns y Patterns Patterns Gateway Model View Mapper Controller Layer Page Client Supertyp Controller Session Optimistic e Front State Remote Offline Lock Separated Controller Server Faade Pesimistic Interface Template Session Data Offline Lock Registry View State Transfer CoarseValue Transform Databas Object Grained Lock Object View e Implicit Lock Money Two Step Session Special View State Case Application Plugin Controller Service

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 ObjectRelational Metadata Mapping Patterns Metadata Mapping Query Object Repository

Stub Record Set

Tabla 3: Clasificacin de patrones de arquitectura de aplicaciones empresariales de PEEA. Volver al texto . Un detalle interesante para destacar de este libro es que se provee cdigo fuente en Java y/o C# de todos los patrones. Ejemplo: El patrn 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 aplicacin 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 representacin de salida y/o comportamiento de entrada. Vista (View): Muestra la informacin al usuario. Obtiene los datos del modelo. Pueden existir mltiples vistas del modelo. Cada vista tiene asociado un componente controlador. Controlador (Controller): Reciben las entradas, usualmente como eventos que codifican los movimientos o pulsacin de botones del ratn, 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 interacta con el sistema a travs de los controladores.

Las Vistas y los Controladores conforman la interfaz de usuario. Un mecanismo de propagacin de cambios asegura la consistencia entre la interfaz y el modelo. La separacin del modelo de los componentes vista y del controlador permite tener mltiples vistas del mismo modelo. Si el usuario cambia el modelo a travs 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 informacin que muestran al usuario. La Figura 2 muestra la estructura del patrn MVC:

Figura 2: Diagrama de clases de MVC, tomado de [Buschman96].Volver al texto . Este patrn 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 programacin visual como Visual Basic, Visual Studio .Net, etc., siguen tambin alguna variante de este esquema. El MVC es un patrn ampliamente utilizado en mltiples plataformas y lenguajes. Algunos de sus principales beneficios son:

Menor acoplamiento o Desacopla las vistas de los modelos o Desacopla los modelos de la forma en que se muestran e ingresan los datos Mayor cohesin

Cada elemento del patrn 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 o Se puede crear mltiples vistas de un modelo o Se puede crear, aadir, modificar y eliminar nuevas vistas dinmicamente o Las vistas pueden anidarse o Se puede cambiar el modo en que una vista responde al usuario sin cambiar su representacin visual o Se puede sincronizar las vistas o Las vistas pueden concentrarse en diferentes aspectos del modelo Mayor facilidad para el desarrollo de clientes ricos en mltiples dispositivos y canales o Una vista para cada dispositivo que puede varias segn sus capacidades o Una vista para la Web y otra para aplicaciones de escritorio Ms claridad de diseo Facilita el mantenimiento Mayor escalabilidad

Patrones de diseo en el MVC

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

Observer: Para el mecanismo de publicacin y suscripcin que permite la notificacin de los cambios en el modelo a las vistas. Composite: para la creacin de vistas compuestas. Utilizando este patrn podemos crear una jerarqua de vistas y tratar a cada vista compuesta igual que una a una vista normal. Strategy: En la relacin entre las vistas y los controladores. Utilizando este patrn podemos cambiar dinmicamente o en tiempo de compilacin los algoritmos del controlador mediante los cuales responde a su entorno. Factory Method: Para especificar la clase controlador predeterminada de una vista. Decorator: Para aadir capacidades adicionales a una vista (por ejemplo, scroll). Proxy: Para distribuir la arquitectura (Modelo y Vista-Controlador) en diferentes emplazamientos.

Para obtener ms detalles sobre este caso particular de composicin de patrones, consulta el Captulo 1 del libro del GoF o de POSA. Principio de la pgina

Antipatrones

Los antipatrones son soluciones negativas que presentan ms problemas que los que solucionan. Son una extensin natural a los patrones de diseo. Comprender los antipatrones provee el conocimiento para intentar evitarlos o recuperarse de ellos. El estudio de los antipatrones permite conocer los errores ms 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 fciles de recordar. Los nombres siempre aluden al problema que tratan con humor. Se documentan mediante una plantilla (como los patrones de diseo) que incluye secciones para documentar la solucin orgen (que es la causa del problema), el contexto, las fuerzas en conflicto y las soluciones correctas propuestas (para ms detalles sobre la plantilla, ver el Captulo 3 de Antipatterns). Un buen antipatrn explica por qu la solucin original parece atractiva, por qu se vuelve negativa y cmo recuperarse de los problemas que sta genera. Segn James Coplien, un antipatrn es... ...algo que se ve como una buena idea, pero que falla malamente cuando se la implementa. La Figura 3 muestra una comparacin entre patrones y antipatrones:

Figura 3: Patrones y antipatrones [McCormick98].Volver al texto . Nota cmo en los antipatrones se parte desde una solucin (que es la que genera el problema), mientras que en los patrones se parte de un problema a resolver. Por qu estudiar antipatrones

Un antipatrn (antipattern, en ingls) es una forma literaria que describe una solucin comn a un problema que genera decididamente consecuencias negativas. Segn el libro AntiPatterns: Refactoring Software , Architectures and Projects in Crisis, los antipatrones...:

Son un mtodo eficiente para vincular una situacin general a una clase de solucin especfica. Proveen experiencia del mundo real para reconocer problemas recurrentes en la industria del software, ofreciendo tambin una solucin para sus implicaciones ms comunes. Establecen un vocabulario comn para identificar problemas y discutir soluciones. Soportan la resolucin holstica de conflictos, utilizando recursos organizacionales a diferentes niveles.

Categoras de antipatrones En el libro de antipatrones, stos se dividen en 3 grandes categoras a las cuales se denominan puntos de vista:

Desarrollo de Software: Se centran en problemas asociados al desarrollo de software a nivel de aplicacin. Arquitectura de Software: Se centran en la estructura de las aplicaciones y componentes a nivel de sistema y empresa. Gestin de Proyectos de Software: En la ingeniera del software, ms de la mitad del trabajo consiste en comunicacin entre personas y resolver problemas relacionados con stas. Los antipatrones de gestin 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 distribucin de los antipatrones definidos en el libro en las categoras mencionadas anteriormente: Desarrollo de software The Blob Lava Flow Functional Decomposition Poltergeists Golden Hammer Spaghetti Code Cut and Paste Programming Mini antipatterns

Arquitectura Stovepipe Enterprise Vendor Lock-in Architecture by Implication Design by Committee Reinvent the Wheel

Gestin Analysis Paralysis Death by Planning Corncob Irrational Management Project Missmanagement

Mini antipatterns Mini antipatterns

Continuous Obsolescence Ambiguous Viewpoint

Autogenerated Stovepipe Jumble Cover your Assets Wolf Ticket Warm Bodies Swiss Army Knife

Blowhard Jamboree Viewgraph Engineering Fear of Success Intellectual

Boat Anchor Dead End Input Kludge Walking through a Minefield Mushroom Management

The Grand Old Duke of York

Violence Smoke and Mirrors Throw it over the wall Fire Drill The Feud E-Mail is Dangerous

Tabla 4: Clasificacin de antipatrones. Volver al texto . En este mismo libro se plantea un modelo de referencia terico que va ms all de estas divisiones. Para ms detalles sobre el modelo, consulta los Captulos 2, 3 y 4 de esta obra. Principio de la pgina

Otros tipos de patrones...

Los patrones pueden encontrarse en todas las reas de la ingeniera informtica. A continuacin, enumeraremos una serie de reas donde existen patrones aceptados y conocidos en la industria:

Idiomas: Son especficos del lenguaje de programacin. Describen cmo implementar ciertos aspectos de un problema utilizando las caractersticas de un lenguaje de programacin. Patrones de Anlisis: 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 notacin preUML. Patrones de Integracin de Aplicaciones: Patrones para integracin de aplicaciones. La obra ms 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 categoras bien diferenciadas: algunas se encargan de detalles relacionados con la cognicin, memoria a corto plazo y mejoras en la experiencia del usuario, mientras que otros describen tcnicas de ingeniera para crear interfaces de usuario. Patrones de Pruebas: Patrones para disear y realizar pruebas.

Principio de la pgina

Patrones en todas partes!

Al momento de escribir este trabajo, una bsqueda de la palabra pattern en los principales buscadores retorna ms de 20.000.000 resultados. Evidentemente no todos los resultados se refieren a patrones de software, pero en la primera pgina de resultados

aparecen sitios emblemticos 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 tecnologas. Principio de la pgina

Referencias
Alexander, Christopher: A Timeless Way of Building, Oxford University Press, 1979. Alexander, Christopher et al.: A Pattern Language, Oxford University [AIX77] Press, 1977. Brown, W., Malveau, R., Mc Cormick III, H., Mowbray, T.: [BMMM98] Antipatterns: Refactoring Software , Architectures and Project in Crisis, Wiley and Sons, 1998. Buschmann, Frank et al.: Pattern Oriented Software Architecture, [Buschman96] Volume 1: A System of Patterns, Willey & Sons, 1996. Cueva Lovelle, Juan Manuel: Tecnologa de Objetos: Patrones de [Cueva04] Diseo, 2004. [Evitts00] Evitts, Paul: A UML Pattern Language, SAMS Publishing, 2000. Fowler, Martin: Enterprise Application Architecture Patterns, Addison [Fowler03] Wesley, 2003. Fowler, Martin: Analysis Patterns: Reusable Object Models, Adisson [Fowler97] Wesley, 1997. Fowler, Martin: Refactoring: Improving the Design of Existing Code, [Fowler99] Adisson Wesley, 1999. Gall, John: Systemantics: How Systems Work and Especially How They [Gall75] Fail, New York, Quadrangle, 1975. Gamma E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: [GoF95] Elements of Reusable Object Oriented Software, Addison Wesley, 1995. Hillside Group: Home of the Patterns Library, 2003 <en lnea> [Hillside03] http://hillside.net/. Hophe, Gregor, Woolf, Robert: Enterprise Integration Patterns: [Hophe03] Designing, Building, and Deploying Messaging Solutions, Addisson Wesley, 2003. [Kerievsky04] Kerievsky, Joshua: Refactoring to Patterns, Addison-Wesley, 2004. McCormick, Hays: Antipatterns Tutorial, 1998 <en lnea> [McCormick98] http://www.antipatterns.com/briefing/sld001.htm. [Microsoft03] Microsoft Corp: Enterprise Solution Patterns, Microsoft Press, 2003. Microsoft Corp: Enterprise Development Reference Architecture, [Microsoft04] Microsoft Press, 2004. [PPR04] C2 WikiWikiWeb: Portland Pattern Repository <en lnea> [Alexander79]

[ST01] [Vlissides98]

http://c2.com/ppr/. Shalloway, Alan; Trott James: Design Patterns Explained: A New perspective on Object Oriented Design, Pearson Education, 2001. Vlissides, John: Pattern Hatching: Design Patterns Applied, Addison Wesley, 1998.

Len Welicki es Profesor Asociado de Ingeniera Web en el Mster en Ingeniera del Software de la Universidad Pontificia de Salamanca, Madrid, Espaa; donde actualmente est realizando el Doctorado en Ingeniera Informtica, su tesis doctoral trata sobre las Arquitecturas de Software y Paradigmas No Convencionales para Ingeniera Web. Trabaja como Arquitecto de Software. Cuenta con ms de 12 aos de experiencia profesional en diversas reas de la Ingeniera del Software.
Fuente: http://msdn.microsoft.com/es-es/library/bb972251.aspx#EEAA