Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoArquitectura del SoftwareParte II. Taxonomías de...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoEstilos según comportamientoFuncionamiento en ti...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoTiposFlujo de datosOrganización del trabajoInter...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSecuencial BatchPipes & FiltersPipes & Filters I...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSecuencial - BatchProgramas separados son ejecut...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSecuencial - BatchElementos:Programas ejecutable...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSecuencial - BatchVentajasDébil acoplamiento ent...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & FiltersDatos fluyen a través de tuberías...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & FiltersElementosFiltro: componente que t...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & FiltersRestriccionesLas tuberías conecta...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & FiltersVentajasFacilita comprensiónCompo...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & FiltersProblemasPosibles retardos si hay...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & FiltersAplicacionesUnixwho | wc -lJavaCl...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & Filters - interfaz uniformeVariación de ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & Filters - interfaz uniformeVentajas:Desa...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & Filters - interfaz uniformeEjemplos:Sist...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMaster-Slave
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMaster-SlaveMaestro divide el trabajo en subtare...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMaster-SlaveElementosMaster: Se encarga de coord...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMaster-SlaveVentajasComputación paralelaToleranc...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMaster-SlaveAplicaciones:Sistemas de control de ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVC: Modelo - vista - controladorVariaciones de ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCMVC: Modelo - Vista - ControladorCreado por T...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCModelo: Lógica de negocio y estadoVista: Mues...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCElementosModeloRepresenta lógica de negocio y...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCRestriccionesEl controlador se encarga de pro...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCVentajasMúltiples vistas del mismo modeloSinc...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCProblemasMayor complejidad en desarrollo de G...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCAplicacionesMuchos marcos de aplicación Web s...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoVariaciones de MVCPACModel-View-PresenterModel V...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPACPAC: Presentación-Abstracción-ControlJerarquí...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPACElementosAgentes conPresentación: aspecto de ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPACRestriccionesCada agente se encarga de una as...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPACVentajasSeparación de preocupacionesIdentific...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPACProblemasComplejidad del sistemaDemasiados ag...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPACAplicacionesSistema de monitorización de rede...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoDatos compartidosBlackboardBasados en reglas
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoDatos compartidosVarios componentes independient...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoDatos compartidosElementosAlmacén de datosBase d...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoDatos compartidosVentajasComponentes independien...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoDatos compartidosProblemasPunto de fallo únicoFa...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoDatos compartidosAplicacionesGran cantidad de si...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBlackboardProblemas complejos de difícil solució...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBlackboardElementosBlackboard: Almacén de datos ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBlackboardRestriccionesLas fuentes de conocimien...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBlackboardVentajasAplicable para problemas abier...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBlackboardProblemasDificultad para pruebas y dep...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBlackboardAplicacionesSistemas de reconocimiento...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSistemas basados en reglasVariante de memoria co...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSistemas basados en reglasElementos:Base de cono...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSistemas basados en reglasRestricciones:Base de ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSistemas basados en reglasVentajasSolución decla...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSistemas basados en reglasProblemasDepuraciónRen...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSistemas basados en reglasAplicacionesSistemas e...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCall-returnCliente-ServidorArquitecturas basadas...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCall-ReturnUn componente realiza una llamada a o...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCall-returnElementosComponente que realiza la ll...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCall-returnVentajasSencillo de implementarProble...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-ServidorVariación de sistemas en capas2 ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-ServidorElementosServidor: ofrece servic...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-ServidorRestriccionesClientes se comunic...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-ServidorVentajasServidores pueden estar ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-ServidorProblemasCada servidor puede ser...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-ServidorVariantesSin estadoServidor repl...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoRedCliente-Servidor sin estadoRestricción:El ser...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-Servidor sin estadoVentajasEscalabilidad...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoRedServidor ReplicadoRestricciónVarios servidore...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoServidor ReplicadoVentajasMejora tiempos de resp...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-servidor con cachéCaché = mediador entre...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-servidor con cachéVentajas:Menor carga e...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-servidor con cachéProblemasComplejidad d...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBasados en eventosArquitecturas basadas en event...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBasados en eventosElementos:Evento:Algo que ha o...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBasados en eventosRestricciones:Comunicación así...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBasados en eventosVentajasDesacoplamiento: el pr...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBasados en eventosProblemasSolución no secuencia...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBasados en eventosAplicacionesRedes de procesami...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPublish-SubscribeComponentes se subscriben a un ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPublish-subscribeElementos:Componente:Componente...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPublish-SubscribeRestricciones:Separación puerto...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPublish-subscribeVentajasCalidad de comunicación...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPublish-SubscribeProblemasSe añade nivel de indi...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBrókerPeer-to-peerMapReduce
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBrókerNodo intermediario que gestiona la comunic...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBrókerElementosBrókerSe encarga de la comunicaci...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBrókerVentajasSeparación de responsabilidadesDel...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBrókerProblemasRendimientoSe añade una capa de i...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBrókerAplicacionesCORBA y sistemas distribuidosA...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPeer-to-PeerNodos (peers) iguales y autónomos se...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPeer-to-PeerElementosNodos computacionales: peer...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPeer-to-PeerVentajasInformación y control descen...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPeer-to-PeerProblemasMantenimiento del estado de...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPeer-to-PeerAplicaciones popularesNapster, BitTo...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReducePropuesto por GooglePublicado en 2004Im...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduceComputaciones distribuidasTroceado de d...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduceElementosNodo master: Controla la ejecu...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - EsquemaInspirado en P. funcional:2 c...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - MapperPara cada (clave1,valor1) devu...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Mezcla y ordenaciónEl sistema se enc...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - ReducerPara cada clave2, toma la lis...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Esquema generalc1 vi1c1 vi1c1 vi1 ma...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Cuenta palabrasd1 a bd2 a c ad3 a c4...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Entorno ejecuciónEl entorno de ejecu...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Sistema de ficherosGoogle desarrolló...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Sistema de ficherosNamenodefichero1:...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Índice InversoDada una serie de docu...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Índice inversoEsquema básico de un b...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Índice inversod1 a bd2 a c ad3 a cd2...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Canciones popularesA partir de los l...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: canciones populares9:41 A C1MapReduce...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: Amigos comunesEncontrar la lista de a...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: Amigos comunesA D J LD A J L MJ A D L...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: SimilaridadA partir de los logs, enco...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce2MapReduce: Similaridad9:41 A C19:42 D ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: AplicacionesMúltiples aplicaciones:Go...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: ImplementacionesGoogle (interna)Hadoo...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: Librerías/lenguajesHive (Hadoop): len...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginsMicrokernelReflectionIntérpretes y DSLCód...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginPluginPluginsPermite extender el sistema m...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginsElementosSistema base:Sistema que admite ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginsRestriccionesEl motor en tiempo de ejecuc...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginsVentajasExtensibilidadLa aplicación puede...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginsProblemasRendimientoRetardo en la búsqued...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginsEjemplosEclipseFirefoxTecnologíasSistemas...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMicrokernelIdentificar funcionalidad mínima en m...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMicrokernelElementosMicrokernel: Funcionalidad m...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMicrokernelRestricciones:El microkernel implemen...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMicrokernelVentajasPortabilidadSólo es necesario...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMicrokernelProblemasRendimientoSistema monolític...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMicrokernelAplicacionesSistemas operativosJuegos
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoReflectionPermite cambiar la estructura y compor...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoReflectionElementosNivel base: Implementa lógica...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoReflectionRestriccionesEl nivel base utiliza asp...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoReflectionVentajasFlexibilidadEl sistema puede a...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoReflectionProblemasImplementaciónNo todos los le...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoReflectionAplicacionesMuchos lenguajes dinámicos...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIntérpretes y DSLsIncluyen un lenguaje de domini...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIntérpretes y DSLsElementosIntérprete: Módulo qu...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIntérpretes y DSLsRestriccionesEl intérprete eje...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIntérpretes y DSLsVentajasFlexibilidadModificar ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIntérpretes y DSLsProblemasDiseño del lenguajeSi...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIntérpretes y DSLsVariaciones:DSL empotrados: Le...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo móvilCódigo que se transfiere de una máqu...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo móvilElementosIntérprete: Ejecuta el códi...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo móvilRestriccionesEl programa debe poder ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo móvilVentajasFlexibilidad y adaptación a ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo móvilVariantesCódigo bajo demandaEvaluaci...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoRedCódigo bajo demandaCódigo es descargado y eje...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo bajo demandaElementosClienteServidorCódig...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo bajo demandaVentajasMejora experiencia de...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo bajo demandaProblemasSeguridadCoherenciaD...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo bajo demandaAplicaciones:RIA (Rich Intern...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoEvaluación remotaEl sistema A envía código al si...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoEvaluación remotaElementosSistema emisor: Realiz...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoEvaluación remotaVentajasAprovechar capacidades ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoEvaluación remotaEjemplo:Computación voluntariaS...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAgentes móvilesCódigo y datos pueden moverse de ...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAgentes móvilesElementosAgente móvil: Programa q...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAgentes móvilesVentajasReducción de tráfico en l...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAgentes móvilesProblemasComplejidad de la config...
Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAgentes móvilesAplicacionesRecuperación de infor...
Upcoming SlideShare
Loading in...5
×

Arquitectura software.taxonomias.comportamiento.001

306

Published on

Presentación. Arquitectura del Software. Estilos arquitectónicos de comportamiento.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
306
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Arquitectura software.taxonomias.comportamiento.001"

  1. 1. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoArquitectura del SoftwareParte II. Taxonomías de arquitecturaTema 4: Comportamiento: componentes y conectoresJose Emilio Labra Gayo2013Universidad de Oviedo
  2. 2. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoEstilos según comportamientoFuncionamiento en tiempo de ejecuciónComponentes y conectores
  3. 3. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoTiposFlujo de datosOrganización del trabajoInteractivosInvocaciónSistemas distribuidosSistemas adaptables
  4. 4. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSecuencial BatchPipes & FiltersPipes & Filters Interfaz Uniforme
  5. 5. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSecuencial - BatchProgramas separados son ejecutados en ordenLos datos deben pasarse de un programa alsiguienteNotaEl estilo secuencial (batch) puede considerarse elabuelo de los estilos arquitectónicosEtapaPuertoescrituraEtapaComponenteEtapaConectorentre etapasEtapaPuertoLectura
  6. 6. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSecuencial - BatchElementos:Programas ejecutables independientesRestriccionesEs posible encadenar la salida de un programa a laentrada de otroNormalmente, un programa debe esperar a quetermine la ejecución el programa anterior
  7. 7. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSecuencial - BatchVentajasDébil acoplamiento entre componentesRe-configurabilidadEtapas identificadas facilitan depuración de procesoProblemasNo proporciona interfaz interactivoRequiere intervención externaNo hay soporta para concurrenciaBaja velocidad (throughput)Alta latencia
  8. 8. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & FiltersDatos fluyen a través de tuberías (pipes) y sonprocesados mediante filtrosFiltroPuertoLecturaPuertoEscrituraFiltroComponentefiltroPipe óTuberíaFiltroFiltro Filtro
  9. 9. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & FiltersElementosFiltro: componente que transforma los datos. Losfiltros pueden ejecutarse concurréntemente.Tubería (Pipe): Lleva datos de la salida de un filtroa la entrada de otro filtroPropiedades: tamaño de búffer, formato dedatos, protocolo de interacción
  10. 10. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & FiltersRestriccionesLas tuberías conectan las salidas de un filtro a laentrada de otroLos filtros deben estar de acuerdo sobre losformatos que admiten
  11. 11. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & FiltersVentajasFacilita comprensiónComportamiento total = suma de comportamiento decada filtroReusabilidad:2 filtros cualquiera pueden recombinarseExtensibilidad: crear/añadir nuevos filtrosEvolución: Substuirse filtros viejos por nuevosVerificación independiente de cada filtroMejora rendimientoPermite ejecución concurrente entre filtros
  12. 12. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & FiltersProblemasPosibles retardos si hay tuberías largasDifícil pasar estructuras de datos complejasNo interactividadUn filtro no puede interactuar con el entorno
  13. 13. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & FiltersAplicacionesUnixwho | wc -lJavaClases java.io (PipedReader, PipedWriter)
  14. 14. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & Filters - interfaz uniformeVariación de Pipes & Filters en la que los filtrostienen la misma interfazElementosLos mismos que en Pipes & FiltersRestriccionesLos filtros deben tener una interfaz uniforme
  15. 15. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & Filters - interfaz uniformeVentajas:Desarrollo independiente de filtrosReconfigurabilidadFacilita la comprensión del sistemaProblemas:Empeora rendimiento si los datos debentransformarse de su representación natural
  16. 16. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPipes & Filters - interfaz uniformeEjemplos:Sistema operativo UnixProgramas con una entrada (stdin) y dos salidas(stdout y stderr)Arquitectura de la Web: REST
  17. 17. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMaster-Slave
  18. 18. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMaster-SlaveMaestro divide el trabajo en subtareasAsigna cada subtarea a diferentes nodosEl resultado computacional se obtiene a partir delos resultados de los nodos esclavosSlave 1 Slave 2MasterSlave N. . .Problematarea 1 tarea 2 tarea NSoluciónresultado Nresultado 2resultado 1
  19. 19. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMaster-SlaveElementosMaster: Se encarga de coordinar la ejecuciónSlave: realiza una tarea y devuelte un resultadoRestriccionesLos slave se encargan únicamente de realizar lacomputaciónEl control es realizado desde el nodo Master
  20. 20. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMaster-SlaveVentajasComputación paralelaTolerancia a fallosProblemasDificultad de coordinación entre nodos slaveDependencia de nodo MasterDependencia de configuración física
  21. 21. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMaster-SlaveAplicaciones:Sistemas de control de procesosSistemas empotradosSistemas tolerantes a fallosSistemas de búsqueda de soluciones precisas
  22. 22. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVC: Modelo - vista - controladorVariaciones de MVCPAC: Presentación - Abstracción - ControlDCI : Datos - Contexto - Interacción
  23. 23. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCMVC: Modelo - Vista - ControladorCreado por Trygve Reenskaug a finales de los 70Solución para GUIIncorpora un controlador para separar el modelode la vista que se ofrece al usuarioEl usuario trabaja con un "modelo mental" delmodelo real, que se ofrece a través de vistas
  24. 24. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCModelo: Lógica de negocio y estadoVista: Muestra datos al usuarioControlador: Coordina interacción, vistas y modeloModelomentalControladorModeloVista 1Vista 2Usuario
  25. 25. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCElementosModeloRepresenta lógica de negocio y estadoEnlace con almacén de datos y actualizaciónVistaMuestra contenidos de un modeloControladorRecibe interacciones del usuario con la vistaCoordina acciones a realizar por modeloCreación/coordinación de vistas
  26. 26. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCRestriccionesEl controlador se encarga de procesar los eventosdel usuarioLa vista se encarga únicamente de mostrar valoresdel modeloModelo es independiente de controladores/vistas
  27. 27. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCVentajasMúltiples vistas del mismo modeloSincronización de vistasSeparación de incumbenciasInteracción (controlador), funcionalidad (modelo)Facilidad para crear nuevas vistas y controladoresIntercambiar look & feelPotencial para creación de marcos genéricos
  28. 28. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCProblemasMayor complejidad en desarrollo de GUIsAcoplación entre controladores y vistasControlador/Vistas dependen del interfaz delmodeloDificultades con herramientas GUI
  29. 29. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMVCAplicacionesMuchos marcos de aplicación Web siguen MVCRuby on Rails, Spring MVC, Play, etc.DiferenciaPush: el controlador envía órdenes a la vistaRoRPull: el controlador recibe órdenes de la vistaPlay
  30. 30. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoVariaciones de MVCPACModel-View-PresenterModel View ViewModel...
  31. 31. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPACPAC: Presentación-Abstracción-ControlJerarquía de agentesCada agente contiene 3 componentesPresentaciónAbstracción ControlAgente PACPresentaciónAbstracción ControlAgente PACPresentaciónAbstracción ControlAgente PAC
  32. 32. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPACElementosAgentes conPresentación: aspecto de visualizaciónAbstracción: modelo de datos de un agenteControl: conecta los componentes anteriores ypermite la comunicación entre agentesRelación jerárquica entre agentes
  33. 33. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPACRestriccionesCada agente se encarga de una aspecto de lafuncionalidadEn cada agente no hay comunicación directa entreAbstracción y PresentaciónComunicación a través de componente de control
  34. 34. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPACVentajasSeparación de preocupacionesIdentificación de la funcionalidadSoporte para cambios y extensionesSe puede modificar una parte en un agente sinmodificar el restoMultitareaLos agentes pueden estar en diferentes hilos, procesoso máquinas
  35. 35. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPACProblemasComplejidad del sistemaDemasiados agentes pueden generar una estructuracompleja y difícil de mantenerComplejidad del componente de controlComponentes de control gestionan comunicaciónSu calidad es fundamental para la calidad del sistemaRendimientoSobrecarga de comunicación entre agentes
  36. 36. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPACAplicacionesSistema de monitorización de redesRobots móvilesRelacionesRelacionado con MVCEn MVC el componente de Presentación se separa enVista y ControladorEn MVC no hay componentes de control ni jerarquíade agentes.Redescubierto y rebautizado como MVC jerárquico
  37. 37. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoDatos compartidosBlackboardBasados en reglas
  38. 38. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoDatos compartidosVarios componentes independientes acceden almismo estadoAplicaciones basadas en un modelo centralizadoComponente ComponenteDatoscompartidosComponente...
  39. 39. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoDatos compartidosElementosAlmacén de datosBase de datos o repositorio centralizadoComponentesProcesadores que acceden a la memoria compartidaRestriccionesComponentes 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
  40. 40. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoDatos compartidosVentajasComponentes independientesNo necesitan conocer existencia de otros componentesFacilita comunicación entre componentesConsistencia de datosEstado global centralizadoBackup único de todo el sistema
  41. 41. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoDatos compartidosProblemasPunto de fallo únicoFallo del almacén puede comprometer todo el sistemaDistribución del almacén puede ser costosaPosible cuello de botellaIneficiencia en comunicaciónSincronización en acceso a memoria compartida
  42. 42. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoDatos compartidosAplicacionesGran cantidad de sistemas utilizan este esquemaAlgunas variantesEste patrón se conoce también como:Shared Memory, Repository, Shared data, etc.BlackboardSistemas basados en reglas
  43. 43. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBlackboardProblemas complejos de difícil soluciónSe dividen en varios elementos fuentes deconocimiento que resuelven partes del problemaCada fuente de conocimiento agrega solucionesparciales en el blackboardFuenteconocimientoFuenteconocimientoBlackboardFuenteConocimiento ...Control
  44. 44. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBlackboardElementosBlackboard: Almacén de datos centralFuente de conocimiento: resuelve una parte delproblema y va añadiendo los resultados parcialesControl: Organiza las tareas y chequea el estado deltrabajoFuenteconocimientoFuenteconocimientoBlackboardFuenteConocimiento ...Control
  45. 45. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBlackboardRestriccionesLas fuentes de conocimiento resuelven parte delproblemaEl blackboard contiene soluciones parciales quevan mejorándose a partir del trabajo de las fuentesde conocimiento
  46. 46. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBlackboardVentajasAplicable para problemas abiertosExperimentaciónFacilita cambio de estrategiasFuentes de conocimiento reutilizablesSoporte a tolerancia a fallos
  47. 47. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBlackboardProblemasDificultad para pruebas y depuraciónNo hay garantía de encontrar solución adecuadaDificultad para establecer estrategia central decontrolBajo rendimientoPuede ser necesario rechazar hipótesis incorrectasAlto coste de desarrolloParalelismo debe ser implementadoNecesidad de sincronizar acceso al blackboard
  48. 48. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBlackboardAplicacionesSistemas de reconocimiento del hablaHEARSAY-IIReconocimiento de patronesPredicción atmosféricaJuegosAnálisis de estructura molecularCrystalis
  49. 49. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSistemas basados en reglasVariante de memoria compartidaMemoria compartida = Base de conocimientoContiene reglas y hechosMotor deinferenciaBase deconocimientoInterfaz deusuario
  50. 50. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSistemas basados en reglasElementos:Base de conocimiento: Conjunto de hechos y reglassobre un determinado dominioInterfaz de usuario: Accede a la base deconocimiento para consultar/modificarMotor de inferencia: Sistema encargado deresponder consultas a partir de los datos y la basede conocimiento
  51. 51. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSistemas basados en reglasRestricciones:Base de conocimiento declarativaExpresividad limitada respecto lenguajes imperativos
  52. 52. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSistemas basados en reglasVentajasSolución declarativaSeparación de preocupacionesAlgoritmoConocimiento del dominioReutilización
  53. 53. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSistemas basados en reglasProblemasDepuraciónRendimientoCreación y mantenimiento de las reglas
  54. 54. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoSistemas basados en reglasAplicacionesSistemas expertosSistemas de producciónLibrerías de reglas en JavaJRules, Drools, JESSLenguajes basados en reglasProlog
  55. 55. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCall-returnCliente-ServidorArquitecturas basadas en eventosPublish-Subscribe
  56. 56. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCall-ReturnUn componente realiza una llamada a otrocomponente y espera a recibir la respuestaComponente A Componente Bcallreturn
  57. 57. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCall-returnElementosComponente que realiza la llamadaComponente que devuelve la respuestaRestriccionesComunicación síncrona:Componente que realiza llamada queda esperando larespuesta.Componente A Componente Bcallreturn
  58. 58. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCall-returnVentajasSencillo de implementarProblemasProblemas para ejecución concurrenteComponente queda bloqueado esperando respuestaPuede estar ocupando recursos generando bloqueosEntornos distribuidosPoco aprovechamiento de capacidadescomputacionales
  59. 59. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-ServidorVariación de sistemas en capas2 capas separadas físicamente (2-tier)Funcionalidad separada en varios servidoresClientes se conectan a los serviciosInterfaz Petición/respuestaRedpeticiónrespuestaclienteservidor
  60. 60. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-ServidorElementosServidor: ofrece servicios a través de un protocolopetición/respuestaCliente: realiza peticiones y procesa las respuestasProtocolo de red: gestión de comunicación entreclientes y servidoresRedpeticiónrespuestaClienteservidor
  61. 61. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-ServidorRestriccionesClientes se comunican con servidoresNo al revésClientes son independientes de otros clientesLos servidores no conocen a los clientesProtocolo de red ofrece garantías de comunicación
  62. 62. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-ServidorVentajasServidores pueden estar distribuidosSeparación de funcionalidad cliente/servidorDesarrollo independienteEscalabilidadFuncionalidad general disponible para todos losclientesAunque no todos los servidores deben ofrecer toda lafuncionalidad
  63. 63. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-ServidorProblemasCada servidor puede ser un punto de falloAtaques a un servidorRendimiento impredecibleDependencia de la red y del sistemaProblemas si los servidores pertenecen a otrasorganizacionesCómo garantizar calidad de servicio
  64. 64. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-ServidorVariantesSin estadoServidor replicadoCon caché
  65. 65. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoRedCliente-Servidor sin estadoRestricción:El servidor no almacena información sobre losclientesAnte la misma petición responde la mismarespuestapeticiónrespuestaclienteservidor
  66. 66. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-Servidor sin estadoVentajasEscalabilidadProblemasGestión del estado de la aplicaciónCliente debe recordar peticionesNecesidad de estrategias para mantener informaciónentre peticiones
  67. 67. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoRedServidor ReplicadoRestricciónVarios servidores ofrecen el mismo servicioOfrecer al cliente la ilusión de que solamente hay unservidorpeticiónrespuestaclienteservidorservidorservidorServidorabstracto
  68. 68. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoServidor ReplicadoVentajasMejora tiempos de respuestaMenor latenciaTolerancia a fallosProblemasMantenimiento de consistenciaSincronización
  69. 69. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-servidor con cachéCaché = mediador entre cliente/servidorAlmacena copias de respuestas anteriores apeticiones del servidorCuando se repite la petición, se devuelve la respuestasin necesidad de consultar el servidorRedpeticiónrespuestacliente servidorCaché
  70. 70. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-servidor con cachéVentajas:Menor carga en la redMuchas peticiones repetidas se almacenan en cachéMenor tiempo de respuestaRespuestas de caché llegan antes
  71. 71. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCliente-servidor con cachéProblemasComplejidad de configuraciónSe requiere política de expiraciónNo apropiado en ciertos dominiosSi se requieren fidelidad de respuestasEj. sistemas en tiempo real
  72. 72. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBasados en eventosArquitecturas basadas en eventos:EDA (Event-Driven-Architecture)Productoresde eventosProcesadorde eventosConsumidoresde eventos
  73. 73. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBasados 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
  74. 74. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBasados en eventosRestricciones:Comunicación asíncronaProductores generan eventos en cualquier momentoA los consumidores les llegan eventos en cualquiermomentoRelación uno-a-muchosUn evento puede ser enviado a varios consumidores
  75. 75. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBasados en eventosVentajasDesacoplamiento: el productor de eventos nodepende del consumidor, ni viceversa.Atemporalidad: los eventos se publican sinnecesidad de esperar por la finalización de un cicloAsincronicidad: Para publicar un evento no esnecesario esperar a terminar de procesar otroevento
  76. 76. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBasados en eventosProblemasSolución no secuencialDificultad de depuración
  77. 77. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBasados en eventosAplicacionesRedes de procesamiento de eventosEvent-Stream-Processing (ESP)Complex-event-processingVariacionesPublish-subscribe
  78. 78. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPublish-SubscribeComponentes se subscriben a un canal pararecibir mensajes de otros componentesComponenteBus de eventosPuertosuscripciónPuertoPublicaciónComponenteComponente ComponenteComponente
  79. 79. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPublish-subscribeElementos:Componente:Componente que se suscribe al bus de eventosPuerto de publicaciónSe registra para publicar mensajesPuerto de suscripciónSe registra para recibir cierto tipo de mensajesBus de eventos (canal de mensajes):Transmite mensajes a los suscriptores
  80. 80. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPublish-SubscribeRestricciones:Separación puerto de suscripción/publicaciónUn componente puede tener ambos puertosComunicación no directaEn general, comunicación asíncronaA través de canal de mensajesComponentes delegan responsabilidad al canal
  81. 81. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPublish-subscribeVentajasCalidad de comunicaciónMayor eficienciaDepuraciónBajo acoplamiento entre componentesSuscriptores no dependen de publicadores...ni viceversa.
  82. 82. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPublish-SubscribeProblemasSe añade nivel de indirecciónComunicación directa puede ser más eficienteImplementación complejaPuede requerir COTS
  83. 83. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBrókerPeer-to-peerMapReduce
  84. 84. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBrókerNodo intermediario que gestiona la comunicaciónentre un cliente y un servidorCliente ServidorBrokerstub skeletonCliente ServidorBrokerstub skeletonbridge
  85. 85. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBrókerElementosBrókerSe encarga de la comunicaciónCliente: Envía peticionesProxy de cliente: stubServidor: Devuelve respuestasProxy de servidor: skeletonBridge: Puede conectar brókers entre síCliente ServidorBrokerstub skeletonbridge
  86. 86. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBrókerVentajasSeparación de responsabilidadesDelega aspectos comunicación al brókerMantenimiento por separadoReutilizaciónServidores independientes de clientesPortabilidadBróker = aspectos de bajo nivelInteroperabilidadMediante bridges
  87. 87. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBrókerProblemasRendimientoSe añade una capa de indirecciónComunicación directa siempre va a ser más rápidaPuede suponer acoplamiento fuerte entrecomponentesBróker = punto de fallo único en el sistema
  88. 88. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBrókerAplicacionesCORBA y sistemas distribuidosAndroid utiliza variación de patrón Bróker
  89. 89. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPeer-to-PeerNodos (peers) iguales y autónomos se comunicanentre síRedNodoNodoNodoNodoNodoNodo
  90. 90. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPeer-to-PeerElementosNodos computacionales: peersTienen su propio estado e hilo de controlProtocolo de redRestricciónNo existe un nodo principal
  91. 91. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPeer-to-PeerVentajasInformación y control descentralizadosTolerancia a fallosNo hay un punto único de falloFallo de un nodo único no es determinante
  92. 92. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPeer-to-PeerProblemasMantenimiento del estado del sistemaComplejidad de protocoloLimitaciones de ancho de bandaLatencia de la red y protocoloSeguridadDetección de peers maliciosos
  93. 93. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPeer-to-PeerAplicaciones popularesNapster, BitTorrent, Gnutella, ...No sólo compartir ficherosComercio electrónico (B2B)Sistemas colaborativosRedes de sensores...VariantesSuper-peers
  94. 94. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReducePropuesto por GooglePublicado en 2004Implementación interna propietariaObjetivo: grandes cantidades de datosMuchos nodos computacionalesTolerancia a fallosEstilo compuesto deMaster-slaveSecuencial (batch)
  95. 95. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduceComputaciones distribuidasTroceado de datos de entradaReplicated repositoryTolerancia a fallos de nodosHardware/software heterogéneoProcesamiento grandes cantidades de datosWrite-once. Read-many
  96. 96. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduceElementosNodo master: Controla la ejecuciónTabla de nodosGestiona sistema de ficheros replicadoNodos slaveEjecutan funcionesMapperReducerContienen bloques de datos replicados
  97. 97. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - EsquemaInspirado en P. funcional:2 componentes: mapper y reducerLos datos se trocean para su procesamientoCada dato asociado a una claveTransforma [(clave1,valor1)] en [(clave2,valor2)]c1Entrada:[(Clave1,Valor1)]v1c1 v1c1 v1Salida:[(Clave2,Valor2)]c2 v2c2 v2c2 v2c2 v2MapReduce
  98. 98. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - MapperPara cada (clave1,valor1) devuelve una lista de(clave2,valor2)Tipo: (clave1, valor1) [(clave2,valor2)]c1 vi1c2 vi2c3 vi3k1 v1k2 v2k1 v3k3 v4k1 v5k1 v6k3 v7mappermappermapper
  99. 99. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Mezcla y ordenaciónEl sistema se encarga de mezclar y ordenarresultados intermedios en función de las clavesk1 v1k2 v2k1 v3k3 v4k1 v5k1 v6k3 v7k1 v1 v3 v5 v6k2 v2k3 v4 v7Mezclayordena
  100. 100. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - ReducerPara cada clave2, toma la lista de valores asociaday los combina en uno soloTipo: (clave2, [valor2]) (clave2,valor2)k1 v1 v3 v5 v6k2 v2k3 v4 v7 reducerreducerreducer vf1vf2vf3k1k2k3
  101. 101. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Esquema generalc1 vi1c1 vi1c1 vi1 mapperreducerreducerreducer vf1vf2vf3k1k2k3mappermapperk1 v1k2 v2k1 v3k3 v4k1 v5k1 v6k3 v7k1 v1 v3 v5 v6k2 v2k3 v4 v7MezclayordenaMapReduce
  102. 102. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Cuenta palabrasd1 a bd2 a c ad3 a c412abca 1b 1a 1c 1a 1a 1c 1mappermappermapperreducerreducerreducera 1 1 1 1b 1c 1 1MezclayordenaMapReduce// devuelve cada palabra con un 1mapper(d,ps) {for each p in ps:emit (p, 1)}// suma la lista de números de cada palabrareducer(p,ns) {sum = 0for each n in ns { sum += n; }emit (p, sum)}
  103. 103. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Entorno ejecuciónEl entorno de ejecución se encarga dePlanificación: Cada trabajo (job) se divide en tareas(tasks)Co-localización de datos/códigoCada nodo computacional contiene sus datos de formalocal (no existe un sistema central)Sincronización:Tareas reduce deben esperar final de fase mapGestión de errores y fallosAlta tolerancia a fallos de los nodos computacionales
  104. 104. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Sistema de ficherosGoogle desarrolló sistema distribuido GFSHadoop creó HDFSFicheros se dividen en bloques (chunks)2 tipos de nodos:Namenode (maestro), datanodes (servidores datos)Datanodes almacenan diferentes bloquesReplicación de bloquesNamenode contiene metadatosEn qué nodo está cada trozoComunicación directa entre clientes y datanodes
  105. 105. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Sistema de ficherosNamenodefichero1: (B1 – N1 N2, B2 – N1 N2 N3)fichero2: (B3 – N2 N3, B4 – N1 N2)fichero3: (B5 – N1 N3)B1 B1B4B4B5B5B3 B3Cliente1Cliente2N1 N2 N3DatanodesSlavesB2B2 B2Master
  106. 106. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Índice InversoDada una serie de documentos, obtener la lista depalabras asociando a cada palabra el documentoen el que aparece.Ordenar los documentos según el mayor número deaparicionesDocumento 1En un lugar de la Mancha , decuyo nombre no quieroacordarme no ha mucho tiempoque vivía un hidalgo de los delanza en astillero, adarga antigua,rocín flaco y galgo corredor. Unaolla de algo más…Índiceinversolugar doc16, doc21, doc23, doc45Mancha doc22, doc2, doc4, doc9, doc11Quijote doc22, doc1, doc2, doc7. . .
  107. 107. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Índice inversoEsquema básico de un buscadorP1P1P1Documentosen cachéWebcrawlingWebIndexadoÍndicepalabra1 doc1, doc23, doc4,…palabra2 doc54,doc23palabra3 doc1,doc7,d1oc9,doc5...palabra4 doc7,doc9,doc10…consultaBúsqueda
  108. 108. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Índice inversod1 a bd2 a c ad3 a cd2d1d2abca d1b d1a d2c d2a d2a d3c d3mappermappermapperreducerreducerreducera d1 d2 d2 d3b d1c d2 d3MezclayordenaMapReduce// devuelve cada palabra con su// documentomapper(d,ps) {for each p in ps:emit (p, d)}// ordena la lista de documentos por// importanciareducer(p,ds) {ds1 = ordena(ds)emit (p, ds1)}d1 d3d3
  109. 109. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce - Canciones popularesA partir de los logs de los usuarios de un servidorde música, obtener el número de veces que seescucha cada canciónInspirado en last.fm2/3/2010 9:41 Ana C12/3/2010 9:42 Dani C22/3/2010 9:44 Ana C22/3/2010 10:01 Luis C12/3/2010 10:10 Ana C32/3/2010 10:15 Ana C22/3/2010 10:20 Dani C22/3/2010 10:21 Luis C42/3/2010 10:24 Luis C22/3/2010 10:26 Luis C42/3/2010 10:27 Ana C4AnalizadorC1 2 oyentes, 2 escuchasC2 3 oyentes, 5 escuchasC3 2 oyentes, 2 escuchasC4 2 oyentes, 3 escuchas
  110. 110. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: canciones populares9:41 A C1MapReducereducerreducerreducerreducerC1 2C2 3C3 1C4 29:42 D C29:44 A C210:01 L C110:10 A C310:15 A C210:20 D C210:21 L C410:24 L C210:26 L C425310:27 A C4mappermappermappermapperC1 AC2 DC2 AC1 LC3 AC2 AC2 DC4 LC2 LC4 LC4 AC1 A CC2 DC3 AC4 L LMezclayordenaA A D LA
  111. 111. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: Amigos comunesEncontrar la lista de amigos comunesInspirado en FacebookAna Dani Juan LuisDani Ana Juan Luis MarJuan Ana Dani Luis MarLuis Ana Dani Juan MarMar Dani Juan LuisSi Ana visita la página de Juan, el sistema debería mostrar Dani, LuisDaniJuanLuisMarAna
  112. 112. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: Amigos comunesA D J LD A J L MJ A D L MreducerreducerreducerMapReduceL A D J MM D J LA D D J LA J D J LA L D J LA D A J L MD JD LD MmappermappermappermapperD M D J LJ M D J LmapperA J A D L MD JJ LJ ML M D J LA L A D J MD LJ LL MA J L MA J L MA J L MA D L MA D L MA D L MA D J MA D J MA D J MreducerreducerreducerreducerreducerreducerA D J LA J D LA L D JD J A L MD L A J MD M J LJ L A D MJ M D LL M D JA D D J L A J L MA J D J L A D L MA L D J L A D J MD J A J L M A D L MD L A J L M A D J MD M A J L M D J LJ L A D L M A D J MJ M A D L M D J LL M A D J M D J LMezclayordena
  113. 113. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: SimilaridadA partir de los logs, encontrar número decanciones en común entre 2 usuariosInspirado en Amazon (libros similares), Facebook(posibles amigos), etc.Habitualmente se realizan varios pasosmapReduce
  114. 114. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce2MapReduce: Similaridad9:41 A C19:42 D C29:44 A C210:01 L C110:10 A C310:15 A C210:20 D C210:21 L C410:24 L C210:26 L C410:27 A C4A C C1, 1A D C2, 2A L C2, 1A LmappermapperC4, 2A C C1, 1A D C2, 2A L C2 1 C4 2MezclayordenareducerreducerreducerA C 1A D 2A L 3C1 A CC2 DC3 AC4 L LA A D LAMapReduce1
  115. 115. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: AplicacionesMúltiples aplicaciones:Google en 2007, 20petabytes al día, en una mediade 100mil trabajos mapreduce/díaEl algoritmo PageRank puede implementarsemediante MapReduceCasos de éxito:Traducción automática, Similaridad entreítems, ordenamiento (Hadoop ordena 500GB/59sg(véase: sortbenchmark.org)Otras compañías:last.fm, facebook, Yahoo!, twitter, etc.
  116. 116. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: ImplementacionesGoogle (interna)Hadoop (open source)CloudMapReduce (basado en servicios deAmazon)Aster Data (SQL)Greenplum (SQL)Disco (Python/Erlang)Holumbus (Haskell)
  117. 117. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMapReduce: Librerías/lenguajesHive (Hadoop): lenguaje de consulta inspirado enSQLPig (Hadoop): lenguaje específico para definirflujos de datosCascading: API para especificar flujos de datosdistribuidosFlume Java (Google)Dryad (Microsoft)
  118. 118. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginsMicrokernelReflectionIntérpretes y DSLCódigo móvilCódigo bajo demanda
  119. 119. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginPluginPluginsPermite extender el sistema mediante laincorporación de plugins que añaden nuevasfuncionalidadesMotor tiempoejecuciónSistema basePlugin
  120. 120. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginsElementosSistema base:Sistema que admite la incorporación de pluginsPlugins: Componentes que pueden ser añadirse oeliminarse dinámicamenteMotor de ejecución:Arranca, localiza, inicializa y ejecuta plugins
  121. 121. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginsRestriccionesEl motor en tiempo de ejecución se encarga de lagestión de los pluginsEl sistema admite añadir/eliminar pluginsLos plugins pueden depender de otrosDebe declarar sus dependencias y el API que exporta
  122. 122. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginsVentajasExtensibilidadLa aplicación puede mejorar su funcionamiento deforma inesperada
  123. 123. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginsProblemasRendimientoRetardo en la búsqueda de pluginsSeguridadPlugins realizados por terceras partesGestión de plugins y dependencias
  124. 124. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPluginsEjemplosEclipseFirefoxTecnologíasSistemas de componentes: OSGi
  125. 125. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMicrokernelIdentificar funcionalidad mínima en microkernelLa funcionalidad extra se implementa medianteservidores internosLa comunicación al exterior se realiza medianteservidor externoMicrokernelAdaptadorServidorinternoServidorinternoServidorinternoServidorexternoClienteSistema
  126. 126. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMicrokernelElementosMicrokernel: Funcionalidad mínimaServidor interno: Funcionalidad extraServidor externo: Ofrece API externaCliente: Aplicación externaAdaptador: Componente que se comunica conservidor externoMicrokernelAdaptadorServidorinternoServidorinternoServidorinternoServidorexternoClienteSistema
  127. 127. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMicrokernelRestricciones:El microkernel implementa solamente lafuncionalidad mínimaEl resto de funcionalidad es implementada porservidores internosLa comunicación del cliente con el sistema se realizaa través de los servidores externos
  128. 128. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMicrokernelVentajasPortabilidadSólo es necesario portar el kernelFlexibilidad y extensibilidadAñadir nueva funcionalidad mediante nuevosservidores internosSeguridad y fiabilidadEncapsular partes críticasLos errores en partes externas no afectan almicrokernel
  129. 129. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMicrokernelProblemasRendimientoSistema monolítico puede ser más eficienteComplejidad de diseñoIdentificar componentes del kernelPunto de fallo únicoSi falla el microkernel puede comprometerse laseguridad
  130. 130. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMicrokernelAplicacionesSistemas operativosJuegos
  131. 131. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoReflectionPermite cambiar la estructura y comportamientode una aplicación de forma dinámicaSistemas que pueden modificarse a sí mismosNivel baseMetanivelProtocoloMetaobjetos
  132. 132. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoReflectionElementosNivel base: Implementa lógica de la aplicaciónMetanivel: Aspectos que pueden modificarseProtocolo metaobjetos: Interfaz que permitemodificar el metanivelNivel baseMetanivelProtocoloMetaobjetos
  133. 133. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoReflectionRestriccionesEl nivel base utiliza aspectos del metanivel para sufuncionamientoDurante la ejecución, el sistema puede modificar elmetanivel mediante el protocolo metaobjetos
  134. 134. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoReflectionVentajasFlexibilidadEl sistema puede adaptarse a condiciones cambiantesNo es necesario modificar código fuente
  135. 135. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoReflectionProblemasImplementaciónNo todos los lenguajes facilitan la meta-programaciónRendimientoPuede ser necesario realizar optimizaciones paralimitar la reflexividadSeguridad:Mantenimiento de consistencia
  136. 136. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoReflectionAplicacionesMuchos lenguajes dinámicos soportan reflectividadScheme, CLOS, Ruby, Python, ....Sistemas inteligentesCódigo auto-modificable
  137. 137. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIntérpretes y DSLsIncluyen un lenguaje de dominio específico que esinterpretado por el sistemaContextoIntérpreteProgramaen DSLAplicaciónUsuario
  138. 138. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIntérpretes y DSLsElementosIntérprete: Módulo que ejecuta el programaPrograma: Programa escrito en el lenguaje dedominio específico (DSL)El DSL puede estar pensado para que el propiousuario final pueda escribir sus programas en élContexto: Entorno en el que se ejecuta el programa
  139. 139. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIntérpretes y DSLsRestriccionesEl intérprete ejecuta un programa modificando elcontextoEs necesario definir el DSLSintaxis (gramática)Semántica (comportamiento)
  140. 140. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIntérpretes y DSLsVentajasFlexibilidadModificar comportamiento según necesidadUsabilidadLos usuarios finales pueden escribir sus programasAdaptabilidad
  141. 141. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIntérpretes y DSLsProblemasDiseño del lenguajeSintaxis y semántica del DSLComplejidad de implementaciónCreación del intérpreteSeparación de contexto/intérprete
  142. 142. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIntérpretes y DSLsVariaciones:DSL empotrados: Lenguajes de dominio específicoque están empotrados en lenguajes de alto nivelTécnica muy utilizada en lenguajes dinámicos comoHaskell, Ruby, Scala, etc.
  143. 143. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo móvilCódigo que se transfiere de una máquina a otraSistema A transfiere un programa para que seejecute en el sistema BEl sistema B debe contener un intérprete dellenguaje correspondienteRedSistemaASistemaBIntérpretePrograma
  144. 144. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo móvilElementosIntérprete: Ejecuta el códigoPrograma: Código que se transfiereProtocolo de red: Encargado de transferir el códigoRedSistemaASistemaBIntérpretePrograma
  145. 145. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo móvilRestriccionesEl programa debe poder ejecutarse en el sistemareceptorEl protocolo de red se encarga de transferir elprograma
  146. 146. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo móvilVentajasFlexibilidad y adaptación a diferentes entornosProblemasComplejidad de la implementaciónSeguridad
  147. 147. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo móvilVariantesCódigo bajo demandaEvaluación remotaAgentes móviles
  148. 148. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoRedCódigo bajo demandaCódigo es descargado y ejecutado cuando elcliente lo solicitaCombinación de código móvil y cliente-servidorEjemplo:ECMAScriptClienteProgramaServidorPeticiónIntérpreteRespuesta
  149. 149. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo bajo demandaElementosClienteServidorCódigo que se transmite del servidor al clienteRestriccionesEl código reside o se genera en el servidorSe transmite al cliente cuando el cliente lo solicitaSe ejecuta en el clienteEl cliente debe tener un intérprete del lenguajecorrespondiente
  150. 150. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo bajo demandaVentajasMejora experiencia de usuarioExtensibilidad: La aplicación puede añadir nuevasfuncionalidades no previstasNo es necesario descargar o instalar la aplicaciónConcepto de Beta permanenteAdaptación a entorno del cliente
  151. 151. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo bajo demandaProblemasSeguridadCoherenciaDifícil garantizar comportamiento homogéneo endiferentes tipos de clientesEl cliente puede incluso no ejecutar el programaRecordar: Diseño responsable2013 = Año del diseño web responsable
  152. 152. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCódigo bajo demandaAplicaciones:RIA (Rich Internet Applications)HTML5 estandariza gran cantidad de APIsMejora coherencia entre clientesVariacionesAJAXOriginalmente: Asynchronous Javascript and XMLEl programa que se ejecuta en el cliente envíapeticiones asíncronas de información al servidor sindetener su ejecución
  153. 153. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoEvaluación remotaEl sistema A envía código al sistema B para que loejecute y le devuelva los resultadosSistemaASistemaBRespuesta(Resultado)IntérpreteProgramaPeticiónRed
  154. 154. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoEvaluación remotaElementosSistema emisor: Realiza una petición adjuntando unprogramaSistema receptor: Ejecuta el programa y devuelveuna respuesta con los resultadosRestriccionesSistema receptor ejecuta el programaDebe tener intérprete del lenguaje correspondienteProtocolo de red transfiere el programa y lasrespuestas
  155. 155. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoEvaluación remotaVentajasAprovechar capacidades de terceras partesCapacidades computacionales, de memoria, etc.ProblemasSeguridadCódigo no confiableVirus = variante de este estiloConfiguración
  156. 156. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoEvaluación remotaEjemplo:Computación voluntariaSETI@HOMESirvió de base para sistema BOINCBerkeley Open Infrastructure for Network ComputingOtros proyectos:Folding@HOME, Predictor@Home, AQUA@HOME, etc.
  157. 157. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAgentes móvilesCódigo y datos pueden moverse de una máquina aotra para su ejecuciónUn proceso lleva su estado de una máquina a otraEl código puede moverse de forma autónomaSistema BPrograma IntérpreteSistema APrograma Intérprete
  158. 158. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAgentes móvilesElementosAgente móvil: Programa que se ejecuta de unsistema a otro de forma autónomaSistema: Entorno de ejecución en que se ejecuta elagente móvilProtocolo de red: transfiere el estado del agenteRestriccionesLos sistemas alojan y ejecutan los agentes móvilesLos agentes móviles pueden decidir cambiar suejecución de un sistema a otroPueden comunicarse con otros agentes
  159. 159. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAgentes móvilesVentajasReducción de tráfico en la redSe transmiten bloques de código que se ejecutanParalelismo implícitoTolerancia a fallos de redConceptualmente sencillosAgente = unidad independiente de ejecuciónPosibilidad de sistemas de agentes móvilesAdaptación a cambios en el entornoSistemas reactivos y de aprendizaje
  160. 160. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAgentes móvilesProblemasComplejidad de la configuraciónSeguridadCódigo malicioso o erróneo
  161. 161. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAgentes móvilesAplicacionesRecuperación de informaciónWeb crawlersSistemas peer-to-peerTelecomunicacionesControl remoto y monitorizaciónSistemas:JADE (Java Agent DEvelopment framework)Aglets de IBM

×