Contrastando arquitectura y patrn de diseo.

Los patrones de software facilitan el reutilizacin del diseo y de la arquitectura, capturando las estructuras
estticas y dinmicas de colaboracin de soluciones exitosas a problemas que surgen al construir aplicaciones.
Es un esquema genrico 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.

Los patrones en general, y en particular los de arquitectura, son un intento de formalizar la
comunicacin y el reuso de la experiencia de diseo,
capturan la experiencia probada de diseo de software,
describen problemas recurrentes que surgen en determinados contextos,
describen esquemas de soluciones probados,
Son una herramienta para los no expertos,
Ofrecen un paso ms hacia la ingeniera de software
Capas en modelos arquitectnicos
Los beneficios de trabajar un sistema en capas son:
- Se puede entender una capa como un todo, sin considerar las otras.
- Las capas se pueden sustituir con implementaciones alternativas de los mismos servicios bsicos
- Se minimizan dependencias entre capas.
- Las capas posibilitan la estandarizacin de servicios
- Luego de tener una capa construida, puede ser utilizada por muchos servicios de mayor nivel.


1. Capa de Presentacin: Referente a la interaccin entre el
usuario y el software. Puede ser tan simple como un men
basado en lneas de comando o tan complejo como una
aplicacin basada en formas. Su principal responsabilidad
es mostrar informacin al usuario, interpretar los comandos
de este y realizar algunas validaciones simples de los datos
ingresados.
2. Capa de Reglas de Negocio (Empresarial): Tambin
denominada Lgica de Dominio, esta capa contiene la
funcionalidad que implementa la aplicacin. Involucra
clculos basados en la informacin dada por el usuario y
datos almacenados y validaciones. Controla la ejecucin de
la capa de acceso a datos y servicios externos. Se puede
disear la lgica de la capa de negocios para uso directo por
parte de componentes de presentacin o su
encapsulamiento como servicio y llamada a travs de una
interfaz de servicios que coordina la conversacin con los clientes del servicio o invoca cualquier flujo o
componente de negocio.
3. Capa de Datos: Esta capa contiene la lgica de comunicacin con otros sistemas que llevan a cabo tareas por
la aplicacin. Estos pueden ser monitores transaccionales, otras aplicaciones, sistemas de mensajeras, etc.
Para el caso de aplicaciones empresariales, generalmente esta representado por una base de datos, que es
responsable por el almacenamiento persistente de informacin. Esta capa debe abstraer completamente a las
capas superiores (negocio) del dialecto utilizado para comunicarse con los repositorios de datos (PL/SQL,
Transact-SQL, etc.).
Tuberas y filtros
Una tubera (pipeline) es una popular arquitectura que conecta componentes computacionales filtros) a travs
de conectores (pipes), de modo que las computaciones se ejecutan a la manera de un flujo. Los datos se
transportan a travs de las tuberas entre los filtros, transformando gradualmente las entradas en salidas.

Debido a su simplicidad y su facilidad para captar una funcionalidad, es una arquitectura mascota cada vez que
se trata de demostrar ideas sobre la formalizacin del espacio de diseo arquitectnico, igual que el tipo de
datos stack lo fue en las especificaciones algebraicas o en los tipos de datos abstractos.

El sistema tubera-filtros se percibe como una serie de transformaciones sobre sucesivas piezas de los datos de
entrada. Los datos entran al sistema y fluyen a travs de los componentes. En el estilo secuencial por lotes
(batch sequential) los componentes son programas independientes; el supuesto es que cada paso se ejecuta
hasta completarse antes que se inicie el paso siguiente. Garlan y Shaw sostienen que la variante por lotes es un
caso degenerado del estilo, en el cual las tuberas se han vuelto residuales.

Arquitecturas de Pizarra o Repositorio
En esta arquitectura hay dos componentes principales: una estructura de datos que representa el estado actual
y una coleccin de componentes independientes que operan sobre l [SG96].

Si los tipos de transacciones en el flujo de entrada definen los procesos a ejecutar, el repositorio puede ser una
base de datos tradicional (implcitamente no cliente-servidor). Si el estado actual de la estructura de datos
dispara los procesos a ejecutar, el repositorio es lo que se llama una pizarra pura o un tablero de control.



Model-View-Controller (MVC)
Es un patrn de arquitectura de software que separa los datos de una aplicacin, la interfaz de usuario, y la
lgica de control en tres componentes distintos
Modelo: representa la informacin con la que trabaja la aplicacin, o sea, su lgica de negocio.
Vista: convierte el modelo en una pgina web que facilita al usuario interactuar con ella.
Controlador: es el encargado de procesar las interacciones del usuario y ejecuta los cambios adecuados
en el modelo o en la vista. La arquitectura MVC separa la lgica de negocio (el modelo) y la
presentacin (la vista), lo que permite un mantenimiento ms sencillo de las aplicaciones. El
controlador es el encargado de aislar al modelo y a la vista de los detalles del protocolo usado para las
peticiones (HTTP, consola de comandos, email, etc.). El modelo se encarga de la abstraccin de la lgica
referida a los datos, lo que permite que la vista y las acciones sean independientes de, por ejemplo, el
tipo de gestor de bases de datos que la aplicacin utiliza.