M a s t e r 2 – i a d N I 2 1 2 – m i n g i n g é n i e r i e o b j e t j a v a u n i v e r s i t é p a r i s 6 p i e r r e & m a r i e c u r i e u f r.

Présentation au sujet: "M a s t e r 2 – i a d N I 2 1 2 – m i n g i n g é n i e r i e o b j e t j a v a u n i v e r s i t é p a r i s 6 p i e r r e & m a r i e c u r i e u f r."— Transcription de la présentation:

1 m a s t e r 2 – i a d N I 2 1 2 – m i n g i n g é n i e r i e o b j e t j a v a u n i v e r s i t é p a r i s 6 p i e r r e & m a r i e c u r i e u f r d’ i n f o r m a t i q u e 1architectures -- applications pilotées par les événementsmingdidier vaudène 2 0 0 8 d i d i e r v a u d è n e 2008 architectures 1 applications pilotées par les événements principe de la séquencialisation des messages interruptions et événements métaphore postale et point de vue procédural schéma simplifié d’une application la boucle d’acquisition des messages le protocole d’acheminement détermination des destinataires l’intervention des composants visuels diffusions broadcast et par abonnement classification des appels

2 mingdidier vaudène 2architectures -- applications pilotées par les événements2008 principe de la séquentialisation des messages côté systèmecôté application le traitement à destination des applications est différé l « messages » endogènes postés l produits par l’application elle-même l traitement différé l gestion générale des applications par le système l coopération et communications entre applications l gestion interne du système sur interruptions l ne produit pas directement des messages destinés aux applications l gestion des équipements sur interruption l produisent des messages dans la file d’attente l prise en compte différée dans l’application l confinement de la gestion des interruptions dans le système l séquentialisation des messages via la file d’attente de l’application

3 mingdidier vaudène 3architectures -- applications pilotées par les événements2008 interruptions et événements l côté système, tout de suite : l’événement est enregistré comme « message » le « message » est placé dans une file d’attente l côté application, plus tard : le « message » est extrait de la file d’attente le « message » sert à déclencher le traitement associé l comme effectivité accomplissement d’une action ou d’un traitement l comme descripteurs [d’événements] les « messages » enregistrés, photographiés, congelés, etc. pour attendre dans la file d’attente gestionnaire d’interruption gestionnaire d’événement côté systèmecôté application

4 mingdidier vaudène 4architectures -- applications pilotées par les événements2008 le cheminement d’une analogie l appel différé : l’événement est enregistré comme « message » plus tard, le gestionnaire opère avec le « message » appel immédiat du point de vue de l’appelé : un appel de procédure est comme l’acheminement d’un « message » l’acheminement d’un « message » est comme un appel de procédure appel différé l appel immédiat : l’appelant empile les paramètres d’appel l’appelé opère avec les paramètres les paramètres d’appel sont « comme » un message les messages sont « comme » des paramètres d’appel

5 mingdidier vaudène 5architectures -- applications pilotées par les événements2008 la métaphore postale et le point de vue procédural l métaphore postale tout est vu comme « envoi de messages »… par exemple : SmallTalk l’accent est porté sur le message lui-même l’acheminement est [relativement] mis entre parenthèses source émetteur appelant récepteur destinataire appelé l … mais tout est en fait procédural : envoi immédiat = appel de procédure envoi différé = message posté l il n’y a jamais que des appels de procédures plus ou moins « distants » : pas de calcul = immédiat + liaison statique : appel statique (compilé) peu de calcul = immédiat + liaison dynamique : appel virtuel (redéfinition) plus de calcul = immédiat/différé + dynamique : appel « hyper-virtuel »

6 mingdidier vaudène 6architectures -- applications pilotées par les événements2008 qu’est-ce qu’une architecture « event-driven » ? dans une architecture pilotée par les événements, programmer une application c’est répondre à des événements gestionnaires apparents système, middleware librairie d’exécution, composants standard application pilotée par les événements l côté système tout est transformé en « technologie événementielle » l côté application (1) tout est relayé en « technologie événementielle » librairies d’exécution, composants standard, etc. l côté application (2) la partie apparente se borne à compléter les « trous » gestionnaires d’événements tous protocoles

7 mingdidier vaudène 7architectures -- applications pilotées par les événements2008 structure globale d’une architecture event-driven dans une architecture event-driven, c’est l’utilisateur qui réalise au vol le schéma de contrôle de l’application programmation apparente de l’application l’application comme logiciel schéma de contrôle global de l’application système + librairies d’exécutions + composants standard globalement homogènes à un protocole d’appel de procédure une commande utilisateur est globalement homogène à un appel de procédure

8 mingdidier vaudène 8architectures -- applications pilotées par les événements2008 schéma simplifié d’une application event-driven gestionnaires d’événements event handlers, listeners, etc. boucle d’acquisition des messages séquentiellement, un à un file d’attente des messages gestion grosso modo fifo « message pump » protocole de diffusion et d’acheminement détermination du destinataire + traitements standard, comportements automatiques système vous avez dit « événements » ? des procédures que l’application apparente n’appelle pas mais qui sont effectivement exécutées

9 mingdidier vaudène 9architectures -- applications pilotées par les événements2008 la boucle d’acquisition des messages l extraction/diffusion : déterminer tous les destinataires du message répéter extraire le premier message diffuser ce message jusqu’à ce que l’application soit terminée la diffusion d’un message est globalement homogène à un appel de procédure si la file est vide alors idle attendre qu’il y ait un message l traitement « idle » (tranquille) : traitements de fond pas trop longs qui peuvent attendre relâchement du processeur si la file d’attente est vide

10 mingdidier vaudène 10architectures -- applications pilotées par les événements2008 exemples de programmes principaux d’applications program Jiminy ; uses … ; begin Application.Title := 'Jiminy'; Application.Initialize; Application.CreateForm(TJiminyForm, JiminyForm); Application.Run; end. namespace ming.events ; public class MainForm : Form { InitComponent() ; } public static void Main() { Application.Run( new MainForm() ) ; } programme principal en Delphi programme principal en C# public class MainForm extends javax.swing.JFrame { public MainForm() { initComponents(); } public static void main(String args[]) { java.awt.EventQueue.invokeLater(new Runnable() { public void run() { new MainForm().setVisible(true); } }); } programme principal en Java/NetBeans

11 mingdidier vaudène 11architectures -- applications pilotées par les événements2008 canevas de la méthode Run en Delphi/Kylix procedure TApplication.Run ; var msg TMsg ; begin FRunning := true ; try finally FRunning := false end {try} ; end {run} ; { Boucle de traitement des messages } repeat try except HandleException(self) end {try} ; until FTerminate ; { Acquérir un message } if PeekMessage(msg, 0, 0, 0, PM_REMOVE) then begin end else Idle ; if msg.message = WM_QUIT then FTerminate := true else begin end {else} ; extraire le prochain message de la file des messages code du message demandant la terminaison de l’application diffuser et acheminer le message tout en recherchant ses destinataires traitements de fond quand l’application n’a rien d’autre à faire récupérer les exceptions non traitées par l’application TMsg = record hwnd : HWND ; message : longint ; wParam : longint ; lParam : longint ; time : DWORD ; pt : TPoint ; end ; TranslateMessage( msg ) ; DispatchMessage ( msg ) ;

12 mingdidier vaudène 12architectures -- applications pilotées par les événements2008 la diffusion et l’acheminement des messages ce message est destiné à ses destinataires ! code événement : 1534 arg. 1 = 125 arg. 2 = 167FDE80 qui en veut ? le producteur d’un message effectue une notification : commande, action, changement d’état, etc. généralement, le producteur d’un message ignore à qui s’adresse le message les destinataires sont dynamiquement déterminés par le protocole de diffusion et d’acheminement le protocole assure à la fois : la recherche des destinataires la diffusion des messages l’acheminement des messages ?

13 mingdidier vaudène 13architectures -- applications pilotées par les événements2008 diffusion 1 – 1 statique ou dynamique diffusion 1 – plusieurs sur abonnement abonnement explicite diffusion aux seuls abonnés diffusion 1 – plusieurs « broadcast » pas d’abonnement diffusion potentielle à tous les composants d’une structure existante + optimisations + filtrages abonnement et diffusion « broadcast » appel de procédure ou de méthode listeners à base d’interfaces event handlers à base de méthodes distributeur d’appels réalisation par appels de méthodes récursif + itératif combinaisons abonnement et broadcast selon opportunités liste des abonnés

14 mingdidier vaudène 14architectures -- applications pilotées par les événements2008 articulation avec les composants visuels arbre de composants selon l’ardre z l traits caractéristiques des composants visuels : structure organisées en arbre selon l’ordre z « gros clients » de la technologie événementielle souvent requis pour la détermination des destinataires des messages zone de diffusion style « broadcast » zone de diffusion style « abonnement » l structure hautement dynamique à diverses facettes traitement progressif et multiple des messages combine diffusion, acheminement et détermination des destinataires affichage, contrôle, filtrage, etc. l combinaison avec une diffusion par abonnement gestion événementielle apparente : programmation des applications

15 mingdidier vaudène 15architectures -- applications pilotées par les événements2008 classification des appels (1) l un message peut déclencher plusieurs gestionnaires protocole de diffusion « broadcast » sous-protocoles d’abonnements, listeners, etc. l un gestionnaire peut appeler d’autres procédures c’est toujours globalement homogène à un appel de procédure appels immédiats

16 mingdidier vaudène 16architectures -- applications pilotées par les événements2008 classification des appels (2) l un gestionnaire peut diffuser un autre message directement (explicitement) ou indirectement (par ricochet) déclenche le protocole de diffusion (appel de procédure) la diffusion est immédiate l appel immédiat « hyper-virtuel » c’est toujours globalement homogène à un appel de procédure 1 12 attention aux récursions sans fin

17 mingdidier vaudène 17architectures -- applications pilotées par les événements2008 classification des appels (3) l un gestionnaire peut poster un autre message directement (explicitement) ou indirectement (par ricochet) l le dépôt du message est immédiat l la diffusion et le traitement sont différés l appel différé « hyper-virtuel » c’est toujours globalement homogène à un appel de procédure 1 1 2