Embed Size (px)
Citation preview
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Comportamiento
Jose Emilio Labra GayoCurso 2020/2021
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Estilos según comportamientoFuncionamiento en tiempo de ejecuciónComponentes y conectores
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Secuencial BatchPipes & Filters
Pipes & Filters Interfaz Uniforme
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Secuencial - Batch
Programas separados son ejecutados en ordenLos datos deben pasarse de un programa al
siguiente
NotaEl estilo secuencial (batch) puede considerarse el abuelo de los estilos arquitectónicos
Etapa
Puerto escritura
Etapa
ComponenteEtapa
Conectorentre etapasEtapa
PuertoLectura
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Secuencial - BatchElementos:
Programas ejecutables independientesRestricciones
Encadenar salida de un programa a entrada de otroNormalmente, un programa debe esperar a que
termine la ejecución el programa anterior
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Secuencial - Batch
VentajasDébil acoplamiento entre
componentesRe-configurabilidadDepuración
Se puede depurar cada entrada de forma independiente
ProblemasNo proporciona interfaz
interactivoRequiere intervención
externaNo hay soporte para
concurrenciaBaja velocidad (throughput)
Alta latencia
Definiciones: Throughput: velocidad a la que algo puede procesarse
Ejemplo: nº trabajos/segundoLatencia: retardo experimentado por un proceso
Ejemplo: 2 segundos
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Secuencial - BatchProblemas
No proporciona interfaz interactivoRequiere intervención externaNo hay soporte para concurrencia
Baja velocidad (throughput)Alta latencia
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Pipes & FiltersDatos fluyen a través de tuberías (pipes) y son
procesados mediante filtros
Filtro
Puerto Lectura
Puerto Escritura
Filtro
Componentefiltro
Pipe óTubería
Filtro
Filtro Filtro
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Pipes & FiltersElementos
Filtro: componente que transforma los datos. Los filtros pueden ejecutarse concurréntemente.Tipos de filtros
Fuentes de datos (entrada al sistema)FlujoSumideros (sinks) (salida del sistema)
Tubería (Pipe): Lleva datos de la salida de un filtro a la entrada de otro filtroPropiedades: tamaño de búffer, formato de datos,
protocolo de interacción
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Pipes & Filters
RestriccionesTuberías conectan salidas de un filtro a entrada de otroLos filtros deben estar de acuerdo sobre los formatos
que admiten
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Pipes & FiltersVentajas
Comprensión global sistemaComportamiento total = suma
comportamiento de cada filtro
Reconfiguración: Filtros pueden recombinarse
Evolución y extensibilidad: Crear/añadir nuevos filtrosSe pueden sustituir filtros
viejos por nuevosTestabilidad
Verificación independiente de cada filtro
RendimientoPermite ejecución
concurrente entre filtros
RetosPosibles retardos si hay
tuberías largasDifícil pasar estructuras de
datos complejasNo interactividad
Un filtro no puede interactuar con el entorno
BackpressureConsumidores que reciben más
cantidad de datos de la que pueden procesar
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Pipes & FiltersAplicaciones
Unixwho | wc -l
Yahoo PipesJava StreamsFlow based programming
https://en.wikipedia.org/wiki/Flow-based_programmingStream programming
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Pipes & Filters - interfaz uniformeVariación de Pipes & Filters en la que los filtros
tienen la misma interfazElementos
Los mismos que en Pipes & FiltersRestricciones
Los filtros deben tener una interfaz uniforme
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Pipes & Filters - interfaz uniformeVentajas:
Facilita desarrollo independiente de filtrosMás fácil porque el interfaz es conocido
ReconfigurabilidadFacilita la comprensión del sistema
Problemas:Empeora rendimiento si los datos deben
transformarse desde su representación originalMarshalling
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Pipes & Filters - interfaz uniformeEjemplos:
Sistema operativo UnixProgramas con una entrada (stdin) y dos salidas
(stdout y stderr)Arquitectura de la Web: REST
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Master-Slave
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Master-SlaveMaestro divide el trabajo en subtareasAsigna cada subtarea a diferentes nodosEl resultado computacional se obtiene a partir de
los resultados de los nodos esclavos
Slave 1 Slave 2
Master
Slave N. . .
Problema
tarea 1 tarea 2 tarea N
Solución
resultado Nresultado 2resultado 1
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Master-SlaveElementos
Master: Se encarga de coordinar la ejecuciónSlave: realiza una tarea y devuelte un resultado
RestriccionesLos slave se encargan únicamente de realizar la
computaciónEl control es realizado desde el nodo Master
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Master-SlaveVentajas
Computación paralelaTolerancia a fallos
ProblemasDificultad de coordinación entre nodos slaveDependencia de nodo MasterDependencia de configuración física
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Master-SlaveAplicaciones:
Sistemas de control de procesosSistemas empotradosSistemas tolerantes a fallosSistemas de búsqueda de soluciones precisas
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
MVC: Modelo - vista - controladorVariaciones de MVC
PAC: Presentación - Abstracción - ControlDCI : Datos - Contexto - Interacción
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
MVCMVC: Modelo - Vista - Controlador
Trygve Reenskaug, finales de los 70Solución para GUIIncorpora un controlador para separar el modelo
de la vista que se ofrece al usuarioEl usuario trabaja con un "modelo mental" del
modelo real, que se ofrece a través de vistas
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
MVC
Modelo: Lógica de negocio y estadoVista: Muestra datos al usuarioControlador: Coordina interacción, vistas y modelo
Modelo mental
Controlador
Modelo
Vista 1
Vista 2
Usuario
CuboEsferaCono
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
MVCElementos
ModeloRepresenta lógica de negocio y estadoEnlace con almacén de datos y actualización
VistaMuestra contenidos de un modelo
ControladorRecibe interacciones del usuario con la vistaCoordina acciones a realizar por modeloCreación/coordinación de vistas
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
MVCRestricciones
El controlador se encarga de procesar los eventos del usuario
La vista se encarga únicamente de mostrar valores del modelo
Modelo es independiente de controladores/vistas
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
MVCVentajas
Múltiples vistas del mismo modelo
Sincronización de vistasSeparación de
incumbenciasInteracción (controlador),
funcionalidad (modelo)Facilidad para crear nuevas
vistas y controladoresIntercambiar look & feel
Potencial para creación de marcos genéricos
ProblemasMayor complejidad en
desarrollo de GUIsAcoplación entre
controladores y vistasControlador/Vistas
dependen del interfaz del modelo
Dificultades con herramientas GUI
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
MVC
AplicacionesMuchos marcos de aplicación Web siguen MVC
Ruby on Rails, Spring MVC, Play, etc.Diferencia
Push: el controlador envía órdenes a la vistaRuby on Rails, Struts1
Pull: el controlador recibe órdenes de la vistaPlay! Framework, Struts2
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Variaciones de MVCPACModel-View-PresenterModel View ViewModelModel View Update...
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
PAC
PAC: Presentación-Abstracción-ControlJerarquía de agentesCada agente contiene 3 componentes
PresentaciónAbstracción Control
Agente PAC
PresentaciónAbstracción Control
Agente PAC
PresentaciónAbstracción Control
Agente PAC
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
PAC
ElementosAgentes con
Presentación: aspecto de visualizaciónAbstracción: modelo de datos de un agenteControl: conecta los componentes anteriores y permite la
comunicación entre agentesRelación jerárquica entre agentes
RestriccionesCada agente se encarga de un aspecto de la
funcionalidadEn cada agente no hay comunicación directa entre
Abstracción y PresentaciónComunicación a través de componente de control
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
PACVentajas
Separación de responsabilidades
Soporte para cambios y extensionesmodificar un agente sin
modificar el restoMultitarea
Los agentes pueden ejecutarse en paralelo
ProblemasComplejidad del sistema
Demasiados agentes pueden generar una estructura compleja y difícil de mantener
Complejidad del componente de controlComponentes de control
gestionan comunicaciónSu calidad es fundamental
para la calidad del sistemaRendimiento
Sobrecarga de comunicación entre agentes
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
PACAplicaciones
Sistema de monitorización de redesRobots móviles
RelacionesRelacionado con MVC
En MVC el componente de Presentación se separa en Vista y Controlador
En MVC no hay componentes de control ni jerarquía de agentes.
Redescubierto y rebautizado como MVC jerárquico
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Datos compartidosBlackboardBasados en reglas
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Datos compartidosVarios componentes independientes acceden al
mismo estadoAplicaciones basadas en un modelo centralizado
Componente Componente
Datoscompartidos
Componente...
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Datos compartidosElementos
Almacén de datosBase de datos o repositorio centralizado
ComponentesProcesadores que acceden a la memoria compartida
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Datos compartidosRestricciones
Componentes actúan sobre el estado globalLos componentes no se comunican entre sí
Sólo a través del estado compartidoEl estado garantiza la estabilidad de los datos
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Datos compartidos
VentajasComponentes
independientesNo necesitan conocer
existencia de otros componentes
Facilita comunicación entre componentes
Consistencia de datosEstado global centralizadoBackup único de todo el
sistema
ProblemasPunto de fallo único
Fallo del almacén puede comprometer todo el sistema
Distribución del almacén puede ser costosa
Posible cuello de botellaIneficiencia en
comunicaciónSincronización en acceso
a memoria compartida
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Datos compartidosAplicaciones
Gran cantidad de sistemas utilizan este esquemaAlgunas variantes
Este patrón se conoce también como:Shared Memory, Repository, Shared data, etc.
BlackboardSistemas basados en reglas
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
BlackboardProblemas complejos de difícil solución
Se dividen en fuentes de conocimiento que resuelven partes del problema
Cada fuente de conocimiento agrega soluciones parciales en el blackboard
Fuente conocimiento
Fuenteconocimiento
Blackboard
FuenteConocimiento ...
Control
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Blackboard
ElementosBlackboard: Almacén de datos centralFuente de conocimiento: resuelve una parte del
problema y va añadiendo los resultados parcialesControl: Organiza tareas y chequea estado del
trabajo
Fuente conocimiento
Fuenteconocimiento
Blackboard
FuenteConocimiento ...
Control
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
BlackboardRestricciones
El problema se descompone en partesCada fuente de conocimiento sólo resuelve una
parte del problemaEl blackboard contiene soluciones parciales que
van mejorándose
Fuente conocimiento
Fuenteconocimiento
Blackboard
FuenteConocimiento ...
Control
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Blackboard
VentajasExperimentación
Aplicable para problemas abiertos
Facilita cambio de estrategias
ReusabilidadFuentes de
conocimiento reutilizables
Tolerancia a fallos
ProblemasDepuración
No hay garantía de encontrar solución adecuada
Dificultad para establecer estrategia central de control
RendimientoPuede ser necesario rechazar
hipótesis incorrectasAlto coste de desarrollo
Implementación del paralelismo
Necesidad de sincronizar acceso al blackboard
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
BlackboardAplicaciones
Sistemas de reconocimiento del hablaHEARSAY-II
Reconocimiento de patronesPredicción atmosféricaJuegos Análisis de estructura molecular
Crystalis
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Sistemas basados en reglasVariante de memoria compartida
Memoria compartida = Base de conocimientoContiene reglas y hechos
Motor de inferencia
Base de conocimiento
Interfaz de usuario
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Sistemas basados en reglasElementos:
Base de conocimiento: Conjunto de hechos y reglas sobre un determinado dominio
Interfaz de usuario: Accede a la base de conocimiento para consultar/modificar
Motor de inferencia: Sistema encargado de responder consultas a partir de los datos y la base de conocimiento
Motor de inferencia
Base de conocimiento
Interfaz de usuario
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Sistemas basados en reglasRestricciones:
Base de conocimiento declarativaSe basa en reglas del tipo:
IF antecedentes THEN consecuenteExpresividad limitada respecto lenguajes imperativos
Motor de inferencia
Base de conocimiento
Interfaz de usuario
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Sistemas basados en reglas
VentajasMantenibilidad
Solución declarativaPuede ser gestionada
por expertos del dominio
Separación de responsabilidadesAlgoritmoConocimiento del
dominioReutilización
ProblemasDepuraciónRendimiento
Sistema de inferenciaCreación y mantenimiento
de las reglasActualización de las reglas
en tiempo de ejecuciónAprendizaje de nuevas
reglasIntrospección
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Sistemas basados en reglasAplicaciones
Sistemas expertosSistemas de producciónLibrerías de reglas en Java
JRules, Drools, JESSLenguajes basados en reglas
PrologBRMS - Business rules management systems
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Call-returnCliente-ServidorArquitecturas basadas en eventos
Publish-SubscribeModelos de Actores
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Call-returnUn componente realiza una llamada a otro
componente y espera a recibir la respuesta
Componente A Componente B
call
return
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Call-returnElementos
Componente que realiza la llamadaComponente que devuelve la respuesta
RestriccionesComunicación síncrona:
Componente que realiza llamada queda esperando la respuesta.
Componente A Componente B
call
return
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Call-returnVentajas
Sencillo de implementarProblemas
Problemas para ejecución concurrenteComponente queda bloqueado esperando respuesta
Puede estar ocupando recursos generando bloqueosEntornos distribuidos
Poco aprovechamiento de capacidades computacionales
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Cliente-ServidorVariación de sistemas en capas
2 capas separadas físicamente (2-tier)Funcionalidad separada en varios servidoresClientes se conectan a los servicios
Interfaz Petición/respuesta
Red
petición
respuesta
clienteservidor
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Cliente-ServidorElementos
Servidor: ofrece servicios a través de un protocolo petición/respuesta
Cliente: realiza peticiones y procesa las respuestasProtocolo de red: gestión de comunicación entre
clientes y servidores
Red
petición
respuesta
ClienteServidor
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Cliente-ServidorRestricciones
Clientes se comunican con servidoresNo al revés
Clientes son independientes de otros clientesLos servidores no conocen a los clientesProtocolo de red ofrece garantías de comunicación
petición
respuesta
ClienteServidor
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Cliente-Servidor
VentajasServidores pueden estar
distribuidosSeparación de funcionalidad
cliente/servidorDesarrollo independienteEscalabilidad
Funcionalidad general disponible para todos los clientesAunque no todos los
servidores deben ofrecer toda la funcionalidad
ProblemasCada servidor puede ser
un punto de falloAtaques a un servidor
Rendimiento impredecibleDependencia de la red y
del sistemaSeguridad
Problemas si los servidores pertenecen a otras organizacionesCómo garantizar calidad
de servicio
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Cliente-ServidorVariantes
Sin estadoServidor replicadoCon caché
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Red
Cliente-Servidor sin estadoRestricción:
El servidor no almacena información sobre los clientes
Ante la misma petición responde la misma respuesta
petición
respuesta
ClienteServidor
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Cliente-Servidor sin estadoVentajas
EscalabilidadProblemas
Gestión del estado de la aplicaciónCliente debe recordar peticiones Estrategias mantener información entre peticiones
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Red
Servidor ReplicadoRestricción
Varios servidores ofrecen el mismo servicioOfrecer al cliente la ilusión de que solamente hay un
servidor
petición
respuestacliente
servidor
servidor
servidor
Servidorabstracto
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Servidor ReplicadoVentajas
Mejora tiempos de respuestaMenor latenciaTolerancia a fallos
ProblemasMantenimiento de consistenciaSincronización
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Cliente-servidor con cachéCaché = mediador entre cliente/servidor
Almacena copias de respuestas anteriores a peticiones del servidorCuando se repite la petición, se devuelve la respuesta
sin necesidad de consultar el servidor
Redpetición
respuestacliente servidor
Caché
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Cliente-servidor con cachéElementos:
Añade nodos intermedios con cachéRestricciones
Algunas peticiones se resuelven en el nodo cachéEl nodo caché contiene política de gestión de
respuestasTiempo de expiración
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Cliente-servidor con caché
Ventajas:Menor carga en la red
Muchas peticiones repetidas se almacenan en caché
Menor tiempo de respuestaRespuestas de caché
llegan antes
ProblemasComplejidad de
configuraciónSe requiere política de
expiraciónNo apropiado en ciertos
dominios Si se requiere fidelidad de
respuestasEj. sistemas en tiempo real
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Arquitectura basada en eventosEDA (Event-Driven-Architecture)
Productoresde eventos
Procesador de eventos
Consumidoresde eventos
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Basados en eventosElementos:
Evento: Algo que ha ocurrido (≠ petición)
Productor de eventosGenerador de eventos (sensores, sistemas, ...)
Consumidor de eventosBD, aplicaciones, cuadros de mando, ...
Procesador de eventosCanal de transmisiónProcesador que filtra y transforma eventos
Productoreseventos
Procesadoreventos
Consumidoreseventos
evento evento
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Basados en eventosRestricciones:
Comunicación asíncronaProductores generan eventos en cualquier momentoA los consumidores les llegan eventos en cualquier
momentoRelación uno-a-muchos
Un evento puede ser enviado a varios consumidores
Productoreseventos
Procesadoreventos
Consumidoreseventos
evento evento
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Basados en eventos
VentajasDesacoplamiento
Productor de eventos no depende del consumidor, ni viceversa.
AtemporalidadLos eventos se publican sin
necesidad de esperar por la finalización de un ciclo
AsincronicidadPara publicar un evento no
es necesario esperar a terminar de procesar otro evento
ProblemasSolución no secuencial
Posible pérdida de controlConsistencia del sistemaDificultad de depuración
Productoreseventos
Procesadoreventos
Consumidoreseventos
evento evento
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Basados en eventosAplicaciones
Redes de procesamiento de eventosEvent-Stream-Processing (ESP)Complex-event-processing
VariacionesPublish-subscribeModelos de actores
Patrones relacionadosCQRS, Event sourcing
Productoreseventos
Procesadoreventos
Consumidoreseventos
evento evento
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Publish-subscribe
Componentes se subscriben a un canal para recibir mensajes de otros componentes
Componente
Bus de eventosPuerto suscripción
Puerto Publicación
Componente
Componente Componente
Componente
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Publish-subscribeElementos:
Componente: Componente que se suscribe al bus de eventos
Puerto de publicaciónSe registra para publicar mensajes
Puerto de suscripciónSe registra para recibir cierto tipo de mensajes
Bus de eventos (canal de mensajes): Transmite mensajes a los suscriptores
Bus eventos
Componente Componente
Componente Componente Componente
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Publish-subscribeRestricciones:
Separación puerto de suscripción/publicaciónUn componente puede tener ambos puertos
Comunicación no directaEn general, comunicación asíncronaA través de canal de mensajesComponentes delegan responsabilidad al canal
Bus eventos
Componente Componente
Componente Componente Componente
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Publish-subscribe
VentajasCalidad de comunicación
Mayor eficienciaDepuración
Bajo acoplamientoSuscriptores no dependen
de publicadores...ni viceversa
Escalabilidad
ProblemasSe añade nivel de
indirecciónComunicación directa
puede ser más eficiente
Implementación complejaPuede requerir COTS
Bus eventos
Componente Componente
Componente Componente Componente
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Modelos de Actores
Utilizados para computación concurrenteActores en lugar de objetosNo hay estado compartido entre actoresPaso de mensajes asíncrono
Desarrollos teóricos desde 1973 (Carl Hewitt)Aplicaciones en telecomunicaciones (Erlang)
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Modelos de actoresElementos
Actor: entidad computacional con estadoSe comunica con los actores enviando mensajesProcesa los mensajes de uno en uno
MensajesDirecciones: Identifican a los actores (mailing address)
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Modelos de actoresRestricciones (1)
Un actor solamente puede:Enviar mensajes a otros actores
Los mensajes son inmutablesCrear nuevos actoresModificar cómo va a procesar siguiente mensaje
Los actores están desacopladosEl receptor no depende del emisor
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Modelos de actoresRestricciones (2)
Paralelismo:Todas las acciones pueden hacerse en paraleloNo hay estado global compartidoLos mensajes pueden llegar en cualquier orden
Direcciones localesUn actor sólo puede enviar mensajes a direcciones
conocidas (porque se le pasaron o porque las crea)
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Modelos de actoresVentajas
ParalelismoTrasparencia y escalabilidad
Direcciones internas vs externas
Modelos de actores no locales
Servicios Web, sistemas multi-agentes
ProblemasEnvío de mensajes
Cómo garantizar que los mensajes llegan
Coordinación entre actores
Sistemas no consistentes por definición
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Modelos de actoresImplementaciones
Erlang (lenguaje de programación)Akka
AplicacionesSistemas reactivosEjemplos: Ericsson, Facebook, twitter
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
CQRS
Command Query Responsability SeggregationSeparar el modelo en 2 partes
Command (modificación): Realiza cambiosQuery (consulta): Sólo realiza consultas, actualiza interfaz
Aplicación
Modelo
InterfazUsuario
BaseDatos
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
CQRS
Command Query Responsability SeggregationSeparar el modelo en 2 partes
Command (modificación): Realiza cambiosQuery (consulta): Sólo realiza consultas, actualiza interfaz
Aplicación
Query
InterfazUsuario
BaseDatos
Command
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
CQRSVentajas
EscalabilidadOptimizar consultas
(sólo lectura)Comandos
asíncronosFacilita
descomposición de equipos
ProblemasOperaciones híbridas
(consulta/comando)Ejemplo: pop() en una
pilaComplejidad
En entornos CRUD puede ser excesivo
SincronizaciónPosibilidad de consultas
sobre datos no actualizadosAplicaciones
Axon Framework
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Event Sourcing
Capturar cambios del estado mediante eventosPermite seguir traza de cómo se llegó a un
determinado estadoEvent Store
Siempre se añaden eventos (no se cambian)
Write
----------------------------------------------------------------------
Eventstore
Gestoreventos
Read
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Event Sourcing
Elementos Almacén de eventos
Almacena cambios en el estadoEventos
No cambian, se enuncian en pasado
Write
----------------------------------------------------------------------
Eventstore
Gestoreventos
Read
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Event Sourcing
Tolerancia a fallosTrazabilidad
Determinar estado de aplicación en cada momento
ReconstrucciónSi aparecen eventos erróneos,
se pueden deshacer sus acciones y reconstruir el resto
EscalabilidadBD de sólo append
Novedad desarrolloDiferente de sistemas
tradicionalesConsistencia de datos
Eventual consistencyActualización software
Convivir versiones de eventos diferentes?
Gestión de recursosGranularidad de los eventosAlmacenamiento de eventos
crece con tiempoRequiere crear instantáneas
(snapshots)
Ventajas Problemas/retos
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Event sourcingAplicaciones
Sistemas de bases de datosDatomic, EventStore
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
PluginsMicrokernelReflectionIntérpretes y DSLCódigo móvilCódigo bajo demanda
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
PluginPlugin
PluginsPermite extender el sistema mediante la
incorporación de plugins que añaden nuevas funcionalidades
Motor tiempoejecución Sistema base
Plugin
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
PluginsElementos
Sistema base: Sistema que admite la incorporación de plugins
Plugins: Componentes que pueden ser añadirse o eliminarse dinámicamente
Motor de ejecución: Arranca, localiza, inicializa y ejecuta plugins
PluginPlugin
Motor tiempoejecución Sistema base
Plugin
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
PluginsRestricciones
El motor en tiempo de ejecución se encarga de la gestión de los plugins
El sistema admite añadir/eliminar pluginsLos plugins pueden depender de otros
Debe declarar sus dependencias y el API que exporta
PluginPlugin
Motor tiempoejecución Sistema base
Plugin
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Plugins
VentajasExtensibilidad
Mejorar funcionamiento de aplicación de forma no prevista inicialmente
PersonalizaciónAplicación puede crecer bajo
demandaAdaptarse a nuevos
requisitos
ProblemasConsistencia
Los plugins deben incorporarse al sistema de forma consistente
RendimientoRetardo en búsqueda de plugins
Seguridad Plugins realizados por terceras
partesGestión de plugins y dependencias
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
PluginsEjemplos
Eclipse Firefox
TecnologíasSistemas de componentes: OSGi
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Microkernel
Identificar funcionalidad mínima en microkernelLa funcionalidad extra se implementa mediante
servidores internosLa comunicación al exterior se realiza mediante
servidor externo
MicrokernelAdaptadorServidor internoServidor
internoServidor interno
Servidor externoCliente
Sistema
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
MicrokernelElementos
Microkernel: Funcionalidad mínimaServidor interno: Funcionalidad extraServidor externo: Ofrece API externaCliente: Aplicación externa
Adaptador: Componente que se comunica con servidor externo
MicrokernelAdaptadorServidor internoServidor
internoServidor interno
Servidor externoCliente
Sistema
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
MicrokernelRestricciones:
El microkernel implementa solamente la funcionalidad mínima
El resto de funcionalidad es implementada por servidores internos
La comunicación del cliente con el sistema se realiza a través de los servidores externos
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
MicrokernelVentajas
PortabilidadSólo es necesario portar el
kernelFlexibilidad y extensibilidad
Añadir nueva funcionalidad mediante nuevos servidores internos
Seguridad y fiabilidadEncapsular partes críticasLos errores en partes
externas no afectan al microkernel
ProblemasRendimiento
Sistema monolítico puede ser más eficiente
Complejidad de diseñoIdentificar componentes del
kernelDifícil separar partes a
servidores internosPunto de fallo único
Si falla el microkernel puede comprometerse la seguridad
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
MicrokernelAplicaciones
Sistemas operativosJuegosEditores
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
ReflectionCambiar la estructura y comportamiento de una
aplicación de forma dinámicaSistemas que pueden modificarse a sí mismos
ElementosNivel base: Implementa lógica de la aplicaciónMetanivel: Aspectos que pueden modificarseProtocolo metaobjetos: Interfaz que permite
modificar el metanivel
Nivel base
Metanivel
Protocolo Metaobjetos
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
ReflectionRestricciones
El nivel base utiliza aspectos del metanivel para su funcionamiento
Durante la ejecución, el sistema puede modificar el metanivel mediante el protocolo metaobjetos
Nivel base
Metanivel
Protocolo Metaobjetos
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Reflection
VentajasFlexibilidad
El sistema puede adaptarse a condiciones cambiantes
No es necesario modificar código fuente ni detener ejecución para realizar cambios en sistema
ProblemasImplementación
No todos los lenguajes facilitan la meta-programación
RendimientoPuede ser necesario realizar
optimizaciones para limitar la reflexividad
Seguridad: Mantenimiento de consistencia
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
ReflectionAplicaciones
Muchos lenguajes dinámicos soportan reflectividadScheme, CLOS, Ruby, Python, ....
Sistemas inteligentesCódigo auto-modificable
Nivel base
Metanivel
Protocolo Metaobjetos
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Intérpretes y DSLsIncluyen un lenguaje de dominio específico que
es interpretado por el sistema
Contexto
IntérpretePrograma
en DSL
Aplicación
Usuario
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Intérpretes y DSLs
ElementosIntérprete: Módulo que ejecuta el programaPrograma: Escrito en lenguaje de dominio específico
(DSL)El DSL puede estar pensado para que el propio usuario final
pueda escribir sus programas en élContexto: Entorno en el que se ejecuta el programa
Contexto
IntérpretePrograma
en DSL
Aplicación
Usuario
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Intérpretes y DSLsRestricciones
El intérprete ejecuta un programa modificando el contexto
Es necesario definir el DSLSintaxis (gramática)Semántica (comportamiento)
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Intérpretes y DSLs
VentajasFlexibilidad
Modificar comportamiento según necesidades del usuario
UsabilidadLos usuarios finales
pueden escribir sus programas
Mayor satisfacciónAdaptabilidad
Facilidad para adaptarse a nuevas situaciones
ProblemasDiseño del lenguaje
Sintaxis y semántica del DSLComplejidad de
implementaciónCreación del intérpreteSeparación de
contexto/intérpreteRendimiento
Posibles programas no óptimos
SeguridadPosibles programas
incorrectos
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Intérpretes y DSLsVariaciones:
DSL empotrados
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
DSLs empotradosEmbedded DSLsLenguajes de dominio específico que están
empotrados en lenguajes de alto nivelTécnica muy utilizada en lenguajes dinámicos
como Haskell, Ruby, Scala, etc.Ventajas:
Se reutiliza la sintaxis del lenguaje anfitrión Acceso a librerías y entornos del lenguaje anfitrión
ProblemasSeparación entre DSL y lenguaje anfitrión
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Código móvilCódigo que se transfiere de una máquina a otra
Sistema A transfiere un programa para que se ejecute en el sistema B
El sistema B debe contener un intérprete del lenguaje correspondiente
Red
Sistema A
SistemaB
Intérprete
Programa
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Código móvilElementos
Intérprete: Ejecuta el códigoPrograma: Código que se transfiereProtocolo de red: Encargado de transferir el código
Red
Sistema A
SistemaB
Intérprete
Programa
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Código móvilRestricciones
El programa debe poder ejecutarse en el sistema receptor
El protocolo de red se encarga de transferir el programa
Red
Sistema A
SistemaB
Intérprete
Programa
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Código móvilVentajas
Flexibilidad y adaptación a diferentes entornosProblemas
Complejidad de la implementaciónSeguridad
Red
Sistema A
SistemaB
Intérprete
Programa
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Código móvilVariantes
Código bajo demandaEvaluación remotaAgentes móviles
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Red
Código bajo demandaCódigo es descargado y ejecutado cuando el
cliente lo solicitaCombinación de código móvil y cliente-servidorEjemplo:
ECMAScript
Cliente
Programa
ServidorPetición
IntérpreteRespuesta
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Código bajo demandaElementos
ClienteServidorCódigo que se transmite del servidor al cliente
RestriccionesEl código reside o se genera en el servidorSe transmite al cliente cuando el cliente lo solicitaSe ejecuta en el cliente
El cliente debe tener un intérprete del lenguaje correspondiente
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Código bajo demandaVentajas
Mejora experiencia de usuario
Extensibilidad: La aplicación puede añadir nuevas funcionalidades no previstasNo es necesario descargar
o instalar la aplicaciónConcepto de Beta
permanenteAdaptación a entorno del
cliente
ProblemasSeguridadCoherencia
Difícil garantizar comportamiento homogéneo en diferentes tipos de clientesEl cliente puede incluso no
ejecutar el programaRecordar: Diseño
responsable
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Código bajo demandaAplicaciones:
RIA (Rich Internet Applications)HTML5 estandariza gran cantidad de APIsMejora coherencia entre clientes
VariacionesAJAX
Originalmente: Asynchronous Javascript and XMLEl programa que se ejecuta en el cliente envía
peticiones asíncronas de información al servidor sin detener su ejecución
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Evaluación remotaEl sistema A envía código al sistema B para que
lo ejecute y le devuelva los resultados
Sistema A
Sistema B
Respuesta(Resultado)
Intérprete
Programa
Petición
Red
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Evaluación remotaElementos
Sistema emisor: Realiza una petición adjuntando un programa
Sistema receptor: Ejecuta el programa y devuelve una respuesta con los resultados
RestriccionesSistema receptor ejecuta el programa
Debe tener intérprete del lenguaje correspondienteProtocolo de red transfiere el programa y las
respuestas
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Evaluación remotaVentajas
Aprovechar capacidades de terceras partesCapacidades computacionales, de memoria, etc.
ProblemasSeguridad
Código no confiableVirus = variante de este estilo
Configuración
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Evaluación remotaEjemplo:
Computación voluntariaSETI@HOME
Sirvió de base para sistema BOINC Berkeley Open Infrastructure for Network Computing
Otros proyectos: Folding@HOME, Predictor@Home, AQUA@HOME, etc.
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Agentes móvilesCódigo y datos pueden moverse de una máquina
a otra para su ejecuciónUn proceso lleva su estado de una máquina a otraEl código puede moverse de forma autónoma
Sistema B
Programa Intérprete
Sistema A
Programa Intérprete
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Agentes móvilesElementos
Agente móvil: Programa que se ejecuta de un sistema a otro de forma autónoma
Sistema: Entorno de ejecución en que se ejecuta el agente móvil
Protocolo de red: transfiere el estado del agente
Sistema B
Programa Intérprete
Sistema A
Programa Intérprete
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Agentes móvilesRestricciones
Los sistemas alojan y ejecutan los agentes móvilesLos agentes móviles pueden decidir cambiar su
ejecución de un sistema a otroPueden comunicarse con otros agentes
Sistema B
Programa Intérprete
Sistema A
Programa Intérprete
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Agentes móviles
VentajasReducción de tráfico en la red
Se transmiten bloques de código que se ejecutan
Paralelismo implícitoTolerancia a fallos de redConceptualmente sencillos
Agente = unidad independiente de ejecución
Posibilidad de sistemas de agentes móviles
Adaptación a cambios en el entornoSistemas reactivos y de
aprendizaje
ProblemasComplejidad de la
configuraciónSeguridad
Código malicioso o erróneo
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Agentes móvilesAplicaciones
Recuperación de informaciónWeb crawlers
Sistemas peer-to-peerTelecomunicacionesControl remoto y monitorización
Sistemas:JADE (Java Agent DEvelopment framework)Aglets de IBM
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
