Introducción

Un sistema de información es un sistema que recopila y guarda información. En este contexto, nos centraremos en ofrecer un buen sistema de información desde el punto de vista arquitectónico, sin preocuparnos por obtener diseños detallados a nivel de componentes de cada capa. Abordaremos patrones de la arquitectura multicapa o de aplicaciones empresariales. Estas aplicaciones manejan datos persistentes, que son accedidos concurrentemente, poseen una gran cantidad de lógica de negocio, y su acceso se produce a través de elaboradas interfaces de usuario. Además, suelen tener necesidades de integración con otras aplicaciones. Los patrones que se describen a continuación son soluciones simples y elegantes a problemas específicos del diseño de software orientado a objetos (OO), y no se enfocan en EDA (Event-Driven Architecture) ni en diseños específicos de un dominio. Se identifican por las clases e instancias participantes, sus roles y colaboraciones, y la distribución de responsabilidades.

Patrones Auxiliares

Modelo-Vista-Controlador (MVC)

El patrón MVC divide una aplicación interactiva en tres componentes:

• Modelo: Contiene la funcionalidad básica y los datos.
• Vista: Muestra la información al usuario y recoge la información del usuario.
• Controlador: Media entre la vista y el modelo.

Existe una variante activa o pasiva de este patrón.

• Ventajas:
  • El modelo es independiente de la representación de la salida y del comportamiento de la entrada, pudiendo haber múltiples vistas del mismo modelo.
  • Permite cambios independientes en la interfaz o en la lógica.
• Consideraciones:
  • Puede aumentar la complejidad.

MVC es un caso particular del patrón Observador. Las vistas se anidan en MVC, siendo un caso de patrón Compuesto.

Fachada

Si la dependencia fuera una asociación navegada, la responsabilidad de crear los elementos accedidos no debería recaer sobre el objeto que los accede. En su lugar, se delega en otro objeto para crearlo, siguiendo el patrón Factoría Abstracta. El patrón Fachada facilita la estructuración de un sistema en subsistemas. Cada subsistema debe implementar sus responsabilidades, evitando así sistemas monolíticos.

Factoría Abstracta

Factoría Abstracta proporciona una interfaz para crear familias de objetos relacionados o que dependen entre sí, sin especificar sus clases concretas.

• Ventajas:
  • Aísla las clases concretas que se crean en una aplicación y se manejan a través de las interfaces que implementan.
  • Facilita el intercambio de familias de productos.
  • Promueve la consistencia entre productos.
• Consideraciones:
  • La introducción de nuevos tipos de productos provoca la redefinición de la factoría.

Arquitecturas de Software

Arquitectura de una Capa

La arquitectura de una capa no divide al sistema en presentación, negocio e integración.

• Ventajas:
  • Es conceptualmente sencilla.
• Consideraciones:
  • No se puede modificar la interfaz de usuario ni la lógica del negocio sin afectar a las demás capas.
  • Complicación fáctica.

Arquitectura de Dos Capas

La arquitectura de dos capas diferencia entre la capa de presentación y el resto del sistema (sin diferenciar negocio de integración).

• Ventajas:
  • Permite cambios en la interfaz de usuario o en el resto del sistema sin interferencias mutuas.
  • Simplicidad fáctica.
• Consideraciones:
  • Mayor complicación arquitectónica que la de una capa.
  • No se puede modificar la lógica del negocio o la representación de los datos sin interferencias mutuas.

Arquitectura Multicapa

La arquitectura multicapa se compone de:

• Capa de clientes: Representa a todos los dispositivos o clientes del sistema.
• Capa de presentación: Encapsula toda la lógica de presentación.
• Capa de negocio: Proporciona los servicios del sistema.
• Capa de integración: Responsable de la comunicación con recursos y sistemas externos.
• Capa de recursos: Contiene los datos del negocio y recursos externos.

Todas estas son capas lógicas y podrían estar en máquinas distintas. Se puede modificar cualquier capa sin afectar a las demás.

• Ventajas:
  • Integración y reusabilidad.
  • Encapsulación.
  • Distribución.
  • Particionamiento.
  • Escalabilidad.
  • Mejora del rendimiento.
  • Mejora de la fiabilidad.
  • Manejabilidad.
  • Incremento en la consistencia y flexibilidad.
  • Soporte para múltiples clientes.
  • Desarrollo independiente.
  • Desarrollo rápido.
  • Empaquetamiento.
  • Configurabilidad.
• Consideraciones:
  • Posible pérdida de rendimiento y escalabilidad.
  • Riesgos de seguridad.
  • Gestión de componentes.

Patrones Específicos de Capas

Transferencia (Capa de Negocio)

El patrón de Transferencia busca independizar el intercambio de datos entre capas. Si queremos independizar las capas, éstas no pueden tener conocimiento de la representación de las entidades de cada capa.

• Aplicabilidad:
  • Cuando no se desee conocer la representación interna de una entidad dentro de una capa.
• Ventajas:
  • Independiza las capas.
• Consideraciones:
  • Aumenta mucho el número de objetos del sistema.

Data Access Object (DAO) (Capa de Integración)

El patrón Data Access Object (DAO) permite acceder a la capa de datos, proporcionando representaciones orientadas a objetos a sus clientes. Este patrón fuerza a conocer los mecanismos de acceso del sistema de gestión de datos y la representación de los datos en el sistema de gestión de datos. Así, se podría cambiar la capa de datos sin afectar a la capa de negocio. Solamente habría que actualizar la capa de integración. Es fundamental que los DAOs capturen y lancen las excepciones correspondientes al acceder a los recursos externos.

• Aplicabilidad:
  • Cuando se quiera independizar la representación y acceso a los datos de su procesamiento.
• Ventajas:
  • Independiza el tratamiento de los datos de su acceso y estructura.
  • Permite independizar la capa de negocio de la de datos.
• Consideraciones:
  • Aumenta el número de objetos del sistema.

Servicio de Aplicación (Capa de Negocio)

El patrón de Servicio de Aplicación centraliza la lógica del negocio que no debe estar en los clientes ni en la fachada, incluyéndola en servicios de la aplicación.

• Aplicabilidad:
  • Cuando se quiera representar una lógica del negocio que actúe sobre distintos servicios u objetos del negocio.
  • Para agrupar funcionalidades relacionadas o encapsular lógica no representada por objetos del negocio.

Los servicios de aplicación no suelen tener atributos para hacerlos más ligeros.

• Ventajas:
  • Centraliza la lógica del negocio.
  • Mejora la reusabilidad del código.
  • Evita la duplicación de código.
  • Simplifica la implementación de fachadas.
• Consideraciones:
  • Introduce un nivel más de indirección.