PATRONES ARQUITECTONICOS

DEFINICIÓN

Un patrón de arquitectura de software es un esquema genérico probado para

solucionar un problema particular, el cual es recurrente dentro de un cierto

contexto. Este esquema se especifica describiendo los componentes, con sus

responsabilidades y relaciones.

UTILIDAD Y CARACTERÍSTICAS

Patrones arquitectónicos son los patrones del software a los cuales ofrezca las

soluciones establecidas arquitectónico problemas adentro tecnología de dotación

lógica. Da la descripción de los elementos y del tipo de la relación junto con un

sistema de apremios en cómo pueden ser utilizados. Un patrón arquitectónico

expresa un esquema estructural fundamental de la organización para a sistema de

software, que consiste en subsistemas, sus responsabilidades e interrelaciones.

Con respecto a patrones del diseño, los patrones arquitectónicos son más grandes

en escala.

Aun cuando un patrón arquitectónico transporta una imagen de un sistema, él no

es una arquitectura como tal. Un patrón arquitectónico es algo un concepto que

captura elementos esenciales de una arquitectura del software. Diversas

arquitecturas incontables pueden poner el mismo patrón en ejecución y de tal

modo compartir las mismas características. Además, los patrones se definen a

menudo como algo “descrito terminantemente y comúnmente disponible”. Por

ejemplo, la arquitectura acodada es llamar-y-vuelve estilo, cuando define un estilo

total para obrar recíprocamente. Cuando se describe terminantemente y

comúnmente disponible, es un patrón.

Uno de los aspectos más importantes de patrones arquitectónicos es que

incorporan diversas cualidades de la calidad. Por ejemplo, algunos patrones

1

representan soluciones a los problemas de funcionamiento y otros se pueden

utilizar con éxito en sistemas de la alto-disponibilidad. En la fase de diseño

temprana, un arquitecto del software hace una opción de la cual los patrones

arquitectónicos proporcionen lo mejor posible las calidades deseadas del sistema.

Los patrones en general, y en particular los de arquitectura, son un intento de

formalizar la comunicación y el reúso de la experiencia

2

PATRONES ARQUITECTÓNICOS SIMPLES

Son aquellos que expresan un esquema organizativo estructural fundamental para

los sistemas de software.

Entre los cuales podemos hallar patrones de tipo Layers (o de Capas), de Tubos y

Filtros, de Pizarrón, o Repositorios.

SID: Sistema de Información Distribuido.

Es un sistema en el cual sus componentes se transmiten información y

mensajes, pueden intervenir varios actores, los cuales de alguna manera

participan en el proceso de circulación de la información entre ellos, de forma

independiente el uno del otro.

También es una manera de comparar software, hardware, personas y más

cosas que se combinan para construir un sistema que funcione.

Diseño de un SID.

Se deben distinguir dos aspectos fundamentales, los cuales son:

Diseño de Arriba-Abajo: Top-Down: En este tipo de diseño se piensa en

qué consiste el sistema, y vamos refinando en cada capa, empezamos

desde arriba y vamos diseñando hacia abajo, capa a capa, empezando por

la presentación, la lógica y la de datos.

Diseño de Abajo-Arriba: Bottom-Up: Es concretamente lo contrario del

sistema anterior, se empieza diseñando la capa de datos, y se va subiendo.

LAYERS (CAPA):

3

Es el patrón más común de los antes mencionados, este aplica el concepto de

Orientación a Objetos, consiste en estructurar aplicaciones que pueden ser

descompuestas en grupos de sub-tareas las cuales se clasifican de acuerdo a un

nivel particular de abstracción, permitiendo así la reutilización de componentes en

circunstancias similares.

CONTEXTO:

Los grandes sistemas requieren de descomposición.

Una forma de descomponer un sistema consiste en segmentar en

colaboración de objetos. Cuando estos grupos están bien segmentados, y

consolidadas sus interfaces, el resultado es una arquitectura en capas.

PROBLEMA:

Si los servicios de la organización no están bien organizados, el sistema

podría tener problemas de mantenibilidad, adaptabilidad y escalabilidad

SOLUCIÓN

Estructurar el sistema en un número apropiado de capas.

Empezar con la capa con el nivel más bajo de abstracción.

Poner la capa J sobre la J-1 hasta alcanzar la capa N.

Los servicios de J usan los servicios de J-1.

No se requiere un orden en la implementación, ni ninguna sofisticación.

Dentro de cada capa, las componentes tienen el mismo nivel de

abstracción.

La estructura puede verse como una pila o una cebolla

IMPLEMENTACIÓN

Definir los niveles de abstracción para agrupar las tareas.

Determinar el número de capas.

Designar y asignar tareas a las distintas capas.

4

Especificar los servicios de cada capa: es conveniente poner la

funcionalidad dependiente de la aplicación en las capas superiores, y

mantener las inferiores genéricas y sencillas.

Refinar las capas iterando sobre los 4 pasos anteriores: Reorganizar las

tareas de modo que sólo se invoquen servicios de la capa inmediatamente

anterior.

Especificar la interfaz de cada capa: Se incluyen todos los servicios

ofrecidos en la interfaz y la capa se trata como una caja negra.

Definir la estructura de cada capa.

Especificar la comunicación entre las capas: Llamadas a métodos,

mensajes.

Desacoplar capas adyacentes: La capa J no debe saber quien usa sus

servicios.

Diseñar una estrategia de manejo de errores: Los errores deben manejarse

en la capa más baja posible.

Algunas Arquitecturas de Capas son las siguientes:

Arquitectura de 1 Nivel : Este tipo de arquitectura hace que las tres capas:

presentación, negocio y datos se integren en un solo nivel. Este diseño hace se le

llama monolítico, no presentan ninguna tipo de interfaz, y suelen ser cerrados.

Arquitectura de 2 Niveles: Surge con la parición de los PCs, aquí se separara la

capa de presentación de las de datos y de lógica, incluyéndola en un mismo nivel

5

con el cliente, y las otras dos en otro nivel, de esta forma se puede aprovechar la

capacidad de procesamiento del cliente.

Arquitectura de 3 Niveles: Aparece el concepto de Middleware o componente

intermedio, debido a los problemas de integración de varios sistemas, se divide el

sistema en tres niveles, el del medio, incluye la parte de lógica de negocio, que

tiene responsabilidad de integrar las transacciones, balances de carga y

replicaciones.

ARQUITECTURA PIPER

Esta arquitectura se basa en filtros y consiste en ir transformando un flujo de datos

en un proceso comprendido por varias fases secuenciales, siendo la entrada de

cada una la salida de la anterior. Esta arquitectura es muy común en el desarrollo

6

de programas para el intérprete de comandos, ya que se pueden concatenar

comandos fácilmente con tuberías.

También es una arquitectura muy natural en el paradigma de programación

funcional, ya que equivale a la composición de funciones matemáticas.

ARQUITECTURA EN PIZARRA

Es un modelo arquitectónico de software habitualmente utilizado en sistemas

expertos, sistemas multi-agente y, en general, sistemas basados en el

conocimiento.

Consta de múltiples elementos funcionales, denominados agentes, y un

instrumento de control denominado pizarra. Los agentes suelen ser programas

especializados en una tarea concreta o elemental. Todos ellos cooperan para

alcanzar una meta común, si bien, sus objetivos individuales no están

aparentemente coordinados.

El comportamiento básico de cualquier agente consiste en examinar la pizarra,

realizar su tarea y escribir sus conclusiones en la misma pizarra. De esta manera,

otro agente puede trabajar sobre los resultados generados por el primero. La

computación termina cuando se alcanza alguna condición deseada entre los

resultados escritos en la pizarra.

La pizarra tiene un doble papel. Por una parte, coordina a los distintos agentes y,

por otra, facilita su intercomunicación. El estado inicial de la pizarra es una

descripción del problema a resolver. El estado final será la solución del problema.

Los resultados generados por los agentes deben responder a un lenguaje y

semántica común. En general, se suelen utilizar formalismos lógicos o

matemáticos, tales como expresiones lógicas de primer orden.

VENTAJAS

7

Esta arquitectura es tremendamente útil cuando el problema a resolver (o

algoritmo a implementar) es extremadamente complejo en términos cognitivos. Es

decir, cuando el flujo de control del algoritmo es enrevesado, o simplemente, no se

tiene un conocimiento completo del problema a resolver.

DESVENTAJAS:

No existe garantía de que se alcanzará una solución.

Es una arquitectura ineficiente, puesto que no existe una cota respecto al

tiempo de cómputo necesario para resolver el problema.

Es difícil obtener una traza de los pasos que llevaron a la solución, es decir,

no ofrece explicaciones.

8

PATRONES ARQUITECTÓNICOS PARA SISTEMAS INTERACTIVOS.

En muchas aplicaciones de software, la lógica del negocio inferior a la aplicación

tiende a ser relativamente estable. Sin embargo, ciertos aspectos de la aplicación,

tales como las interfaces con el usuario y los reportes tienden a cambiar.

Puesto que el software se debe mantener por períodos de tiempo largos, sería

pragmático separar los componentes que tienden a cambiar de aquellos que no

cambian. El patrón de arquitectura Modelo Vista Controlador permite la separación

de estos componentes.

El modelo representa simplemente los datos, las operaciones y la lógica del

negocio de la aplicación. No conoce acerca de las interfaces de usuario, de

mostrar datos, ni de los reportes generados. Es decir, el modelo es independiente

de la manera en la que se diseñan y desarrollan los componentes de software que

muestran los datos y producen los reportes.

La vista representa la lógica por la cual los datos son manipulados para

visualizarlos o para emitir reportes. Es la interfaz a través de la cual el modelo

muestra los datos al usuario y genera reportes. Típicamente, una aplicación tendrá

muchas vistas para manejar múltiples requerimientos de visualización y reportes.

La vista proporciona la lógica de la presentación para una aplicación de software,

está enterada de la existencia y de la naturaleza del modelo.

El controlador es un componente de software que controla las interacciones entre

el modelo y sus vistas. Traduce las interacciones del usuario a acciones que serán

implementadas por el modelo. El modelo no sabe nada sobre las vistas y la vista

no sabe nada sobre el controlador. Un solo modelo puede tener cualquier número

de pares vista-controlador.

9

La arquitectura MVC logra la separación de la capa de presentación de la capa de

la lógica del negocio de los diversos componentes de software y ayuda a facilitar

el mantenimiento del sistema.

El patrón MVC se especifica de la siguiente manera:

CONTEXTO:

Aplicaciones interactivas con interfaces humano-computador cambiantes y

flexibles.

PROBLEMA:

Las interfaces de usuario son muy frecuentemente cambiadas.

Cambios en la funcionalidad deben reflejarse en las interfaces.

Puede haber interfaces a medida para ciertos usuarios.

Diferentes paradigmas de interfaz:

• digitar información,

• seleccionar íconos.

Construir un sistema monolítico es caro y difícil.

FUERZAS:

la misma información se presenta de distintas formas,

cambios en los datos deben reflejarse en la interfaz inmediatamente,

las interfaces deben modificarse fácilmente, ojalá durante la ejecución,

distintas interfaces portables no deben afectar la operación esencial.

SOLUCIÓN:

MVC divide la aplicación en procesamiento, input y output.

10

El modelo representa la funcionalidad y los datos esenciales, y es

independiente de la representación en las interfaces.

La vista obtiene datos del modelo y los despliega para el usuario. Cada

vista tiene asociada un controlador. El controlador recibe eventos como

input (movimientos del mouse, activación de botones) y los traduce a

solicitudes de servicios del modelo o la vista.

El usuario interactúa con el modelo solamente a través de controladores.

11

PATRONES DE ARQUITECTURA: PRESENTACION-ABSTRACCION-

CONTROL (PAC)

Es un modelo de arquitectura de software, algo similar al modelo-vista-controlador

(MVC). PAC se utiliza como una estructura jerárquica de los agentes, cada uno de

ellos consistente en una tríada de presentación, la abstracción y el control de

partes. Los agentes (o tríadas) se comunican entre sí sólo a través del control de

parte de cada tríada. También difiere de MVC en que dentro de cada tríada, se

aísla por completo la presentación (vista en MVC) y la abstracción (modelo en

MVC), Este ofrece separar el modelo y la vista, lo cuál, da al usuario una

experiencia de usuario por los cortos periodos, de cómo la interfaz (presentación)

puede ser mostrada antes que la abstracción este completamente inicializada.

El control es algo similar al Controlador en la arquitectura MVC. Este procesa

eventos externos y actualiza el modelo. También se actualiza directamente la

parte de presentación. Sin embargo, es diferente del controlador en MVC en la

medida en que éste pasa los cambios que se están realizando a su componente

padre.

La Abstracción contiene los datos, al igual que en MVC. Sin embargo, puede ser

sólo una parte de la estructura de datos completa de la aplicación, y no

desempeñar un papel activo en la notificación de cambios.

La presentación es exactamente igual que la vista en el MVC. Muestra la

información desde la abstracción.

¿Cómo funciona?

El control padre crea los elementos de su hijo PAC, ya sea en el arranque del

programa, o dinámicamente en tiempo de ejecución.

12

Cuando el control de un PAC recibe un evento de usuario (1), este debe actualizar

su presentación (2a) y/o su abstracción (2b). A continuación, se envía un evento

de cambio a su padre (3). El padre actualiza sus hijos (pero no al nodo donde

surgió el cambio) (5), por lo que todos actualizan su Presentación (6a) y/o

abstracción (6b). Después que los nodos han sido actualizados, el padre se

actualiza (7). Esto termina cuando todos los elementos PAC necesarios han sido

actualizados.

Los hijos y padres pueden enviar eventos muy concretos para actualizar a sus

vecinos. De esta forma, los elementos PAC podrán decidir la extensión del efecto

del cambio. Pequeños cambios no tienen por qué ser propagados a través de toda

la jerarquía.

PROBLEMAS

Las actuales herramientas de programación visual tienen algo relacionado con

esta arquitectura, pero tienen todo tipo de peculiaridades y excepciones. Así que

se puede tratar de reconocer la arquitectura en herramientas visuales, pero no son

tan exactos. Además, la mayoría de herramientas dicen basarse en la arquitectura

MVC, lo que tampoco es completamente cierto.

13