Patrones de arquitectura

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 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 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] [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 Layers Pipes and Filtres Blackboard

Distributed Systems Broker

Interactive Systems Model-View-Controller Presentation-AbstractionControl

Adaptable Systems 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. 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 Web Offline Session Distributio Base toRelational Presentatio Concurrenc State n Patterns Patterns Databases n Patterns y Patterns Patterns

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 

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

Remote Façade Data Transfer Object

Client Session Optimistic State Offline Lock  Server Pesimistic Session Offline Lock  State CoarseDatabas Grained Lock  e Implicit Lock  Session State

Gateway Mapper Layer Supertyp e Separated Interface Registry Value Object Money Special Case Plugin 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: 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:

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 prin cipales beneficios son: 



Menor acoplamiento Desacopla las vistas de los modelos o o 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 (l a 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 o Se puede crear, añadir, modificar y eliminar nuevas vistas o dinámicamente Las vistas pueden anidarse o o Se puede cambiar el modo en que una vista responde al usuario sin cambiar su representación visual o Se puede sincronizar las vistas Las vistas pueden concentrarse en diferentes aspectos del modelo o Mayor facilidad para el desarrollo de clientes ricos en múltiples dispositivos y canales o Una vista para cada dispositivo que puede varias según sus capacidades o Una vista para la Web y otra para aplicaciones de escritorio Más claridad de diseño Facilita el mantenimiento Mayor escalabilidad o





  

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. Principio de la página

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 l os 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 i ncluye 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:

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 The Blob Lava Flow Functional Decomposition Poltergeists Golden Hammer Spaghetti Code Cut and Paste Programming 



















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

   



 

Mini antipatterns Mini antipatterns 

Mini antipatterns  



Continuous Obsolescence Ambiguous Viewpoint

Gestión Analysis Paralysis Death by Planning Corncob Irrational Management Project Missmanagement

   

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: 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. Principio de la página

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 preUML. 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.

Principio de la página

¡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. Principio de la página

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 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 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

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. Fuente: http://msdn.microsoft.com/es-es/library/bb972251.aspx#EEAA