Sie sind auf Seite 1von 37

Estilos

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.

• Existen conectores los cuales son


definidos por medio de protocolos
que determinan como interactúan las
capas.

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.

• Condicionales topológicos incluyen


interacciones limitadas de capas adyacentes.

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.

• Aún, si el sistema puede ponerse


en capas, consideraciones de
desempeño pueden requerir
acoplamiento entre capas
superiores e inferiores.

• Es difícil definir el número ideal


de capas.

• Baja eficiencia y trabajo


innecesario.

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

• Seleccionar un proyecto y generar la


arquitectura por capas. Utilizar el wiki para
presentar sus resultados. Fecha de entrega,
próxima clase.

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

• Son las conecciones entre:


• los filtros.
• la fuente de datos y el primer filtro.
• el último filtro y el resultado.

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

• MVC divide a una aplicación en tres


componentes. El modelo contiene la
funcionalidad y los datos. La vista despliega
la información al usuario. Controlador
maneja las entradas del usuario.

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

• Con ayuda del profesor, aplicar el MVC


para el problema de las votaciones.
• Realizarlo en Equipo.

jueves 8 de diciembre de 11
Broker

• Broker puede ser usado para estructurar


sistemas de software distribuidos, esto
desacoplando las llamadas a los
componentes que proveen los servicios y
sustituyendolas por invocaciones remotas.

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

• El broker tiene seis componentes: Clientes,


servidores, brokers, bridges, proxis cliente,
proxis servidor.

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

pack_data upd_repository pack_data


unpack_data reg_service unpack_data
send_request find_server send_request
return find_client call_service
forward_request
forward_response
acknowledgment

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

Das könnte Ihnen auch gefallen