Patrones de arquitecturaLospatrones arquitectnicos, opatrones de arquitectura, tambin llamados arquetipos ofrecen soluciones a problemas de arquitectura de software en ingeniera de software. Dan una descripcin de los elementos y el tipo de relacin que tienen junto con un conjunto de restricciones sobre cmo pueden ser usados. Un patrn arquitectnico expresa un esquema de organizacin estructural esencial para un sistema de software, que consta de subsistemas, sus responsabilidades e interrelaciones. En comparacin con los patrones de diseo, los patrones arquitectnicos tienen un nivel de abstraccin mayor.Aunque un patrn arquitectnico comunica una imagen de un sistema, no es una arquitectura como tal. Un patrn arquitectnico es ms un concepto que captura elementos esenciales de una arquitectura de software. Muchas arquitecturas diferentes pueden implementar el mismo patrn y por lo tanto compartir las mismas caractersticas. Adems, los patrones son a menudo definidos como una cosaestrictamente descrita y comnmente disponible. Por ejemplo, la arquitectura en capas es un estilo de llamamiento-y-regreso, cuando define uno un estilo general para interaccionar. Cuando esto es descrito estrictamente y comnmente disponible, es un patrn.Uno de los aspectos ms importantes de los patrones arquitectnicos es que encarnan diferentes atributos de calidad. Por ejemplo, algunos patrones representan soluciones a problemas de rendimiento y otros pueden ser utilizados con xito en sistemas de alta disponibilidad. A primeros de la fase de diseo, un arquitecto de software escoge qu patrones arquitectnicos mejor ofrecen las calidades deseadas para el sistema.Ejemplos de patrones arquitectnicos incluyen los siguientes: Programacin por capas Tres niveles Pipeline Invocacin implcita Arquitectura en pizarra Arquitectura dirigida por eventos, Presentacin-abstraccin-control Peer-to-peer Arquitectura orientada a servicios Objetos desnudos Modelo Vista Controlador

Dominios en el diseo de patrones Control de acceso.Hay muchas situaciones en las cuales el acceso a datos, caractersticas y funcionalidad son limitadas a la definicin de los usuarios. Desde un punto de vista arquitectnico, acceder a determinadas partes del software debe tener un riguroso control. Concurrencia.Muchas aplicaciones deben manejar mltiples tareas de forma que simule el paralelismo. Hay muchas formas de manejar esta concurrencia y cada una puede ser presentada por un patrn arquitectnico diferente. Distribucin.El problema de distribucin dirige el problema de forma en que los sistemas o componentes se comunican con otros en un entorno distribuido. El patrn ms comn para afrontar el problema esthe broker. Actuando como unmiddlemanentre el componente cliente y el servidor. El cliente enva un mensaje albrokery ste se encarga de completar la conexin. Persistencia.Los datos persistentes son almacenados en bases de datos o archivos y pueden ser ledos o modificados por otros procesos ms adelante. En los entornos orientados a objetos esto va ms all y lo que puede ser accedido o modificable son las propiedades de los objetos.

Tipos de patrones arquitectnicos

A la hora de disear o elegir la arquitectura no contamos con una frmula pero si podemos decir que es un pre- requisito conocer los patrones arquitectnicos para abordar ciertos atributos de calidad. Los principales patrones arquitectnicos son:

N Tier Client- Server (Cliente- Servidor N- Niveles) Messaging (Comunicando) Publish Suscribe (Publicar- Suscribir) Broker (Agente) Process Coordinator (Coordinador de Proceso)

N Tier Client- Server (Cliente- Servidor N- Niveles)

Las propiedades clave de este patrn son:

Separacin de intereses: La presentacin, lgica de negocio y administracin de datos estn claramente divididos en diferentes capas. Comunicaciones sincrnicas: Las comunicaciones entre capas son pedido-respuesta sincrnicas. Las peticiones van en una nica direccin desde la capa cliente a travs de las capas de servidor Web ylgica de negocios hacia la capa de administracin de datos. Cada capa espera la respuesta de la otra capa antes de proceder Despliegue flexible: No hay restricciones respecto de cmo las aplicaciones multi-capa se despliegan. Todas las capas podran correr en la misma mquina o en el otro extremo- cada capa puede ser desplegada en su propia mquina. En las aplicaciones Web, la capa cliente es usualmente un navegador corriendo en un equipo de escritorio del usuario comunicndose de manera remota va Internet con los componentes de la capaWeb.

Messaging (Comunicando)Las propiedades clave de este patrn son:

Comunicaciones asincrnicas: Los clientes envan las peticiones a la cola, donde los mensajes son almacenados hasta que una aplicacin los remueve. Despus que el cliente ha escrito un mensaje en la cola, contina trabajando sin esperar que el mensaje sea removido. Calidad de servicio (QoS) Configurable: La cola puede ser configurada para una entrega de mayor velocidad, no confiable o entrega de menor velocidad, confiable. Las operaciones de la cola se pueden coordinar con las transacciones de la base de datos. Bajo Acoplamiento: No hay vnculo directo entre clientes y servidores. El cliente no es consciente de cul servidor recibe el mensaje. El servidor no es consciente de qu cliente vino el mensaje.

Publish Suscribe (Publicar- Suscribir)

Las propiedades clave de este patrn son:

Mensajera Muchos-a-Muchos: Los mensajes publicados son enviados a todos los suscriptores que se han registrado en un tpico. Muchos publicantes pueden publicar sobre el mismo tpico y muchos suscriptores pueden escuchar sobre el mismo tpico.

Calidad de servicio (QoS) Configurable: Adems de los mensajes no-confiables y confiables, el mecanismo de comunicacin subyacentes puede ser punto-a-punto o multicast/ broadcast. El primero enva un mensaje diferente para cada suscriptor en un tpico, el otro enva un mensaje que cadasuscriptor recibe. Bajo Acoplamiento: Al igual que messaging, no hay vnculo directo entre publicantes y suscriptores. Los publicantes no conocen quin recibe sus mensajes, y los suscriptores no conocen qu publicante envi el mensaje.

Broker (Agente)

Las propiedades clave de este patrn son:

Arquitectura Hub-and-spoke (Eje-rayo): El broker acta como un concentrador de mensajes (eje) y los Remitentes y Receptores se conectan como rayos (como en una rueda de bicicleta) . Las conexiones con el broker son a travs de puertos que estn asociados con un formato de mensaje especfico. Realiza ruteo de mensaje: El bloker incrusta la lgica de procesamiento para entregar un mensaje recibido en un puerto de entrada en un puerto de salida. El camino de entrega puede estar en el cdigo o depender de valores en el mensaje de entrada. Realiza transformacin del mensaje: La lgica del broker transforma el tipo de mensaje fuente recibidoen el puerto de entrada en el tipo de mensaje de destino requerido en el puerto de salida.

Process Coordinator (Coordinador de Proceso)

Las propiedades clave de este patrn son:

Encapsulamiento de Proceso: El coordinador de proceso encapsula la secuencia de pasos necesaria para completar un proceso de negocio. La secuencia puede ser arbitrariamente compleja. El coordinador es unnico punto de definicin para el proceso de negocio, haciendo fcil su comprensin y modificacin. Recibe la peticin de inicio del proceso, llama a los servidores en el orden definido por el proceso y emite los resultados. Bajo Acoplamiento: Los componentes servidores son inconcientes de su rol en todo el proceso de negocio y del orden de los pasos en el proceso. Los servidores simplemente definen un conjunto de servicios que debenrealizar y el coordinador los llama como una parte necesaria del proceso de negocio. Comunicaciones flexibles: Las comunicaciones entre el coordinador y los servidores pueden ser sincrnicas o asincrnicas. Para comunicaciones sincrnicas el coordinador espera hasta que los servidores responden.Para las comunicaciones asincrnicas el coordinador provee un mecanismo de llamada o respuesta cola/tpico y espera hasta que el servidor responda utilizando el mecanismo definido.

Cualidades de software que propician

CONFORMIDAD FUNCIONAL. Segn Pressman (Pressman, 1998) una arquitectura de calidad debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acomodar todos los requisitos implcitos que desea el cliente. Adems, debe proporcionar una idea completa de que es el software, enfocando los dominios de los datos, las funciones y los comportamientos. Segn Lawrence (Lawrence, 1998) la arquitectura del software le dice a los usuarios exactamente lo que el sistema de software har. ADAPTABILIDAD. Esta caracterstica la propone Sommerville (Sommerville, 1998) al sealar que ella mide cuan fcil es hacer cambios en una arquitectura; de seguro, esto implica componentes poco acoplados. En su opinin, un sistema de software adaptable tiene una alta trazabilidad; esto quiere decir, que hay una relacin clara entre los diferentes niveles de abstraccin. MODULARIDAD. Sin considerar el enfoque de diseo utilizado (estilo arquitectural) (Lawrence, 1998), el proceso de descomposicin separa el diseo en partes que lo componen, llamadas mdulos o componentes. Se dice que un sistema es modular cuando cada actividad del sistema de software es ejecutada exactamente por un componente y cuando las entradas y las salidas de los componentes estn bien definidas. Los mdulos se organizan jerrquicamente como resultado de la descomposicin. En la opinin de Pressman (Pressman, 1998), estos mdulos se integrarn para satisfacer los requisitos del sistema. Para este autor modularidad es el atributo del software que permite a un sistema ser manejable intelectualmente. Lawrence (Lawrence, 1998) adems agrega que los mdulos encapsulan informacin; la ventaja de esta caracterstica es que el diseo interno de cada componente est oculto para el resto de los otros componentes. NIVELES DE ABSTRACCIN. Segn Lawrence (Lawrence, 1998), estos mdulos se estructuran segn niveles de abstraccin. Estos niveles de abstraccin ayudan a entender el problema a ser resuelto por el sistema y la solucin propuesta. Segn Pressman (Pressman, 1998), cuando se plantea una solucin modular se pueden presentar muchos niveles de abstraccin. Cada fase del proceso de diseo es un refinamiento en el nivel de abstraccin. Pressman (Pressman, 1998) propone tres (3) niveles de abstraccin: Abstraccin procedimental. Es una secuencia dada de instrucciones que tiene una funcin especfica y limitada. Abstraccin de datos. Es una coleccin determinada de datos que describen un objeto de datos. Abstraccin de control. Implica un mecanismo de control del programa sin especificar detalles internos. ENTENDIBLE. Sommerville (Sommerville, 1998) seala que un sistema antes de hacerle un cambio debe ser entendido. En su opinin este entendimiento estar afectado por: La cohesin, el acoplamiento, la nominacin, la documentacin y la complejidad; inclusive, seala que la complejidad tiene una relacin directa con su fcil entendimiento. COHESIN. Es una consecuencia del ocultamiento de la informacin. Un mdulo con cohesin (Pressman, 1998) realiza solamente una tarea, requiriendo poca interaccin con el resto de los procedimientos que se realizan en el resto del sistema de software. Segn Sommerville (Sommerville, 1998) la cohesin es deseable debido a que una unidad (componente) representa una parte simple de solucin. Si es necesario cambiar el sistema, la parte correspondiente est en un solo lugar y lo que se desee hacer con l estar encapsulado en l. Segn Lawrence (Lawrence, 1998) la meta es hacer que los componentes sean lo ms cohesivos posible. ACOPLAMIENTO. Est relacionado con la cohesin. Es un indicador de la fuerza de interconexin entre los componentes o elementos de la arquitectura (Sommerville, 1998). Sistemas altamente acoplados tienen una fuerte interconexin, lo que se refleja en una gran dependencia entre los componentes. Los sistemas poco acoplados, por otro lado, tienen poca relacin entre sus componentes o elementos. La meta (Lawrence, 1998) es mantener el acoplamiento en el nivel ms bajo posible; la conectividad sencilla entre mdulos da como resultado un software que es ms fcil de comprender y menos propenso al efecto onda (Stevens et al., 1975) producido cuando los errores aparecen en una posicin y se propagan a lo largo del sistema. Pressman (Pressman, 1998) agrega que el acoplamiento depende de la complejidad de las interfaces entre los mdulos, del punto en el que se hace una entrada o referencia a un mdulo y de los datos pasan a travs de esa interfaz.