Está en la página 1de 13

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

También podría gustarte