SlideShare une entreprise Scribd logo
1  sur  11
Equipo 5
América Libertad García Alarcón
Miguel Ángel Merino Martínez
David Lucas Bautista
Daniel López Rosas
4.3 Conceptos básicos de eventos.
• Un evento puede ser definido como "un cambio significativo en un estado“.
Estructura del evento:
• Encabezado evento.
• Cuerpo evento.
Capas del flujo del evento:
• Generador de evento.
• Canal de evento.
• Motor de procesamiento del evento.
• Actividad de descarga dirigida por evento.
Estilos de procesamiento de evento.
Hay tres estilos generales de procesamiento de eventos:
• Procesamiento simple de evento.
• Procesamiento por flujo de evento.
• Procesamiento complejo de evento.
Arquitectura dirigida por eventos
• La Arquitectura dirigida por eventos o EDA, es un patrón de arquitectura de
software que promueve la producción, detección, consumo de, y reacción a
eventos. Las arquitecturas basadas en eventos se han llamado también de
invocación implícita.
• Las arquitecturas basadas en eventos se vinculan históricamente con sistemas
basados en actores, daemons y redes de conmutación de paquetes (publicación-
suscripción).
La idea dominante en la invocación implícita es que, en lugar de invocar un
procedimiento en forma directa (como se haría en un estilo orientado a objetos)
un componente puede anunciar mediante difusión uno o más eventos. Un
componente de un sistema puede anunciar su interés en un evento determinado
asociando un procedimiento con la manifestación de dicho evento.
Un caso clásico en ambientes Microsoft sería el Servicio de Notificación de SQL
Server. Cuando el evento se anuncia, el sistema invoca todos los procedimientos
que se han registrado para él. De este modo, el anuncio de un evento
implícitamente ocasiona la invocación de determinados procedimientos en otros
módulos.
Ejemplo:
• Función en JS que cambia de letras minúsculas a mayúsculas, de un campo en
un formulario en HTML.
Ventajas y Desventajas:
Ventajas:
• 1. Simplicidad
• 2. Evolución: se pueden reemplazar componentes suscriptores.
• 3. Modularidad: una sola modalidad para eventos diversos.
• 4. Puede mejorar la eficiencia, eliminando la necesidad de polling por ocurrencia de
evento.
Desventajas:
• 1. Posibilidad de desborde.
• 2. Potencial imprevisión de escalabilidad.
• 3. Pobre comprensibilidad: Puede ser difícil prever qué pasará en respuesta a
una acción.
• 4. No hay garantía del lado del publicador, que el suscriptor responderá al
evento.
• 5. No hay mucho soporte de recuperación en caso de falla parcial.
4.4 Modelo arquitectónico (Enfoque,
publicación y suscripción).
En un modelo de publicación y suscripción, hay tres componentes:
• Publicadores:
• Puertos de recepción que publican los mensajes que llegan a sus ubicaciones de recepción.
• Orquestaciones que publican mensajes cuando envían mensajes o inician otra orquestación en modo asincrónico.
• Puertos de envío de solicitud-respuesta que publican mensajes cuando reciben una respuesta de la aplicación de destino.
• Suscriptores:
• Suscripción de activación.
• Suscripción de instancia.
• Eventos.
Unidad iv_Arquitectura de software

Contenu connexe

Similaire à Unidad iv_Arquitectura de software

Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
Gustavo Palomo Ureña
 
Ciclo de Vida de los sistemas de Información
Ciclo de Vida de los sistemas de InformaciónCiclo de Vida de los sistemas de Información
Ciclo de Vida de los sistemas de Información
alixindriago2013
 

Similaire à Unidad iv_Arquitectura de software (20)

T2 infoiii-s
T2 infoiii-sT2 infoiii-s
T2 infoiii-s
 
Proceso unificado de desarrollo de software
Proceso unificado de desarrollo de softwareProceso unificado de desarrollo de software
Proceso unificado de desarrollo de software
 
Proceso de software
Proceso de softwareProceso de software
Proceso de software
 
Proceso de software
Proceso de softwareProceso de software
Proceso de software
 
Diagrama Causal en la Aplicación de la Metodología Ágil
Diagrama Causal en la Aplicación de la Metodología ÁgilDiagrama Causal en la Aplicación de la Metodología Ágil
Diagrama Causal en la Aplicación de la Metodología Ágil
 
MAPFRE: Aplicando orientación a eventos en cores de seguros
MAPFRE: Aplicando orientación a eventos en cores de segurosMAPFRE: Aplicando orientación a eventos en cores de seguros
MAPFRE: Aplicando orientación a eventos en cores de seguros
 
S12-DAW-2022S1.pptx
S12-DAW-2022S1.pptxS12-DAW-2022S1.pptx
S12-DAW-2022S1.pptx
 
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
 
Administracion de proyectos
Administracion de proyectosAdministracion de proyectos
Administracion de proyectos
 
Informática: Análisis y Diseño De Sistemas
Informática: Análisis y Diseño De SistemasInformática: Análisis y Diseño De Sistemas
Informática: Análisis y Diseño De Sistemas
 
Modelos de desarrollo del software
Modelos de desarrollo del softwareModelos de desarrollo del software
Modelos de desarrollo del software
 
Unidad III parte 1.pptx
Unidad III parte 1.pptxUnidad III parte 1.pptx
Unidad III parte 1.pptx
 
EDA
EDAEDA
EDA
 
Los 7 pasos del desarrollo de sistemas informaticos
Los 7 pasos del desarrollo de sistemas informaticosLos 7 pasos del desarrollo de sistemas informaticos
Los 7 pasos del desarrollo de sistemas informaticos
 
Procesos de software Unidad 2 - Software Enginnering - Ian sommerville
Procesos de software  Unidad 2 - Software Enginnering - Ian sommervilleProcesos de software  Unidad 2 - Software Enginnering - Ian sommerville
Procesos de software Unidad 2 - Software Enginnering - Ian sommerville
 
Ciclo de Vida de los sistemas de Información
Ciclo de Vida de los sistemas de InformaciónCiclo de Vida de los sistemas de Información
Ciclo de Vida de los sistemas de Información
 
Modelos de Procesos del Software Grupo 1
 Modelos de Procesos del Software Grupo 1 Modelos de Procesos del Software Grupo 1
Modelos de Procesos del Software Grupo 1
 
User stories
User storiesUser stories
User stories
 
Clase2
Clase2Clase2
Clase2
 
Arquitectura del desarrollo del software
Arquitectura del desarrollo del softwareArquitectura del desarrollo del software
Arquitectura del desarrollo del software
 

Dernier (6)

CLASE 1 H.I.pptx,INFORMATICANIVEL AVANZADO
CLASE 1 H.I.pptx,INFORMATICANIVEL AVANZADOCLASE 1 H.I.pptx,INFORMATICANIVEL AVANZADO
CLASE 1 H.I.pptx,INFORMATICANIVEL AVANZADO
 
PRESENTACION SISTEMAS OPERATIVOS MOVILES_20240424_235225_0000.pdf
PRESENTACION SISTEMAS OPERATIVOS MOVILES_20240424_235225_0000.pdfPRESENTACION SISTEMAS OPERATIVOS MOVILES_20240424_235225_0000.pdf
PRESENTACION SISTEMAS OPERATIVOS MOVILES_20240424_235225_0000.pdf
 
La busqueda de la relevancia en la economia (Harberger).pptx
La busqueda de la relevancia en la economia (Harberger).pptxLa busqueda de la relevancia en la economia (Harberger).pptx
La busqueda de la relevancia en la economia (Harberger).pptx
 
La muerte de El Senequita (Amadeo Martinez-Ingles).pdf
La muerte de El Senequita (Amadeo Martinez-Ingles).pdfLa muerte de El Senequita (Amadeo Martinez-Ingles).pdf
La muerte de El Senequita (Amadeo Martinez-Ingles).pdf
 
Vision de asignatura ESTRUCTURA DE DATOS.pptx
Vision de asignatura ESTRUCTURA DE DATOS.pptxVision de asignatura ESTRUCTURA DE DATOS.pptx
Vision de asignatura ESTRUCTURA DE DATOS.pptx
 
Mapa conceptual de el hardware y software
Mapa conceptual de el hardware y softwareMapa conceptual de el hardware y software
Mapa conceptual de el hardware y software
 

Unidad iv_Arquitectura de software

  • 1. Equipo 5 América Libertad García Alarcón Miguel Ángel Merino Martínez David Lucas Bautista Daniel López Rosas
  • 2. 4.3 Conceptos básicos de eventos. • Un evento puede ser definido como "un cambio significativo en un estado“. Estructura del evento: • Encabezado evento. • Cuerpo evento.
  • 3. Capas del flujo del evento: • Generador de evento. • Canal de evento. • Motor de procesamiento del evento. • Actividad de descarga dirigida por evento.
  • 4. Estilos de procesamiento de evento. Hay tres estilos generales de procesamiento de eventos: • Procesamiento simple de evento. • Procesamiento por flujo de evento. • Procesamiento complejo de evento.
  • 5. Arquitectura dirigida por eventos • La Arquitectura dirigida por eventos o EDA, es un patrón de arquitectura de software que promueve la producción, detección, consumo de, y reacción a eventos. Las arquitecturas basadas en eventos se han llamado también de invocación implícita. • Las arquitecturas basadas en eventos se vinculan históricamente con sistemas basados en actores, daemons y redes de conmutación de paquetes (publicación- suscripción).
  • 6. La idea dominante en la invocación implícita es que, en lugar de invocar un procedimiento en forma directa (como se haría en un estilo orientado a objetos) un componente puede anunciar mediante difusión uno o más eventos. Un componente de un sistema puede anunciar su interés en un evento determinado asociando un procedimiento con la manifestación de dicho evento. Un caso clásico en ambientes Microsoft sería el Servicio de Notificación de SQL Server. Cuando el evento se anuncia, el sistema invoca todos los procedimientos que se han registrado para él. De este modo, el anuncio de un evento implícitamente ocasiona la invocación de determinados procedimientos en otros módulos.
  • 7. Ejemplo: • Función en JS que cambia de letras minúsculas a mayúsculas, de un campo en un formulario en HTML.
  • 8. Ventajas y Desventajas: Ventajas: • 1. Simplicidad • 2. Evolución: se pueden reemplazar componentes suscriptores. • 3. Modularidad: una sola modalidad para eventos diversos. • 4. Puede mejorar la eficiencia, eliminando la necesidad de polling por ocurrencia de evento.
  • 9. Desventajas: • 1. Posibilidad de desborde. • 2. Potencial imprevisión de escalabilidad. • 3. Pobre comprensibilidad: Puede ser difícil prever qué pasará en respuesta a una acción. • 4. No hay garantía del lado del publicador, que el suscriptor responderá al evento. • 5. No hay mucho soporte de recuperación en caso de falla parcial.
  • 10. 4.4 Modelo arquitectónico (Enfoque, publicación y suscripción). En un modelo de publicación y suscripción, hay tres componentes: • Publicadores: • Puertos de recepción que publican los mensajes que llegan a sus ubicaciones de recepción. • Orquestaciones que publican mensajes cuando envían mensajes o inician otra orquestación en modo asincrónico. • Puertos de envío de solicitud-respuesta que publican mensajes cuando reciben una respuesta de la aplicación de destino. • Suscriptores: • Suscripción de activación. • Suscripción de instancia. • Eventos.