Patrones de arquitectura

Los patrones arquitectónicos, o patrones de arquitectura, también llamados arquetipos

ofrecen soluciones a problemas de arquitectura de software en ingeniería de software. Dan una
descripción de los elementos y el tipo de relación que tienen junto con un conjunto de
restricciones sobre cómo pueden ser usados. Un patrón arquitectónico expresa un esquema de
organización estructural esencial para un sistema de software, que consta de subsistemas, sus
responsabilidades e interrelaciones. En comparación con los patrones de diseño, los patrones
arquitectónicos tienen un nivel de abstracción mayor.
Aunque un patrón arquitectónico comunica una imagen de un sistema, no es una arquitectura
como tal. Un patrón arquitectónico es más un concepto que captura elementos esenciales de
una arquitectura de software. Muchas arquitecturas diferentes pueden implementar el mismo
patrón y por lo tanto compartir las mismas características. Además, los patrones son a menudo
definidos como una cosa estrictamente descrita y comúnmente 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 comúnmente disponible, es un
patrón.
Uno de los aspectos más importantes de los patrones arquitectónicos 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 diseño, un arquitecto de software escoge qué patrones
arquitectónicos mejor ofrecen las calidades deseadas para el sistema.

Programación por capas

La programación por capas es un modelo de desarrollo software en el que el objetivo primordial
es la separación (desacoplamiento) de las partes que componen un sistema software o también
una arquitectura cliente-servidor: lógica de negocios, capa de presentación y capa de datos. De
esta forma, por ejemplo, es sencillo y mantenible crear diferentes interfaces sobre un mismo
sistema sin requerirse cambio alguno en la capa de datos o lógica.

La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles
y, en caso de que sobrevenga algún cambio, solo afectará al nivel requerido sin tener que revisar
entre el código fuente de otros módulos, dado que se habrá reducido el Acoplamiento
informático hasta una interfaz de paso de mensajes.
Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo,
cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que basta con
conocer la API que existe entre niveles.
En el diseño de sistemas informáticos actual se suelen usar las arquitecturas multinivel o
programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo
que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en caso
de que las necesidades aumenten).
Capas y niveles
1. Capa de presentación: la que ve el usuario (también se la denomina «capa de usuario»),
presenta el sistema al usuario, le comunica la información y captura la información del
usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay
errores de formato). También es conocida como interfaz gráfica y debe tener la
característica de ser «amigable» (entendible y fácil de usar) para el usuario. Esta capa
se comunica únicamente con la capa de negocio.
2. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las
peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de
negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las
reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para
recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al
gestor de base de datos almacenar o recuperar datos de él. También se consideran aquí
los programas de aplicación.
3. Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos.
Está formada por uno o más gestores de bases de datos que realizan todo el
almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de
información desde la capa de negocio.

Arquitectura de microservicios
La arquitectura de microservicios (en inglés, Micro Services Architecture, MSA) es una
aproximación para el desarrollo de software que consiste en construir una aplicación como un
conjunto de pequeños servicios, los cuales se ejecutan en su propio proceso y se comunican
con mecanismos ligeros (normalmente una API de recursos HTTP). Cada servicio se encarga
de implementar una funcionalidad completa del negocio. Cada servicio es desplegado de forma
independiente y puede estar programado en distintos lenguajes y usar diferentes tecnologías
de almacenamiento de datos.1
Se suele considerar la arquitectura de microservicios como una forma específica de realizar
una arquitectura orientada a servicios.
Arquitectura de microkernel

El patrón de arquitectura Microkernel se aplica a sistemas de software que deben estar

habilitados para adaptarse a requerimientos cambiantes del sistema. Separa un núcleo de
funcionalidad mínima de la funcionalidad extendida y de partes específicas al cliente. También
sirve como un socket para conectores en estas extensiones y coordinar su colaboración.

Las funciones centrales de un SO son controladas por el núcleo (kernel) mientras que la interfaz
del usuario es controlada por el entorno (shell). Por ejemplo, la parte más importante del DOS
es un programa con el nombre “COMMAND.COM” Este programa tiene dos partes. El kernel,
que se mantiene en memoria en todo momento, contiene el código máquina de bajo nivel para
manejar la administración de hardware para otros programas que necesitan estos servicios, y
para la segunda parte del COMMAND.COM el shell, el cual es el interprete de comandos.

Las funciones de bajo nivel del SO y las funciones de interpretación de comandos están
separadas, de tal forma que puedes mantener el kernel DOS corriendo, pero utilizar una interfaz
de usuario diferente. Esto es exactamente lo que sucede cuando cargas Microsoft Windows, el
cual toma el lugar del shell, reemplazando la interfaz de línea de comandos con una interfaz
gráfica del usuario. Existen muchos “shells” diferentes en el mercado, ejemplo: NDOS (Norton
DOS), XTG, PCTOOLS, o inclusive el mismo SO MS-DOS a partir de la versión 5.0 incluyó un
Shell llamado DOS SHELL.

Arquitectura en pizarra

La arquitectura en pizarra consta de múltiples elementos funcionales, denominados agentes, y

un instrumento de control denominado pizarra.

Los agentes suelen estar 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 otro.

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 que
resolver y 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.

Arquitectura dirigida por eventos

La Arquitectura dirigida por eventos, Event-driven architecture o EDA, es un patrón de

arquitectura software que promueve la producción, detección, consumo de, y reacción a
eventos.

Un evento puede ser definido como "un cambio significativo en un estado". Por ejemplo, cuando
un consumidor compra un coche, el estado del coche pasa de "se vende" a "vendido". La
arquitectura del sistema del vendedor de coches debe tratar este cambio de estado como un
evento, cuyo suceso puede ser conocido en otras aplicaciones en la arquitectura. Desde una
perspectiva formal, lo que es producido, publicado, propagado, detectado o consumido es un
mensaje (típicamente asíncrono) llamado notificación del evento, y no el evento en sí mismo, el
cual es el cambio de estado que disparó la emisión del evento. Los eventos no viajan, solamente
ocurren. Por otro lado, el término evento es frecuentemente usado para denotar el mensaje de
notificación en sí mismo, lo cual puede llevar a algún tipo de confusión.

Este patrón arquitectónico puede ser aplicado por el diseño e implementación de aplicaciones
y sistemas que transmitan eventos entre componentes software que estén emparejados
libremente y servicios. Un sistema dirigido por eventos está compuesto típicamente de emisores
de eventos (o agentes) y consumidores de eventos (o "sink" en inglés). Los consumidores tienen
la responsabilidad de llevar a cabo una reacción tan pronto como el evento esté presente. La
reacción puede o no puede ser completamente proporcionada por el consumidor en sí mismo.
Por ejemplo, el consumidor debe tener solamente la responsabilidad de filtrar, transformar y
reenviar el evento a otro componente o debe proporcionar una reacción propia a algún evento.

Construir aplicaciones y sistemas alrededor de una arquitectura dirigida por eventos permite a
estas aplicaciones y sistemas ser construidos de una manera que facilita un mayor grado de
reacción, debido a que los sistemas dirigidos por eventos están, por el diseño, más
normalizados para entornos no predecibles y asíncronos.

La arquitectura dirigida por eventos puede complementar la arquitectura orientada a servicios

(SOA) porque los servicios pueden ser activados por disparadores que se encuentran en
eventos entrantes. Este paradigma es particularmente útil cuando el consumidor no proporciona
algún contenedor ejecutivo propio.

SOA 2.0 engloba las implicaciones de las arquitecturas SOA y EDA proporcionando a un más
rico y más robusto nivel, creando un nuevo patrón de eventos. Este nuevo concepto de
disparadores de patrones de inteligencia promueve a humanos autónomos o procesamiento
automático que añade valor exponencial al negocio. Esto se debe a que se inyecta información
de valor añadido en patrón reconocido que no podía haber sido obtenido previamente.
Peer-to-peer

Una red peer-to-peer, red de pares, red entre iguales o red entre pares (P2P, por sus siglas en
inglés) es una red de ordenadores en la que todos o algunos aspectos funcionan sin clientes ni
servidores fijos, sino una serie de nodos que se comportan como iguales entre sí. Es decir,
actúan simultáneamente como clientes y servidores respecto a los demás nodos de la red. Las
redes P2P permiten el intercambio directo de información, en cualquier formato, entre los
ordenadores interconectados.

Normalmente este tipo de redes se implementan como redes superpuestas construidas en la

capa de aplicación de redes públicas como Internet.

El hecho de que sirvan para compartir e intercambiar información de forma directa entre dos o
más usuarios ha propiciado que parte de los usuarios lo utilicen para intercambiar archivos cuyo
contenido está sujeto a las leyes de copyright, lo que ha generado una gran polémica entre
defensores y detractores de estos sistemas.

Las redes peer-to-peer aprovechan, administran y optimizan el uso del ancho de banda de los
demás usuarios de la red por medio de la conectividad entre los mismos, y obtienen así más
rendimiento en las conexiones y transferencias que con algunos métodos centralizados
convencionales, donde una cantidad relativamente pequeña de servidores provee el total del
ancho de banda y recursos compartidos para un servicio o aplicación.

Dichas redes son útiles para diversos propósitos. A menudo se usan para compartir ficheros
(archivos) de cualquier tipo (por ejemplo, audio, vídeo o software). Este tipo de red también
suele usarse en telefonía VoIP para hacer más eficiente la transmisión de datos en tiempo real.
Arquitectura orientada a servicios

La Arquitectura Orientada a Servicios (SOA, siglas del inglés Service Oriented Architecture) es
un estilo de arquitectura de TI que se apoya en la orientación a servicios. La orientación a
servicios es una forma de pensar en servicios, su construcción y sus resultados. Un servicio es
una representación lógica de una actividad de negocio que tiene un resultado de negocio
específico (ejemplo: comprobar el crédito de un cliente, obtener datos de clima, consolidar
reportes de perforación)

El estilo de arquitectura SOA se caracteriza por:

Estar basado en el diseño de servicios que reflejan las actividades del negocio en el mundo
real, estas actividades hacen parte de los procesos de negocio de la compañía.

Representar los servicios utilizando descripciones de negocio para asignarles un contexto de

negocio.

Tener requerimientos de infraestructura específicos y únicos para este tipo de arquitectura, en

general se recomienda el uso de estándares abiertos para la interoperabilidad y transparencia
en la ubicación de servicios.

Estar implementada de acuerdo con las condiciones específicas de la arquitectura de TI en cada

compañía.

Requerir un gobierno fuerte sobre las representación e implementación de servicios.

Requerir un conjunto de pruebas que determinen que es un buen servicio.

El desarrollo e implementación de una arquitectura SOA se rige por los principios descritos en
el manifiesto SOA. Por otra parte la aplicación de la orientación a servicios se divide en 2
grandes etapas:

Análisis orientado a servicios (Modelado de servicios)

Diseño orientado a servicios, El diseño orientado a servicios cuenta con 8 principios de diseño
que se aplican sobre cada uno de los servicios modelados, esto principios de diseño son:

Contrato de servicio estandarizado: Los contratos de servicio cumplen con los mismos
estándares de diseño.

Bajo acoplamiento: Los servicios evitan acoplarse a la tecnología que los implementa y a su vez
reducen el acoplamiento impuesto a los consumidores.

Abstracción: Los contratos presentan la información mínima requerida y la información de los

servicios se limita a los expuesto en el contrato.

Reusabilidad: Los servicios expresan y contienen lógica de negocio independiente del

consumidor y su entorno, por lo tanto se convierten en activos de la empresa.

Autonomía: Los servicios deben tener un gran control de los recursos tecnológicos sobre los
cuales están implementados.
Sin estado: El servicio reduce el consumo de servicios al delegar el manejo de estados
(sesiones) cuando se requiera.

Garantizar su descubrimiento: Lo servicios cuentan con metadata que permite descubrirlos e

interpretar el servicio en términos de negocio.

Preparado para ser usado en composiciones: Los servicios pueden hacer parte de una
composición sin importar el tamaño y complejidad de la misma.

Modelo vista controlador

Modelo-vista-controlador (MVC) es un patrón de arquitectura de software, que separa los datos

y la lógica de negocio de una aplicación de su representación y el módulo encargado de
gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres
componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define
componentes para la representación de la información, y por otro lado para la interacción del
usuario.12 Este patrón de arquitectura de software se basa en las ideas de reutilización de
código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo
de aplicaciones y su posterior mantenimiento.