Organiza el sistema en capas con funcionalidades relacionadas entre sí. Una capa da servicios a la capa de encima, de modo que las capas de nivel inferior representan servicios núcleo que es probable se utilicen a lo largo de todo el sistema.

Patrón de arquitectura en capas. Adaptación tomada del libro de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson. Fig.6.6.

Un sistema para compartir documentos con derechos de autor que utiliza la arquitectura de capas.

El sistema de biblioteca se llama LIBSYS que es parecido a la biblioteca digital del Tecmilenio. Observa que en la capa inferior se encuentran las bases de datos que utilizan una interfaz para servir a la capa superior llamada “Índice de biblioteca”.

Arquitectura del sistema LIBSYS. Adaptación tomada del libro de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson. Fig. 6.7.

• Se usa para construir nuevas facilidades encima de los sistemas existentes.
• Cuando el desarrollo se dispersa a través de varios equipos de trabajo, y cada uno es responsable de una capa de funcionalidad.
• Cuando exista un requerimiento para seguridad multinivel.

• Permite la sustitución de capas completas en tanto se conserve la interfaz.
• Para aumentar la confiabilidad del sistema, en cada capa pueden incluirse facilidades redundantes (por ejemplo, autenticación).

• En la práctica, suele ser difícil ofrecer una separación limpia entre capas, y es posible que una capa de nivel superior deba interactuar directamente con capas de nivel inferior, en vez de que sea a través de la capa inmediatamente abajo de ella.
• El rendimiento suele ser un problema, debido a múltiples niveles de interpretación de una solicitud de servicio mientras se procesa en cada capa.
• Agregar capas puede aumentar la complejidad del sistema y contribuye a impactar en el rendimiento.

• Cada funcionalidad del sistema debe ser ubicada en una capa.
• Debe tener al menos 2 capas.
• Las relaciones entre capas no deben ser circulares. Es decir, una capa inferior no debería requerir de una capa superior.

El objetivo principal es permitir que la interfaz gráfica del usuario sea independiente del código del funcionamiento de la aplicación.

Este patrón arquitectónico divide en tres partes el diseño:

Modelo: gestiona el acceso y actualización de los datos de la aplicación y la lógica de procesamiento.

Vista: muestra una parte de los datos subyacentes e interactúa con el usuario. Habilita la presentación del contenido y la funcionalidad requerida por el usuario.

Controlador: gestiona el acceso al modelo y a la vista. Coordina el flujo de datos entre el modelo y la vista. Administra y notifica los cambios de estado.

Arquitectura MVC. Tomado del libro Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson. Fig. 6.3. Sólo para fines educativos.

El siguiente diagrama representa la arquitectura MVC de una WebApp.

El Controlador administra las solicitudes del usuario. Una vez que se reconoce el tipo de solicitud, envía al Modelo un pedido de comportamiento, éste accede a la base de datos y finalmente la Vista prepara los datos en el formato adecuado (HTML) para que pueda ser interpretado por el navegador del usuario.

Arquitectura MVC de una WebApp. Tomado del libro de Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico. (7a. ed.). México: McGraw Hill. Fig. 13.8. Sólo para fines educativos.

Puedes encontrar el MVC en desarrollos de aplicaciones WEB, en interfaces de usuario como las clases de Swing de Java o en otros frameworks como el de ASP.Net de Microsoft.

• Su implementación es modular, por lo que es más sencillo de modificarse o adaptarse a nuevos requerimientos.
• Es el patrón arquitectónico que mejor se adapta a los desarrollos Web.

• Es una arquitectura que requiere de un diseño orientado a objetos, por lo que obliga al desarrollador a utilizar lenguajes de programación con este paradigma.
• Se requiere de un mayor tiempo de desarrollo, ya que implica diseñar e implementar un mayor número de clases para lograr la modularidad.

• Debe existir al menos una instancia en el modelo, en la vista y en el controlador.
• La comunicación entre los tres módulos se realiza a través de mensajes de notificaciones de cambio de estado.

Permite compartir y manipular grandes cantidades de datos a través de un repositorio central de información, un componente que administra el acceso a la información y un conector que lee y escribe los datos.

Es una solución adecuada cuando existen múltiples componentes independientes.

Architectura centrada en datos. Diagrama tomado del libro Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico. (7a. ed.). México: McGraw Hill. Fig. 9.1. Sólo para fines educativos. .

El siguiente diagrama representa un sistema de administración empresarial que contiene tres tipos de componentes de acceso: aplicaciones Windows, aplicaciones web y programas que ejecutan scripts que accesan a la información sin ninguna interfaz gráfica del usuario llamados headless programs.

Como puedes observar, existe una esfera central de seguridad a la que todos los componentes del sistema deben acudir para corroborar las credenciales de acceso de los usuarios. .

Diagrama de la arquitectura de repositorio de un sistema de administración empresarial Tomado del libro Bass, L., Clements, P. y Kazman, R. (2012). Software Architecture in Practice. EE. UU: Addison - Wesley Professional.

Es útil en arquitecturas que requieren administrar grandes volúmenes de información por periodos extensos de tiempo como sistemas de información administrativa, sistemas CAD y entornos de desarrollo interactivo para software.

• Es ideal para compartir grandes cantidades de información.
• Los componentes pueden ser independientes unos de otros. Se pueden agregar nuevos componentes sin necesidad de interactuar con los existentes, siempre y cuando se ajusten al esquema de la arquitectura.
• Cualquier cambio a los datos del repositorio es propagado al resto de los componentes.

• Dado que el acceso a la información es centralizada en un repositorio puede generarse un cuello de botella afectando el rendimiento.
• El repositorio constituye un punto único de falla.
• Se requiere un esquema de redundancia y respaldo que suelen ser costosos.

• La interacción con la fuente de información debe realizarse a través del componente de acceso.
• La totalidad de datos se puede gestionar de manera consistente por lo que debe controlar cambios que atenten contra la integridad de la información.

Los datos fluyen (como en una tubería) de un componente a otro de forma sucesiva para su procesamiento hasta obtener información de salida útil.

Filtro: son componentes independientes que reciben información de entrada, la transforman en un proceso y generan salidas. Los filtros pueden ejecutarse de manera concurrente o asíncrona entre ellos, y pueden transformar información de forma incremental, es decir pueden producir más información de la que recibieron.

Tubería: es un conector entre el puerto de salida de un filtro al puerto de entrada del siguiente. Debe tener una sola fuente y tener un solo objetivo. Sólo transfiere la información no la transforma.

Según Bass, Clements y Kazman (2012), las características más importantes de la tubería son su capacidad de transferencia y almacenamiento de información (buffer size), velocidad de transmisión, protocolo de interacción y el formato de la información.

Arquitectura de tubería y filtro. Tomado del libro Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico. (7a. ed.). México: McGraw Hill. Fig. 9.2. Sólo para fines educativos.

El siguiente ejemplo describe un sistema de tubería y filtro en el que se obtienen información de las facturas y pagos generados en un periodo de tiempo. Esta información se transforma en recibos de pagos y recordatorios de pagos no efectuados.

Ejemplo de arquitectura de tubería y filtro. Tomado del libro de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson. Fig. 6.13. Sólo para fines educativos..

Esta arquitectura es ideal para aquellos sistemas en los que procesan grandes cantidades de información en batch o requieren registrar un gran número de transacciones. Una vez recopilada la información, se transfiere a otros procesos que la van depurando o manipulando hasta que finalmente la convierten en información útil para la toma de decisiones.

• El estilo del flujo de trabajo coincide con la estructura de muchos procesos empresariales por lo que es fácil de entender.
• Permite reutilizar componentes.
• Puede implementarse como un sistema secuencial o como uno concurrente.

• En escenarios con grandes cantidades de información, el procesamiento suele tomar considerables cantidades de tiempo.
• El procesamiento en paralelo requiere hardware con prestaciones superiores que puedan soportar la carga de información.
• En opinión de Sommerville (2011) y de Bass, Clements y Kazman (2012), los sistemas que son interactivos son difíciles de estructurar por medio de este patrón arquitectónico, ya que requiere procesar información de forma secuencial.

• Se requiere un diseño de abstracción y encapsulamiento de información, de tal manera que los componentes sólo requieran entradas de información en un formato específico, independientemente del proceso que se llevó a cabo en el componente anterior.
• El sistema debe ser dividido en componentes independientes y reusables para lograr que el sistema sea flexible y puedan a la vez ejecutarse en paralelo
• El procesamiento de datos en un sistema se organiza de forma que cada componente de procesamiento (filtro) sea discreto y realice un tipo de transformación de datos.