Beruflich Dokumente
Kultur Dokumente
Arquitectónicos
M.C. Juan Fco Garcilazo Ortiz
Tomado de: Pattern Oriented Software Architecture Volume 1, Frank Buschmann et al, Wiley
jueves 8 de diciembre de 11
Estilo Arquitectónico
• Un estilo arquitectónico define una
familia de sistemas en términos de
patrones de organización estructural.
• Un estilo arquitectónico define un
vocabulario de componentes y tipos
de conectores, y un conjunto de reglas
para combinarlos.
jueves 8 de diciembre de 11
Estilos Arquitectónicos a revisar.
Layers. MVC
Pipes & Filters Reactor
Broker Proactor
jueves 8 de diciembre de 11
Layers
• Un sistema en capas está organizado
jerárquicamente, cada capa provee
servicios a las capas de arriba y estas
sirven como clientes a las capas de
abajo.
jueves 8 de diciembre de 11
Layers
• En algunos de estos sistemas, las capas
interiores están ocultas de todas excepto de las
capas adyacentes que usan ciertas funciones
cuidadosamente seleccionadas a ser
exportadas.
jueves 8 de diciembre de 11
Layers - Properties
• Soporta el diseño basado
en incremento de niveles
de abstracción.
• Soporte al
mejoramiento de los
sistemas.
• Reuso.
jueves 8 de diciembre de 11
Layers - Concerns
• No todos los sistemas pueden ser
fácilmente estructurados en
capas.
jueves 8 de diciembre de 11
Implementation
1. Define cual será el criterio de abstracción para
agrupar componentes.
2. Determinar el numero de niveles de abstracción
de acuerdo al criterio.
3. Nombrar las capas y asignar tareas a cada una.
4. Especificar los servicios.
5. Refinar las capas. Repetir los pasos 1 a 4.
6. Especificar las interfaces para cada capa.
jueves 8 de diciembre de 11
Implementation
7. Estructurar las capas individuales.
8. Especificar la comunicación entre capas
adyacentes.
9. Desacoplar capas adyacentes.
10.Diseñar la estrategia para el manejo de
errores.
jueves 8 de diciembre de 11
Ejemplos
• Máquinas Virtuales
• APIs
• Sistemas de Información
• etc.
jueves 8 de diciembre de 11
To do
jueves 8 de diciembre de 11
Pipes & Filters
• Provee una estructura para sistemas que
procesan un “stream” de datos.
• Cada paso del procesamiento está
encapsulado en los componentes llamados
Filtros.
• Datos son pasados por las tuberias.
jueves 8 de diciembre de 11
Elementos
• Se tienen 4 elementos en este estilo
arquitectónico.
• Filtros
• Tuberias
• Fuente de Datos
• Resultado
jueves 8 de diciembre de 11
Filtros
• Filtros son unidades de procesamiento.
• El filtro enriquece, refina o transforma la entrada de
datos.
• La actividad de un filtro puede ser solicitada debido a
ciertos eventos.
• El siguiente filtro jala información.
• El filtro previo envía información.
• Comúnmente el filtro está en un ciclo donde envía y
recibe información.
jueves 8 de diciembre de 11
Tuberias
jueves 8 de diciembre de 11
To do
• En el foro de discusión grupal (pipes&Filters Foro
GRUPAL), discutir sobre las ventajas y desventajas de
los pipes y filters. Al terminar enviar su aportación al
foro PipesFilters y hacer dos comentarios sobre las
aportaciones del resto de los equipos.
• Generar un modelo de clases que sirva de base para
poder definir filtros y tuberias. Sugerencias: Crear las
clases filtro y tuberia para que puedan ser extendidas
por clases concretas de filtros. Mostrar un ejemplo
de implementación con el problema “KWIC”.
jueves 8 de diciembre de 11
Model-View-Controller
jueves 8 de diciembre de 11
Problemática
• El contexto para el uso del MVC son las aplicaciones
interactivas con interfaces humano-computadoras flexibles.
• Aplicaciones donde las HCI tienden a cambiar.
• Aplicaciones sufren cambios como:
• Información es presentada de diferente forma, ejemplo en
pastel , en barra.
• Se debe mostrar los datos en linea.
• Facilidad para realizar cambios a la interface.
• Portabilidad de las interfaces, posibilidad de poder tener
varios look and feel.
jueves 8 de diciembre de 11
MVC - Estructura
• El modelo contiene la funcionalidad principal
de la aplicación. Encapsula los datos y provee
los servicios para realizar las operaciones.
• Controladores utilizan los servicios del
modelo de acuerdo a como el usuario
demande.
• La vista utiliza visualiza la información que
proporciona el modelo.
jueves 8 de diciembre de 11
MVC - Modelo
Clase Colaboradores
Modelo •Vista
Responsabilidad •Controlador
•Provee la funcionalidad
principal de la app.
•Registra controladores
y vistas dependientes.
•Notifica a
componentes
dependientes de
cambios en los datos.
jueves 8 de diciembre de 11
MVC - Vista
Clase Colaboradores
Vista •Modelo
Responsabilidad •Controlador
•Crear e inicializar el
controlador.
•Desplegar información
al usuario.
•Implementar el
procedimiento de
actualización.
•Recuperar información
del modelo.
jueves 8 de diciembre de 11
MVC - Controlador
Clase Colaboradores
Controlador •Modelo
Responsabilidad •Vista
•Acepta entradas y
eventos del usuario.
•Traslada eventos a
peticiones de servicio
hacia el modelo o
despliega las peticiones
de la vista.
•Implementa el
procedimieto de
actualización, si es
necesario.
•Recuperar información
jueves 8 de diciembre de 11
MVC - Modelo
jueves 8 de diciembre de 11
to-do
jueves 8 de diciembre de 11
Broker
jueves 8 de diciembre de 11
Contexto y Problemática
• El contexto para el uso del Broker son las aplicaciones distribuidas y
posiblemente heterogeneas que cooperan por medio de componentes
independientes.
• Problemática
• La construcción de un conjunto no acoplado de aplicaciones que tienen que
interactuar en un ambiente distribuido. Para este tipo de aplicaciones se tiene
varios beneficios como son la flexibilidad, mantenimiento y facilidad de
cambios.
• Es necesario establecer la comunicación entre los componentes, si esto lo
realizan los componentes mismos tendremos un escenario con varias
limitaciones
• Servicios para adicionar, remover. intercambiar, activar y localizar componentes
serán necesarios..
• Para el desarrollador no debe existir diferencia entre realizar una aplicación en
un ambiente centralizado o distribuido.
jueves 8 de diciembre de 11
Broker - Estructura
jueves 8 de diciembre de 11
Broker - Estructura
• Servidores implementan objetos y exponen sus funcionalidades
por medio de interfaces.
• Clientes aplicaciones que accesan el servicio de cuando menos un
servidor.
• Broker es el mensajero que se encarga de mandar las peticiones del
cliente al servidor y mandar las respuestas del servidor al cliente.
• Proxy cliente se encarga de traducir la interacción entre le broker
y los componentes del cliente.
• Proxy cliente se encarga de traducir la interacción entre le broker
y los componentes del servidor.
• Bridges sirven para intercomunicar brokers.
jueves 8 de diciembre de 11
Broker
Clase Colaboradores
Cliente •Proxy-cliente
Responsabilidad •Broker
•Implementa la
funcionalidad del
usuario.
•Manda peticiones al
servidor por medio
del proxy cliente
jueves 8 de diciembre de 11
Broker
Clase Colaboradores
Servidor •Proxy Server
Responsabilidad •Broker
•Implementa los
servicios.
•Se registra asimismo
con el broker local.
•Envía respuestas y
excepciones al cliente
a traves del proxy
server.
jueves 8 de diciembre de 11
Broker
Clase Colaboradores
Broker •Clientes
•Servidor
Responsabilidad
•Proxy Cliente
•Registro de •Proxy Servidor
servidores.
•Bridge
•Ofrecer API para la
comunicación.
•Transferencia de
Mensajes.
•Recuperación en caso
de error.
•Interoperbilidad con
otros brokers.
•Localización de
brokers
jueves 8 de diciembre de 11
Broker
Clase Colaboradores
Proxy Cliente •Clientes
•Broker
Responsabilidad
•Encapsular
funcionalidad específica
del sistema.
•Mediador entre el
cliente y el broker.
jueves 8 de diciembre de 11
Broker
Clase Colaboradores
Proxy Servidor •Server
•Broker
Responsabilidad
•Llama los servicios que
se encuentran en el
server.
•Encapsular
funcionalidad específica
del sistema.
•Mediador entre el
Servidor y el Broker.
jueves 8 de diciembre de 11
Diagrama de clases
Proxy Cliente Broker Proxy Servidor
Cliente Server
Bridge
call_server init
pack_data run_service
start_task unpack_data
use_Broker_API use_Broker_API
forw_message
trans_message
jueves 8 de diciembre de 11
Ventajas del uso del Broker
• Localización Transparente.
• Componentes fáciles de extender y
cambiar.
• Portabilidad del Broker.
• Interoperabilidad entre Brokers.
• Reusabilidad.
jueves 8 de diciembre de 11
Desventajas del uso del Broker
• Eficiencia restringida.
• Baja tolerancia a fallos.
• Dificultad para probar y dar seguimiento.
jueves 8 de diciembre de 11
Aplicación para el Broker
jueves 8 de diciembre de 11